cfsa-antigravity 1.0.0

package/template/.agent/workflows/write-be-spec-classify.md

@@ -0,0 +1,165 @@
+---
+description: Classify IA shard, load skills, and read all source material for the write-be-spec workflow
+parent: write-be-spec
+shard: classify
+standalone: true
+position: 1
+pipeline:
+  position: 5a.1
+  stage: specification
+  predecessors: [write-architecture-spec]
+  successors: [write-be-spec-write]
+  skills: [resolve-ambiguity, database-schema-design]
+  calls-bootstrap: false
+requires_placeholders: [LANGUAGE_SKILL, DATABASE_SKILLS, AUTH_SKILL, BACKEND_FRAMEWORK_SKILL, ORM_SKILL, UNIT_TESTING_SKILL]
+---
+
+// turbo-all
+
+# Write BE Spec — Classify & Read Sources
+
+Identify the target IA shard, classify it, load skills, and read all source material including cross-references and deep dives.
+
+**Prerequisite**: IA shard must be complete (status ✅ in `docs/plans/ia/index.md`). If not, tell the user to run `/write-architecture-spec` first.
+
+---
+
+## 1. Verify IA layer is complete, then identify the target shard
+
+Before identifying the target shard, verify the entire IA layer is ready:
+
+1. Read `docs/plans/ia/index.md`
+2. Check every shard's status column
+3. **Hard stop** if any shard is not ✅:
+
+> ❌ **Cannot write BE spec — IA layer is incomplete.**
+> The following shards are not yet complete:
+> - [shard-name]: [status]
+>
+> Run `/write-architecture-spec` for each incomplete shard before proceeding to `/write-be-spec`.
+
+**Why**: BE specs resolve cross-shard IA references. If referenced shards are still skeletons, the BE spec will contain gaps or guesses that cascade into FE specs and implementation. The cost of waiting for IA completion is hours; the cost of writing BE specs against incomplete IA is days of rework.
+
+---
+
+Determine which IA shard to process. Read it in full before proceeding.
+
+## 2. Classify the shard
+
+Not every IA shard produces the same output. Before writing anything, classify the shard:
+
+| Classification | Description | BE Spec Output | How to Detect |
+|---------------|-------------|----------------|---------------|
+| **Feature domain** | Defines user interactions, data models, and API-facing behavior for a single cohesive domain | 1 BE spec | Has data model + user flows + access model that imply API endpoints |
+| **Multi-domain** | Covers multiple distinct backend sub-systems that share a product surface but have independent APIs | N BE specs (split along sub-feature boundaries) | Section headers map to independent API surfaces; data models don't overlap between sections; could be developed by different teams |
+| **Cross-cutting** | Defines shared patterns consumed by all feature specs (auth, API conventions, error handling) | 1 cross-cutting BE spec (`00-*`) | Content is about "how all endpoints work" not "what this feature does" |
+| **Structural reference** | Maps structure, naming, or routing without defining API behavior | 0 BE specs | No data model, no user flows, no endpoints — just reference tables |
+| **Composite** | Contains both a structural reference section AND feature behavior (e.g., URL mapping + vanity URL lifecycle) | Depends — feature portion may belong in another shard's BE spec | Look for cross-references pointing the feature content to its owning domain |
+
+**Multi-domain split heuristic — sub-feature endpoint inventory:**
+
+Before classifying a shard as multi-domain, build a **sub-feature endpoint inventory**:
+
+| Sub-feature | Expected endpoints | Data model(s) | Independent? |
+|-------------|-------------------|---------------|-------------|
+| [sub-feature] | `POST /api/...`, `GET /api/...` | [table/collection names] | [Yes/No] |
+| [sub-feature] | `PUT /api/...`, `DELETE /api/...` | [table/collection names] | [Yes/No] |
+
+**Split criterion**: Two or more independent groups each have their own data model and could be assigned to a different developer without coordination → split into separate BE specs. Section header count alone is **NOT** the criterion — independence of data models and API surfaces is.
+
+**Present the classification to the user before proceeding.** Include:
+- The classification and reasoning
+- How many BE specs will be produced
+- For multi-domain: the proposed split boundaries
+- For structural reference: confirmation that no BE spec is needed
+
+## 2.5. Verify tech stack skills are provisioned
+
+Before loading the skill bundle, scan the skill bundle list in Step 3 for any values still containing literal `{{` characters.
+
+If `{{LANGUAGE_SKILL}}`, `{{DATABASE_SKILLS}}`, `{{AUTH_SKILL}}`, `{{BACKEND_FRAMEWORK_SKILL}}`, `{{ORM_SKILL}}`, or `{{UNIT_TESTING_SKILL}}` are still unfilled → **stop** and tell the user: *"Tech stack skills haven't been provisioned yet. The skill bundle placeholders are still unfilled. Run `/create-prd` first to make tech stack decisions and trigger bootstrap provisioning, then return to `/write-be-spec`."*
+
+Only proceed to Step 3 when all skill bundle placeholders are filled with actual skill directory names.
+
+## 3. Load skill bundle
+
+Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Read each skill listed in `{{DATABASE_SKILLS}}` (comma-separated). For each skill directory name, read `.agent/skills/[skill]/SKILL.md` before proceeding.
+Read .agent/skills/{{AUTH_SKILL}}/SKILL.md
+Read .agent/skills/{{BACKEND_FRAMEWORK_SKILL}}/SKILL.md
+Read .agent/skills/rest-api-design/SKILL.md
+Read .agent/skills/api-design-principles/SKILL.md
+Read .agent/skills/error-handling-patterns/SKILL.md
+Read .agent/skills/database-schema-design/SKILL.md
+Read .agent/skills/migration-management/SKILL.md
+Read .agent/skills/{{ORM_SKILL}}/SKILL.md and follow its migration and schema conventions.
+Read .agent/skills/{{UNIT_TESTING_SKILL}}/SKILL.md and follow its test writing conventions.
+Read .agent/skills/testing-strategist/SKILL.md
+Read .agent/skills/logging-best-practices/SKILL.md
+
+**Missing skill fallback**: If any skill in the bundle above is not installed in `.agent/skills/` and is not in `.agent/skill-library/MANIFEST.md`, read `.agent/skills/find-skills/SKILL.md` and follow its discovery methodology to search for a community equivalent before proceeding without it.
+
+### Ambiguity resolution
+
+When writing the BE spec, if any requirement cannot be resolved from `vision.md`, `architecture-design.md`, `data-placement-strategy.md`, or upstream IA specs, **do not guess**. Instead, load and follow `.agent/skills/resolve-ambiguity/SKILL.md` to systematically resolve the ambiguity before proceeding.
+
+## 4. Read reference documents
+
+Read the file at `docs/plans/be/index.md` (conventions template) and the file at `docs/plans/index.md` (master index, tech stack).
+
+Also read `docs/plans/data-placement-strategy.md` if it exists — this document specifies which entities live in which store and defines PII boundaries. Every BE spec must place data consistently with this strategy.
+
+## 5. Read the IA source material
+
+This is the most critical step. Read **all** of the following:
+
+### 5a. Primary shard
+Read the file at `docs/plans/ia/[NN-shard-name].md` (the full IA shard).
+
+### 5b. Resolve cross-shard references
+Scan the primary shard for all cross-references to other shards (look for `See [shard NN](...)`, `defined in [shard NN](...)`, or `Related shards:` headers). For each reference:
+1. Read the referenced section (not the entire shard — just the relevant section)
+2. Note what content is being borrowed (data model? access rules? edge cases?)
+3. Record the reference as: `Source: [shard-file.md] § [section-name] (lines N–M)`
+
+Build a **Referenced Material Inventory**:
+```
+Primary: 09-playground.md (full shard)
+Cross-refs:
+  - 02-account-architecture.md § Junior Account Controls (lines 680–706)
+  - 03-rbac-policies.md § Permission Taxonomy: playground.* (lines 45–52)
+  - 12-resources-settings.md § Credentials Management (lines 93–174)
+```
+
+### 5c. Read deep dives
+List the files in `docs/plans/ia/deep-dives/`.
+Identify which deep dives are referenced by the primary shard. **Read each referenced deep dive in full** — these contain architectural decisions (technology choices, protocol designs, phasing strategies) that the BE spec must implement. Extract and record:
+- Key decisions (what was decided and why)
+- Architectural constraints (what the BE spec must conform to)
+- Data schemas or contracts defined in the deep dive
+
+### 5d. Read the IA shard's testability section
+If the shard has a testability/acceptance criteria section, read it — these become the BE spec's performance targets and test requirements.
+
+## 6. Check cross-cutting specs
+
+Read any completed cross-cutting specs — feature specs must follow their patterns. List the files matching `docs/plans/be/00-*.md` (cross-cutting specs).
+
+## 7. Present classification and request approval
+
+Include the expected endpoint inventory in the classification presentation. The user must verify split boundaries align with the actual API surface before approving.
+
+Call `notify_user` presenting:
+- The classification type and reasoning (from Step 2)
+- The number of BE specs to be produced
+- The Referenced Material Inventory (from Step 5)
+- For multi-domain splits: the proposed split boundaries
+
+> **Do NOT proceed to `/write-be-spec-write` until the user confirms the classification is correct. For multi-domain splits, the user must confirm the split boundaries.**
+
+Once approved, run `/write-be-spec-write`.
+
+> **Seed the spec file**: After classification is approved, read `.agent/skills/prd-templates/references/be-spec-template.md` for the **BE Spec Seed Stub** template. Create the spec file at `docs/plans/be/[NN-feature-name].md` using the stub, filling in the classification details and Referenced Material Inventory from above.
+
+For structural reference classification (0 BE specs): confirm no write shard is needed and propose moving to the next IA shard instead.
+

