skills/team/qraspi-architecture/SKILL.md
QRASPI Architecture phase -- lock the path-dependent decisions for a NEW system as MADR ADRs with alternatives, draw the C4 Context + Container in Mermaid, and specify the required fitness functions. Use for "/qraspi-architecture <project>", "write the ADRs for new X", "what architecture for new X", "C4 for new system X", "lock the stack decisions for X". This is where the picks happen, behind ADRs the human aligns on. Do NOT use to review or critique an EXISTING system's architecture (use architecture-review). Do NOT use for retrospective ADR journaling (use architecture-journal). Do NOT use to design a feature in an existing codebase (use qrspi-spec). Do NOT use for the deprecated RPI workflow.
npx skillsauth add michaelalber/ai-toolkit qraspi-architectureInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
"Architecture represents the significant decisions, where significance is measured by cost of change." -- Adapted from Grady Booch
The Architecture phase is where greenfield finally chooses. Research mapped the landscape and
refused to pick; Architecture locks the path-dependent decisions -- the ones expensive to reverse
once code exists -- as MADR ADRs with real alternatives, then makes each decision executable by
specifying the fitness function that will gate it in CI. The failure mode this phase prevents is the
fait-accompli ADR: a record that rationalizes a decision already made instead of weighing options
the human can redirect. So every ADR carries >= 2 considered options, is written proposed,
presented, and set accepted only after the human aligns -- the greenfield analog of qrspi-spec's
"brain surgery" gate. An ADR that names a measurable quality attribute without a fitness function is
an intention with no teeth; this phase requires both. For high-domain-complexity systems an optional
pre-step invokes domain-model (no 7th phase -- it folds in here).
Non-Negotiable Constraints:
research.md (status: complete) on disk; never design from
memory. The ADR alternatives come from research's "Options on the table".status: proposed, STOP and present, loop on the human's
redirection; set status: accepted only after approval (adrs_aligned: true)= 1 specified fitness function;
fitness_functions_specifiedMUST be > 0 (authoring delegates to thefitness-functionsprimitive, which lands them as CI gates in Skeleton)
architecture.md with progress and
tell the user to start a fresh session.PRE-FLIGHT
[ ] Locate the project folder thoughts/shared/qraspi/YYYY-MM-DD-{slug}/
[ ] Read research.md (status: complete). If absent -> STOP; route the user to /qraspi-research
[ ] Read the answered questions.md for quality attributes + hard constraints
[ ] OPTIONAL: high domain complexity? -> invoke domain-model -> CONTEXT.md the ADRs reference
[ ] Determine adr_dir: default <target-repo>/docs/adr/ (overridable via --adr-dir / frontmatter)
DRAFT (decisions as PROPOSED ADRs)
For each path-dependent decision behind research's "Options on the table":
write a MADR ADR (references/adr-template.md), NNNN-kebab-title.md, >= 2 Considered Options,
status: proposed
Draft architecture.md: summary + C4 Context & Container in Mermaid (references/c4-conventions.md)
+ a fitness-function spec index (references/fitness-spec.md)
ALIGN & LOOP (the "brain surgery" gate -- mirrors qrspi-spec)
Present the proposed ADR set + C4. STOP. The human redirects -> revise -> re-present.
Loop until approved. Only THEN set each ADR status: accepted; adrs_aligned: true.
FITNESS SPEC (required output)
For every accepted ADR naming a measurable quality attribute, specify >= 1 fitness function in
architecture.md (references/fitness-spec.md): attribute, threshold, candidate tool, ADR id.
Authoring/wiring is the fitness-functions primitive's job in Skeleton; this writes the contract.
fitness_functions_specified > 0.
WRITE
<target>/docs/adr/NNNN-*.md (accepted ADRs -- live in the target repo, QRSPI reads them later)
thoughts/shared/qraspi/YYYY-MM-DD-{slug}/architecture.md (status: complete; INDEXES the ADRs)
REPORT
architecture.md path · accepted ADR list · C4 levels drawn · fitness functions specified ·
"Review, then start a NEW session and run /qraspi-skeleton"
Exit criteria: every ADR is MADR format with >= 2 alternatives and status: accepted;
adrs_aligned: true; C4 Context + Container drawn in Mermaid; architecture.md written and indexes
the accepted ADRs; fitness_functions_specified > 0; user told to review before /qraspi-skeleton.
<qraspi-architecture-state>
phase: PRE-FLIGHT | DRAFT | ALIGN-LOOP | FITNESS-SPEC | WRITE | REPORT | COMPLETE
project_folder: thoughts/shared/qraspi/YYYY-MM-DD-{slug}/
adr_dir: [target]/docs/adr/
research_present: true | false # MUST be true to proceed
domain_model_invoked: true | false # optional -- high domain complexity only
adrs_drafted: [count]
adrs_min_alternatives_met: true | false # every ADR has >= 2 Considered Options
adrs_aligned: true | false # MUST be true before any ADR is set accepted
c4_levels: [Context, Container]
fitness_functions_specified: [count] # MUST be > 0 to COMPLETE
alignment_revisions: [count]
context_budget: under-40 | approaching-60 | checkpoint-now
status: in_progress | complete
</qraspi-architecture-state>
See references/adr-template.md for the MADR ADR structure (Considered Options required),
references/c4-conventions.md for the Mermaid C4Context/C4Container conventions and the
architecture.md summary shape, and references/fitness-spec.md for the fitness-function spec table
that hands off to the fitness-functions primitive.
| Skill | Relationship |
|-------|-------------|
| qraspi-research | Prior phase. Its research.md "Options on the table" are the alternatives input for the ADRs. |
| qraspi-skeleton | Next phase. Consumes architecture.md + the accepted ADRs; lands the specified fitness functions as CI gates. |
| fitness-functions | Authors the fitness functions this phase specifies (it owns the per-stack tooling); Skeleton wires them as CI gates. |
| domain-model | Optional pre-step for high domain complexity -- produces a CONTEXT.md the ADRs reference. No 7th phase. |
| architecture-journal | Reusable ADR + retrospective skill; this phase uses a MADR variant (references/adr-template.md) for the greenfield decision lock. |
| qrspi-spec | Brownfield sibling's design gate. Architecture is the greenfield analog -- ADRs-with-alternatives instead of a design brain-dump. |
development
Federal / government security overlay applied ON TOP OF a base language security review (dotnet/python/php/rust/react). Language-agnostic: adds NIST SP 800-53 control mapping, FIPS 140-2/3 cryptographic compliance (with a per-language crypto table), CUI handling, EO 14028 supply-chain requirements, and DOE Order 205.1B, and emits POA&M-ready findings with FIPS 199 impact levels. Use for federal/DOE/DOD/national-laboratory systems. Triggers on "federal security review", "NIST compliance", "NIST 800-53", "FISMA", "CUI", "FIPS audit", "DOE security", "POA&M", "ATO review". Do NOT use alone — run the matching <lang>-security-review FIRST; this overlay maps and extends it.
tools
OWASP-based security review of React / TypeScript front-end applications. Detects the framework (Vite/CRA/Next), entry points, and data flows, scans against the OWASP Top 10 (2025) mapped to React client-side patterns (XSS via raw HTML, URL/protocol injection, secrets in the bundle, insecure token storage, dependency CVEs, missing CSP, open redirects), and produces a manager-friendly executive summary plus a graded technical findings table. Use to audit React code for vulnerabilities. Triggers on "react security review", "frontend security audit", "audit react for vulnerabilities", "owasp react", "react xss", "react security posture", "npm audit review". For federal / gov / DOE / NIST / FIPS / CUI context, run security-review-federal after this base review. Do NOT use to grade architecture/structure — use react-architecture-checklist.
tools
Analyzes legacy React codebases and produces actionable modernization plans. Primary migration paths include class components to function components + hooks, Create React App to Vite, React 16/17 to 18 to 19, JavaScript to TypeScript, Enzyme to React Testing Library, legacy Redux to Redux Toolkit / Zustand / Context, and deprecated lifecycle/API removal. Does NOT perform the migration — assesses, quantifies risk, and plans. Triggers on phrases like "modernize react", "class to hooks", "upgrade react", "migrate CRA to vite", "react legacy migration", "react 17 to 18", "react js to typescript", "react technical debt", "enzyme to RTL".
development
Scaffolds feature-based React / TypeScript architecture using feature folders, presentational + container components, custom hooks, a typed data layer, and structural CQRS (query hooks vs mutation hooks). React analog of dotnet-vertical-slice and python-feature-slice — no DI framework; uses props/context for dependency injection and a query cache for server state. Use when creating feature-based React projects, adding React features, organizing components by feature rather than by technical type, or scaffolding a feature's data layer. Triggers on phrases like "scaffold react feature", "create react slice", "react feature folder", "react vertical slice", "add react feature", "react feature architecture", "organize react by feature".