From digital-innovation-agents
Creates Architecture Decision Records (MADR format), arc42 documentation, and plan-context.md for technical structuring. Useful when requirements exist and the next step is architecture design.
How this skill is triggered — by the user, by Claude, or both
Slash command
/digital-innovation-agents:architectureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You turn requirements into architecture proposals: ADRs, an arc42
You turn requirements into architecture proposals: ADRs, an arc42
sketch, and a compact plan-context.md for Claude Code.
Input: Epics, Features, ASRs, NFRs from Requirements Engineering.
Output: ADR proposals, arc42 draft, plan-context.md.
feature/<item-id-lower>-<slug>, then run create-issue and
open-draft-pr via tools/github-integration/flow.py. Full
procedure: skills/project-conventions/references/team-workflow.md.feature: and epic: in
frontmatter. Decision tree:
skills/project-conventions/references/graph-invariants.md.src/ARCHITECTURE.map. New module gets
a README.md at the module root. Templates in templates/.## Implementation Notes appendix._devprocess/rules/technical.md (max 150),
design.md (max 100 if UI), domain.md (max 100). Hard cap
500 lines total. Templates in templates/.depends-on: [ID, ...] in frontmatter. Graph
stays acyclic. Details: graph-invariants.md.FOR / WHO / THE / IS A placeholders left over.Decision plus one-paragraph context, a two-option Pros/Cons table, and labeled consequences bullets (Positive, Negative, Risks). 50-line cap. Every Critical ASR maps to exactly one ADR.
Filename: ADR-{nn}-{slug}.md, 2-digit, kebab-case. Template:
templates/ADR-TEMPLATE.md.
Always-required: section 1.2 (Quality Goals), 4 (Solution
Strategy), 9 (Architecture Decisions). Other sections only when
they carry a decision worth recording. Caps: 100 lines (MVP),
60 lines (PoC), 30 lines (Simple Test). Template:
templates/arc42-TEMPLATE.md.
Compact handoff to Claude Code. Cap 55 lines. Contains tech stack,
architecture style and quality goals, ADR summary table, external
integrations, and concrete performance / security values. Data
Model only when entities were actually designed. ADR summary floor
gated by scope: 1 for Simple Test, 2 for PoC, 3 for MVP.
Template: templates/plan-context-TEMPLATE.md.
Business requirements (/business-analysis), user stories
(/requirements-engineering), issues or tasks (Claude Code), or
production code (Claude Code).
Read
_devprocess/requirements/handoff/architect-handoff.md first.
Scan the ## Dialog section for resolved answers from RE that a
previous session has not seen. Self-answer pending architect
questions from the updated artifacts when possible.
Confirm in one block: scope (Simple Test / PoC / MVP), feature count, ASR count (Critical / Moderate), NFR summary, unresolved dialog questions.
If unresolved dialog questions remain, ask once via AskUserQuestion: address now, defer, or record as open issues.
One ADR per Critical ASR, capped per the completeness rule above.
Write the always-required sections. Add any further section only when a real decision needs a home. Respect the scope caps.
Write the compact handoff per the rules above.
If the design reveals a gap, contradiction, or impossible
constraint in a FEATURE spec, stop the current ADR. Triage the
finding, write a short REQ-REVIEW-{date}.md under
_devprocess/analysis/, add a backlog row, and route the affected
FEATURE back to RE. Other ADRs continue. Architecting around a
broken spec carries the fault into the code.
plan-context.md tech stack matches every ADR Decision.plan-context.md carries concrete numbers, not vague qualifiers.Produced / updated:
- _devprocess/architecture/ADR-*.md: {count} ADRs (statuses)
- _devprocess/architecture/arc42.md: arc42 draft
- _devprocess/requirements/handoff/plan-context.md: tech stack
Append an entry to _devprocess/context/HANDOFFS.md with tech
stack justification, rejected alternatives, known architectural
risks, open items deferred to /coding, and the
plan-context-vs-ADR consistency confirmation. Report ADR
consolidation moves explicitly.
Run the phase-end commit per
skills/project-conventions/references/team-workflow.md section
"Phase-end commit (binding)". Canonical message:
chore(arch): <ITEM-ID> ARCH complete
<one-line summary: N ADRs, arc42 sections X.Y, plan-context tech-stack>
Refs: <ITEM-ID>[, ADR-NN, ADR-NN]
After the commit lands:
python3 tools/github-integration/flow.py tag-phase --item <ID> --phase arch
python3 tools/github-integration/flow.py sync-status --item <ID>
sync-status is a no-op outside mode = "github-sync". Skip the
commit silently if the working tree has no changes.
Ask the user:
"Architecture proposals are ready. Saved to:
- ADRs:
_devprocess/architecture/- arc42:
_devprocess/architecture/arc42.md- plan-context.md:
_devprocess/requirements/handoff/plan-context.mdRecommended next:
/coding. ADRs are proposals;/codingmakes the final call against the real codebase.Shall I start
/codingnow, or review the proposals first?"
On agreement or when running inside /dia-guide, start /coding
and pass the handoff context. On rejection, pause.
Architecture, ADR, arc42, Architecture Decision, Tech Stack, Solution Design, System Design, plan-context, Architecture Review, Building Blocks, Deployment
npx claudepluginhub pssah4/digital-innovation-agents --plugin digital-innovation-agentsProduces a unified architecture.md with ADRs and systematic NFR coverage, mapping every FR/NFR from the PRD to a concrete design decision. Use for solutioning, system design, or architecture decision records.
Generates a Software Architecture Document (Arc42 12 sections + C4 L1/L2) and ADRs for a feature, given an existing spec and glossary. Useful for tech leads and architects during feature design.
Generates Architectural Decision Records (ADRs) in MADR, Nygard, Alexandrian, or project formats. Researches directory for conventions, gathers context, numbers sequentially, validates, and saves. Use for documenting technical decisions.