architecture-change
Coordinate a traceable architecture change from an idea or stakeholder use case through Business Decision Records, Architecture Design Documents, C4 views, Architecture Decision Records, implementatio
SKILL.mdskills/architecture-change/SKILL.md
GitHubArchitecture Change
Coordinate the lifecycle and use focused skills to author artifacts.
Workflow
- Read the target repository's root
AGENTS.md. Whenproject_nameis supplied, load the exactprofiles/<project_name>/profile.yaml, its configured projectAGENTS.md, and document instructions from the toolkit before authoring artifacts; reject unknown projects. Also readarchitecture/toolkit-profile.yamlwhen present, repository sources, existing artifacts, and stakeholder evidence. The target repository's root instructions remain authoritative. - Resolve the starting point and change slug. Do not recreate an artifact already supplied by reference.
- Use
$idea-taskonly when the problem or intended outcome is still ambiguous. - Use
$generate-bdrbefore or alongside use-case discovery when an authoritative business choice is required. An accepted BDR may authorize or constrain multiple use cases. - Use
$generate-use-case; requireReviewedbefore architecture baselining. - Use
$generate-addfrom reviewed upstream artifacts and source evidence. - Use
$generate-c4only for views that answer concrete stakeholder questions. - Use
$generate-adronce per independently changeable decision. - Reconcile the ADD, BDR impacts, and target-state C4 views after ADR acceptance.
- Use
$prepare-taskto create one or more implementation-ready task specifications. Do not mark a task ready while a blocking decision or compliance question remains open. - After implementation, use
$review-architecture-conformance; use$security-reviewwhen required by the risk or project profile, and$azure-reviewwhen Azure is in scope. Resolve or explicitly govern deviations and findings. - Before an AI solution release or formal gate, use
$ai-solution-final-reviewto synthesize current evidence and recommend readiness without inferring approval.
Read references/artifact-contract.md when creating, linking, or changing lifecycle state for any artifact.
Gates
- Label material claims
Confirmed,Assumption,To verify, orUnknown. - Apply the project profile and applicable privacy, AI, security, safety, accessibility, and sector rules. Stop on unresolved conflicts.
- Never put regulated records, credentials, secrets, or sensitive operational details in artifacts.
- Never infer approval or authority.
- Architecture work does not authorize implementation or external task creation unless the user requests it.
Completion
Report artifact paths and states, traceability gaps, accepted versus proposed decisions, specialist-review status, governance outcome, task or release readiness, and the next responsible action.