Setup Help
Connect your agent to Azure DevOps with your own account and fix corporate certificate errors.
Use this when you already have access to this repository and want an agent to use the Azure DevOps PBI skill.
You only need access to the Azure DevOps project configured for this repository. You do not need to know about or have access to any other contract project.
Fast Path
From the repository root, use the GitHub Copilot setup unless you know you are using a different agent:
scripts/setup-azure-devops-pbi-skill.sh copilot /path/to/project-repo
The setup command:
- Installs the Azure DevOps PBI skill for your agent.
- Checks whether Azure CLI is available.
- Installs the Azure DevOps CLI extension if it is missing.
- Starts
az loginif you are not signed in. - Reads the Azure DevOps project from
skills/azure-devops-pbi/references/project-profile.md. - Configures that Azure DevOps project.
- Runs a read-only access check for that project only.
When the team enables the hosted analytics dashboard, the skill can write safe agent-analytics:v1 metadata to Azure Boards discussion comments. The user's normal Azure Boards access is enough for this metadata path; dashboard collector credentials must never be committed to this repository or distributed to local agent installs.
The setup path is not Codex-only. Codex, Cursor, GitHub Copilot, Claude-style agents, and future hosts should all use the same committed skill and Agent Analytics Metadata Contract. Host-specific wrappers are optional convenience layers; they must not require local dashboard API credentials or a separate metadata schema.
For Codex:
scripts/setup-azure-devops-pbi-skill.sh codex
For Cursor:
scripts/setup-azure-devops-pbi-skill.sh cursor /path/to/project-repo
Authentication Model
The setup uses normal Azure CLI browser login with your own work account:
az login
It does not require a shared PAT. Use a personal access token only when normal az login is not available, and keep that token local to your machine.
If Setup Cannot Finish
If Azure CLI is missing, install it and rerun the setup command:
If setup fails while installing the Azure DevOps CLI extension with SSLCertVerificationError, the problem is usually local certificate trust for Azure CLI/Python, not Azure DevOps project access. This often happens on networks that use Zscaler or another TLS inspection proxy.
Useful checks:
az extension add --name azure-devops --debug
echo "$SSL_CERT_FILE"
echo "$REQUESTS_CA_BUNDLE"
If your organization uses Zscaler or similar TLS inspection, Azure CLI may need SSL_CERT_FILE and REQUESTS_CA_BUNDLE pointed at a certifi bundle that includes the company root CA. Some Node-based tools may also need NODE_EXTRA_CA_CERTS pointed at the company root CA.
Example shape only; use your organization's certificate guidance and do not copy another user's private local path:
export NODE_EXTRA_CA_CERTS="$HOME/.certs/zscaler-root-ca.pem"
export SSL_CERT_FILE="$HOME/.certs/certifi-zscaler-bundle.pem"
export REQUESTS_CA_BUNDLE="$SSL_CERT_FILE"
Do not disable SSL verification as the primary fix. If you do not already have the company root CA or certificate bundle, ask IT for Azure CLI/Python certificate trust guidance.
If Azure login opens a browser, sign in with your normal work account. If project or Boards access fails for your assigned project, ask the project admin to confirm that your account has access to the right Azure DevOps project.
Do not try a different Azure DevOps project to work around an access failure. Use the project configured in this repository unless a project admin tells you otherwise.
You can rerun only the read-only access check at any time:
scripts/check-azure-devops-access.sh
If a project admin tells you to use a different project, you can pass it explicitly:
scripts/setup-azure-devops-pbi-skill.sh copilot /path/to/project-repo --project <project>
scripts/check-azure-devops-access.sh <project>
Credentials
Use your own Azure DevOps identity. Repo access does not provide shared Azure DevOps credentials or permissions to other Azure DevOps projects.
Do not put shared PATs, tokens, passwords, or service credentials in this repo.
Prefer normal az login. Use a personal access token only when normal login is not available. If a PAT is needed, it must be user-owned, scoped only to what that user needs, stored locally, and never committed or shared. A PAT does not fix certificate verification failures while Azure CLI is downloading extensions.
Microsoft's Azure DevOps CLI docs cover both az login and PAT fallback: Sign in with a personal access token.
What To Tell The Agent
Once setup passes, give the agent the work context and a parent Feature/Epic when possible:
Create the PBI for this work under Feature 12345.
If the agent cannot identify the parent Feature/Epic safely, it should ask instead of guessing.