skills/team/qraspi-architecture/SKILL.md
QRASPI Architecture phase — locks the path-dependent decisions for a NEW system as MADR ADRs (with alternatives), draws the C4 Context + Container in Mermaid, and specifies required fitness functions. Use for '/qraspi-architecture <project>', 'write the ADRs for new X', 'what architecture for new X', 'lock the stack decisions for X'. Not for critiquing an EXISTING system (architecture-review), retrospective ADR journaling (architecture-journal), a feature in an existing codebase (qrspi-spec), or 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
Interviews the user relentlessly about a plan, decision, or idea — one question at a time, each with a recommended answer. Shared engine behind "grill-me" and "grill-with-docs". Use on any "grill" trigger phrase or to stress-test thinking. Do NOT use to build the plan; it ends at shared understanding, not implementation.
testing
Runs a relentless interview to sharpen a plan or design, capturing the decisions as ADRs and a glossary along the way. Use when the user wants to be grilled AND wants the session to leave durable domain documentation behind. Do NOT use for a throwaway stress-test with no artifacts; use grill-me instead.
tools
OWASP-based security review of Vue/TypeScript front-ends. Detects framework (Vite/Vue CLI/Nuxt), entry points, and data flows; scans the OWASP Top 10 (2025) mapped to Vue client-side risks (raw-HTML XSS via v-html, URL/protocol injection, bundled secrets, insecure token storage, dependency CVEs, missing CSP, open redirects, router guard bypass); emits an exec summary plus graded findings. Use to audit Vue for vulnerabilities. Not for architecture grading (vue-architecture-checklist).
tools
Analyzes legacy Vue codebases and produces actionable modernization plans. Primary migration paths include Options API to Composition API, Vue 2 to Vue 3, Vue CLI to Vite, JavaScript to TypeScript, Vue Test Utils/Karma/Mocha to Vitest + Vue Testing Library, legacy Vuex to Pinia, and removed-in-Vue-3 pattern cleanup (filters, event bus, `$listeners`). Does NOT perform the migration — assesses, quantifies risk, and plans.