MicrosoftKnown publishermicrosoft/devsquad-copilot/.github/plugins/devsquad/skills/adr-workflow/SKILL.mdadr-workflow
Skill50 starsChanged 16 days agoMITView on GitHub
Complete workflow for creating and managing ADRs (Architecture Decision Records). Includes duplicate checking, status determination, Microsoft documentation lookup, Azure cost estimates, and completeness validation. Use when you need to create or update ADRs during planning. Do not use for decisions that don't need an ADR (use conventions in plan.md).
We split this skill into the rules it gives an agent
14 rules. 0 are common, 9 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Before creating any ADR, check if an ADR already exists in the same domain.
- Distinctive: line 12
If a Proposed ADR exists: recommend reviewing and accepting the existing one before creating a new one.
- Distinctive: line 13
If an Accepted ADR exists: if the decision has changed, use "Superseded by NNNN".
- Distinctive: line 19
If no existing ADR exists in the domain:
- Distinctive: line 30
Never invent options from templates, generic READMEs, or placeholder content.
- Very specific: line 35
Use microsoft_docs_search to look up limits, SLAs, pricing tiers, comparisons
- Very specific: line 36
Use microsoft_docs_fetch for full content of relevant pages
- Very specific: line 40
Use azure/pricing when cost is a ranked priority or the user asks about pricing
- Distinctive: line 41
Do not block creation if the tool is unavailable: record "pricing not verified"
- Very specific: line 44
Use azure/cloudarchitect (design) for Azure architecture recommendations
- Very specific: line 45
Use azure/deploy (architecture diagram) for Mermaid topology diagram
- Distinctive: line 53
Use the decision domain, not the choice made (e.g., "Data Persistence", not "Use PostgreSQL")
- Distinctive: line 58
Before considering the ADR complete, verify:
- Distinctive: line 64
If there are missing fields, request information from the user.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Creation Flow
1. Check for duplicates
Before creating any ADR, check if an ADR already exists in the same domain.
If a Proposed ADR exists: recommend reviewing and accepting the existing one before creating a new one. If an Accepted ADR exists: if the decision has changed, use "Superseded by NNNN".
Options: [R] Review existing / [S] Supersede (create new ADR) / [C] Create separate (different domain).
2. Determine status
If no existing ADR exists in the domain:
[A]Decision already made: ask for the final decision and options considered. Create with Accepted status (but recommend Proposed for team review).[B]Needs discussion: ask for options to consider. Create with Proposed status.
3. Options and recommendations
Options preferably come from the user. Offer suggestions only if:
- The user explicitly asks
- The user has no options or has only 1
Never invent options from templates, generic READMEs, or placeholder content.
4. Tool consultation (when available)
Microsoft Documentation (for decisions involving Microsoft/Azure services):
- Use
microsoft_docs_searchto look up limits, SLAs, pricing tiers, comparisons - Use
microsoft_docs_fetchfor full content of relevant pages - Incorporate data into the ADR options evaluation
Azure Cost Estimate (if Azure MCP Server is available):
- Use
azure/pricingwhen cost is a ranked priority or the user asks about pricing - Do not block creation if the tool is unavailable: record "pricing not verified"
Azure Cloud Architect (if Azure MCP Server is available and the project deploys to Azure):
- Use
azure/cloudarchitect(design) for Azure architecture recommendations - Use
azure/deploy(architecture diagram) for Mermaid topology diagram - Present as options for the ADR, not as a final decision
- Options:
[S]Incorporate /[M]Modify first /[I]Ignore
5. Format and naming
- Template:
docs/architecture/decisions/ADR-TEMPLATE.md - Naming:
NNNN-domain.md(e.g.,0001-data-persistence.md) - Use the decision domain, not the choice made (e.g., "Data Persistence", not "Use PostgreSQL")
- Sequential numbering (0001, 0002, etc.)
6. Completeness validation
Before considering the ADR complete, verify:
- Context filled in
- At least 2 options documented
- Decision with justification
- Pros and cons for each option
If there are missing fields, request information from the user.
Common Rationalizations
| Rationalization | Reality |
| "ADRs are overhead" | A 10-minute ADR prevents a 2-hour debate about the same decision six months later. |
| "The code is self-documenting" | Code shows what was built. It does not show why, what alternatives were rejected, or what constraints applied. |
| "We will document the decision later" | Decisions made without records get re-debated. Later never comes. |
| "Nobody reads ADRs" | Future agents read them to avoid re-deciding. Future engineers read them to understand context. |
| "This decision is obvious, no ADR needed" | Obvious decisions still have alternatives. Recording the reasoning prevents someone from proposing the discarded alternative later. |
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- ramboz/jig★ 7same name
- SecuringTheRealm/str-agentic-adventures★ 4same name
- gabrielbauman/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository26 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- .github/plugins/devsquad/hooks/templates/.github/copilot-instructions.mdCopilot instructions
- board-configSkill
- complexity-analysisSkill
- debugging-recoverySkill
- deep-clarificationSkill
- diagram-designSkill
- documentation-styleSkill
- domain-glossarySkill
- engineering-practicesSkill
- git-branchSkill
- git-commitSkill
- harness-learningsSkill
- init-configSkill
- init-docsSkill
- init-scaffoldSkill
- lsp-setupSkill
- next-taskSkill
- pull-requestSkill
- quality-gateSkill
- reasoningSkill
- security-reviewSkill
- test-disciplineSkill
- triage-workflowSkill
- work-item-creationSkill
- work-item-workflowSkill
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
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.