package/template/.agent/workflows/write-be-spec-write.md

@@ -0,0 +1,98 @@
+---
+description: Write BE spec, update indexes, run ambiguity gate, and check for new dependencies for the write-be-spec workflow
+parent: write-be-spec
+shard: write
+standalone: true
+position: 2
+pipeline:
+  position: 5a.2
+  stage: specification
+  predecessors: [write-be-spec-classify]
+  successors: [plan-phase]
+  skills: [technical-writer, testing-strategist, prd-templates]
+  calls-bootstrap: true
+---
+
+// turbo-all
+
+# Write BE Spec — Write & Validate
+
+Write the BE spec(s) to `docs/plans/be/`, update indexes, run quality checks, and present for review.
+
+**Prerequisite**: Read the spec file at `docs/plans/be/[NN-feature-name].md`. The `## Classification` section and Referenced Material Inventory should be present from the classify shard. If the file does not exist or lacks a `## Classification` section, run `/write-be-spec-classify` first.
+
+---
+
+## 7. Write the spec to `docs/plans/be/[NN-feature-name].md`
+
+**Endpoint completeness reconciliation**: Before writing any section, build a reconciliation table from the sub-feature endpoint inventory (produced during `/write-be-spec-classify`):
+
+| Sub-feature | Expected endpoints | Specced? | Notes |
+|-------------|-------------------|----------|-------|
+| [sub-feature] | `POST /api/...` | ✅ | — |
+| [sub-feature] | `GET /api/...` | ❌ | [Deferred to Phase N — reason] |
+| [sub-feature] | `PUT /api/...` | ❌ | — |
+
+**Rule**: For every unspecced expected endpoint, either add it to the spec immediately or add an explicit `[Deferred to Phase N — reason]` note in the Notes column. An empty Notes column for an unspecced endpoint is a spec failure.
+
+**Gate**: Do not write the spec sections until every expected endpoint is either specced or explicitly deferred. This reconciliation table becomes the first section of the spec file after `## Classification`.
+
+Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
+Read .agent/skills/testing-strategist/SKILL.md and follow its methodology.
+
+**Naming convention**: Use the same number prefix as the IA shard that sources it, followed by a kebab-case feature name. For multi-domain splits from the same shard, append a letter suffix (e.g., `09a-chat-api.md`, `09b-agent-flow-api.md`). For cross-cutting specs, use the `00-` prefix (e.g., `00-api-conventions.md`).
+
+Read `.agent/skills/prd-templates/references/be-spec-template.md` for the document structure and quality gates checklist. Follow the conventions template from `be/index.md`.
+
+## 8. Update the BE index
+
+Add or update the spec entry in `docs/plans/be/index.md`. For multi-domain splits, add one row per BE spec with the shared IA source.
+
+If a shard was classified as **structural reference** with 0 BE specs, add a row with `—` status and a note explaining why (e.g., "Structural reference — no API surface").
+
+## 9. Update spec pipeline
+
+Read `.agent/skills/session-continuity/protocols/08-spec-pipeline-update.md` and follow the **Spec Pipeline Update Protocol** to mark this shard's BE column as complete in `.agent/progress/spec-pipeline.md`.
+
+## 10. Cross-reference check
+
+Verify:
+- [ ] New spec links back to its IA source shard
+- [ ] Related BE specs are cross-referenced (especially for multi-domain splits from the same shard)
+- [ ] Cross-shard referenced material is cited with file + section + line numbers
+- [ ] IA source shard links forward to the new BE spec
+
+## 11. Ambiguity gate
+
+Read `.agent/skills/session-continuity/protocols/ambiguity-gates.md` and run:
+
+- **Micro**: Walk each endpoint, request/response field, error code, schema constraint, and middleware rule. Would an implementer need to guess? Fix it now.
+- **Macro**: Would the FE spec writer need to guess anything from this BE spec? Fix it now.
+- **Two-implementer test**: Would two developers reading only this spec make the same decision? If not — fix it now.
+- **Devil's advocate pass**: "What would a junior developer get wrong?" Fix any revealed gaps.
+
+## 12. Full ambiguity audit (mandatory when last BE spec)
+
+1. Read `docs/plans/be/index.md`
+2. Check if all BE specs show ✅
+
+**More specs remain**: Proceed to the next spec.
+
+**This is the last BE spec**: Run `/audit-ambiguity be` now. **Hard gate**: Do NOT propose `/write-fe-spec` until `/audit-ambiguity be` scores 0%.
+
+## 13. Check for new dependencies
+
+If this BE spec introduces a technology not already in the project's tech stack:
+1. Identify the stack category (e.g., QUEUE, CACHE, SEARCH, STORAGE)
+2. Read `.agent/workflows/bootstrap-agents.md` and fire bootstrap with `PIPELINE_STAGE=write-be-spec` + the key-value pair
+3. Confirm matching skill installed
+
+## 14. Request review and propose next steps
+
+Read .agent/skills/verification-before-completion/SKILL.md and follow its methodology.
+
+Use `notify_user` presenting:
+1. **Spec created** (link)
+2. **Cross-reference verification**
+3. **Ambiguity Gate confirmation**
+4. **Pipeline State** — read `.agent/progress/spec-pipeline.md` and propose next step

