agentleFS
Sign inStart free
aiagentkit-labsaiagentkit-labs/agentic-dev-kit/skills/ado-implement/SKILL.md

ado-implement

Skill0 starsChanged 26 days agoMITView on GitHub

Legacy Azure DevOps entry point for implementing a work item through the provider-neutral implementation workflow. Use when the user mentions ADO, Azure Boards, AB# IDs, or an Azure DevOps work-item URL.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use the first channel that works:

    line 14
  2. Very specific:

    az CLI: if MCP is unavailable or can't authenticate.

    line 17

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Azure DevOps compatibility entry point

This skill remains installed so existing /ado-implement commands and ADO-specific discovery keep working. The canonical workflow is implement; follow it for every gate, test, review, PR, and hand-back. Do not use a separate ADO-only process.

When the user provides an ADO URL or AB#<id>, use the Azure DevOps connection rules below to load the task, then pass its source metadata and available capabilities into the generic task record. If ADO tools are unavailable, ask the user to paste or export the item text and continue through implement's text/file path. Never claim tracker updates or PR linking unless the connected ADO integration supports them.

Connect to Azure DevOps

Use the first channel that works:

  1. Azure DevOps MCP tools (core_list_orgs, wit_work_item, repo_pull_request_write, …) from the hosted server. Pass the organization on every call. Resolve it from the user message, an ADO remote, or ask the user to select from core_list_orgs. The client handles Microsoft Entra sign-in.
  2. az CLI if MCP is unavailable or can't authenticate. Configure az devops configure --defaults organization=<url> project=<name>. Sign in with az login, or a PAT the user exports as AZURE_DEVOPS_EXT_PAT in their own terminal.

The ADO integration may read and update work items, create child items, and link PRs only when those capabilities are exposed. Ask before every ADO write as required by implement.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free