cfsa-antigravity 1.0.0

package/template/.agent/workflows/create-prd-compile.md

@@ -0,0 +1,138 @@
+---
+description: Development methodology, phasing, and document compilation for the create-prd workflow
+parent: create-prd
+shard: compile
+standalone: true
+position: 4
+pipeline:
+  position: 2.4
+  stage: architecture
+  predecessors: [create-prd-security]
+  successors: [decompose-architecture]
+  skills: [technical-writer, prd-templates, pipeline-rubrics]
+  calls-bootstrap: true
+requires_placeholders: [UNIT_TESTING_SKILL, E2E_TESTING_SKILL, CI_CD_SKILL]
+---
+
+// turbo-all
+
+# Create PRD — Compile
+
+Document the development methodology and phasing strategy. Compile the architecture design document and engineering standards.
+
+**Prerequisite**: Security model and integration points must be defined (from `/create-prd-security`). All tech stack decisions, system architecture, data strategy, and security model must be complete.
+
+---
+
+## 0. Placeholder guard
+
+Before any skill reads, verify that the following placeholder values have been filled by `/bootstrap-agents`. For each placeholder, check whether the literal characters `{{` still appear in the value. If **any** are unfilled, emit a **HARD STOP** and do not proceed to Step 8.
+
+| Placeholder | Filled by | Recovery | Why this matters |
+|---|---|---|---|
+| `{{UNIT_TESTING_SKILL}}` | `/create-prd-stack` when the unit testing framework is confirmed | If `docs/plans/*-architecture-design.md` exists, read it and extract the confirmed unit testing framework, then run `/bootstrap-agents UNIT_TESTING=<confirmed-framework>`. Otherwise run `/create-prd-stack` first. | Development methodology (Step 8) cannot document correct test conventions without the unit testing skill — TDD patterns will be generic instead of framework-specific. |
+| `{{E2E_TESTING_SKILL}}` | `/create-prd-stack` when the E2E testing framework is confirmed | If `docs/plans/*-architecture-design.md` exists, read it and extract the confirmed E2E testing framework, then run `/bootstrap-agents E2E_TESTING=<confirmed-framework>`. Otherwise run `/create-prd-stack` first. | Development methodology (Step 8) cannot document correct E2E test conventions without the E2E testing skill — integration test patterns will be generic. |
+| `{{CI_CD_SKILL}}` | `/create-prd-stack` when CI/CD platform is confirmed | If `docs/plans/*-architecture-design.md` exists, read it and extract the confirmed CI/CD platform, then run `/bootstrap-agents CI_CD=<confirmed-platform>`. Otherwise run `/create-prd-stack` first. | Phasing strategy (Step 9) cannot produce correct pipeline configuration without the CI/CD skill — deployment and quality gate patterns will lack platform-specific conventions. |
+
+For the hard stop message format and recovery instructions, see `.agent/skills/prd-templates/references/placeholder-guard-template.md`.
+
+Only proceed to Step 8 when all three placeholders report no literal `{{` characters.
+
+---
+
+## 8. Development methodology
+
+Read .agent/skills/tdd-workflow/SKILL.md and follow its methodology.
+
+Document the agreed approach:
+
+1. **Contract-first** — Zod schemas (or equivalent) before implementation
+2. **TDD** — Failing tests before code
+   Read .agent/skills/{{UNIT_TESTING_SKILL}}/SKILL.md and follow its test writing conventions.
+   Read .agent/skills/{{E2E_TESTING_SKILL}}/SKILL.md and follow its E2E test conventions.
+3. **Vertical slices** — All surfaces per feature
+4. **Spec layers** — IA → BE → FE pipeline
+5. **Quality gates** — What must pass before merge
+
+## 9. Phasing strategy
+
+Read .agent/skills/{{CI_CD_SKILL}}/SKILL.md and follow its pipeline configuration conventions.
+
+Break the feature inventory from `vision.md` into dependency-ordered phases.
+
+> **This kit does not build MVPs.** Every phase ships production-grade code —
+> fully tested, fully specified, fully accessible. Phases exist to manage
+> dependency order and incremental delivery, not to defer quality.
+
+1. **Phase 1 (Foundation)** — Infrastructure + core entities. Must-haves that everything else depends on. Production-grade from day one. Phase 1 must begin with the `00-infrastructure` slice (CI/CD, environment, deployment, scaffolding, database). After this slice, `/verify-infrastructure` must pass before any feature slice begins. After the auth slice, `/verify-infrastructure` must pass again. Document these as hard gates.
+2. **Phase 2 (Core Experience)** — Primary user flows built on the foundation. Same quality bar as Phase 1.
+3. **Phase 3+ (Expansion)** — Additional features, integrations, scale. Same standards.
+
+For multi-surface projects, consider whether phases are **per-surface** or **cross-surface**. The decision depends on whether surfaces have independent value.
+
+Each phase should have a rough timeline estimate and must pass the full validation suite before the next phase begins.
+
+**Present to user**: Show the phasing breakdown. Walk through the dependency order. Ask:
+- "Are there features in Phase 2 that actually depend on something not in Phase 1?"
+- "Is the Phase 1 scope achievable without cutting quality?"
+
+Refine based on discussion before proceeding.
+
+## 9.5. Lock project directory structure
+
+Based on the locked tech stack, generate a canonical directory tree.
+
+1. Build the tree showing where source code, contracts/schemas, tests, config files, and build output live — tailored to the confirmed stack
+2. Present the tree to the user with one-line descriptions per top-level directory. Adapt the tree to the actual stack — e.g., a CLI project won't have `components/`, a monorepo will have `apps/` and `packages/`
+3. Build an architecture separation table mapping each concern to its directory and runtime
+4. **Present to user**: Show the directory tree and architecture table. Ask: "Does this structure match your expectations?" **Do not proceed until explicit approval.**
+5. After approval, fire bootstrap with: `PROJECT_STRUCTURE`, `ARCHITECTURE_TABLE`, `CONTRACTS_DIR`, `BUILD_OUTPUT_DIR`
+6. Append a `## Directory Structure` section to `docs/plans/architecture-draft.md`
+
+> If invoked standalone, surface via `notify_user`.
+
+## 10. Compile architecture design document
+
+Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
+
+Read .agent/skills/technical-writer/SKILL.md and apply its clarity and structure standards throughout document compilation.
+
+Read `docs/plans/architecture-draft.md` as the authoritative source. Read `.agent/skills/prd-templates/references/architecture-design-template.md` for the document structure. Compile it into `docs/plans/YYYY-MM-DD-architecture-design.md` (use today's date).
+
+> **Depth rule**: Each section must contain the full detail gathered during steps 3-9. If a section is under 200 words, it's almost certainly too shallow. Apply the two-implementer test.
+
+## 10.5. Performance budget interview
+
+Read `.agent/skills/performance-budgeting/SKILL.md` and follow its Interview Protocol for all applicable axes.
+
+Surface conditioning rules and the write-as-you-go rule are defined in the skill.
+
+Write each confirmed axis to `docs/plans/ENGINEERING-STANDARDS.md` immediately after confirmation.
+
+**Present to user**: Summarise all confirmed performance budgets. Ask: "Any axis you want to tighten, loosen, or add?"
+
+## 11. Compile Engineering Standards
+
+Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
+
+Read `.agent/skills/prd-templates/references/engineering-standards-template.md` for the document structure. Create `docs/plans/ENGINEERING-STANDARDS.md` — the non-negotiable quality bar for the project. Fill in concrete values based on tech stack decisions from step 3 and methodology from step 8. **No TBDs allowed.**
+
+## 12. Request review and propose next steps
+
+Read `.agent/skills/pipeline-rubrics/SKILL.md` and follow its pre-flight self-check protocol for the Architecture rubric.
+
+Run a pre-flight self-check before presenting. Read `.agent/skills/pipeline-rubrics/references/architecture-rubric.md` and apply each of the 15 dimensions as a self-check.
+
+> ❌ **STOP** — If any dimension scores ⚠️ or ❌, do not call `notify_user`. Fix the gap now and re-run the self-check until all 15 dimensions are ✅.
+
+Call `notify_user` presenting:
+- `docs/plans/YYYY-MM-DD-architecture-design.md` (use the actual dated filename)
+- `docs/plans/ENGINEERING-STANDARDS.md`
+- The self-check results (all 15 dimensions with scores)
+- Any gaps resolved during the self-check
+
+> **Both documents must be approved before proceeding. Do NOT proceed until the user sends a message explicitly approving this output.**
+
+### Proposed next steps
+
+**Hard gate**: Run `/audit-ambiguity architecture`. This is unconditionally mandatory — the self-check above cannot replace it.

package/template/.agent/workflows/create-prd-design-system.md

@@ -0,0 +1,135 @@
+---
+description: Navigation paradigm, layout grid, page archetypes, component hierarchy, motion, data density, state design language for the create-prd workflow
+parent: create-prd
+shard: design-system
+standalone: true
+position: 1.5
+pipeline:
+  position: 2.15
+  stage: architecture
+  predecessors: [create-prd-stack]
+  successors: [create-prd-architecture]
+  skills: [design-direction, technical-writer]
+  calls-bootstrap: false
+---
+
+// turbo-all
+
+# Create PRD — Design System Decisions
+
+Establish the structural UI architecture — navigation paradigm, layout grid, page archetypes, global component inventory, motion language, data density philosophy, and global state design language. Produces `docs/plans/design-system.md` which all FE specs must consume.
+
+**Prerequisite**: Tech stack decisions must be locked (`/create-prd-stack` completed). Design direction must be confirmed in `.agent/skills/brand-guidelines/SKILL.md`.
+
+---
+
+## 0. Prerequisite check
+
+1. Read `.agent/skills/brand-guidelines/SKILL.md`.
+2. Scan for any `{{PLACEHOLDER}}` values that are still unfilled. If any exist → **stop** and tell the user: _"Design direction hasn't been confirmed yet. Run `/create-prd-stack` first to establish the design direction before designing the system."_
+3. If all placeholders are filled → extract and store for this session: the confirmed `DESIGN_DIRECTION`, color palette, typography choices, motion philosophy, and anti-patterns.
+
+---
+
+## 1. Read source documents
+
+1. Read `docs/plans/vision.md` — extract the **Project Surfaces** section and the feature inventory.
+2. Read `.agent/skills/brand-guidelines/SKILL.md` — extract the confirmed `DESIGN_DIRECTION`.
+3. Read `.agent/skills/design-direction/SKILL.md` — for direction characteristics and anti-patterns.
+4. Read `.agent/skills/technical-writer/SKILL.md` — for document writing conventions.
+5. Read `.agent/skills/prd-templates/references/design-system-decisions.md` — all decision option menus and the output template for `docs/plans/design-system.md`.
+6. Note which surfaces are in scope from `## Project Surfaces`.
+
+---
+
+## 2. Decision 1 — Navigation paradigm
+
+Present surface-appropriate options from the **Navigation Paradigm Options** section of `design-system-decisions.md`. Present only the options for surfaces in scope. Include tradeoff framing — e.g., sidebar is good for complex apps with deep IA but bad for mobile-first or content-focused sites.
+
+> **Decision prompt**: "Which navigation pattern fits your app's usage pattern and audience?"
+
+**Wait for explicit user confirmation before proceeding.**
+
+On confirmation, write the `## Navigation Paradigm` section to `docs/plans/design-system.md` immediately.
+
+---
+
+## 3. Decision 2 — Layout grid
+
+Ask the user about grid structure per breakpoint (mobile ≤768px, tablet 769–1024px, desktop ≥1025px): columns, gutter, max content width, grid type (CSS Grid / Flexbox / Hybrid).
+
+Provide a **default recommendation** based on the confirmed design direction:
+- Information-dense → 12-column, 24px gutter, 1440px max
+- Editorial/spacious → 12-column, 32px gutter, 1200px max
+- Mobile-first → 4/8/12 column progression, 16px gutter
+
+**Wait for explicit user confirmation before proceeding.**
+
+On confirmation, write the `## Layout Grid` table to `docs/plans/design-system.md`.
+
+---
+
+## 4. Decision 3 — Page archetypes
+
+Based on the feature inventory from `vision.md`, propose a named archetype set using the **Page Archetype Options** from `design-system-decisions.md` as a starting point. Each archetype defines named layout zones. For each proposed archetype, produce a layout zones line (pipe-separated) and optionally an ASCII wireframe.
+
+Present the proposed archetypes to the user. Ask whether any are missing or should be renamed. **Wait for explicit user confirmation before proceeding.**
+
+On confirmation, write the `## Page Archetypes` section to `docs/plans/design-system.md`.
+
+---
+
+## 5. Decision 4 — Component hierarchy
+
+Derive the global component list from the confirmed navigation paradigm and page archetypes. Use the **Global Component Categories** from `design-system-decisions.md` as a seed. Global components are those used across multiple archetypes or present on every page.
+
+Present the derived list. Ask: (1) Are any components missing? (2) Should any be feature-local instead of global? (3) Are there project-specific components not covered?
+
+**Wait for explicit user confirmation before proceeding.**
+
+On confirmation, write the `## Global Component Inventory` section to `docs/plans/design-system.md`. This serves as the **Component Inventory Seed** — all FE specs must consume (not re-invent) these global components.
+
+---
+
+## 6. Decision 5 — Motion language
+
+Present the options from the **Motion Language Options** in `design-system-decisions.md`. Present a recommendation based on the confirmed design direction. **Wait for explicit user confirmation before proceeding.**
+
+On confirmation, write the `## Motion Language` section to `docs/plans/design-system.md`.
+
+---
+
+## 7. Decision 6 — Data density philosophy
+
+Present the options from the **Data Density Options** in `design-system-decisions.md`. If **Hybrid** is selected, ask the user to define per-archetype density rules. **Wait for explicit user confirmation before proceeding.**
+
+On confirmation, write the `## Data Density Philosophy` section to `docs/plans/design-system.md`.
+
+---
+
+## 8. Decision 7 — Global state design language
+
+Two-part decision. Present the loading state, error state, and empty state options from the **Global State Design Language Options** in `design-system-decisions.md`. Present recommendations based on the confirmed design direction. **Wait for explicit user confirmation before proceeding.**
+
+On confirmation, write the `## Global State Design Language` section to `docs/plans/design-system.md`.
+
+---
+
+## 9. Write and verify design-system.md
+
+After all seven decisions, verify that `docs/plans/design-system.md` was written progressively and is complete. Use the **design-system.md Output Template** from `design-system-decisions.md` as the canonical structure.
+
+Verify:
+1. All seven sections are present and filled (no placeholders, no TBDs).
+2. The **Global Component Inventory** serves as the Component Inventory Seed.
+3. Every decision references the confirmed design direction for rationale consistency.
+
+If any section is incomplete, loop back to the relevant decision step and resolve with the user.
+
+---
+
+### Propose next step
+
+Design system decisions are locked. Next: Run `/create-prd-architecture` to design the system architecture and data strategy.
+
+> If this shard was invoked standalone (not from `/create-prd`), surface this via `notify_user`.

package/template/.agent/workflows/create-prd-security.md

@@ -0,0 +1,113 @@
+---
+description: Security model and integration points for the create-prd workflow
+parent: create-prd
+shard: security
+standalone: true
+position: 3
+pipeline:
+  position: 2.3
+  stage: architecture
+  predecessors: [create-prd-architecture]
+  successors: [create-prd-compile]
+  skills: [security-scanning-security-hardening, resolve-ambiguity, logging-best-practices]
+  calls-bootstrap: true
+requires_placeholders: [SECURITY_SKILLS, AUTH_SKILL]
+---
+
+// turbo-all
+
+# Create PRD — Security & Integrations
+
+Define the security model with full compliance escalation, and document all integration points with failure modes and fallbacks.
+
+**Prerequisite**: System architecture and data strategy must be designed (from `/create-prd-architecture`). The agent should have component diagrams, data placement, and PII boundaries established.
+
+---
+
+## 0. Placeholder guard
+
+Before any skill reads, verify that the following placeholder values have been filled by `/bootstrap-agents`. For each placeholder, check whether the literal characters `{{` still appear in the value. If **any** are unfilled, emit a **HARD STOP** and do not proceed to Step 6.
+
+| Placeholder | Filled by | Recovery | Why this matters |
+|---|---|---|---|
+| `{{SECURITY_SKILLS}}` | `/create-prd-stack` when security tooling is confirmed | If `docs/plans/*-architecture-design.md` exists, read it and extract the confirmed security framework, then run `/bootstrap-agents SECURITY=<confirmed-framework>`. Otherwise run `/create-prd-stack` first. | Security model (Step 6) cannot produce stack-specific threat analysis without the security skill — the model will miss framework-specific attack vectors. |
+| `{{AUTH_SKILL}}` | `/create-prd-stack` when auth provider is confirmed | If `docs/plans/*-architecture-design.md` exists, read it and extract the confirmed auth provider, then run `/bootstrap-agents AUTH=<confirmed-provider>`. Otherwise run `/create-prd-stack` first. | Authentication design (Step 6.1) cannot produce correct auth flows without the auth skill — identity provider conventions and token handling will be generic. |
+
+For the hard stop message format and recovery instructions, see `.agent/skills/prd-templates/references/placeholder-guard-template.md`.
+
+Only proceed to Step 6 when both placeholders report no literal `{{` characters.
+
+---
+
+## 6. Security model
+
+Read .agent/skills/security-scanning-security-hardening/SKILL.md and follow its defense-in-depth methodology.
+
+Using `{{AUTH_SKILL}}`:
+
+Read each skill listed in `{{SECURITY_SKILLS}}` (comma-separated). For each skill directory name, read `.agent/skills/[skill]/SKILL.md` before proceeding.
+
+1. **Authentication** — How do users prove identity?
+2. **Authorization** — RBAC vs ABAC? Permission model?
+3. **Data protection** — PII handling, encryption at rest/transit
+4. **Input validation** — Where and how? (Zod recommended for TypeScript)
+5. **Age restrictions** — If applicable: age verification model
+6. **Rate limiting** — Per-route? Per-user? Per-IP?
+7. **CSP/CORS** — Content Security Policy, allowed origins (web surfaces)
+8. **Code signing** — App signing certificates, notarization (desktop/mobile surfaces)
+
+### Compliance escalation
+
+If any compliance constraint from `vision.md` involves **minors, payments, health data, or government-regulated domains**, it is NOT a sub-bullet — it becomes its own top-level section in the architecture document with the same depth as System Architecture. For example:
+
+- **Minors/COPPA/age-gating** → requires: account type hierarchy, consent flows, content filtering architecture, Guardian oversight model, age verification mechanism, blocked content categories, notification system for filter triggers
+- **Payments/PCI** → requires: token handling architecture, PCI scope boundaries, payment name verification, refund flows, dispute handling
+- **Health data/HIPAA** → requires: PHI isolation boundaries, audit logging, access controls, breach notification procedures
+
+Each of these must be specified with the same depth as any other architectural component — field-level detail, flow diagrams, error cases, and permission boundaries. A single bullet saying "age verification model" is not architecture.
+
+Read .agent/skills/resolve-ambiguity/SKILL.md and follow its methodology.
+
+**Present to user**: Show the security model and any compliance sections. Walk through each flow step by step. Ask:
+- "Can you think of a way to bypass any of these controls?"
+- "Are there edge cases in the age/payment/compliance flows I haven't covered?"
+
+Refine based on discussion before proceeding.
+
+**Bootstrap fire — security decision confirmed**
+
+If the security model confirmed a specific security framework or compliance approach (e.g., crypto patterns, custom HSM approach), read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents SECURITY=[confirmed value]` to provision additional skills. Note: surface-triggered security skills (`owasp-web-security`, `csp-cors-headers`, `input-sanitization`, `api-security-checklist`, `dependency-auditing`, `desktop-security-sandboxing`) are provisioned automatically by bootstrap when surfaces are confirmed in `/create-prd-stack` — no manual fire needed for those.
+
+## 6.5. Attack Surface Review
+
+Read .agent/skills/security-scanning-security-hardening/SKILL.md and follow its Attack Surface Review Protocol for each surface confirmed in /create-prd-stack. Apply Universal checks to all projects, then surface-specific checks conditionally.
+
+**Present to user**: Show the attack surface review findings. Ask:
+- "Are there any attack vectors I've missed for your specific domain?"
+- "Do the OWASP mechanisms look correct, or are any of them actually handled differently?"
+
+## 7. Integration points
+
+For each external service:
+
+1. **What it provides** — Specific features used
+2. **Failure mode** — What happens when it's down?
+3. **Fallback strategy** — Graceful degradation plan
+4. **Cost model** — Pricing tier, expected usage
+
+## 7.5. Observability Architecture
+
+Read .agent/skills/logging-best-practices/SKILL.md and follow its Observability Architecture Interview — all 5 decisions (logging, tracing, alerting, dashboards, retention) must be confirmed. Fire bootstrap per the skill's instructions for each confirmed tool.
+
+**Present to user**: Show the observability architecture decisions. Ask:
+- "Are these logging levels and PII exclusions correct for your compliance requirements?"
+- "Are the alerting thresholds appropriate for your expected traffic?"
+
+After the security model (Step 6) is completed and confirmed, write the `## Security Model` section to `docs/plans/architecture-draft.md`. After the attack surface review (Step 6.5) is completed and confirmed, write the `## Security — Attack Surface` section to `docs/plans/architecture-draft.md`. After the integration points (Step 7) are completed and confirmed, write the `## Integration Points` section to `docs/plans/architecture-draft.md`. After the observability architecture (Step 7.5) is completed and confirmed, write the `## Observability Architecture` section to `docs/plans/architecture-draft.md`. Do not wait until the end — write each section as it is completed.
+
+### Propose next step
+
+Security model and integration points are defined. Next: Run `/create-prd-compile` to document the development methodology, phasing strategy, and compile the final architecture design document and Engineering Standards.
+
+> If this shard was invoked standalone (not from `/create-prd`), surface this via `notify_user`.
+

package/template/.agent/workflows/create-prd-stack.md

@@ -0,0 +1,91 @@
+---
+description: Constraint-first discovery and tech stack decisions for the create-prd workflow
+parent: create-prd
+shard: stack
+standalone: true
+position: 1
+pipeline:
+  position: 2.1
+  stage: architecture
+  predecessors: [ideate]
+  successors: [create-prd-architecture]
+  skills: [brainstorming, resolve-ambiguity, tech-stack-catalog, design-direction]
+  calls-bootstrap: true
+---
+
+// turbo-all
+
+# Create PRD — Stack Decisions
+
+Build the decision constraints map from vision.md, then walk through each tech stack axis with the user.
+
+**Prerequisite**: `docs/plans/vision.md` must exist. If it does not, tell the user to run `/ideate` first.
+
+---
+
+## 2.5. Constraint-first discovery
+
+Before any tech stack decision, read `vision.md` constraints and surface classification to build the **decision constraints map**:
+
+1. **Hard constraints** — decisions already locked by compliance, team, or budget
+2. **Surface constraints** — the project surfaces constrain framework choices
+3. **Soft constraints** — preferences that should bias decisions but aren't hard rules
+
+Present the constraints map to the user before starting tech decisions. Constraints narrow the option space — some decisions may be obvious. Skip those with a brief rationale.
+
+Read `.agent/skills/tech-stack-catalog/references/constraint-questions.md` for the per-axis constraint questions to ask before presenting options.
+
+## 3. Tech stack decisions
+
+Read the **Project Surfaces** section from `vision.md` to determine which decision axes apply.
+
+Read `.agent/skills/tech-stack-catalog/references/surface-decision-tables.md` and present only the tables for applicable surfaces. For each axis, use the option presentation format from `.agent/skills/tech-stack-catalog/SKILL.md`.
+Read .agent/skills/tech-stack-catalog/SKILL.md and follow its per-axis constraint-first selection methodology.
+
+> ⚠️ **Skip the `Database` axis** from the surface decision tables during this generic per-axis loop. All persistence decisions (primary, vector, graph, cache, time-series) are handled exclusively by the **Database: Persistence Map Interview** section below. Do not present a single DATABASE option here — this avoids duplicate/conflicting bootstrap calls.
+
+Score Fit from 1–5 based on how well the option matches the constraints map. If constraints eliminate all but 1-2 options, present only those with a note explaining why others were eliminated.
+
+**Per-axis flow**:
+1. Ask the constraint questions for this axis
+2. Filter options based on answers
+3. Present the filtered option table with recommendation
+4. Wait for user confirmation
+5. Fire bootstrap with only that key: read `.agent/workflows/bootstrap-agents.md` and call with `PIPELINE_STAGE=create-prd` + the confirmed key
+6. Move to next axis
+
+> **Note on backend axis bootstrap keys**: `BACKEND_FRAMEWORK` and `API_LAYER` are distinct bootstrap keys and must each fire as a separate `/bootstrap-agents` call — do not combine them.
+> - `BACKEND_FRAMEWORK` (e.g., `Hono`, `FastAPI`, `NestJS`) → provisions the backend framework skill
+> - `API_LAYER` (e.g., `tRPC`, `GraphQL`) → provisions the API layer skill
+>
+> These are independent MANIFEST entries. Firing bootstrap with `BACKEND_FRAMEWORK=Hono` does **not** provision the tRPC skill — `API_LAYER=tRPC` must be fired separately. Similarly, skipping the `Database` axis (handled by the Persistence Map Interview) does not affect backend framework or API layer keys — those must still fire individually.
+
+Get explicit user decisions — no "TBD" allowed. Use the brainstorming skill's approach — one decision at a time.
+
+### Database: Persistence Map Interview
+
+Instead of a single DATABASE decision pass, use the following structured persistence map interview to identify all required stores.
+
+Read .agent/skills/database-schema-design/SKILL.md and follow its Persistence Map Interview methodology (Sub-steps A–E). Fire bootstrap per the skill's instructions for each confirmed store.
+
+### Design Direction
+
+Read `.agent/skills/design-direction/SKILL.md` and follow its interview methodology to determine the project's visual direction. After confirmation, fire bootstrap with `DESIGN_DIRECTION=[confirmed direction]`.
+
+### Development tooling
+
+Read `.agent/skills/tech-stack-catalog/references/dev-tooling-decisions.md` for the tooling axes and bootstrap keys. After the user confirms all development tooling, fire bootstrap immediately with all keys listed in that reference file.
+
+### After each tech decision
+
+Read each installed skill's SKILL.md before proceeding. Append the confirmed decision to `docs/plans/architecture-draft.md`.
+
+### Fill kit templates (progressive bootstrap)
+
+Read `.agent/workflows/bootstrap-agents.md` and call it with `PIPELINE_STAGE=create-prd` plus only the keys just decided. Bootstrap runs after **each confirmed decision**, not in a batch at the end. At the end of all tech decisions, call bootstrap once more with `ARCHITECTURE_DOC` set to the dated filename.
+
+### Propose next step
+
+All tech stack decisions are locked. Next: Run `/create-prd-architecture` to design the system architecture and data strategy.
+
+> If invoked standalone, surface via `notify_user`.

package/template/.agent/workflows/create-prd.md

@@ -0,0 +1,168 @@
+---
+description: Expand vision into full architecture design document — tech stack decisions, system design, data strategy, security model
+pipeline:
+  position: 2
+  stage: architecture
+  predecessors: [ideate]
+  successors: [decompose-architecture]
+  skills: [brainstorming, resolve-ambiguity, technical-writer, database-schema-design]
+  calls-bootstrap: true # tech stack decisions trigger skill provisioning
+shards: [create-prd-stack, create-prd-design-system, create-prd-architecture, create-prd-security, create-prd-compile]
+---
+
+// turbo-all
+
+# Create PRD / Architecture Design
+
+Transform `vision.md` into a production-grade architecture design document with explicit decisions on every axis.
+
+**Input**: `docs/plans/vision.md` (must exist and be approved)
+**Output**: `docs/plans/YYYY-MM-DD-architecture-design.md` + `docs/plans/ENGINEERING-STANDARDS.md` + `docs/plans/data-placement-strategy.md`
+
+> **Depth standard**: Every section of the architecture document must be specified
+> to the point where a developer cannot misinterpret it. If you can write a
+> one-paragraph section summary, it's not detailed enough. Each section should
+> define every field, every flow, every error case, every permission boundary.
+> The depth-standards rule (`.agent/rules/depth-standards.md`) applies to every
+> word of the output. One-line placeholders like `[Auth, authorization, rate limits]`
+> are not architecture — they are headings waiting for content.
+
+---
+
+## 1. Read vision document
+
+Read `docs/plans/vision.md`.
+
+If the file doesn't exist, tell the user to run `/ideate` first. Do not proceed without an approved vision.
+
+Pay special attention to the **Project Surfaces** section — it determines which tech stack axes apply and whether this is a single-surface or multi-surface project.
+
+---
+
+## 2. Load skills
+
+### Bundled skills
+
+These skills are included in the kit — read each SKILL.md:
+1. `.agent/skills/rest-api-design/SKILL.md` — API conventions
+2. `.agent/skills/api-design-principles/SKILL.md` — API design principles
+3. `.agent/skills/security-scanning-security-hardening/SKILL.md` — Security model
+4. `.agent/skills/clean-code/SKILL.md` — Architecture principles
+5. `.agent/skills/brainstorming/SKILL.md` — For collaborative decisions
+
+### Stack-specific skill discovery
+
+Check `.agent/skills/` for relevant skills. Read `.agent/skills/find-skills/SKILL.md` for guidance on discovering community skills for your chosen stack.
+
+---
+
+## Shard Overview
+
+| # | Shard | What It Does |
+|---|-------|-------------|
+| 1 | [`create-prd-stack`](.agent/workflows/create-prd-stack.md) | Constraint-first discovery, tech stack decisions with bootstrap firing |
+| 1.5 | [`create-prd-design-system`](.agent/workflows/create-prd-design-system.md) | Navigation paradigm, layout grid, page archetypes, component hierarchy, motion, state design language → `docs/plans/design-system.md` |
+| 2 | [`create-prd-architecture`](.agent/workflows/create-prd-architecture.md) | System architecture, data strategy, data placement strategy document |
+| 3 | [`create-prd-security`](.agent/workflows/create-prd-security.md) | Security model, compliance escalation, integration points |
+| 4 | [`create-prd-compile`](.agent/workflows/create-prd-compile.md) | Development methodology, phasing, compile architecture-design.md + ENGINEERING-STANDARDS.md |
+
+> **Progressive working artifact**: `docs/plans/architecture-draft.md` is written incrementally by shards 1–3 (stack decisions, system architecture, data strategy, security model, integration points) and read by shard 4 (compile) to produce the final dated `architecture-design.md`.
+
+---
+
+## Orchestration
+
+### Step A — Run `.agent/workflows/create-prd-stack.md`
+
+Builds the constraints map from vision.md, presents tech stack options per axis, gets user decisions, fires bootstrap after each confirmation.
+
+### Step A.5 — Run `.agent/workflows/create-prd-design-system.md`
+
+Establishes the structural UI architecture — navigation paradigm, layout grid, page archetypes, global component inventory, motion language, data density philosophy, and global state design language. Produces `docs/plans/design-system.md` which all FE specs must consume.
+
+### Step B — Run `.agent/workflows/create-prd-architecture.md`
+
+Designs system architecture (components, data flow, deployment topology, API surface) and data strategy (placement, schema, queries, migrations, PII boundaries). Creates `docs/plans/data-placement-strategy.md`.
+
+### Step C — Run `.agent/workflows/create-prd-security.md`
+
+Defines the security model (auth, authorization, validation, rate limits). Escalates compliance-heavy domains to full-depth sections. Documents integration points with failure modes and fallbacks.
+
+### Step D — Run `.agent/workflows/create-prd-compile.md`
+
+Documents development methodology and phasing strategy. Compiles `docs/plans/YYYY-MM-DD-architecture-design.md` and `docs/plans/ENGINEERING-STANDARDS.md`.
+
+---
+
+## 12. Quality gate
+
+### Self-check against Architecture rubric
+
+Read .agent/skills/pipeline-rubrics/SKILL.md and apply its Architecture rubric for the self-check.
+
+Before presenting to the user, self-check both documents against the **Architecture Rubric** (12 dimensions) from `/audit-ambiguity`:
+
+| # | Dimension | Check |
+|---|-----------|-------|
+| 1 | Tech Stack Decisiveness | Is every applicable axis decided with rationale? No TBDs? |
+| 2 | System Architecture | Are all components, flows, and failure modes documented? |
+| 3 | Data Strategy | Are placement, schema, queries, migrations, and PII boundaries defined? |
+| 4 | Security Model | Are auth, authz, validation, rate limits, and CSP fully specified? |
+| 5 | Compliance Depth | Are regulated domains (minors, payments, health) given full-depth sections? |
+| 6 | API Design | Are surface, versioning, conventions, errors, and pagination defined? |
+| 7 | Integration Robustness | Do all externals have failure + fallback plans? |
+| 8 | Phasing Clarity | Are phases dependency-ordered with entry/exit criteria? |
+| 9 | Engineering Standards | Are all thresholds concrete? No TBDs in ENGINEERING-STANDARDS.md? |
+| 10 | Persistence Architecture | Is the persistence map complete? Do all cross-store entities have a consistency contract (canonical ID, creation sequence, deletion cascade, read join)? |
+| 11 | Error Architecture | Is the global error envelope defined with all four fields? Are all five error decisions confirmed (envelope, propagation chain, unhandled exceptions, client fallback, error boundaries)? |
+| 12 | Attack Surface Coverage | Is the attack surface review complete? Are OWASP Top 10 (web) and API Top 10 (API) addressed with named mechanisms? Are security headers configured? Is the observability architecture documented? |
+
+Also verify completeness:
+
+- [ ] Every "Must Have" feature from vision.md has a home in the architecture
+- [ ] Security model addresses all compliance constraints from vision.md
+- [ ] Compliance-heavy domains have their own top-level sections (not buried as sub-bullets)
+- [ ] All relevant skills installed for chosen stack
+- [ ] Validation command in Engineering Standards matches `AGENTS.md` validation command
+- [ ] For multi-surface: sync strategy defined, data ownership clear, conflict resolution specified
+- [ ] For cross-platform: platform-specific considerations documented for each target OS
+- [ ] Design system document exists at docs/plans/design-system.md and all seven decision areas are filled (no placeholders)
+
+For any dimension that scores ⚠️ or ❌, resolve it NOW. Loop back to the relevant step and resolve with the user.
+
+> ❌ STOP — do not call notify_user until all dimensions score ✅.
+
+### Depth audit
+
+Before presenting to the user, re-read the entire architecture document and for EACH section ask:
+
+> "Could a developer implement this without asking a single clarifying question?"
+
+If the answer is no for ANY section:
+1. Identify what's missing (field types? flow steps? error cases? permission rules?)
+2. Add the missing detail NOW — do not flag it, resolve it
+3. Re-check the section
+
+This is the single most important step. The difference between a useful architecture document and a useless one is whether this audit is done honestly. A 2,000-word architecture doc is almost certainly too shallow for any non-trivial project.
+
+If gaps are found, loop back to the relevant step and resolve with the user.
+
+> **Note**: This is an internal self-check, not a formal audit. For a rigorous,
+> independent audit with evidence citations, run `/audit-ambiguity architecture` as a
+> separate step after this workflow completes.
+
+## 13. Request review and next steps
+
+Use `notify_user` to present to the user:
+- **Both** the architecture design document and the Engineering Standards document
+- Summary of the self-check results (all 12 dimensions + completeness checklist)
+- Any areas where you resolved gaps during the self-check
+
+Both documents must be approved before proceeding. Do NOT proceed to the next step until the user sends a message explicitly approving this output. Proposing next steps is not the same as receiving approval. Wait for explicit approval before continuing.
+
+### Proposed next steps
+
+Once approved, present the user with the appropriate next step:
+
+- **Default recommendation**: Run `/audit-ambiguity architecture` — recommended for all projects, especially those with compliance constraints
+- **Skip condition**: Only skip `/audit-ambiguity architecture` if all 12 dimensions scored ✅ AND the project has zero compliance constraints. In that case, recommend `/decompose-architecture` directly.