package/template/.agent/workflows/write-be-spec.md

@@ -0,0 +1,76 @@
+---
+description: Write a backend specification — classifies IA shard, resolves cross-references, reads deep dives, produces BE spec(s)
+pipeline:
+  position: 5a
+  stage: specification
+  predecessors: [write-architecture-spec]
+  successors: [plan-phase]
+  parallel-with: [write-fe-spec] # can run in parallel
+  skills: [resolve-ambiguity, error-handling-patterns, database-schema-design, migration-management, testing-strategist, logging-best-practices]
+  calls-bootstrap: true # may discover new backend dependencies
+shards: [write-be-spec-classify, write-be-spec-write]
+---
+
+// turbo-all
+
+# Write Backend Specification
+
+**Input**: A complete IA shard (or set of related shards)
+**Output**: One or more BE specs with endpoints, contracts, schemas, middleware, error handling
+
+---
+
+## Skill Bootstrap
+
+Check installed skills for stack-appropriate coverage:
+- Database expert skill (schema design)
+- Hosting/deployment skill (runtime/worker patterns)
+- HTTP router/framework skill (middleware)
+- REST API design skill (API conventions)
+- Auth skill (JWT/session patterns)
+
+Conditionally look for:
+- Payment provider integration skill (if billing-related spec)
+- Rate limiting / abuse protection skill
+- TypeScript advanced patterns skill (for complex contract types)
+- Security hardening skill (for auth/RBAC specs)
+
+If a needed skill is missing, check if a matching entry exists in `.agent/skill-library/MANIFEST.md`. Read `.agent/workflows/bootstrap-agents.md` and execute its utility instructions immediately with the appropriate stack key to install it.
+
+---
+
+## Shard Overview
+
+| # | Shard | What It Does |
+|---|-------|-------------|
+| 1 | [`write-be-spec-classify`](.agent/workflows/write-be-spec-classify.md) | Classifies IA shard, loads skills, reads source material + cross-references + deep dives |
+| 2 | [`write-be-spec-write`](.agent/workflows/write-be-spec-write.md) | Writes the BE spec, updates indexes, runs ambiguity gate, checks for new dependencies |
+
+---
+
+## Orchestration
+
+### Step A — Run `.agent/workflows/write-be-spec-classify.md`
+
+Identifies the target IA shard, classifies it (feature domain / multi-domain / cross-cutting / structural reference / composite), loads the skill bundle, reads all source material (primary shard, cross-shard references, deep dives, testability section), and reads cross-cutting specs.
+
+### Step B — Run `.agent/workflows/write-be-spec-write.md`
+
+Writes the BE spec(s) to `docs/plans/be/`, updates the BE index, runs cross-reference checks and the ambiguity gate, checks for new dependencies (firing bootstrap if needed), and presents for review.
+
+---
+
+## Quality Gate
+
+Before presenting to the user, verify:
+
+Read .agent/skills/code-review-pro/SKILL.md and apply its adversarial review discipline to each checklist item.
+
+- [ ] Every endpoint has a Zod request AND response schema
+- [ ] Every database table has defined fields, indexes, and permissions
+- [ ] Security constraints from IA shard reflected in middleware section
+- [ ] Error codes are specific (not generic 500s)
+- [ ] Rate limits specified per endpoint
+- [ ] Every deep dive key decision is reflected in the spec
+- [ ] Every cross-shard reference has been resolved
+- [ ] IA Source Map is complete — no BE spec section lacks a traceable IA source

