The official GitHub Certified: Agentic AI Business Professional syllabus, organized by domain. Check off each point as you review it.
Inicia sesión para guardar tu progreso entre sesiones.
Apply GitHub management best practices and policies
User-level budgets cap each person and always enforce a hard stop; cost center, organization and enterprise budgets limit metered charges and only block when the stop-usage setting is enabled. They work together: whichever has the least headroom blocks first, and a higher budget never extends a user-level budget.
Budgets for usage-based billing ↗Getting started with budget controls ↗
Each interaction consumes input, output and cached tokens, priced according to the model. To reduce them, match the model to the task, write clear prompts with a stopping condition, keep context lean with new conversations or /compact, enable only the tools you need, and avoid changing model or reasoning mid-session.
Optimizing your AI usage to maximize efficiency and reduce cost ↗Usage-based billing for organizations and enterprises ↗
Organization custom instructions share language, security or compliance guidance with all members, but they do not guarantee compliance. To enforce standards, use rulesets and CODEOWNERS, which also bind Copilot, and organization-level custom agent profiles for consistent configuration.
Custom instructions for GitHub Copilot ↗Building a secure cloud environment for agents in your enterprise ↗
Secret scanning detects exposed credentials, and the priority after an alert is to rotate them; push protection blocks them before they reach the repository. Copilot cloud agent only receives Agents secrets, not Actions secrets, and those with the COPILOT_MCP_ prefix are reserved for MCP servers.
Secret scanning ↗Configure secrets and variables for Copilot cloud agent ↗
Copilot policies control features and models; when a user has licenses from several organizations, the least restrictive usually applies. Content exclusion makes Copilot ignore files, and Copilot cloud agent offers traceability: co-authored commits, session logs and mandatory human review before merging.
GitHub Copilot policies for enterprises and organizations ↗Risks and mitigations for GitHub Copilot cloud agent ↗
Microsoft defines six principles: fairness, reliability and safety, privacy and security, inclusiveness, transparency and accountability. With Copilot they translate into human oversight, avoiding overreliance, reviewing and testing what the agent produces, and taking extra care with consequential decisions or sensitive domains.
What is Responsible AI? ↗Application card: GitHub Copilot Agents ↗
GitHub flow uses one branch per set of unrelated changes and pull requests to review them. Branch protection rules and rulesets require reviews or checks; several rulesets can layer, and the most restrictive version of a rule applies. Copilot is also subject to them.
The model chosen in GitHub Copilot influences the quality and relevance of a response: some offer lower latency, others fewer hallucinations or deeper reasoning. To explain and check a result, review the links to the context used, see which models took part and always keep human review, because no model guarantees accuracy.
AI model comparison ↗Application card: GitHub Copilot Chat ↗
Choose a model by task, not by name: general-purpose models are a good default, fast models suit simple questions, deep reasoning models suit complex analysis and multimodal models handle images. If you prefer not to decide, auto model selection routes each prompt. Availability depends on your plan, your client and your organization's policies.
AI model comparison ↗About GitHub Copilot auto model selection ↗
Custom instructions are persistent guidance applied automatically within their scope. Prompt files are reusable templates that you invoke yourself for a specific task. Agent skills are folders with a SKILL.md file, and sometimes scripts or templates, that Copilot loads when relevant. Instructions guide the model but do not guarantee that it follows every rule.
Comparing Copilot customization features ↗Copilot customization cheat sheet ↗
Use an MCP server when Copilot needs information from an external system or must act in another service, and avoid it when built-in tools are enough. MCP provides the connection, while a skill can describe how to use it. Review third-party servers, enable only the tools needed, preferably read-only, and remember that Copilot cloud agent uses these tools without asking for approval.
Model Context Protocol (MCP) ↗Comparing Copilot customization features ↗
Plan and manage work
A project can start blank, from a built-in GitHub template or from an organization template, and recommended templates are suggested first. A template or a copy carries over views, custom fields, draft issues, configured workflows except auto-add ones, and insights, but a copy does not keep the original items, collaborators or team and repository links.
Creating a project ↗Managing project templates in your organization ↗
Each project view can use a table, board or roadmap layout, with its own filters, grouping and sorting. On a board, columns come from a single select or iteration field, and column limits only warn. Built-in workflows update status and add or archive items, while custom date, number, text, single select and iteration fields enrich the data.
Customizing the board layout ↗Using the built-in automations ↗
In an organization project, the base role sets general access and can be complemented by read, write or admin roles for teams and individuals. The base role does not affect owners or people with individual access. Public or private visibility applies only to the project itself: viewing an item from a private repository requires access to that repository.
Managing access to your projects ↗Managing visibility of your projects ↗
Issues track tasks, bugs and ideas, and can be created from a repository, a comment or a line of code. Sub-issues build hierarchies, dependencies mark blockers and labels classify work inside each repository: the triage role can apply labels and assign issues, but creating or editing labels requires write access.
GitHub offers several collaboration channels: issues for tasks and bugs with a clear owner, pull requests for proposing and commenting on changes, and GitHub Discussions for open conversations, announcements and polls. Mentions alert people and teams, and Copilot helps summarize long threads in issues and discussions.
Track and capture work
A pull request proposes merging a compare branch into a base branch and brings together conversation, checks and changed files. A draft shares work in progress that cannot be merged and does not request code owner reviews. Without write access you start from a fork, and templates and Copilot summaries help give reviewers context.
Assignees show who is working on a pull request, which differs from reviewers, who are asked for feedback. You can assign people with write permissions, anyone who has commented and organization members with read access, one at a time or in bulk. Teams can distribute reviews automatically with round robin or load balance routing.
Assigning issues and pull requests to other GitHub users ↗Managing code review settings for your team ↗
Linking a pull request to an issue shows that work is in progress and closes the issue on merge into the default branch. You link with keywords in the description, which are ignored for any other target branch, or manually with write permissions from the sidebar; only the issue sidebar accepts a pull request from another repository.
A project is fed by issues and pull requests added individually, in bulk or through the auto-add workflow, which does not include existing items. Draft issues exist only in the project until converted to issues. Linking a project to a repository lists it there, provided that both have the same owner.
Adding items to your project ↗Adding your project to a repository ↗
A repository wiki hosts long-form documentation, while the README summarizes the project. You edit it on GitHub or locally, because it is a Git repository: every change is a commit you can compare and revert. It follows the visibility of the repository, and by default only people with write access can edit it. If search engines must index the content, use GitHub Pages.