package/template/.agent/workflows/write-fe-spec-classify.md

@@ -0,0 +1,170 @@
+---
+description: Classify FE target, load skills, and read all source material for the write-fe-spec workflow
+parent: write-fe-spec
+shard: classify
+standalone: true
+position: 1
+pipeline:
+  position: 5b.1
+  stage: specification
+  predecessors: [write-architecture-spec]
+  successors: [write-fe-spec-write]
+  skills: [resolve-ambiguity, accessibility]
+  calls-bootstrap: false
+requires_placeholders: [LANGUAGE_SKILL, FRONTEND_FRAMEWORK_SKILL, FRONTEND_DESIGN_SKILL, ACCESSIBILITY_SKILL, STATE_MANAGEMENT_SKILL]
+---
+
+// turbo-all
+
+# Write FE Spec — Classify & Read Sources
+
+Identify the target FE spec, classify it, load skills, and read all source material including BE spec, IA shard, cross-references, and deep dives.
+
+**Prerequisite**: BE spec(s) for this feature must be complete (if applicable). Read `docs/plans/be/index.md` to verify.
+
+---
+
+## 0. Placeholder guard
+
+Before any skill reads, verify that the five placeholder values listed in `requires_placeholders` frontmatter 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 0.5.
+
+For the hard stop message format and recovery instructions, see `.agent/skills/prd-templates/references/placeholder-guard-template.md`. For placeholder-to-recovery mappings specific to this workflow, see `.agent/skills/session-continuity/protocols/10-placeholder-verification-gate.md`.
+
+Only proceed to Step 0.5 when all five placeholders report no literal `{{` characters.
+
+---
+
+## 0.5. Brand-guidelines 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` first to establish the design direction before writing FE specs."_
+3. If all placeholders are filled → extract and store for this session: confirmed design direction, color palette, typography choices, motion philosophy, and anti-patterns. These become requirements for every component spec written in this session.
+
+---
+
+## 0.75. Design system prerequisite check
+
+1. Check whether `docs/plans/design-system.md` exists.
+2. If it does not exist → **stop** and tell the user: _"The design system has not been established yet. Run `/create-prd-design-system` to lock navigation paradigm, layout grid, page archetypes, and global state design language before writing FE specs."_
+3. If it exists → read the file and extract all seven decision areas: Navigation Paradigm, Layout Grid, Page Archetypes, Global Component Inventory, Motion Language, Data Density Philosophy, and Global State Design Language.
+4. The extracted decisions are **requirements** for this FE spec — any violation is a rubric failure under Dimension 11 (Design System Consistency).
+5. **Fail-fast validation checks** — verify the following before proceeding. If any check fails, classification must **stop** and instruct the user to run `/create-prd-design-system` to resolve drift before continuing:
+   - **Page archetype match**: At least one page archetype from `design-system.md` applies to the feature being classified. If no archetype matches, the design system is incomplete for this feature.
+   - **Global component / navigation compliance**: The navigation paradigm and Global Component Inventory sections are populated (not empty or placeholder). Every navigation element the FE spec will use must exist in the inventory — re-inventing global components is a rubric failure.
+   - **Global state design language compliance**: The Loading States, Error States, and Empty States sub-sections are populated with confirmed approaches. The FE spec must use these confirmed patterns — inventing loading/error/empty state patterns outside the design language is a rubric failure.
+
+---
+
+## 1. Identify the target spec
+
+Determine which FE spec to write. Match it to its BE spec and IA shard sources (if applicable).
+
+If the BE spec was a multi-domain split (multiple BE specs from one IA shard), determine
+which BE spec(s) this FE spec covers. An FE spec may correspond to:
+- 1 BE spec (most common)
+- N BE specs that share a UI surface (e.g., a dashboard page consuming multiple APIs)
+- 0 BE specs (pure client-side, static content — rare but valid)
+
+## 2. Classify the target
+
+Not every FE spec maps 1:1 to a BE feature spec. Before writing anything, classify the target spec:
+
+| Classification | Description | Source Inputs | How to Detect |
+|---------------|-------------|----------------|---------------|
+| **Feature spec** | Defines UI components, routing, and state for a specific product feature. | 1+ BE specs + 1 IA shard | Maps to a specific IA feature shard; consumes specific API endpoints. |
+| **Cross-cutting** | Defines shared UI patterns, design tokens, layouts, or routing guards. | Tech stack conventions + global IA principles | Numbered `00-*`; no specific BE spec; content is about "how all UI works" not a specific feature. |
+
+**Present the classification and source mapping to the user before proceeding.** Include:
+- The classification and reasoning
+- For feature specs: the BE spec(s) and IA shard it maps to
+- For cross-cutting specs: confirmation that BE spec/IA shard mapping is skipped
+
+## 3. Load skill bundle
+
+Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Read .agent/skills/{{FRONTEND_FRAMEWORK_SKILL}}/SKILL.md
+Read .agent/skills/{{FRONTEND_DESIGN_SKILL}}/SKILL.md and follow its design methodology.
+Read .agent/skills/{{ACCESSIBILITY_SKILL}}/SKILL.md
+Read .agent/skills/{{STATE_MANAGEMENT_SKILL}}/SKILL.md and follow its state management conventions.
+Read .agent/skills/error-handling-patterns/SKILL.md
+Read .agent/skills/testing-strategist/SKILL.md
+Read .agent/skills/technical-writer/SKILL.md
+
+**Missing skill fallback**: If any skill in the bundle above is not installed in `.agent/skills/` and is not in `.agent/skill-library/MANIFEST.md`, read `.agent/skills/find-skills/SKILL.md` and follow its discovery methodology to search for a community equivalent before proceeding without it.
+
+### Ambiguity resolution
+
+When writing the FE spec, if any requirement cannot be resolved from `vision.md`, `architecture-design.md`, `data-placement-strategy.md`, or upstream IA/BE specs, **do not guess**. Instead, load and follow `.agent/skills/resolve-ambiguity/SKILL.md` to systematically resolve the ambiguity before proceeding.
+
+## 4. Read source documents
+
+Read **all** of the following:
+
+### 4a. Conventions and tech stack
+Read the file at `docs/plans/fe/index.md` (conventions template) and the file at `docs/plans/index.md` (master index, tech stack).
+
+### 4b. BE source spec(s) (if Feature spec)
+Read the file at `docs/plans/be/[NN-spec-name].md` (BE source spec(s)). Pay special attention to:
+- Request/Response contracts — these define the data shapes your components will consume
+- Error codes — these define the error states your UI must handle
+- Rate limits — these affect loading/retry UX patterns
+
+### 4c. IA source shard (if Feature spec)
+Read the file at `docs/plans/ia/[NN-shard-name].md` (IA source shard). The FE spec needs the IA shard **in addition to** the BE spec because the IA shard contains:
+- **User flows** — step-by-step interaction sequences the UI must implement
+- **Access model** — which account tiers see which features (drives conditional rendering)
+- **Responsive behavior** — device strategy, breakpoints, mobile-specific behavior
+- **Accessibility specifications** — WCAG requirements, keyboard navigation, screen reader behavior
+- **Edge cases** — UX for error states, empty states, concurrent access scenarios
+- **Junior/age-restricted rules** — content that must be hidden or gated per account type
+
+These are frontend concerns that the BE spec doesn't fully capture.
+
+**Accessibility extraction**: From the IA shard's accessibility specifications, extract every WCAG requirement, keyboard navigation pattern, and screen reader behavior. These MUST appear in the FE spec's component definitions — not as a separate section, but woven into each component's specification. If the IA shard lacks accessibility detail for a given interaction, flag it as a gap and resolve before proceeding.
+
+**Accessibility extraction gate** (Step 4c gate):
+
+Read `.agent/skills/prd-templates/references/fe-classification-procedures.md` § **Accessibility Extraction Gate** and follow its procedure. Build the five-column accessibility inventory table, apply the thin a11y coverage flag (< 3 specs for an interactive feature triggers a user choice gate), and carry the inventory forward as inline annotations in `## Component Inventory` during `/write-fe-spec-write`.
+
+### Step 4c.5 — Conditional rendering enumeration
+
+Read `.agent/skills/prd-templates/references/fe-classification-procedures.md` § **Conditional Rendering Enumeration** and follow its procedure. Build the role × feature rendering matrix from the IA shard's `## Access Control`, map every non-trivial cell to a named component variant, and flag unspecified role × feature combinations with a "define or apply closest-tier default?" gate.
+
+### 4d. Resolve cross-shard references
+If the IA shard references other shards for UI-relevant content (e.g., "navigation behavior
+defined in shard 04", "shared component patterns in shard 12"), read those sections. Build a
+Referenced Material Inventory the same way the BE skill does:
+```
+Primary: 09-playground.md (full shard)
+BE Source: 09a-chat-api.md, 09b-agent-flow-api.md
+Cross-refs:
+  - 04-navigation.md § Dashboard Sidebar (lines 45–60)
+  - 12-resources-settings.md § Appearance & Accessibility (lines 332–347)
+```
+
+### 4e. Read deep dives with FE implications
+Some IA deep dives contain frontend architectural decisions (component phasing, performance
+budgets, UX patterns). Check the BE spec's IA Source Map for referenced deep dives and read
+any that contain FE-relevant decisions.
+
+## 5. Check cross-cutting FE specs
+
+Read any completed cross-cutting FE specs — feature specs must follow their patterns. List the files matching `docs/plans/fe/00-*.md` (cross-cutting specs).
+
+## 6. Present classification and request approval
+
+Call `notify_user` presenting:
+- The classification type and reasoning (from Step 2)
+- The source mapping (which BE spec(s) and IA shard this FE spec covers)
+- The brand-guidelines extraction summary (design direction, colors, typography, anti-patterns extracted in Step 0)
+- **Design System Compliance Check**:
+  - Which page archetype(s) from `design-system.md` this FE spec uses
+  - Confirmation that global components are consumed from the Global Component Inventory (not re-invented)
+  - Confirmation that loading/error/empty states follow the confirmed Global State Design Language
+
+> **Do NOT proceed to `/write-fe-spec-write` until the user confirms the classification and source mapping.**
+
+Once approved, run `/write-fe-spec-write`.
+
+> **Seed the spec file**: After classification is approved, read `.agent/skills/prd-templates/references/fe-spec-template.md` for the **FE Spec Seed Stub** (under the `## FE Spec Seed Stub` heading at the bottom of the file). Also read `.agent/skills/prd-templates/references/be-spec-template.md` for the Referenced Material Inventory format. Create the spec file at `docs/plans/fe/[NN-feature-name].md` using the stub, filling in classification details, Referenced Material Inventory, and Design Requirements from above.
+

package/template/.agent/workflows/write-fe-spec-write.md

@@ -0,0 +1,94 @@
+---
+description: Write FE spec, update indexes, run ambiguity gate, and check for new dependencies for the write-fe-spec workflow
+parent: write-fe-spec
+shard: write
+standalone: true
+position: 2
+pipeline:
+  position: 5b.2
+  stage: specification
+  predecessors: [write-fe-spec-classify]
+  successors: [plan-phase]
+  skills: [technical-writer, accessibility, prd-templates, pipeline-rubrics]
+  calls-bootstrap: true
+---
+
+// turbo-all
+
+# Write FE Spec — Write & Validate
+
+Write the FE spec to `docs/plans/fe/`, update indexes, run quality checks, and present for review.
+
+**Prerequisite**: Read the spec file at `docs/plans/fe/[NN-feature-name].md`. The `## Classification` section, Referenced Material Inventory, and Design Requirements should be present from the classify shard. If the file lacks a `## Classification` section, run `/write-fe-spec-classify` first.
+
+---
+
+## 6. Write the spec to `docs/plans/fe/[NN-feature-name].md`
+
+Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
+Read .agent/skills/accessibility/SKILL.md and follow its methodology.
+Read .agent/skills/testing-strategist/SKILL.md and follow its methodology.
+
+**Naming convention**: Numbered prefix matching feature position + kebab-case name (e.g., `01-auth-ui.md`). Cross-cutting: `00-` prefix.
+
+Read `.agent/skills/prd-templates/references/fe-spec-template.md` for the document structure and quality gates checklist. Follow the conventions from `fe/index.md`.
+
+## 7. Update the FE index
+
+Change the spec's status from 🔲 to ✅ in `docs/plans/fe/index.md`.
+
+## 8. Update spec pipeline
+
+Read `.agent/skills/session-continuity/protocols/08-spec-pipeline-update.md` and follow the **Spec Pipeline Update Protocol** (skip for cross-cutting specs).
+
+## 9. Cross-reference check
+
+Verify:
+- [ ] New spec links back to its BE source spec(s) (if applicable)
+- [ ] New spec links back to its IA source shard (if applicable)
+- [ ] Related FE specs are cross-referenced
+- [ ] Cross-shard referenced material is cited with file + section + line numbers
+
+## 10. Ambiguity gate
+
+Read `.agent/skills/session-continuity/protocols/ambiguity-gates.md` and run:
+
+- **Micro**: Walk each component, prop, interaction, state transition, responsive breakpoint, and a11y rule. Would an implementer need to guess? Fix it now.
+- **Macro**: Would an implementer running `/implement-slice` need to guess anything from this spec? Fix it now.
+- **Two-implementer test**: Would two developers reading only this spec make the same decision? If not — fix it now.
+- **Devil's advocate pass**: "What would a junior developer get wrong?" Fix any revealed gaps.
+
+## 11. Full ambiguity audit (mandatory when last FE spec)
+
+1. Read `docs/plans/fe/index.md`
+2. Check if all FE specs show ✅
+
+**More specs remain**: Proceed to the next spec.
+
+**This is the last FE spec**: Run `/audit-ambiguity fe` now. **Hard gate**: Do NOT propose `/plan-phase` until `/audit-ambiguity fe` scores 0%.
+
+## 12. Check for new dependencies
+
+If this FE spec introduces a new technology:
+1. Identify the stack category (e.g., CHARTS, ANIMATION)
+2. Read `.agent/workflows/bootstrap-agents.md` and fire bootstrap with `PIPELINE_STAGE=write-fe-spec` + the key-value pair
+3. Confirm matching skill installed
+
+## 13. Request review and propose next steps
+
+Read .agent/skills/verification-before-completion/SKILL.md and follow its methodology.
+
+Use `notify_user` presenting:
+1. **Spec created** (link)
+2. **Cross-reference verification**
+3. **Ambiguity Gate confirmation**
+4. **Pipeline State** — read `.agent/progress/spec-pipeline.md` and propose next step
+
+## 14. Navigation Completeness Check
+
+> Runs only when ALL FE shards for the current phase are complete (all ✅ in index).
+
+1. Collect every route across all FE specs
+2. Verify each is reachable from at least one navigation element
+3. Verify navigation structure itself is specced
+4. Flag orphan routes (specced but unreachable) — these block `/plan-phase`