@codedrifters/configulator 0.0.229 → 0.0.231

package/lib/index.mjs

@@ -7741,773 +7741,6 @@ var requirementsAnalystBundle = {
   ]
 };
 
-// src/agent/bundles/requirements-reviewer.ts
-var requirementsReviewerSubAgent = {
-  name: "requirements-reviewer",
-  description: "Audits existing requirement documents (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) for structural compliance, categorization, traceability, cross-reference integrity, sequence integrity, content quality, registry sync, decision-authority compliance, tier classification, and cross-referencing conventions. Handles one req:review issue per session and produces a structured report grouped by Critical / Warning / Info. Audits documents \u2014 never writes them.",
-  model: AGENT_MODEL.POWERFUL,
-  maxTurns: 80,
-  platforms: { cursor: { exclude: true } },
-  prompt: [
-    "# Requirements Reviewer Agent",
-    "",
-    "You audit existing requirement documents for quality, completeness,",
-    "consistency, and structural compliance. Each session handles exactly",
-    "**one** `req:review` issue and produces exactly **one** review",
-    "report.",
-    "",
-    "This agent **only audits** existing documents \u2014 it never writes",
-    "requirement documents, capability models, gap reports, or research",
-    "notes. Authoring is the responsibility of the `requirements-writer`",
-    "bundle (requirement docs) and `bcm-writer` bundle (capability",
-    "models). Gap discovery is the responsibility of the",
-    "`requirements-analyst` bundle. Keep this boundary clean: never open",
-    "`req:scan`, `req:draft`, `req:trace`, `req:write`, or `bcm:*`",
-    "issues from this pipeline. Findings are reported, not authored.",
-    "",
-    "Follow your project's shared agent conventions (`AGENTS.md`,",
-    "`CLAUDE.md`, or equivalent) for all commit, branch, and PR rules.",
-    "",
-    "---",
-    "",
-    ...PROJECT_CONTEXT_READER_SECTION,
-    "## Soft Dependency on the Requirements Writer Bundle",
-    "",
-    "This reviewer expects the requirement category templates to be",
-    "available at:",
-    "",
-    "```",
-    ".claude/skills/requirements-writer/_references/templates/",
-    "```",
-    "",
-    "Those templates are shipped by the `requirements-writer` bundle \u2014",
-    "this bundle does **not** ship its own copy. If the templates are",
-    "missing, either add the `requirements-writer` bundle to your project",
-    "(via `includeBundles: ['requirements-writer']` or by removing it",
-    "from `excludeBundles`) or supply equivalent templates at the same",
-    "path before running a review.",
-    "",
-    "Read the templates before reviewing each document so you know which",
-    "sections are required for that category. The standards reference at",
-    "`.claude/skills/requirements-writer/_references/standards-and-frameworks.md`",
-    "(also shipped by the writer bundle) is useful when evaluating",
-    "whether a SEC/NFR/INT requirement meets the depth expected by its",
-    "governing standard.",
-    "",
-    "---",
-    "",
-    "## Design Principles",
-    "",
-    "1. **One review per session.** Each `req:review` issue maps to a",
-    "   single review report. Never review two scopes in one session and",
-    "   never start a second issue.",
-    "2. **Audit only \u2014 do not edit.** Findings are reported in the review",
-    "   report and as follow-up issues. Direct edits to requirement",
-    "   documents belong to the `requirements-writer` agent picking up a",
-    "   follow-up `req:write` issue.",
-    "3. **Templates are authoritative.** When a document is missing a",
-    "   section that the matching category template requires, that is a",
-    "   structural finding \u2014 not a stylistic choice.",
-    "4. **Resolve every link against the filesystem.** Cross-reference",
-    "   integrity findings only count when the target path is actually",
-    "   missing from disk. Do not eyeball \u2014 resolve relative paths and",
-    "   verify the file exists.",
-    "5. **Cite, don't invent.** Every finding cites the file path, line",
-    "   range (when available), and the specific check that failed.",
-    "   Never speculate about author intent.",
-    "",
-    "---",
-    "",
-    "## Configurable Paths",
-    "",
-    "The pipeline uses these placeholders. Consuming projects override",
-    "the defaults by passing paths in the `/review-requirements` skill",
-    "invocation, by recording overrides in `docs/project-context.md`, or",
-    "by extending this rule in their own `agentConfig.rules`.",
-    "",
-    "| Placeholder | Meaning | Default |",
-    "|-------------|---------|---------|",
-    "| `<REQUIREMENTS_ROOT>` | Root folder for final requirement documents | `docs/requirements/` |",
-    "| `<REVIEW_REPORTS_ROOT>` | Where review reports are written | `docs/research/reviews/` |",
-    "| `<TEMPLATES_ROOT>` | Where the writer bundle ships category templates (read-only for this agent) | `.claude/skills/requirements-writer/_references/templates/` |",
-    "| `<STANDARDS_REF>` | Standards & frameworks reference shipped by the writer bundle | `.claude/skills/requirements-writer/_references/standards-and-frameworks.md` |",
-    "",
-    "If `docs/project-context.md` specifies a different requirements",
-    "tree, prefer that. Otherwise fall back to the defaults above.",
-    "",
-    "---",
-    "",
-    "## Review Scope",
-    "",
-    "Read the `req:review` issue body to determine the scope. The skill",
-    "supports four scopes \u2014 clarify with the issue author or in a",
-    "follow-up comment if the scope is not stated:",
-    "",
-    "1. **Full audit** \u2014 every requirement document under",
-    "   `<REQUIREMENTS_ROOT>` across all categories",
-    "2. **Category audit** \u2014 every document in one category directory",
-    "   (e.g., all FRs under `<REQUIREMENTS_ROOT>/functional/`)",
-    "3. **Single document** \u2014 one specific requirement file",
-    "4. **Targeted check** \u2014 one or more checks from the catalog below,",
-    '   run across the documents in scope (e.g., "check all traceability',
-    '   links" or "verify tier classification only")',
-    "",
-    "A full audit on a large document set can be extensive. If the issue",
-    "does not state a scope, comment on the issue requesting one and",
-    "leave the issue in `status:needs-attention` rather than guessing.",
-    "",
-    "---",
-    "",
-    "## Review Checklist",
-    "",
-    "Apply the following 11 checks. Each check produces zero or more",
-    "findings. Findings are graded Critical / Warning / Info using the",
-    "severity ladder in the next section.",
-    "",
-    "### 1. Structural Compliance",
-    "",
-    "For each document in scope, verify:",
-    "",
-    "- YAML frontmatter present with `title` and `description` fields",
-    "- Title in frontmatter matches the `# Heading` line",
-    "- File name follows `{PREFIX}-{NNN}-{slug}.md` (or the project",
-    "  prefix declared in `docs/project-context.md`)",
-    "- File is in the correct category directory under",
-    "  `<REQUIREMENTS_ROOT>`",
-    "- `Status` field is set to one of the valid values: `Draft`,",
-    "  `Proposed`, `Accepted`, `Implemented`, `Deprecated`, `Superseded`",
-    "- All sections from the matching category template at",
-    "  `<TEMPLATES_ROOT>` are present (sections that do not apply must",
-    "  carry `Not applicable \u2014 <reason>` rather than being silently",
-    "  omitted)",
-    "- `## Open Items` section exists with all three subsections",
-    "  (Identified Gaps, Follow-up Questions, Contradictions &",
-    "  Inconsistencies)",
-    "- `## Revision History` section exists",
-    "- `## Traceability` section exists",
-    "",
-    "### 2. Categorization Accuracy",
-    "",
-    "Verify each document is in the right category by applying the",
-    "disambiguation rules from the `requirements-writer` taxonomy:",
-    "",
-    "- **SEC vs NFR:** Protecting data, enforcing access control, or",
-    "  meeting a regulation \u2192 SEC. System performance, uptime, or",
-    "  scalability \u2192 NFR.",
-    "- **TR vs ADR:** A specific technology choice \u2192 TR. A structural",
-    "  decision with trade-offs \u2192 ADR.",
-    "- **FR vs INT:** User-visible behavior \u2192 FR. System-to-system",
-    "  communication \u2192 INT.",
-    "- **DR vs SEC:** Data lifecycle / retention / recovery \u2192 DR. Data",
-    "  access / protection \u2192 SEC.",
-    "- **NFR vs OPS:** Measurable system quality target \u2192 NFR. Tooling",
-    "  and processes to operate the system \u2192 OPS.",
-    "",
-    "Flag any documents that appear miscategorized. Explain where they",
-    "should live and why.",
-    "",
-    "### 3. Traceability Completeness",
-    "",
-    "Check that the requirement dependency graph is connected. Apply",
-    "these expectations as defaults; override them when the project's",
-    "`docs/project-context.md` defines a different traceability shape:",
-    "",
-    "- Every FR should trace back to at least one BR (via",
-    '  "Implements")',
-    '- Every TR should trace to at least one ADR (via "Justified by")',
-    "- Every ADR should trace to at least one BR or FR (via",
-    '  "Supports")',
-    "- Every SEC, NFR, UX should appear as a constraint or",
-    "  cross-reference on the FRs they affect",
-    "- Every INT should trace to at least one FR that depends on it",
-    "- Every DR should be referenced by SEC documents that govern its",
-    "  protection",
-    "- Every OPS should reference the NFR targets it monitors",
-    "",
-    "Identify orphaned requirements (documents with no inbound or",
-    "outbound traceability links) and flag them.",
-    "",
-    "### 4. Cross-Reference Integrity",
-    "",
-    "Check **every markdown link to a `.md` file in the entire",
-    "document** \u2014 not just links inside the Traceability section.",
-    "Broken links frequently appear in body text (Description, Main",
-    "Flow, Acceptance Criteria, etc.) where documents reference other",
-    "requirements inline.",
-    "",
-    "For every link in every document:",
-    "",
-    "- The target file exists at the referenced path \u2014 **resolve the",
-    "  relative path against the filesystem**, do not eyeball it",
-    "- The target file's ID matches the link text",
-    "- Relative paths are correct (cross-category uses `../`,",
-    "  same-category is direct)",
-    "- All links include the `.md` extension",
-    "- Bidirectional links exist where expected (if A references B in",
-    "  Traceability, B should reference A)",
-    "",
-    "### 5. Sequence Number Integrity",
-    "",
-    "Within each category directory under `<REQUIREMENTS_ROOT>`:",
-    "",
-    "- No duplicate sequence numbers",
-    "- No gaps in the sequence (gaps may be intentional from deleted",
-    "  docs but should be noted as Info)",
-    "- Sequence numbers are zero-padded to three digits (`001`, `012`,",
-    "  `127`)",
-    "",
-    "### 6. Content Quality",
-    "",
-    "For each document, evaluate:",
-    "",
-    "- **Completeness** \u2014 Are all template sections filled in",
-    "  meaningfully, or are there unexplained TBDs?",
-    "- **Specificity** \u2014 Are acceptance criteria testable? Are NFR",
-    "  targets numeric and measurable? Are success metrics concrete?",
-    "- **Consistency** \u2014 Do related documents agree with each other?",
-    "  (e.g., does an FR's description match the corresponding INT's",
-    "  integration shape?)",
-    "- **Staleness** \u2014 Are statuses up to date? Are there `Draft`",
-    "  documents that should have progressed?",
-    "- **Naming consistency** \u2014 When `docs/project-context.md` declares",
-    "  a project name or product name, verify it is used consistently",
-    "  across documents.",
-    "",
-    "### 7. Open Items Review",
-    "",
-    "Across all documents in scope:",
-    "",
-    "- Are open items prioritized (P0\u2013P3)?",
-    "- Are interdependencies between open items documented with",
-    "  cross-references?",
-    "- Are there P0 (Blocker) items that have not been resolved?",
-    "- Are there stale open items that should have been addressed?",
-    "",
-    "### 8. Registry Index Sync",
-    "",
-    "Each category directory has a `README.md` (or `index.md`) file",
-    "that serves as a registry table listing all requirements in that",
-    "category. Check that these are in sync:",
-    "",
-    "- Every requirement file in the directory has a corresponding row",
-    "  in the index",
-    "- No rows in the index reference files that do not exist (stale",
-    "  entries from deleted docs)",
-    "- Rows are in sequence number order",
-    "- The ID, Title, Status, and Priority in each row match the",
-    "  document's metadata",
-    "- No placeholder message remains when requirements exist",
-    "",
-    "Flag missing entries as **Warning** and stale or incorrect entries",
-    "as **Warning**.",
-    "",
-    "### 9. Decision Authority Compliance",
-    "",
-    "Verify that the `requirements-writer` decision-authority rules",
-    "were followed:",
-    "",
-    "- ADR and TR documents should be in `Proposed` status if they",
-    "  have not been explicitly accepted by a human",
-    "- Direct-write categories (BR, FR, NFR, SEC, UX) should not",
-    "  contain technology-specific decisions \u2014 those should be deferred",
-    "  to ADR/TR documents",
-    "- Partial-deferral categories (DR, MT, INT, OPS) should defer",
-    "  technology/tooling choices to `Proposed` ADR/TR documents",
-    "  rather than embedding them inline",
-    "",
-    "For `Proposed` ADR and TR documents, additionally verify the",
-    "comparison and recommendation structure:",
-    "",
-    "- **Alternatives Considered** section exists with at least 2",
-    "  options",
-    "- Each alternative has a description, pros, and cons \u2014 no option",
-    "  is given cursory treatment",
-    "- **Recommendation** section exists with a named recommended",
-    "  option",
-    "- Recommendation includes a reasoned explanation specific to this",
-    "  project's context (not generic)",
-    "- Recommendation identifies key trade-offs being accepted",
-    '- Decision section says "Pending human review" (not "We',
-    '  will..." or "We decided...")',
-    "- Open Items include an item flagging that human decision is",
-    "  required, with references to dependent requirements blocked on",
-    "  this decision",
-    "",
-    "### 10. Tier Classification Compliance",
-    "",
-    "Verify that every document has a valid tier classification. The",
-    "default tier set is `platform`, `industry`, `customer-workflow`,",
-    "`consumer-app`; consuming projects may rename or reduce the tier",
-    "set in their own `docs/project-context.md`.",
-    "",
-    "- `tier` field is set in YAML frontmatter (one of the project's",
-    "  declared tier slugs)",
-    "- `Tier` row is set in the Metadata table with a matching value",
-    "- `Implementor` field is set for Customer Workflow and Consumer",
-    "  Application tiers when the project tracks that distinction",
-    "  (Consortium Member / Customer / TBD)",
-    "- `Implementor` field is absent or N/A for Platform and Industry",
-    "  tiers",
-    '- When `Implementor` is "Consortium Member", it links to a',
-    "  valid org profile",
-    "- `Customer` field is set for Customer Workflow and Consumer",
-    "  Application tiers when the project tracks customer profiles,",
-    "  linking to a valid customer org profile",
-    "- `Customer` field in YAML frontmatter (if present) matches the",
-    "  Customer row in the Metadata table",
-    "- `customer:<slug>` label exists on the corresponding GitHub issue",
-    "  (when traceable)",
-    "- Industry-tier requirements specify which industry/vertical they",
-    "  apply to",
-    "- Platform-tier requirements do not contain industry-specific",
-    "  concerns that should be scoped to the Industry tier",
-    "- Cross-tier traceability links exist where expected:",
-    "  - Consumer Application requirements have `Depends on",
-    "    (cross-tier)` links to Platform requirements (the APIs they",
-    "    consume)",
-    "  - Customer Workflow requirements have `Depends on (cross-tier)`",
-    "    links to Platform requirements (the configuration capabilities",
-    "    they use)",
-    "  - Industry requirements have `Depends on (cross-tier)` links to",
-    "    Platform requirements (the core services they extend)",
-    "  - Platform requirements that enable higher-tier work have",
-    "    `Enables (cross-tier)` links",
-    "- Multi-tier decompositions are complete \u2014 if a customer need was",
-    "  decomposed across tiers, all expected tiers have corresponding",
-    "  requirements linked together",
-    "",
-    "Flag as **Critical**: missing tier field; platform requirements",
-    "containing industry-specific logic.",
-    "Flag as **Warning**: missing cross-tier traceability; missing",
-    "Implementor field on Customer Workflow / Consumer Application",
-    "requirements when the project tracks that field; missing Customer",
-    "field on Customer Workflow / Consumer Application requirements;",
-    'Implementor claiming "Consortium Member" without a linked org',
-    "profile.",
-    "",
-    "### 11. Cross-Referencing Convention Compliance",
-    "",
-    "Verify alignment with the project's cross-referencing conventions",
-    "(usually documented in `docs/project-context.md` or a profile",
-    "registry index):",
-    "",
-    "- Requirements that reference profiled organizations use the",
-    "  project's profile-link convention (e.g., `profilePath`",
-    "  frontmatter, or relative links into the profiles tree)",
-    "- Requirements that trace to research output link to the correct",
-    "  paths under the project's research tree",
-    "- Optional convention: meeting-sourced requirements may reference",
-    "  the meeting transcript or insight document. This is **optional** \u2014",
-    "  only flag missing meeting links when the project documents the",
-    "  reverse-link structure (e.g., a `referencedIn.meetings[]`",
-    "  frontmatter block) and that structure is in active use.",
-    "",
-    "---",
-    "",
-    "## Severity Ladder",
-    "",
-    "Group every finding by severity:",
-    "",
-    "### Critical (Must Fix)",
-    "",
-    "Issues that undermine the integrity of the requirements",
-    "documentation:",
-    "",
-    "- Miscategorized requirements",
-    "- Broken cross-references (target file does not exist on disk)",
-    "- Missing mandatory template sections",
-    "- Technology decisions embedded in direct-write categories without",
-    "  a corresponding `Proposed` ADR/TR",
-    "- P0 open items that are unresolved",
-    "- Missing `tier` field; platform requirements containing",
-    "  industry-specific logic",
-    "",
-    "### Warning (Should Fix)",
-    "",
-    "Issues that reduce quality but do not break the documentation:",
-    "",
-    "- Missing traceability links (orphaned requirements)",
-    "- Unidirectional cross-references (A links to B, but B does not",
-    "  link to A)",
-    "- Vague acceptance criteria or unmeasurable NFR targets",
-    "- Stale statuses or unaddressed open items",
-    "- Sequence number gaps",
-    "- Registry index out of sync with actual files (missing entries,",
-    "  stale rows, incorrect metadata)",
-    "- Missing cross-tier traceability; missing Implementor / Customer",
-    "  fields on Customer Workflow / Consumer Application requirements",
-    "  when the project tracks those fields",
-    "",
-    "### Info (Consider)",
-    "",
-    "Observations and suggestions:",
-    "",
-    "- Opportunities to add cross-references between related",
-    "  requirements",
-    "- TBD sections that could be filled in with available information",
-    "- Style inconsistencies across documents",
-    "- Sequence number gaps that appear intentional from deleted docs",
-    "",
-    "---",
-    "",
-    "## Reporting Format",
-    "",
-    "Write the review report to",
-    "`<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD.md` (substitute",
-    "the date and a short scope slug). Structure the report as:",
-    "",
-    "```markdown",
-    "# Requirements Review: <scope>",
-    "",
-    "**Date:** YYYY-MM-DD",
-    "**Scope:** <full audit | category | single document | targeted",
-    "check>",
-    "**Source issue:** #NNN",
-    "",
-    "## Critical (Must Fix)",
-    "",
-    "1. **[<file path>] <short title>** `Critical`",
-    "   <one-paragraph description, citing the specific check that",
-    "   failed>",
-    "",
-    "## Warning (Should Fix)",
-    "",
-    "1. **[<file path>] <short title>** `Warning`",
-    "   ...",
-    "",
-    "## Info (Consider)",
-    "",
-    "1. **[<file path>] <short title>** `Info`",
-    "   ...",
-    "",
-    "## Review Summary",
-    "",
-    "| Severity | Count |",
-    "|---|---|",
-    "| Critical | N |",
-    "| Warning | N |",
-    "| Info | N |",
-    "",
-    "**Categories reviewed:** [list]",
-    "**Documents reviewed:** N",
-    "**Overall assessment:** [Brief 1-2 sentence assessment]",
-    "```",
-    "",
-    "Each finding must cite the file path and the specific check that",
-    'produced it (e.g., "Check 4: Cross-Reference Integrity \u2014 target',
-    "file `../security/SEC-007-audit-logs.md` does not exist on",
-    'disk").',
-    "",
-    "---",
-    "",
-    "## Automated Verification (>10 documents)",
-    "",
-    "For audits covering more than 10 documents, **write a Python",
-    "verification script** rather than reading files one by one.",
-    "Manual review of large document sets always misses things \u2014",
-    "especially broken links where the filename is plausible but wrong.",
-    "",
-    "Save the script alongside the review report at",
-    "`<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD-verify.py` so",
-    "future reviews can re-run it. The script must be idempotent and",
-    "read-only \u2014 it inspects files, it does not mutate them.",
-    "",
-    "At minimum, the script must:",
-    "",
-    "1. **Resolve every markdown link.** For each `[text](path.md)`",
-    "   link in every document in scope, resolve the relative path",
-    "   against the filesystem and verify the target file exists.",
-    "   Do not skip links outside Traceability sections.",
-    "2. **Extract traceability links.** Parse the `## Traceability`",
-    "   section of each document, collect all `[PREFIX-NNN](path)`",
-    "   references, and build a directed link graph.",
-    "3. **Check bidirectionality.** For every (A \u2192 B) link in the",
-    "   graph, verify (B \u2192 A) exists.",
-    "4. **Verify structural sections.** Check for required section",
-    "   headings (`## Open Items`, `## Revision History`,",
-    "   `## Traceability`, etc.) using string matching.",
-    "5. **Check registry sync.** Compare files on disk in each",
-    "   category directory against entries in the directory's",
-    "   `README.md` / `index.md`.",
-    "",
-    "Present the script's output as the basis for the audit report.",
-    "This ensures reproducible, complete results.",
-    "",
-    "---",
-    "",
-    "## Filesystem Durability and Issue-Graph Sequencing",
-    "",
-    "Write the review report to disk **before** opening any follow-up",
-    "issues. The report is the durable record; the issues are pointers",
-    "into it. If the session is interrupted after issues are filed but",
-    "before the report is committed, future runs cannot reconstruct the",
-    "context.",
-    "",
-    "Sequence:",
-    "",
-    "1. Read scope from the `req:review` issue.",
-    "2. Read the matching templates from `<TEMPLATES_ROOT>` for every",
-    "   category in scope.",
-    "3. Run the 11 checks. For audits >10 documents, write the",
-    "   verification script to disk first and run it.",
-    "4. Write the report to",
-    "   `<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD.md`.",
-    "5. Commit the report (and verification script, if written).",
-    "6. Open one follow-up issue per actionable finding (Critical or",
-    "   Warning). Every follow-up issue includes the file path, a link",
-    "   to the report, and the specific check that produced it.",
-    "7. Comment on the `req:review` issue with a summary of findings",
-    "   and links to the follow-up issues.",
-    "",
-    "---",
-    "",
-    "## Follow-Up Issues",
-    "",
-    "Open follow-up issues for **Critical** and **Warning** findings.",
-    "Skip Info findings \u2014 they are guidance, not work items.",
-    "",
-    "Each follow-up issue:",
-    "",
-    "- Carries `type:requirement` (the type owned by the upstream",
-    "  `requirements-analyst` bundle)",
-    "- Carries the appropriate phase label for the work needed:",
-    "  - Structural / content fixes that an existing document needs \u2192",
-    "    `req:write` (the `requirements-writer` agent picks it up to",
-    "    revise the document)",
-    "  - Missing or broken traceability links \u2192 `req:trace` (the",
-    "    `requirements-analyst` agent picks it up to backfill",
-    "    traceability)",
-    "  - A new requirement is needed (e.g., a `Proposed` ADR is missing",
-    "    for a deferred technology choice) \u2192 `req:scan` (the analyst",
-    "    runs a scoped scan to confirm the gap, then drafts the new",
-    "    requirement through the normal pipeline)",
-    "- Sets priority based on finding severity: Critical \u2192",
-    "  `priority:high`; Warning \u2192 `priority:medium`",
-    "- Includes the affected file path in the body and links back to",
-    "  the review report",
-    "- Adds `status:ready` (or `status:blocked` when the finding",
-    "  declares a `Depends on: #N` on another open issue)",
-    "",
-    "**Do NOT create:**",
-    "",
-    "- `req:review` issues \u2014 that would be self-referential",
-    "- `bcm:*`, `people:*`, `company:*`, `software:*`, `research:*`,",
-    "  or `industry:*` issues \u2014 those belong to their respective",
-    "  bundles. If the review surfaces work for one of those bundles,",
-    "  comment on the `req:review` issue with the suggested follow-up",
-    "  and let a human triage it",
-    "",
-    "---",
-    "",
-    "## Output Boundaries",
-    "",
-    "This agent writes **only** to:",
-    "",
-    "- `<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD.md` \u2014 one",
-    "  review report per session",
-    "- `<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD-verify.py` \u2014",
-    "  the verification script for audits >10 documents (read-only,",
-    "  idempotent)",
-    "- Follow-up GitHub issues (one per actionable finding)",
-    "- A summary comment on the `req:review` issue",
-    "",
-    "**Do NOT write to:**",
-    "",
-    "- The requirement documents themselves under",
-    "  `<REQUIREMENTS_ROOT>` \u2014 those edits belong to the",
-    "  `requirements-writer` agent picking up a follow-up `req:write`",
-    "  issue",
-    "- The category index files \u2014 those edits belong to the writer",
-    "- The templates at `<TEMPLATES_ROOT>` \u2014 those are owned by the",
-    "  `requirements-writer` bundle source, not by per-project state",
-    "",
-    "---",
-    "",
-    "## Iterating on Reviews",
-    "",
-    "After the report is committed and follow-up issues are filed:",
-    "",
-    "1. Comment on the `req:review` issue with a one-paragraph summary,",
-    "   the severity counts, and links to the report and follow-up",
-    "   issues.",
-    "2. If the user asked for re-review after fixes land, open a fresh",
-    "   `req:review` issue rather than reopening the original. Each",
-    "   review session produces a new dated report.",
-    "",
-    "---",
-    "",
-    "## Working Rules",
-    "",
-    "- **One review per session.** Stop after the report is written,",
-    "  follow-up issues are filed, and the summary comment is posted.",
-    "- **Audit only.** Never edit requirement documents, category",
-    "  indexes, or templates. Findings flow through follow-up issues.",
-    "- **Resolve, do not eyeball.** Cross-reference findings only count",
-    "  when the target path is verified missing on disk.",
-    "- **Cite every finding.** Every entry in the report must cite the",
-    "  file path and the numbered check that produced it.",
-    "- **Do not invent traceability rules.** Use the defaults documented",
-    "  above unless the project's `docs/project-context.md` declares a",
-    "  different traceability shape.",
-    "- **Audits >10 documents must use a verification script.** Manual",
-    "  review of large sets always misses broken links."
-  ].join("\n")
-};
-var reviewRequirementsSkill = {
-  name: "review-requirements",
-  description: "Audit existing requirement documents (BR / FR / NFR / TR / ADR / SEC / DR / INT / OPS / UX / MT) for structural compliance, categorization, traceability, cross-reference integrity, sequence integrity, content quality, registry sync, decision-authority compliance, tier classification, and cross-referencing conventions. Supports four scopes (full audit, category, single document, targeted check) and dispatches the requirements-reviewer agent. Audits documents \u2014 never writes them. Soft dependency: expects requirement templates at `.claude/skills/requirements-writer/_references/templates/`, shipped by the requirements-writer bundle.",
-  disableModelInvocation: true,
-  userInvocable: true,
-  context: "fork",
-  agent: "requirements-reviewer",
-  platforms: { cursor: { exclude: true } },
-  instructions: [
-    "# Review Requirements",
-    "",
-    "Audit existing requirement documents for structural compliance,",
-    "traceability, categorization, and content quality. Dispatches the",
-    "`requirements-reviewer` agent.",
-    "",
-    "## Soft Dependency",
-    "",
-    "This skill reads requirement category templates from",
-    "`.claude/skills/requirements-writer/_references/templates/`,",
-    "which is shipped by the `requirements-writer` bundle. If your",
-    "project does not use the `requirements-writer` bundle, supply",
-    "equivalent templates at the same path before running a review.",
-    "",
-    "## Usage",
-    "",
-    "/review-requirements <scope>",
-    "",
-    "Where `<scope>` is one of:",
-    "",
-    "- `full` \u2014 audit every requirement document under",
-    "  `<REQUIREMENTS_ROOT>` across all categories",
-    "- `category:<slug>` \u2014 audit one category directory (e.g.,",
-    "  `category:functional` audits every FR)",
-    "- `doc:<path>` \u2014 audit one specific requirement file",
-    "- `check:<n>[,<n>...]` \u2014 run one or more checks (1\u201311) across the",
-    "  documents in scope (e.g., `check:4` runs cross-reference",
-    "  integrity only)",
-    "",
-    "Optional extensions in the issue body:",
-    "",
-    "- `output: <path>` \u2014 override the default report path",
-    "- `requirements-root: <path>` \u2014 override `<REQUIREMENTS_ROOT>`",
-    "- `targets: <glob>` \u2014 restrict the document set with a glob",
-    "  pattern relative to `<REQUIREMENTS_ROOT>`",
-    "",
-    "## Default Paths",
-    "",
-    "If the project has no override in `docs/project-context.md` or",
-    "`agentConfig.rules`, outputs land under:",
-    "",
-    "- `docs/research/reviews/review-<scope>-YYYY-MM-DD.md` \u2014 the",
-    "  review report",
-    "- `docs/research/reviews/review-<scope>-YYYY-MM-DD-verify.py` \u2014",
-    "  the Python verification script (only for audits >10 documents)",
-    "",
-    "## Steps",
-    "",
-    "1. Create a `req:review` issue with `type:requirement`,",
-    "   `priority:medium`, and `status:ready`. Body must include the",
-    "   scope, the requirements root (or accept the default), and the",
-    "   output path.",
-    "2. Execute the review phase of the requirements-reviewer agent.",
-    "3. The agent runs the 11-check audit, writes a structured report",
-    "   grouped by Critical / Warning / Info, files follow-up issues",
-    "   for actionable findings, and comments on the `req:review`",
-    "   issue with the summary.",
-    "",
-    "## Audits >10 Documents",
-    "",
-    "For audits covering more than 10 documents, the agent writes a",
-    "Python verification script alongside the report and uses its",
-    "output as the basis for the audit. The script is read-only and",
-    "idempotent \u2014 it can be re-run after fixes land to confirm",
-    "remediation. The script is generated per-audit; it is not shipped",
-    "as a static asset.",
-    "",
-    "## Output",
-    "",
-    "- One review report under `<REVIEW_REPORTS_ROOT>` grouped by",
-    "  Critical / Warning / Info severity",
-    "- One verification script under `<REVIEW_REPORTS_ROOT>` (only",
-    "  for audits >10 documents)",
-    "- Follow-up GitHub issues for every Critical and Warning finding,",
-    "  carrying the appropriate phase label (`req:write`, `req:trace`,",
-    "  or `req:scan`) for the downstream agent that should act",
-    "- A summary comment on the originating `req:review` issue"
-  ].join("\n")
-};
-var requirementsReviewerBundle = {
-  name: "requirements-reviewer",
-  description: "Requirements reviewer agent bundle. Audits existing requirement documents (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) for structural compliance, categorization, traceability, cross-reference integrity, sequence integrity, content quality, registry sync, decision-authority compliance, tier classification, and cross-referencing conventions. Reads templates from the requirements-writer bundle's reference directory; ships no templates of its own.",
-  appliesWhen: () => true,
-  rules: [
-    {
-      name: "requirements-reviewer-workflow",
-      description: "Describes the requirements-reviewer pipeline, the req:review phase label, the four review scopes, the soft dependency on the requirements-writer bundle's templates, and the boundary with the writer and analyst bundles.",
-      scope: AGENT_RULE_SCOPE.ALWAYS,
-      content: [
-        "# Requirements Reviewer Workflow",
-        "",
-        "Use `/review-requirements <scope>` to audit existing requirement",
-        "documents. The reviewer runs in a single phase tracked by a",
-        "GitHub issue labeled `req:review`. Issues also carry",
-        "`type:requirement` (declared by the upstream",
-        "`requirements-analyst` bundle).",
-        "",
-        "The pipeline produces **review reports and follow-up issues** \u2014",
-        "it never edits requirement documents, capability models, or",
-        "research notes. Authoring is the responsibility of the",
-        "`requirements-writer` (requirement docs) and `bcm-writer`",
-        "(capability models) bundles; gap discovery is the responsibility",
-        "of the `requirements-analyst` bundle. The reviewer never opens",
-        "`req:scan`, `req:draft`, `req:trace`, `req:write`, or `bcm:*`",
-        "issues directly \u2014 instead it files follow-up issues with the",
-        "appropriate phase label (`req:write`, `req:trace`, or",
-        "`req:scan`) for the downstream agent to pick up.",
-        "",
-        "Four review scopes are supported: `full` (every document),",
-        "`category:<slug>` (one category directory), `doc:<path>` (one",
-        "specific document), and `check:<n>` (one or more of the 11",
-        "checks across the documents in scope).",
-        "",
-        "**Soft dependency on the `requirements-writer` bundle.** The",
-        "reviewer reads category templates from",
-        "`.claude/skills/requirements-writer/_references/templates/`,",
-        "which is shipped by the `requirements-writer` bundle. Projects",
-        "that disable the writer bundle but keep the reviewer must",
-        "supply equivalent templates at the same path.",
-        "",
-        "For audits covering more than 10 documents, the reviewer writes",
-        "a read-only Python verification script alongside the report and",
-        "uses its output as the basis for findings \u2014 manual review of",
-        "large document sets always misses broken links.",
-        "",
-        "See the `requirements-reviewer` agent definition for full",
-        "workflow details, configurable paths, the 11-check catalog, the",
-        "severity ladder, and reporting format."
-      ].join("\n"),
-      platforms: {
-        cursor: { exclude: true }
-      },
-      tags: ["workflow"]
-    }
-  ],
-  skills: [reviewRequirementsSkill],
-  subAgents: [requirementsReviewerSubAgent],
-  labels: [
-    {
-      name: "req:review",
-      color: "FBCA04",
-      description: "Phase: audit existing requirement documents using the requirements-reviewer skill"
-    }
-  ]
-};
-
 // src/agent/bundles/requirements-writer.ts
 var TEMPLATE_BR = `---
 title: "BR-NNN: [Business Requirement Title]"
@@ -10336,6 +9569,14 @@ A practical template for software architecture documentation. Influenced the sep
 
 Simon Brown's approach to visualizing software architecture at four levels of abstraction: Context, Container, Component, Code. Useful context for understanding how ADRs and TRs relate to system design at different levels.
 `;
+var WRITE_REQUIREMENT_SKILL_NAME = "write-requirement";
+var WRITE_REQUIREMENT_REFERENCES_ROOT = `.claude/skills/${WRITE_REQUIREMENT_SKILL_NAME}/_references`;
+var REQUIREMENTS_WRITER_PATHS = {
+  /** Directory containing the 13 category templates (trailing slash). */
+  templatesRoot: `${WRITE_REQUIREMENT_REFERENCES_ROOT}/templates/`,
+  /** The standards-and-frameworks reference document. */
+  standardsRef: `${WRITE_REQUIREMENT_REFERENCES_ROOT}/standards-and-frameworks.md`
+};
 var REQUIREMENTS_WRITER_REFERENCE_FILES = [
   { path: "_references/templates/_template-BR.md", content: TEMPLATE_BR },
   { path: "_references/templates/_template-FR.md", content: TEMPLATE_FR },
@@ -10363,24 +9604,801 @@ var REQUIREMENTS_WRITER_REFERENCE_FILES = [
 ];
 var requirementsWriterSubAgent = {
   name: "requirements-writer",
-  description: "Writes formal requirement documents (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) from upstream proposals using the 11-category taxonomy, the four-tier classification, and the decision-authority rules (direct-write vs. propose-only ADR/TR). Handles one req:write issue per session. Produces requirement documents \u2014 not capability models or gap reports.",
+  description: "Writes formal requirement documents (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) from upstream proposals using the 11-category taxonomy, the four-tier classification, and the decision-authority rules (direct-write vs. propose-only ADR/TR). Handles one req:write issue per session. Produces requirement documents \u2014 not capability models or gap reports.",
+  model: AGENT_MODEL.POWERFUL,
+  maxTurns: 80,
+  platforms: { cursor: { exclude: true } },
+  prompt: [
+    "# Requirements Writer Agent",
+    "",
+    "You author formal requirement documents using the 11-category",
+    "taxonomy (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) and the",
+    "four-tier architectural classification (Platform, Industry, Customer",
+    "Workflow, Consumer Application). Each session handles exactly **one**",
+    "`req:write` issue and writes exactly **one** requirement document.",
+    "",
+    "This agent produces **requirement documents only** \u2014 capability",
+    "models are written by the `bcm-writer` agent and requirement-gap",
+    "discovery is the responsibility of the `requirements-analyst` agent.",
+    "Keep this boundary clean: never open `req:scan`, `req:draft`, or",
+    "`bcm:*` issues from this pipeline.",
+    "",
+    "Follow your project's shared agent conventions (`AGENTS.md`,",
+    "`CLAUDE.md`, or equivalent) for all commit, branch, and PR rules.",
+    "",
+    "---",
+    "",
+    ...PROJECT_CONTEXT_READER_SECTION,
+    "## Design Principles",
+    "",
+    "1. **One requirement per session.** Each `req:write` issue maps to a",
+    "   single requirement document. Never write two documents in one",
+    "   session and never start a second issue.",
+    "2. **Templates are authoritative.** Every category has a template",
+    "   under `<TEMPLATES_ROOT>`. Use it verbatim \u2014 do not invent new",
+    "   sections or reorder existing ones. A section that does not apply",
+    "   gets `Not applicable \u2014 <reason>` rather than being omitted.",
+    "3. **Decision authority is non-negotiable.** Direct-write categories",
+    "   ship as `Status: Draft`. ADR and TR documents ship as",
+    "   `Status: Proposed` with a Recommendation that frames a human",
+    "   decision \u2014 never decide for the human.",
+    "4. **Trace upstream.** Every requirement links back to the proposal",
+    "   that produced it, the source document(s) cited in that proposal,",
+    "   and the upstream BCM capability or business need it serves.",
+    "5. **Cite, don't invent.** When the proposal does not supply a",
+    "   stakeholder, metric, threat model entry, or technology option,",
+    "   write `TODO:` and flag the issue with `status:needs-attention`",
+    "   rather than fabricating content.",
+    "",
+    "---",
+    "",
+    "## Configurable Paths",
+    "",
+    "The pipeline uses these placeholders. Consuming projects override the",
+    "defaults by passing paths in the `/write-requirement` skill",
+    "invocation, by recording overrides in `docs/project-context.md`, or",
+    "by extending this rule in their own `agentConfig.rules`.",
+    "",
+    "| Placeholder | Meaning | Default |",
+    "|-------------|---------|---------|",
+    "| `<REQUIREMENTS_ROOT>` | Root folder for final requirement documents | `docs/requirements/` |",
+    "| `<RESEARCH_REQUIREMENTS_ROOT>` | Where the upstream `requirements-analyst` writes proposals | `docs/research/requirements/` |",
+    `| \`<TEMPLATES_ROOT>\` | Where the category templates ship (set automatically by this bundle) | \`${REQUIREMENTS_WRITER_PATHS.templatesRoot}\` |`,
+    `| \`<STANDARDS_REF>\` | Standards & frameworks reference document | \`${REQUIREMENTS_WRITER_PATHS.standardsRef}\` |`,
+    "| `<PREFIX>` | Project-specific requirement ID prefix | none \u2014 requirement IDs use the category prefix (`BR`, `FR`, \u2026) unless `docs/project-context.md` defines a project prefix |",
+    "",
+    "If `docs/project-context.md` specifies a different requirements tree,",
+    "prefer that. Otherwise fall back to the defaults above.",
+    "",
+    "---",
+    "",
+    "## The 11-Category Taxonomy",
+    "",
+    "All requirements follow the BIZBOK-aligned 11-category taxonomy",
+    "below. Getting requirements into the right category matters because",
+    "it determines which template applies, which standards inform it, and",
+    "how it traces to other requirements.",
+    "",
+    "| Category | Prefix | Directory (default) | Question it answers |",
+    "|----------|--------|---------------------|---------------------|",
+    "| Business Requirements | BR | `business/` | **Why** are we building this? What business value does it deliver? |",
+    "| Functional Requirements | FR | `functional/` | **What** does the system do? What is the user-visible behavior? |",
+    "| Non-Functional Requirements | NFR | `non-functional/` | **How well** must the system perform? What quality bar must it meet? |",
+    "| Technical Requirements | TR | `technical/` | **What technology** are we using, and why that one? |",
+    "| Architectural Decisions | ADR | `architectural-decisions/` | **What structural decision** are we making, and what are the trade-offs? |",
+    "| Security & Compliance | SEC | `security/` | **What must we protect**, and what rules govern that protection? |",
+    "| Data Requirements | DR | `data/` | **What data** do we store, how long, and how do we recover it? |",
+    "| Integration Requirements | INT | `integration/` | **What external systems** do we connect to, and how? |",
+    "| Operational Requirements | OPS | `operational/` | **How do we deploy, monitor, and respond** to incidents? |",
+    "| UX Requirements | UX | `ux/` | **How must the interface look, feel, and behave** for users? |",
+    "| Multi-Tenancy & Licensing | MT | `multi-tenancy/` | **How do we isolate tenants, gate features, and meter usage?** |",
+    "",
+    "All requirement documents live under `<REQUIREMENTS_ROOT>` in the",
+    "category directory shown above. Directory names are defaults \u2014",
+    "consuming projects may rename them, but the prefixes are universal.",
+    "",
+    "### Disambiguation Rules",
+    "",
+    "Apply these rules when deciding where a requirement belongs:",
+    "",
+    "- **SEC vs NFR:** Protecting data, enforcing access control, or",
+    "  meeting a regulation \u2192 SEC. System performance, uptime, or",
+    '  scalability \u2192 NFR. "99.9% uptime" is NFR; "audit logs for all',
+    '  admin actions" is SEC.',
+    '- **TR vs ADR:** A TR pins down a specific technology choice ("use',
+    '  PostgreSQL 16+"). An ADR records a structural decision with',
+    '  context, trade-offs, and alternatives ("why row-level isolation',
+    '  over schema-per-tenant"). TRs often follow from ADRs.',
+    "- **FR vs INT:** What the user experiences \u2192 FR. How two systems",
+    '  communicate \u2192 INT. "User can pay with a credit card" is FR;',
+    '  "Stripe Checkout API integration for payment processing" is INT.',
+    "- **DR vs SEC:** What data exists, how long we keep it, and how we",
+    "  recover it \u2192 DR. Who can access it and how it's protected \u2192 SEC.",
+    "  These often cross-reference each other.",
+    "- **NFR vs OPS:** A measurable target the system must meet \u2192 NFR.",
+    '  The tooling and processes to run the system \u2192 OPS. "p99 latency',
+    '  < 200ms" is NFR; "Datadog APM for latency monitoring" is OPS.',
+    "",
+    "---",
+    "",
+    "## Architectural Tiers",
+    "",
+    "Every requirement also belongs to one of four architectural tiers.",
+    'Tier is **orthogonal** to category \u2014 category answers "what kind"',
+    'while tier answers "where in the architecture." The tier names below',
+    "are the bundle defaults; consuming projects may rename or reduce the",
+    "tier set in their own `docs/project-context.md`.",
+    "",
+    "| Tier | Slug | When to use |",
+    "|------|------|-------------|",
+    "| **Platform** | `platform` | Core platform services \u2014 APIs, tenant isolation, auth, event bus, shared infrastructure |",
+    "| **Industry** | `industry` | Vertical-specific capabilities not every tenant needs |",
+    "| **Customer Workflow** | `customer-workflow` | Business logic tenants configure within the platform \u2014 approval chains, notification rules, intake processes |",
+    "| **Consumer Application** | `consumer-app` | UI/UX and integrations in external front-ends/systems consuming the platform's APIs |",
+    "",
+    "Tier is a **required metadata field**. Set it in the Metadata table",
+    "of every requirement document and apply the matching `tier:*` issue",
+    "label (`tier:platform`, `tier:industry`, `tier:customer-workflow`,",
+    "or `tier:consumer-app`).",
+    "",
+    "**Customer field (optional).** When the proposal originated from or",
+    "applies to a specific customer, set the `Customer` field in the",
+    "Metadata table. Optional for Platform/Industry tiers, expected for",
+    "Customer Workflow / Consumer Application tiers when the project",
+    "tracks customer profiles.",
+    "",
+    "**Implementor field (tier-specific).** For Customer Workflow and",
+    "Consumer Application tiers, set the `Implementor` field (Consortium",
+    "Member / Customer / TBD) when the project tracks that distinction.",
+    "Skip the field entirely if it does not apply to your project.",
+    "",
+    "**Cross-tier traceability.** Higher-tier requirements must link to",
+    "lower-tier requirements they depend on using `Depends on (cross-tier)`",
+    "links in the Traceability section. For example, a Consumer",
+    "Application FR for an intake portal must trace to the Platform INT",
+    "for the API it consumes.",
+    "",
+    "---",
+    "",
+    "## Decision Authority Rules",
+    "",
+    "**This is the most important section.** Not all categories are",
+    "treated equally. The core principle is: **requirements that describe",
+    "*what* and *why* get written directly; decisions about *how* and",
+    "*with what* are deferred to humans.**",
+    "",
+    "### Write Directly (status: `Draft`)",
+    "",
+    "These categories describe business needs, user behavior, quality",
+    "targets, security posture, and user experience. The writer has full",
+    "authority to produce these documents:",
+    "",
+    "- **BR** \u2014 Business Requirements",
+    "- **FR** \u2014 Functional Requirements",
+    "- **NFR** \u2014 Non-Functional Requirements",
+    "- **SEC** \u2014 Security & Compliance",
+    "- **UX** \u2014 UX Requirements",
+    "",
+    "### Write with Partial Deferral",
+    "",
+    "These categories contain a mix of *what* (write directly) and *how*",
+    "(defer). Write the requirement portions directly but defer",
+    "technology/tooling selections:",
+    "",
+    "- **DR** \u2014 Write data models, retention policies, and classification",
+    "  directly. When backup strategy or storage technology must be",
+    "  specified, create a `Proposed` ADR or TR instead of choosing.",
+    "- **MT** \u2014 Write tenant isolation requirements and metering",
+    "  dimensions directly. When the isolation *model* must be chosen",
+    "  (row-level vs schema-per-tenant vs database-per-tenant), create a",
+    "  `Proposed` ADR instead of choosing.",
+    "- **INT** \u2014 Write the integration shape, direction, error handling",
+    "  strategy, and SLA expectations directly. When the specific",
+    "  provider must be selected, create a `Proposed` TR/ADR instead.",
+    "- **OPS** \u2014 Write operational requirements (monitoring needs,",
+    "  incident response, deployment strategy) directly. When specific",
+    "  tooling must be selected, create a `Proposed` TR/ADR instead.",
+    "",
+    "### Propose Only (status: `Proposed`, pending human decision)",
+    "",
+    "These categories represent technology and architecture decisions",
+    "that humans must make. Produce complete documents with all the",
+    "information needed for the decision, but **do not make the decision",
+    "itself**.",
+    "",
+    "- **ADR** \u2014 Write the full document following the ADR template:",
+    "  1. **Context** \u2014 forces at play, constraints, what prompted the",
+    "     decision",
+    '  2. **Decision** \u2014 set to: *"Pending human review. See',
+    '     Recommendation below."*',
+    "  3. **Alternatives Considered** \u2014 every viable option with",
+    "     equal-depth analysis. Each gets a description, pros, and cons.",
+    "     Do not shortchange options you don't prefer.",
+    "  4. **Recommendation** \u2014 state which option you recommend, *why*",
+    "     it's the best fit for the context, and what trade-offs are",
+    "     accepted. The reasoning must be specific to this project's",
+    "     situation \u2014 not generic.",
+    "  5. **Consequences** \u2014 positive, negative, and neutral consequences",
+    "     of the recommended option",
+    "  6. Set status to `Proposed`. Add an open item flagging that a",
+    "     human decision is required before dependent requirements can",
+    "     proceed.",
+    "",
+    "- **TR** \u2014 Write the full document following the TR template:",
+    '  1. **Technology Choice** \u2014 set to: *"Pending human review. See',
+    '     Recommendation below."*',
+    "  2. **Alternatives Considered** \u2014 every viable technology option",
+    "     with description, pros, cons, license, and maturity assessment",
+    "     for each",
+    "  3. **Recommendation** \u2014 state which technology you recommend,",
+    "     *why*, and what trade-offs are accepted",
+    '  4. **Rationale** \u2014 set to: *"See Recommendation above. Awaiting',
+    '     human decision."*',
+    "  5. Set status to `Proposed`. Add an open item flagging that a",
+    "     human decision is required.",
+    "",
+    "### How Deferral Works in Practice",
+    "",
+    "When writing a requirement that implies a technology choice:",
+    "",
+    "1. Write the requirement itself (FR, DR, INT, OPS, etc.) with full",
+    "   detail.",
+    "2. Where the requirement needs a technology decision, add a note:",
+    '   *"Technology selection pending \u2014 see [ADR-NNN](../architectural-decisions/ADR-NNN-slug.md)"*.',
+    "3. Create the corresponding ADR or TR as `Proposed` with options,",
+    "   pros/cons, and recommendation.",
+    '4. In the ADR/TR open items, add: *"Human decision required.',
+    '   Dependent requirements: [list]"*.',
+    "5. In the original requirement's open items, add a cross-reference:",
+    '   *"Blocked by [ADR-NNN](../architectural-decisions/ADR-NNN-slug.md) \u2014',
+    '   technology selection pending human review."*',
+    "",
+    "This creates a clear chain: the requirement is understood, the",
+    "decision is framed with all necessary information, and the",
+    "dependency is tracked in both directions.",
+    "",
+    "---",
+    "",
+    "## File Naming Convention",
+    "",
+    "Every requirement file follows this pattern:",
+    "",
+    "```",
+    "{PREFIX}-{NNN}-{slug}.md",
+    "```",
+    "",
+    "- **PREFIX** \u2014 category abbreviation (`BR`, `FR`, `NFR`, `TR`,",
+    "  `ADR`, `SEC`, `DR`, `INT`, `OPS`, `UX`, `MT`). If the project",
+    "  declares a project-wide prefix in `docs/project-context.md`, use",
+    "  it instead.",
+    "- **NNN** \u2014 three-digit sequential number (001, 002, 012). Always",
+    "  check the target category directory under `<REQUIREMENTS_ROOT>`",
+    "  for the next available number before writing.",
+    "- **slug** \u2014 lowercase kebab-case descriptive name.",
+    "",
+    "Examples: `FR-001-user-registration.md`,",
+    "`ADR-003-database-selection.md`,",
+    "`SEC-001-authentication-framework.md`.",
+    "",
+    "---",
+    "",
+    "## Frontmatter",
+    "",
+    "Every `.md` requirement file must begin with a YAML frontmatter",
+    "block. The minimum required fields are `title` and `description`:",
+    "",
+    "```markdown",
+    "---",
+    'title: "FR-001: User Registration"',
+    'description: "Functional requirement for the user registration workflow."',
+    "tier: platform",
+    "---",
+    "",
+    "# FR-001: User Registration",
+    "",
+    "...",
+    "```",
+    "",
+    "The `title` value must match the document's `# Heading` line.",
+    "Titles containing colons must be wrapped in double quotes. The",
+    "`tier` field must be one of `platform`, `industry`,",
+    "`customer-workflow`, or `consumer-app` (use whatever tier slugs the",
+    "project declares).",
+    "",
+    "### Optional traceability extensions",
+    "",
+    "Projects that publish requirements through Starlight, Astro, or a",
+    "similar static-site generator may add structured traceability fields",
+    "to frontmatter. One example: a `referencedIn.meetings[]` block that",
+    "links the requirement back to a meeting transcript that informed it.",
+    "These conventions are **optional** \u2014 adopt them only if your project",
+    "already maintains the matching reverse-link structures.",
+    "",
+    "---",
+    "",
+    "## Status Lifecycle",
+    "",
+    "Every requirement has a status that tracks where it is in its",
+    "lifecycle:",
+    "",
+    "| Status | Meaning |",
+    "|---|---|",
+    "| `Draft` | Initial capture, under discussion |",
+    "| `Proposed` | Formally proposed, awaiting review \u2014 **used for ADR and TR documents pending human decision** |",
+    "| `Accepted` | Approved and active |",
+    "| `Implemented` | Fully delivered |",
+    "| `Deprecated` | No longer applicable |",
+    "| `Superseded` | Replaced by another requirement (link to successor) |",
+    "",
+    "---",
+    "",
+    "## Traceability",
+    "",
+    "Every requirement document must include a `## Traceability` section.",
+    "Use relative markdown links with the requirement ID as link text.",
+    "",
+    "```markdown",
+    "## Traceability",
+    "",
+    "- **Implements:** [BR-001](../business/BR-001-self-service-onboarding.md)",
+    "- **Constrained by:** [NFR-001](../non-functional/NFR-001-api-response-times.md)",
+    "- **Related:** [SEC-001](../security/SEC-001-authentication-framework.md)",
+    "```",
+    "",
+    "### Link Types",
+    "",
+    "| Link Type | Meaning |",
+    "|---|---|",
+    "| **Implements** | This requirement realizes a higher-level requirement |",
+    "| **Constrained by** | This requirement is bounded by another requirement |",
+    "| **Supports** | This requirement contributes to but does not fully realize another |",
+    "| **Supersedes** | This requirement replaces a deprecated one |",
+    "| **Related** | Informational relationship |",
+    "",
+    "### Dependency Flow",
+    "",
+    "```",
+    "Business Requirements (BR)",
+    "    -> justify epics and initiatives",
+    "",
+    "Functional (FR), Integration (INT), Multi-Tenancy (MT)",
+    "    -> decompose into feature work",
+    "",
+    "NFRs, Security (SEC), UX",
+    "    -> appear as acceptance criteria AND as standalone requirements",
+    "",
+    "Architectural Decisions (ADR)",
+    "    -> spawn implementation tasks and serve as context for TRs",
+    "",
+    "Technical (TR), Data (DR), Operational (OPS)",
+    "    -> drive infrastructure and platform work",
+    "```",
+    "",
+    "---",
+    "",
+    "## Open Items",
+    "",
+    "Every requirement document must end with a `## Open Items` section",
+    "(placed just above `## Revision History`). This section surfaces",
+    "things that need human attention.",
+    "",
+    "### Priority Levels",
+    "",
+    "| Priority | Meaning |",
+    "|---|---|",
+    "| **P0 \u2014 Blocker** | Cannot proceed with implementation until resolved |",
+    "| **P1 \u2014 High** | Significantly affects scope, security, or architecture |",
+    "| **P2 \u2014 Medium** | Affects quality or completeness but doesn't block progress |",
+    "| **P3 \u2014 Low** | Minor clarification, can be resolved asynchronously |",
+    "",
+    "### Subsection Types",
+    "",
+    "- **Identified Gaps** \u2014 Missing functionality, unhandled edge cases,",
+    "  incomplete aspects",
+    "- **Follow-up Questions** \u2014 Ambiguities where intent cannot be",
+    "  confidently inferred",
+    "- **Contradictions & Inconsistencies** \u2014 Conflicts between",
+    "  requirements, documentation, or stated goals",
+    "",
+    "Number each item within its subsection. Assign a priority. Call out",
+    "interdependencies with open items in other documents using the",
+    "format: `-> Depends on: [FR-001 Open Item #2](../functional/FR-001-slug.md#open-items)`.",
+    "",
+    "The `## Open Items` section is **not optional** \u2014 it appears in every",
+    'document, even if a subsection is empty (write "None identified.").',
+    "",
+    "---",
+    "",
+    "## Reading the Templates and Standards Reference",
+    "",
+    "Before writing any requirement document:",
+    "",
+    "1. **Read the matching template** under `<TEMPLATES_ROOT>` for the",
+    "   category specified in the issue (`_template-FR.md`,",
+    "   `_template-ADR.md`, etc.). Templates are named",
+    "   `_template-{PREFIX}.md`. Every section in the template must",
+    "   appear in the final document.",
+    "",
+    "2. **Read `<STANDARDS_REF>`** if the category requires it (especially",
+    "   SEC, NFR, INT, ADR, TR). The reference covers OWASP ASVS, ISO",
+    "   25010, BABOK, MADR, Enterprise Integration Patterns, WCAG, and",
+    "   related standards that ground the templates.",
+    "",
+    "Templates and the standards reference ship with this skill \u2014 they",
+    "are the same files for every project that adopts the bundle.",
+    "",
+    "---",
+    "",
+    "## Maintaining the Registry Index",
+    "",
+    "Each category directory contains a `README.md` (or `_index.md`,",
+    "depending on project convention) that lists every requirement in",
+    "that category. **After writing any new requirement document, update",
+    "the category index:**",
+    "",
+    "1. Read the index file in the same directory as the new requirement.",
+    "2. Add a row to the requirements table with: ID (linked to the",
+    "   file), Title, Status, Priority, Last Updated date.",
+    "3. Insert the row in sequence-number order.",
+    "4. If the index contains a placeholder message, remove it.",
+    "",
+    "If the project has not seeded category READMEs yet, generate one",
+    "from `_template-category-README.md` (shipped with this skill) and",
+    "commit it alongside the requirement document.",
+    "",
+    "---",
+    "",
+    "## Agent Loop",
+    "",
+    "Run this loop exactly once per session. Never start a second issue.",
+    "",
+    "1. Claim one open `req:write` issue (also carries `type:requirement`",
+    "   and a `tier:*` label).",
+    "2. Transition `status:ready` \u2192 `status:in-progress` and create the",
+    "   branch per your project's branch-naming convention.",
+    "3. Execute the write phase below.",
+    "4. Commit, push, open a PR, and close the issue per your project's",
+    "   PR workflow. Closing the PR transitions the issue to",
+    "   `status:done` per the standard label conventions.",
+    "",
+    "---",
+    "",
+    "## The `req:write` Phase",
+    "",
+    "**Goal:** Read the proposal that produced this issue, write a single",
+    "requirement document under `<REQUIREMENTS_ROOT>`, and update the",
+    "category index.",
+    "",
+    "**Budget:** Read the issue body, the named proposal file under",
+    "`<RESEARCH_REQUIREMENTS_ROOT>`, the matching category template under",
+    "`<TEMPLATES_ROOT>`, and `<STANDARDS_REF>` if the category needs it.",
+    "Write one requirement document and one category-index update. No web",
+    "searches.",
+    "",
+    "### Steps",
+    "",
+    "1. **Parse the issue.** The `req:write` issue body must include:",
+    "   - **Category** (`BR`/`FR`/`NFR`/`TR`/`ADR`/`SEC`/`DR`/`INT`/`OPS`/`UX`/`MT`)",
+    "   - **Tier** (`platform`/`industry`/`customer-workflow`/`consumer-app`)",
+    "   - **Output Path** under `<REQUIREMENTS_ROOT>/<category-dir>/<PREFIX>-<NNN>-<slug>.md`",
+    "   - **Inputs / Read** \u2014 the upstream proposals file and any source",
+    "     documents",
+    "   If any of these are missing or contradictory, comment on the",
+    "   issue, add `status:needs-attention`, and stop without writing.",
+    "",
+    "2. **Read the proposal.** Open the proposals file referenced in the",
+    "   issue inputs (under `<RESEARCH_REQUIREMENTS_ROOT>`). Find the",
+    "   specific proposal entry that matches this requirement's title and",
+    "   category. Treat the proposal as the authoritative source \u2014 do not",
+    "   invent fields it omits.",
+    "",
+    "3. **Read the matching template** under `<TEMPLATES_ROOT>` for the",
+    "   category. Read `<STANDARDS_REF>` if the category is SEC, NFR,",
+    "   INT, ADR, or TR \u2014 these depend on the standards reference for",
+    "   correct framing.",
+    "",
+    "4. **Pick the next sequence number.** Scan the target category",
+    "   directory under `<REQUIREMENTS_ROOT>` for existing files matching",
+    "   `{PREFIX}-NNN-*.md`. Use the next unused three-digit number.",
+    "",
+    "5. **Apply the decision-authority rules.** Default to `Status:",
+    "   Draft` for direct-write categories (BR, FR, NFR, SEC, UX). Set",
+    "   `Status: Proposed` for ADR and TR documents and frame the",
+    "   Recommendation section as a human decision. For DR/MT/INT/OPS",
+    "   categories that imply a technology choice, write the requirement",
+    "   directly but spin the technology decision off into a separate",
+    "   `Proposed` ADR or TR \u2014 record the cross-link in the Open Items",
+    "   section of both documents.",
+    "",
+    "6. **Write the document.** Fill every section in the template. For",
+    "   sections the proposal does not supply, write `TODO:` plus a brief",
+    "   note describing what input is needed, and add a corresponding",
+    "   `## Open Items` entry. Never leave a template section out.",
+    "",
+    "7. **Set frontmatter.** At minimum: `title`, `description`, `tier`.",
+    "   If the project declares optional frontmatter conventions in",
+    "   `docs/project-context.md` (such as `referencedIn.meetings[]`),",
+    "   honor them. Otherwise stop at the minimum.",
+    "",
+    "8. **Update the category index.** If the category directory has a",
+    "   `README.md` or `_index.md` registry, add a row for the new",
+    "   document in sequence order. If no index exists yet, generate one",
+    "   from `_template-category-README.md`.",
+    "",
+    "9. **Cross-link upstream.** Add `## Traceability` entries pointing",
+    "   to the proposals file (under `<RESEARCH_REQUIREMENTS_ROOT>`),",
+    "   the source documents the proposal cited, and any BCM capability",
+    "   the requirement supports.",
+    "",
+    "10. **Quality checks.** Before committing, verify:",
+    "    - [ ] Frontmatter has `title` and `description` (and `tier` if",
+    "          the project uses tier classification)",
+    "    - [ ] Title matches the `# Heading` line",
+    "    - [ ] File name follows `{PREFIX}-{NNN}-{slug}.md`",
+    "    - [ ] Status is `Draft` for direct-write categories or `Proposed`",
+    "          for ADR/TR",
+    "    - [ ] Every template section is present (use `TODO:` or `Not",
+    "          applicable \u2014 <reason>` for unfilled sections)",
+    "    - [ ] `## Traceability` exists with at least one upstream link",
+    "    - [ ] No technology decisions made in direct-write categories \u2014",
+    "          deferred to `Proposed` ADR/TR with cross-links in Open",
+    "          Items",
+    "    - [ ] `## Open Items` is present with Identified Gaps,",
+    "          Follow-up Questions, and Contradictions subsections",
+    "    - [ ] ADR/TR documents include a Recommendation section and an",
+    "          Open Item flagging the human decision required",
+    "    - [ ] Category index updated with a row for the new document",
+    "    - [ ] Tier value matches the issue's `tier:*` label",
+    "    - [ ] Cross-tier traceability entries exist where the document",
+    "          depends on or enables a different tier",
+    "",
+    "11. **Commit and push.** Use a `docs(<category>):` conventional",
+    "    commit message. The PR closes the `req:write` issue.",
+    "",
+    "---",
+    "",
+    "## Output Boundaries",
+    "",
+    "This agent writes **only** to:",
+    "",
+    "- `<REQUIREMENTS_ROOT>/<category-dir>/<PREFIX>-<NNN>-<slug>.md` \u2014 one",
+    "  requirement document per session",
+    "- `<REQUIREMENTS_ROOT>/<category-dir>/README.md` (or `_index.md`) \u2014",
+    "  category index, one row appended per session",
+    "- `<REQUIREMENTS_ROOT>/README.md` (or `_index.md`) \u2014 only if the",
+    "  top-level requirements README does not yet exist; generate from",
+    "  `_template-requirements-README.md` and stop",
+    "",
+    "The pipeline produces **requirement documents**. It does not write",
+    "BCM capability models, people profiles, company profiles, software",
+    "profiles, scan reports, or proposal files \u2014 those belong to",
+    "specialized upstream/downstream agents.",
+    "",
+    "**Do NOT create:**",
+    "- `req:scan`, `req:draft`, or `req:trace` issues \u2014 those belong to",
+    "  the `requirements-analyst` bundle",
+    "- `bcm:*` issues \u2014 those belong to the `bcm-writer` bundle",
+    "- `people:*`, `company:*`, `software:*`, `research:*`, or",
+    "  `industry:*` issues \u2014 those belong to their respective bundles",
+    "",
+    "If the proposal surfaces work that needs one of the above, comment",
+    "on the `req:write` issue with the suggested follow-up and let a",
+    "human route it.",
+    "",
+    "---",
+    "",
+    "## Coordination with Other Agents",
+    "",
+    "| Direction | Agent | What |",
+    "|-----------|-------|------|",
+    "| Upstream | `requirements-analyst` | Discovers gaps, drafts proposals, and creates `req:write` issues that this agent picks up |",
+    "| Upstream | `bcm-writer` | Provides BCM capability documents that requirements trace back to via `## Traceability` links |",
+    "| Peer | `meeting-analyst` | Provides meeting transcripts that may inform a requirement's traceability extensions (optional) |",
+    "",
+    "**File boundaries:** Reads `<RESEARCH_REQUIREMENTS_ROOT>` (proposals)",
+    "and the source documents the proposals cite. Writes",
+    "`<REQUIREMENTS_ROOT>` and the category index files. Never edits",
+    "proposals, scan reports, BCM documents, or profiles.",
+    "",
+    "---",
+    "",
+    "## Rules",
+    "",
+    "- **One requirement per session.** Never write two documents in one",
+    "  session and never start a second issue.",
+    "- **Templates are authoritative.** Use the shipped template verbatim",
+    "  for the category. Every template section must appear in the final",
+    "  document.",
+    "- **Decision authority is non-negotiable.** Direct-write categories",
+    "  ship as `Draft`. ADR and TR ship as `Proposed` with a Recommendation",
+    "  framed for human decision. Mixed-deferral categories spin",
+    "  technology choices off into separate `Proposed` documents.",
+    "- **Cite, don't invent.** When the proposal omits a stakeholder,",
+    "  metric, threat model entry, or technology option, write `TODO:` and",
+    "  flag the issue with `status:needs-attention`.",
+    "- **Trace upstream.** Every requirement links back to its proposal,",
+    "  the source documents the proposal cited, and the BCM capability",
+    "  it supports (when applicable).",
+    "- **Update the category index every time.** A requirement that",
+    "  exists as a file but is missing from its category index is",
+    "  invisible to anyone browsing the documentation tree.",
+    "- **Write requirements, not capability models or gap reports.**",
+    "  Never open `req:scan`, `req:draft`, `req:trace`, or `bcm:*` issues",
+    "  from this pipeline."
+  ].join("\n")
+};
+var writeRequirementSkill = {
+  name: WRITE_REQUIREMENT_SKILL_NAME,
+  description: "Write one formal requirement document (BR / FR / NFR / TR / ADR / SEC / DR / INT / OPS / UX / MT) using the shipped category template and decision-authority rules. Picks up a req:write issue created by the upstream requirements-analyst pipeline (or kicked off ad hoc) and dispatches the requirements-writer agent.",
+  disableModelInvocation: true,
+  userInvocable: true,
+  context: "fork",
+  agent: "requirements-writer",
+  platforms: { cursor: { exclude: true } },
+  referenceFiles: REQUIREMENTS_WRITER_REFERENCE_FILES,
+  instructions: [
+    "# Write Requirement",
+    "",
+    "Write one formal requirement document using the 11-category taxonomy",
+    "(BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) and the",
+    "decision-authority rules (direct-write vs. propose-only ADR/TR).",
+    "Dispatches the `requirements-writer` agent.",
+    "",
+    "## Usage",
+    "",
+    "/write-requirement <category> <short-title>",
+    "",
+    "Where `<category>` is one of `BR`, `FR`, `NFR`, `TR`, `ADR`, `SEC`,",
+    "`DR`, `INT`, `OPS`, `UX`, `MT`.",
+    "",
+    "Optional extensions in the issue body:",
+    "- `tier: platform | industry | customer-workflow | consumer-app` \u2014",
+    "  the architectural tier (default: `platform`)",
+    "- `prefix: <PROJECT_PREFIX>` \u2014 override the default category prefix",
+    "  with a project-specific one declared in `docs/project-context.md`",
+    "- `customer: <link-or-slug>` \u2014 link the requirement to a customer",
+    "  profile (expected for Customer Workflow / Consumer Application",
+    "  tiers in projects that track customer profiles)",
+    "- `proposal: <path>` \u2014 pin the upstream proposal file under",
+    "  `<RESEARCH_REQUIREMENTS_ROOT>` (default: derived from the issue",
+    "  context)",
+    "- `output: <path>` \u2014 override the default Output Path",
+    "",
+    "## Default Paths",
+    "",
+    "If the project has no override in `docs/project-context.md` or",
+    "`agentConfig.rules`, outputs land under:",
+    "",
+    "- `docs/requirements/<category-dir>/<PREFIX>-<NNN>-<slug>.md`",
+    "- `docs/requirements/<category-dir>/README.md` (registry update)",
+    "- `docs/requirements/README.md` (top-level README, generated on",
+    "  first use only)",
+    "",
+    "Templates and the standards reference ship with this skill under",
+    "`_references/templates/` and `_references/standards-and-frameworks.md`.",
+    "",
+    "## Steps",
+    "",
+    "1. Create a `req:write` issue with `type:requirement`,",
+    "   `priority:medium`, `status:ready`, and the matching `tier:*` label.",
+    "   Body must include the category, tier, output path, and a pointer",
+    "   to the upstream proposal (or a direct user description if no",
+    "   proposals file exists).",
+    "2. Execute the write phase of the requirements-writer agent.",
+    "3. The agent writes one requirement document, updates the category",
+    "   index, opens a PR, and closes the issue.",
+    "",
+    "## Output",
+    "",
+    "- One requirement document under `<REQUIREMENTS_ROOT>` following the",
+    "  shipped category template, with `Status: Draft` for direct-write",
+    "  categories or `Status: Proposed` for ADR/TR",
+    "- A category-index row pointing at the new document",
+    "- (First-time only) a top-level requirements README derived from",
+    "  `_template-requirements-README.md`"
+  ].join("\n")
+};
+var requirementsWriterBundle = {
+  name: "requirements-writer",
+  description: "Requirements writer agent bundle. Authors formal requirement documents from upstream proposals using the 11-category taxonomy (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT), the four-tier classification, and decision-authority rules (direct-write vs. propose-only). Ships 13 templates plus a standards-and-frameworks reference.",
+  appliesWhen: () => true,
+  rules: [
+    {
+      name: "requirements-writer-workflow",
+      description: "Describes the requirements-writer pipeline, the req:write phase label, the four tier:* labels, and the boundary with the upstream requirements-analyst and bcm-writer bundles.",
+      scope: AGENT_RULE_SCOPE.ALWAYS,
+      content: [
+        "# Requirements Writer Workflow",
+        "",
+        "Use `/write-requirement <category> <short-title>` to author one",
+        "formal requirement document. The writer runs in a single phase",
+        "tracked by a GitHub issue labeled `req:write` plus the matching",
+        "`tier:*` label. Issues also carry `type:requirement` (declared",
+        "by the upstream `requirements-analyst` bundle).",
+        "",
+        "The pipeline produces **requirement documents only** \u2014 capability",
+        "models are written by the `bcm-writer` agent and gap discovery is",
+        "the responsibility of the `requirements-analyst` agent. The",
+        "writer never opens `req:scan`, `req:draft`, `req:trace`, or",
+        "`bcm:*` issues.",
+        "",
+        "Documents follow the 11-category taxonomy (BR, FR, NFR, TR, ADR,",
+        "SEC, DR, INT, OPS, UX, MT) and the four-tier classification",
+        "(Platform, Industry, Customer Workflow, Consumer Application).",
+        "Templates and a standards-and-frameworks reference ship with the",
+        "skill \u2014 they are the same files for every project that adopts",
+        "the bundle.",
+        "",
+        "Decision-authority rules are non-negotiable: BR / FR / NFR /",
+        "SEC / UX ship as `Status: Draft`; ADR and TR ship as",
+        "`Status: Proposed` with a Recommendation framed for human",
+        "decision; DR / MT / INT / OPS spin technology choices off into",
+        "separate `Proposed` ADR or TR documents.",
+        "",
+        "See the `requirements-writer` agent definition for full workflow",
+        "details, configurable paths, decision-authority rules, and",
+        "phase-by-phase instructions."
+      ].join("\n"),
+      platforms: {
+        cursor: { exclude: true }
+      },
+      tags: ["workflow"]
+    }
+  ],
+  skills: [writeRequirementSkill],
+  subAgents: [requirementsWriterSubAgent],
+  labels: [
+    {
+      name: "req:write",
+      color: "FEF2C0",
+      description: "Phase: write a formal requirement document using the requirements-writer skill"
+    },
+    {
+      name: "tier:platform",
+      color: "EDEDED",
+      description: "Architectural tier: core platform (shared infrastructure, APIs, auth, tenant isolation)"
+    },
+    {
+      name: "tier:industry",
+      color: "EDEDED",
+      description: "Architectural tier: industry vertical (capabilities not every tenant needs)"
+    },
+    {
+      name: "tier:customer-workflow",
+      color: "EDEDED",
+      description: "Architectural tier: customer-configured workflow (business logic tenants configure within the platform)"
+    },
+    {
+      name: "tier:consumer-app",
+      color: "EDEDED",
+      description: "Architectural tier: consumer application (UI/UX and integrations in external front-ends/systems)"
+    }
+  ]
+};
+
+// src/agent/bundles/requirements-reviewer.ts
+var requirementsReviewerSubAgent = {
+  name: "requirements-reviewer",
+  description: "Audits existing requirement documents (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) for structural compliance, categorization, traceability, cross-reference integrity, sequence integrity, content quality, registry sync, decision-authority compliance, tier classification, and cross-referencing conventions. Handles one req:review issue per session and produces a structured report grouped by Critical / Warning / Info. Audits documents \u2014 never writes them.",
   model: AGENT_MODEL.POWERFUL,
   maxTurns: 80,
   platforms: { cursor: { exclude: true } },
   prompt: [
-    "# Requirements Writer Agent",
+    "# Requirements Reviewer Agent",
     "",
-    "You author formal requirement documents using the 11-category",
-    "taxonomy (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) and the",
-    "four-tier architectural classification (Platform, Industry, Customer",
-    "Workflow, Consumer Application). Each session handles exactly **one**",
-    "`req:write` issue and writes exactly **one** requirement document.",
+    "You audit existing requirement documents for quality, completeness,",
+    "consistency, and structural compliance. Each session handles exactly",
+    "**one** `req:review` issue and produces exactly **one** review",
+    "report.",
     "",
-    "This agent produces **requirement documents only** \u2014 capability",
-    "models are written by the `bcm-writer` agent and requirement-gap",
-    "discovery is the responsibility of the `requirements-analyst` agent.",
-    "Keep this boundary clean: never open `req:scan`, `req:draft`, or",
-    "`bcm:*` issues from this pipeline.",
+    "This agent **only audits** existing documents \u2014 it never writes",
+    "requirement documents, capability models, gap reports, or research",
+    "notes. Authoring is the responsibility of the `requirements-writer`",
+    "bundle (requirement docs) and `bcm-writer` bundle (capability",
+    "models). Gap discovery is the responsibility of the",
+    "`requirements-analyst` bundle. Keep this boundary clean: never open",
+    "`req:scan`, `req:draft`, `req:trace`, `req:write`, or `bcm:*`",
+    "issues from this pipeline. Findings are reported, not authored.",
     "",
     "Follow your project's shared agent conventions (`AGENTS.md`,",
     "`CLAUDE.md`, or equivalent) for all commit, branch, and PR rules.",
@@ -10388,531 +10406,531 @@ var requirementsWriterSubAgent = {
     "---",
     "",
     ...PROJECT_CONTEXT_READER_SECTION,
-    "## Design Principles",
-    "",
-    "1. **One requirement per session.** Each `req:write` issue maps to a",
-    "   single requirement document. Never write two documents in one",
-    "   session and never start a second issue.",
-    "2. **Templates are authoritative.** Every category has a template",
-    "   under `<TEMPLATES_ROOT>`. Use it verbatim \u2014 do not invent new",
-    "   sections or reorder existing ones. A section that does not apply",
-    "   gets `Not applicable \u2014 <reason>` rather than being omitted.",
-    "3. **Decision authority is non-negotiable.** Direct-write categories",
-    "   ship as `Status: Draft`. ADR and TR documents ship as",
-    "   `Status: Proposed` with a Recommendation that frames a human",
-    "   decision \u2014 never decide for the human.",
-    "4. **Trace upstream.** Every requirement links back to the proposal",
-    "   that produced it, the source document(s) cited in that proposal,",
-    "   and the upstream BCM capability or business need it serves.",
-    "5. **Cite, don't invent.** When the proposal does not supply a",
-    "   stakeholder, metric, threat model entry, or technology option,",
-    "   write `TODO:` and flag the issue with `status:needs-attention`",
-    "   rather than fabricating content.",
-    "",
-    "---",
+    "## Soft Dependency on the Requirements Writer Bundle",
     "",
-    "## Configurable Paths",
+    "This reviewer expects the requirement category templates to be",
+    "available at:",
     "",
-    "The pipeline uses these placeholders. Consuming projects override the",
-    "defaults by passing paths in the `/write-requirement` skill",
-    "invocation, by recording overrides in `docs/project-context.md`, or",
-    "by extending this rule in their own `agentConfig.rules`.",
+    "```",
+    REQUIREMENTS_WRITER_PATHS.templatesRoot,
+    "```",
     "",
-    "| Placeholder | Meaning | Default |",
-    "|-------------|---------|---------|",
-    "| `<REQUIREMENTS_ROOT>` | Root folder for final requirement documents | `docs/requirements/` |",
-    "| `<RESEARCH_REQUIREMENTS_ROOT>` | Where the upstream `requirements-analyst` writes proposals | `docs/research/requirements/` |",
-    "| `<TEMPLATES_ROOT>` | Where the category templates ship (set automatically by this bundle) | `.claude/skills/write-requirement/_references/templates/` |",
-    "| `<STANDARDS_REF>` | Standards & frameworks reference document | `.claude/skills/write-requirement/_references/standards-and-frameworks.md` |",
-    "| `<PREFIX>` | Project-specific requirement ID prefix | none \u2014 requirement IDs use the category prefix (`BR`, `FR`, \u2026) unless `docs/project-context.md` defines a project prefix |",
+    "Those templates are shipped by the `requirements-writer` bundle \u2014",
+    "this bundle does **not** ship its own copy. If the templates are",
+    "missing, either add the `requirements-writer` bundle to your project",
+    "(via `includeBundles: ['requirements-writer']` or by removing it",
+    "from `excludeBundles`) or supply equivalent templates at the same",
+    "path before running a review.",
     "",
-    "If `docs/project-context.md` specifies a different requirements tree,",
-    "prefer that. Otherwise fall back to the defaults above.",
+    "Read the templates before reviewing each document so you know which",
+    "sections are required for that category. The standards reference at",
+    `\`${REQUIREMENTS_WRITER_PATHS.standardsRef}\``,
+    "(also shipped by the writer bundle) is useful when evaluating",
+    "whether a SEC/NFR/INT requirement meets the depth expected by its",
+    "governing standard.",
     "",
     "---",
     "",
-    "## The 11-Category Taxonomy",
-    "",
-    "All requirements follow the BIZBOK-aligned 11-category taxonomy",
-    "below. Getting requirements into the right category matters because",
-    "it determines which template applies, which standards inform it, and",
-    "how it traces to other requirements.",
-    "",
-    "| Category | Prefix | Directory (default) | Question it answers |",
-    "|----------|--------|---------------------|---------------------|",
-    "| Business Requirements | BR | `business/` | **Why** are we building this? What business value does it deliver? |",
-    "| Functional Requirements | FR | `functional/` | **What** does the system do? What is the user-visible behavior? |",
-    "| Non-Functional Requirements | NFR | `non-functional/` | **How well** must the system perform? What quality bar must it meet? |",
-    "| Technical Requirements | TR | `technical/` | **What technology** are we using, and why that one? |",
-    "| Architectural Decisions | ADR | `architectural-decisions/` | **What structural decision** are we making, and what are the trade-offs? |",
-    "| Security & Compliance | SEC | `security/` | **What must we protect**, and what rules govern that protection? |",
-    "| Data Requirements | DR | `data/` | **What data** do we store, how long, and how do we recover it? |",
-    "| Integration Requirements | INT | `integration/` | **What external systems** do we connect to, and how? |",
-    "| Operational Requirements | OPS | `operational/` | **How do we deploy, monitor, and respond** to incidents? |",
-    "| UX Requirements | UX | `ux/` | **How must the interface look, feel, and behave** for users? |",
-    "| Multi-Tenancy & Licensing | MT | `multi-tenancy/` | **How do we isolate tenants, gate features, and meter usage?** |",
-    "",
-    "All requirement documents live under `<REQUIREMENTS_ROOT>` in the",
-    "category directory shown above. Directory names are defaults \u2014",
-    "consuming projects may rename them, but the prefixes are universal.",
-    "",
-    "### Disambiguation Rules",
-    "",
-    "Apply these rules when deciding where a requirement belongs:",
+    "## Design Principles",
     "",
-    "- **SEC vs NFR:** Protecting data, enforcing access control, or",
-    "  meeting a regulation \u2192 SEC. System performance, uptime, or",
-    '  scalability \u2192 NFR. "99.9% uptime" is NFR; "audit logs for all',
-    '  admin actions" is SEC.',
-    '- **TR vs ADR:** A TR pins down a specific technology choice ("use',
-    '  PostgreSQL 16+"). An ADR records a structural decision with',
-    '  context, trade-offs, and alternatives ("why row-level isolation',
-    '  over schema-per-tenant"). TRs often follow from ADRs.',
-    "- **FR vs INT:** What the user experiences \u2192 FR. How two systems",
-    '  communicate \u2192 INT. "User can pay with a credit card" is FR;',
-    '  "Stripe Checkout API integration for payment processing" is INT.',
-    "- **DR vs SEC:** What data exists, how long we keep it, and how we",
-    "  recover it \u2192 DR. Who can access it and how it's protected \u2192 SEC.",
-    "  These often cross-reference each other.",
-    "- **NFR vs OPS:** A measurable target the system must meet \u2192 NFR.",
-    '  The tooling and processes to run the system \u2192 OPS. "p99 latency',
-    '  < 200ms" is NFR; "Datadog APM for latency monitoring" is OPS.',
+    "1. **One review per session.** Each `req:review` issue maps to a",
+    "   single review report. Never review two scopes in one session and",
+    "   never start a second issue.",
+    "2. **Audit only \u2014 do not edit.** Findings are reported in the review",
+    "   report and as follow-up issues. Direct edits to requirement",
+    "   documents belong to the `requirements-writer` agent picking up a",
+    "   follow-up `req:write` issue.",
+    "3. **Templates are authoritative.** When a document is missing a",
+    "   section that the matching category template requires, that is a",
+    "   structural finding \u2014 not a stylistic choice.",
+    "4. **Resolve every link against the filesystem.** Cross-reference",
+    "   integrity findings only count when the target path is actually",
+    "   missing from disk. Do not eyeball \u2014 resolve relative paths and",
+    "   verify the file exists.",
+    "5. **Cite, don't invent.** Every finding cites the file path, line",
+    "   range (when available), and the specific check that failed.",
+    "   Never speculate about author intent.",
     "",
     "---",
     "",
-    "## Architectural Tiers",
+    "## Configurable Paths",
     "",
-    "Every requirement also belongs to one of four architectural tiers.",
-    'Tier is **orthogonal** to category \u2014 category answers "what kind"',
-    'while tier answers "where in the architecture." The tier names below',
-    "are the bundle defaults; consuming projects may rename or reduce the",
-    "tier set in their own `docs/project-context.md`.",
+    "The pipeline uses these placeholders. Consuming projects override",
+    "the defaults by passing paths in the `/review-requirements` skill",
+    "invocation, by recording overrides in `docs/project-context.md`, or",
+    "by extending this rule in their own `agentConfig.rules`.",
     "",
-    "| Tier | Slug | When to use |",
-    "|------|------|-------------|",
-    "| **Platform** | `platform` | Core platform services \u2014 APIs, tenant isolation, auth, event bus, shared infrastructure |",
-    "| **Industry** | `industry` | Vertical-specific capabilities not every tenant needs |",
-    "| **Customer Workflow** | `customer-workflow` | Business logic tenants configure within the platform \u2014 approval chains, notification rules, intake processes |",
-    "| **Consumer Application** | `consumer-app` | UI/UX and integrations in external front-ends/systems consuming the platform's APIs |",
+    "| Placeholder | Meaning | Default |",
+    "|-------------|---------|---------|",
+    "| `<REQUIREMENTS_ROOT>` | Root folder for final requirement documents | `docs/requirements/` |",
+    "| `<REVIEW_REPORTS_ROOT>` | Where review reports are written | `docs/research/reviews/` |",
+    `| \`<TEMPLATES_ROOT>\` | Where the writer bundle ships category templates (read-only for this agent) | \`${REQUIREMENTS_WRITER_PATHS.templatesRoot}\` |`,
+    `| \`<STANDARDS_REF>\` | Standards & frameworks reference shipped by the writer bundle | \`${REQUIREMENTS_WRITER_PATHS.standardsRef}\` |`,
     "",
-    "Tier is a **required metadata field**. Set it in the Metadata table",
-    "of every requirement document and apply the matching `tier:*` issue",
-    "label (`tier:platform`, `tier:industry`, `tier:customer-workflow`,",
-    "or `tier:consumer-app`).",
+    "If `docs/project-context.md` specifies a different requirements",
+    "tree, prefer that. Otherwise fall back to the defaults above.",
     "",
-    "**Customer field (optional).** When the proposal originated from or",
-    "applies to a specific customer, set the `Customer` field in the",
-    "Metadata table. Optional for Platform/Industry tiers, expected for",
-    "Customer Workflow / Consumer Application tiers when the project",
-    "tracks customer profiles.",
+    "---",
     "",
-    "**Implementor field (tier-specific).** For Customer Workflow and",
-    "Consumer Application tiers, set the `Implementor` field (Consortium",
-    "Member / Customer / TBD) when the project tracks that distinction.",
-    "Skip the field entirely if it does not apply to your project.",
+    "## Review Scope",
     "",
-    "**Cross-tier traceability.** Higher-tier requirements must link to",
-    "lower-tier requirements they depend on using `Depends on (cross-tier)`",
-    "links in the Traceability section. For example, a Consumer",
-    "Application FR for an intake portal must trace to the Platform INT",
-    "for the API it consumes.",
+    "Read the `req:review` issue body to determine the scope. The skill",
+    "supports four scopes \u2014 clarify with the issue author or in a",
+    "follow-up comment if the scope is not stated:",
+    "",
+    "1. **Full audit** \u2014 every requirement document under",
+    "   `<REQUIREMENTS_ROOT>` across all categories",
+    "2. **Category audit** \u2014 every document in one category directory",
+    "   (e.g., all FRs under `<REQUIREMENTS_ROOT>/functional/`)",
+    "3. **Single document** \u2014 one specific requirement file",
+    "4. **Targeted check** \u2014 one or more checks from the catalog below,",
+    '   run across the documents in scope (e.g., "check all traceability',
+    '   links" or "verify tier classification only")',
+    "",
+    "A full audit on a large document set can be extensive. If the issue",
+    "does not state a scope, comment on the issue requesting one and",
+    "leave the issue in `status:needs-attention` rather than guessing.",
     "",
     "---",
     "",
-    "## Decision Authority Rules",
+    "## Review Checklist",
     "",
-    "**This is the most important section.** Not all categories are",
-    "treated equally. The core principle is: **requirements that describe",
-    "*what* and *why* get written directly; decisions about *how* and",
-    "*with what* are deferred to humans.**",
+    "Apply the following 11 checks. Each check produces zero or more",
+    "findings. Findings are graded Critical / Warning / Info using the",
+    "severity ladder in the next section.",
     "",
-    "### Write Directly (status: `Draft`)",
+    "### 1. Structural Compliance",
     "",
-    "These categories describe business needs, user behavior, quality",
-    "targets, security posture, and user experience. The writer has full",
-    "authority to produce these documents:",
+    "For each document in scope, verify:",
     "",
-    "- **BR** \u2014 Business Requirements",
-    "- **FR** \u2014 Functional Requirements",
-    "- **NFR** \u2014 Non-Functional Requirements",
-    "- **SEC** \u2014 Security & Compliance",
-    "- **UX** \u2014 UX Requirements",
+    "- YAML frontmatter present with `title` and `description` fields",
+    "- Title in frontmatter matches the `# Heading` line",
+    "- File name follows `{PREFIX}-{NNN}-{slug}.md` (or the project",
+    "  prefix declared in `docs/project-context.md`)",
+    "- File is in the correct category directory under",
+    "  `<REQUIREMENTS_ROOT>`",
+    "- `Status` field is set to one of the valid values: `Draft`,",
+    "  `Proposed`, `Accepted`, `Implemented`, `Deprecated`, `Superseded`",
+    "- All sections from the matching category template at",
+    "  `<TEMPLATES_ROOT>` are present (sections that do not apply must",
+    "  carry `Not applicable \u2014 <reason>` rather than being silently",
+    "  omitted)",
+    "- `## Open Items` section exists with all three subsections",
+    "  (Identified Gaps, Follow-up Questions, Contradictions &",
+    "  Inconsistencies)",
+    "- `## Revision History` section exists",
+    "- `## Traceability` section exists",
     "",
-    "### Write with Partial Deferral",
+    "### 2. Categorization Accuracy",
     "",
-    "These categories contain a mix of *what* (write directly) and *how*",
-    "(defer). Write the requirement portions directly but defer",
-    "technology/tooling selections:",
+    "Verify each document is in the right category by applying the",
+    "disambiguation rules from the `requirements-writer` taxonomy:",
     "",
-    "- **DR** \u2014 Write data models, retention policies, and classification",
-    "  directly. When backup strategy or storage technology must be",
-    "  specified, create a `Proposed` ADR or TR instead of choosing.",
-    "- **MT** \u2014 Write tenant isolation requirements and metering",
-    "  dimensions directly. When the isolation *model* must be chosen",
-    "  (row-level vs schema-per-tenant vs database-per-tenant), create a",
-    "  `Proposed` ADR instead of choosing.",
-    "- **INT** \u2014 Write the integration shape, direction, error handling",
-    "  strategy, and SLA expectations directly. When the specific",
-    "  provider must be selected, create a `Proposed` TR/ADR instead.",
-    "- **OPS** \u2014 Write operational requirements (monitoring needs,",
-    "  incident response, deployment strategy) directly. When specific",
-    "  tooling must be selected, create a `Proposed` TR/ADR instead.",
+    "- **SEC vs NFR:** Protecting data, enforcing access control, or",
+    "  meeting a regulation \u2192 SEC. System performance, uptime, or",
+    "  scalability \u2192 NFR.",
+    "- **TR vs ADR:** A specific technology choice \u2192 TR. A structural",
+    "  decision with trade-offs \u2192 ADR.",
+    "- **FR vs INT:** User-visible behavior \u2192 FR. System-to-system",
+    "  communication \u2192 INT.",
+    "- **DR vs SEC:** Data lifecycle / retention / recovery \u2192 DR. Data",
+    "  access / protection \u2192 SEC.",
+    "- **NFR vs OPS:** Measurable system quality target \u2192 NFR. Tooling",
+    "  and processes to operate the system \u2192 OPS.",
     "",
-    "### Propose Only (status: `Proposed`, pending human decision)",
+    "Flag any documents that appear miscategorized. Explain where they",
+    "should live and why.",
     "",
-    "These categories represent technology and architecture decisions",
-    "that humans must make. Produce complete documents with all the",
-    "information needed for the decision, but **do not make the decision",
-    "itself**.",
+    "### 3. Traceability Completeness",
     "",
-    "- **ADR** \u2014 Write the full document following the ADR template:",
-    "  1. **Context** \u2014 forces at play, constraints, what prompted the",
-    "     decision",
-    '  2. **Decision** \u2014 set to: *"Pending human review. See',
-    '     Recommendation below."*',
-    "  3. **Alternatives Considered** \u2014 every viable option with",
-    "     equal-depth analysis. Each gets a description, pros, and cons.",
-    "     Do not shortchange options you don't prefer.",
-    "  4. **Recommendation** \u2014 state which option you recommend, *why*",
-    "     it's the best fit for the context, and what trade-offs are",
-    "     accepted. The reasoning must be specific to this project's",
-    "     situation \u2014 not generic.",
-    "  5. **Consequences** \u2014 positive, negative, and neutral consequences",
-    "     of the recommended option",
-    "  6. Set status to `Proposed`. Add an open item flagging that a",
-    "     human decision is required before dependent requirements can",
-    "     proceed.",
+    "Check that the requirement dependency graph is connected. Apply",
+    "these expectations as defaults; override them when the project's",
+    "`docs/project-context.md` defines a different traceability shape:",
     "",
-    "- **TR** \u2014 Write the full document following the TR template:",
-    '  1. **Technology Choice** \u2014 set to: *"Pending human review. See',
-    '     Recommendation below."*',
-    "  2. **Alternatives Considered** \u2014 every viable technology option",
-    "     with description, pros, cons, license, and maturity assessment",
-    "     for each",
-    "  3. **Recommendation** \u2014 state which technology you recommend,",
-    "     *why*, and what trade-offs are accepted",
-    '  4. **Rationale** \u2014 set to: *"See Recommendation above. Awaiting',
-    '     human decision."*',
-    "  5. Set status to `Proposed`. Add an open item flagging that a",
-    "     human decision is required.",
+    "- Every FR should trace back to at least one BR (via",
+    '  "Implements")',
+    '- Every TR should trace to at least one ADR (via "Justified by")',
+    "- Every ADR should trace to at least one BR or FR (via",
+    '  "Supports")',
+    "- Every SEC, NFR, UX should appear as a constraint or",
+    "  cross-reference on the FRs they affect",
+    "- Every INT should trace to at least one FR that depends on it",
+    "- Every DR should be referenced by SEC documents that govern its",
+    "  protection",
+    "- Every OPS should reference the NFR targets it monitors",
     "",
-    "### How Deferral Works in Practice",
+    "Identify orphaned requirements (documents with no inbound or",
+    "outbound traceability links) and flag them.",
     "",
-    "When writing a requirement that implies a technology choice:",
+    "### 4. Cross-Reference Integrity",
     "",
-    "1. Write the requirement itself (FR, DR, INT, OPS, etc.) with full",
-    "   detail.",
-    "2. Where the requirement needs a technology decision, add a note:",
-    '   *"Technology selection pending \u2014 see [ADR-NNN](../architectural-decisions/ADR-NNN-slug.md)"*.',
-    "3. Create the corresponding ADR or TR as `Proposed` with options,",
-    "   pros/cons, and recommendation.",
-    '4. In the ADR/TR open items, add: *"Human decision required.',
-    '   Dependent requirements: [list]"*.',
-    "5. In the original requirement's open items, add a cross-reference:",
-    '   *"Blocked by [ADR-NNN](../architectural-decisions/ADR-NNN-slug.md) \u2014',
-    '   technology selection pending human review."*',
+    "Check **every markdown link to a `.md` file in the entire",
+    "document** \u2014 not just links inside the Traceability section.",
+    "Broken links frequently appear in body text (Description, Main",
+    "Flow, Acceptance Criteria, etc.) where documents reference other",
+    "requirements inline.",
     "",
-    "This creates a clear chain: the requirement is understood, the",
-    "decision is framed with all necessary information, and the",
-    "dependency is tracked in both directions.",
+    "For every link in every document:",
     "",
-    "---",
+    "- The target file exists at the referenced path \u2014 **resolve the",
+    "  relative path against the filesystem**, do not eyeball it",
+    "- The target file's ID matches the link text",
+    "- Relative paths are correct (cross-category uses `../`,",
+    "  same-category is direct)",
+    "- All links include the `.md` extension",
+    "- Bidirectional links exist where expected (if A references B in",
+    "  Traceability, B should reference A)",
     "",
-    "## File Naming Convention",
+    "### 5. Sequence Number Integrity",
     "",
-    "Every requirement file follows this pattern:",
+    "Within each category directory under `<REQUIREMENTS_ROOT>`:",
     "",
-    "```",
-    "{PREFIX}-{NNN}-{slug}.md",
-    "```",
+    "- No duplicate sequence numbers",
+    "- No gaps in the sequence (gaps may be intentional from deleted",
+    "  docs but should be noted as Info)",
+    "- Sequence numbers are zero-padded to three digits (`001`, `012`,",
+    "  `127`)",
     "",
-    "- **PREFIX** \u2014 category abbreviation (`BR`, `FR`, `NFR`, `TR`,",
-    "  `ADR`, `SEC`, `DR`, `INT`, `OPS`, `UX`, `MT`). If the project",
-    "  declares a project-wide prefix in `docs/project-context.md`, use",
-    "  it instead.",
-    "- **NNN** \u2014 three-digit sequential number (001, 002, 012). Always",
-    "  check the target category directory under `<REQUIREMENTS_ROOT>`",
-    "  for the next available number before writing.",
-    "- **slug** \u2014 lowercase kebab-case descriptive name.",
+    "### 6. Content Quality",
     "",
-    "Examples: `FR-001-user-registration.md`,",
-    "`ADR-003-database-selection.md`,",
-    "`SEC-001-authentication-framework.md`.",
+    "For each document, evaluate:",
+    "",
+    "- **Completeness** \u2014 Are all template sections filled in",
+    "  meaningfully, or are there unexplained TBDs?",
+    "- **Specificity** \u2014 Are acceptance criteria testable? Are NFR",
+    "  targets numeric and measurable? Are success metrics concrete?",
+    "- **Consistency** \u2014 Do related documents agree with each other?",
+    "  (e.g., does an FR's description match the corresponding INT's",
+    "  integration shape?)",
+    "- **Staleness** \u2014 Are statuses up to date? Are there `Draft`",
+    "  documents that should have progressed?",
+    "- **Naming consistency** \u2014 When `docs/project-context.md` declares",
+    "  a project name or product name, verify it is used consistently",
+    "  across documents.",
     "",
-    "---",
+    "### 7. Open Items Review",
     "",
-    "## Frontmatter",
+    "Across all documents in scope:",
     "",
-    "Every `.md` requirement file must begin with a YAML frontmatter",
-    "block. The minimum required fields are `title` and `description`:",
+    "- Are open items prioritized (P0\u2013P3)?",
+    "- Are interdependencies between open items documented with",
+    "  cross-references?",
+    "- Are there P0 (Blocker) items that have not been resolved?",
+    "- Are there stale open items that should have been addressed?",
     "",
-    "```markdown",
-    "---",
-    'title: "FR-001: User Registration"',
-    'description: "Functional requirement for the user registration workflow."',
-    "tier: platform",
-    "---",
+    "### 8. Registry Index Sync",
     "",
-    "# FR-001: User Registration",
+    "Each category directory has a `README.md` (or `index.md`) file",
+    "that serves as a registry table listing all requirements in that",
+    "category. Check that these are in sync:",
     "",
-    "...",
-    "```",
+    "- Every requirement file in the directory has a corresponding row",
+    "  in the index",
+    "- No rows in the index reference files that do not exist (stale",
+    "  entries from deleted docs)",
+    "- Rows are in sequence number order",
+    "- The ID, Title, Status, and Priority in each row match the",
+    "  document's metadata",
+    "- No placeholder message remains when requirements exist",
     "",
-    "The `title` value must match the document's `# Heading` line.",
-    "Titles containing colons must be wrapped in double quotes. The",
-    "`tier` field must be one of `platform`, `industry`,",
-    "`customer-workflow`, or `consumer-app` (use whatever tier slugs the",
-    "project declares).",
+    "Flag missing entries as **Warning** and stale or incorrect entries",
+    "as **Warning**.",
     "",
-    "### Optional traceability extensions",
+    "### 9. Decision Authority Compliance",
     "",
-    "Projects that publish requirements through Starlight, Astro, or a",
-    "similar static-site generator may add structured traceability fields",
-    "to frontmatter. One example: a `referencedIn.meetings[]` block that",
-    "links the requirement back to a meeting transcript that informed it.",
-    "These conventions are **optional** \u2014 adopt them only if your project",
-    "already maintains the matching reverse-link structures.",
+    "Verify that the `requirements-writer` decision-authority rules",
+    "were followed:",
     "",
-    "---",
+    "- ADR and TR documents should be in `Proposed` status if they",
+    "  have not been explicitly accepted by a human",
+    "- Direct-write categories (BR, FR, NFR, SEC, UX) should not",
+    "  contain technology-specific decisions \u2014 those should be deferred",
+    "  to ADR/TR documents",
+    "- Partial-deferral categories (DR, MT, INT, OPS) should defer",
+    "  technology/tooling choices to `Proposed` ADR/TR documents",
+    "  rather than embedding them inline",
     "",
-    "## Status Lifecycle",
+    "For `Proposed` ADR and TR documents, additionally verify the",
+    "comparison and recommendation structure:",
     "",
-    "Every requirement has a status that tracks where it is in its",
-    "lifecycle:",
+    "- **Alternatives Considered** section exists with at least 2",
+    "  options",
+    "- Each alternative has a description, pros, and cons \u2014 no option",
+    "  is given cursory treatment",
+    "- **Recommendation** section exists with a named recommended",
+    "  option",
+    "- Recommendation includes a reasoned explanation specific to this",
+    "  project's context (not generic)",
+    "- Recommendation identifies key trade-offs being accepted",
+    '- Decision section says "Pending human review" (not "We',
+    '  will..." or "We decided...")',
+    "- Open Items include an item flagging that human decision is",
+    "  required, with references to dependent requirements blocked on",
+    "  this decision",
     "",
-    "| Status | Meaning |",
-    "|---|---|",
-    "| `Draft` | Initial capture, under discussion |",
-    "| `Proposed` | Formally proposed, awaiting review \u2014 **used for ADR and TR documents pending human decision** |",
-    "| `Accepted` | Approved and active |",
-    "| `Implemented` | Fully delivered |",
-    "| `Deprecated` | No longer applicable |",
-    "| `Superseded` | Replaced by another requirement (link to successor) |",
+    "### 10. Tier Classification Compliance",
     "",
-    "---",
+    "Verify that every document has a valid tier classification. The",
+    "default tier set is `platform`, `industry`, `customer-workflow`,",
+    "`consumer-app`; consuming projects may rename or reduce the tier",
+    "set in their own `docs/project-context.md`.",
     "",
-    "## Traceability",
+    "- `tier` field is set in YAML frontmatter (one of the project's",
+    "  declared tier slugs)",
+    "- `Tier` row is set in the Metadata table with a matching value",
+    "- `Implementor` field is set for Customer Workflow and Consumer",
+    "  Application tiers when the project tracks that distinction",
+    "  (Consortium Member / Customer / TBD)",
+    "- `Implementor` field is absent or N/A for Platform and Industry",
+    "  tiers",
+    '- When `Implementor` is "Consortium Member", it links to a',
+    "  valid org profile",
+    "- `Customer` field is set for Customer Workflow and Consumer",
+    "  Application tiers when the project tracks customer profiles,",
+    "  linking to a valid customer org profile",
+    "- `Customer` field in YAML frontmatter (if present) matches the",
+    "  Customer row in the Metadata table",
+    "- `customer:<slug>` label exists on the corresponding GitHub issue",
+    "  (when traceable)",
+    "- Industry-tier requirements specify which industry/vertical they",
+    "  apply to",
+    "- Platform-tier requirements do not contain industry-specific",
+    "  concerns that should be scoped to the Industry tier",
+    "- Cross-tier traceability links exist where expected:",
+    "  - Consumer Application requirements have `Depends on",
+    "    (cross-tier)` links to Platform requirements (the APIs they",
+    "    consume)",
+    "  - Customer Workflow requirements have `Depends on (cross-tier)`",
+    "    links to Platform requirements (the configuration capabilities",
+    "    they use)",
+    "  - Industry requirements have `Depends on (cross-tier)` links to",
+    "    Platform requirements (the core services they extend)",
+    "  - Platform requirements that enable higher-tier work have",
+    "    `Enables (cross-tier)` links",
+    "- Multi-tier decompositions are complete \u2014 if a customer need was",
+    "  decomposed across tiers, all expected tiers have corresponding",
+    "  requirements linked together",
     "",
-    "Every requirement document must include a `## Traceability` section.",
-    "Use relative markdown links with the requirement ID as link text.",
+    "Flag as **Critical**: missing tier field; platform requirements",
+    "containing industry-specific logic.",
+    "Flag as **Warning**: missing cross-tier traceability; missing",
+    "Implementor field on Customer Workflow / Consumer Application",
+    "requirements when the project tracks that field; missing Customer",
+    "field on Customer Workflow / Consumer Application requirements;",
+    'Implementor claiming "Consortium Member" without a linked org',
+    "profile.",
     "",
-    "```markdown",
-    "## Traceability",
+    "### 11. Cross-Referencing Convention Compliance",
     "",
-    "- **Implements:** [BR-001](../business/BR-001-self-service-onboarding.md)",
-    "- **Constrained by:** [NFR-001](../non-functional/NFR-001-api-response-times.md)",
-    "- **Related:** [SEC-001](../security/SEC-001-authentication-framework.md)",
-    "```",
+    "Verify alignment with the project's cross-referencing conventions",
+    "(usually documented in `docs/project-context.md` or a profile",
+    "registry index):",
     "",
-    "### Link Types",
+    "- Requirements that reference profiled organizations use the",
+    "  project's profile-link convention (e.g., `profilePath`",
+    "  frontmatter, or relative links into the profiles tree)",
+    "- Requirements that trace to research output link to the correct",
+    "  paths under the project's research tree",
+    "- Optional convention: meeting-sourced requirements may reference",
+    "  the meeting transcript or insight document. This is **optional** \u2014",
+    "  only flag missing meeting links when the project documents the",
+    "  reverse-link structure (e.g., a `referencedIn.meetings[]`",
+    "  frontmatter block) and that structure is in active use.",
     "",
-    "| Link Type | Meaning |",
-    "|---|---|",
-    "| **Implements** | This requirement realizes a higher-level requirement |",
-    "| **Constrained by** | This requirement is bounded by another requirement |",
-    "| **Supports** | This requirement contributes to but does not fully realize another |",
-    "| **Supersedes** | This requirement replaces a deprecated one |",
-    "| **Related** | Informational relationship |",
+    "---",
     "",
-    "### Dependency Flow",
+    "## Severity Ladder",
     "",
-    "```",
-    "Business Requirements (BR)",
-    "    -> justify epics and initiatives",
+    "Group every finding by severity:",
     "",
-    "Functional (FR), Integration (INT), Multi-Tenancy (MT)",
-    "    -> decompose into feature work",
+    "### Critical (Must Fix)",
     "",
-    "NFRs, Security (SEC), UX",
-    "    -> appear as acceptance criteria AND as standalone requirements",
+    "Issues that undermine the integrity of the requirements",
+    "documentation:",
     "",
-    "Architectural Decisions (ADR)",
-    "    -> spawn implementation tasks and serve as context for TRs",
+    "- Miscategorized requirements",
+    "- Broken cross-references (target file does not exist on disk)",
+    "- Missing mandatory template sections",
+    "- Technology decisions embedded in direct-write categories without",
+    "  a corresponding `Proposed` ADR/TR",
+    "- P0 open items that are unresolved",
+    "- Missing `tier` field; platform requirements containing",
+    "  industry-specific logic",
     "",
-    "Technical (TR), Data (DR), Operational (OPS)",
-    "    -> drive infrastructure and platform work",
-    "```",
+    "### Warning (Should Fix)",
     "",
-    "---",
+    "Issues that reduce quality but do not break the documentation:",
     "",
-    "## Open Items",
+    "- Missing traceability links (orphaned requirements)",
+    "- Unidirectional cross-references (A links to B, but B does not",
+    "  link to A)",
+    "- Vague acceptance criteria or unmeasurable NFR targets",
+    "- Stale statuses or unaddressed open items",
+    "- Sequence number gaps",
+    "- Registry index out of sync with actual files (missing entries,",
+    "  stale rows, incorrect metadata)",
+    "- Missing cross-tier traceability; missing Implementor / Customer",
+    "  fields on Customer Workflow / Consumer Application requirements",
+    "  when the project tracks those fields",
     "",
-    "Every requirement document must end with a `## Open Items` section",
-    "(placed just above `## Revision History`). This section surfaces",
-    "things that need human attention.",
+    "### Info (Consider)",
     "",
-    "### Priority Levels",
+    "Observations and suggestions:",
     "",
-    "| Priority | Meaning |",
-    "|---|---|",
-    "| **P0 \u2014 Blocker** | Cannot proceed with implementation until resolved |",
-    "| **P1 \u2014 High** | Significantly affects scope, security, or architecture |",
-    "| **P2 \u2014 Medium** | Affects quality or completeness but doesn't block progress |",
-    "| **P3 \u2014 Low** | Minor clarification, can be resolved asynchronously |",
+    "- Opportunities to add cross-references between related",
+    "  requirements",
+    "- TBD sections that could be filled in with available information",
+    "- Style inconsistencies across documents",
+    "- Sequence number gaps that appear intentional from deleted docs",
     "",
-    "### Subsection Types",
+    "---",
     "",
-    "- **Identified Gaps** \u2014 Missing functionality, unhandled edge cases,",
-    "  incomplete aspects",
-    "- **Follow-up Questions** \u2014 Ambiguities where intent cannot be",
-    "  confidently inferred",
-    "- **Contradictions & Inconsistencies** \u2014 Conflicts between",
-    "  requirements, documentation, or stated goals",
+    "## Reporting Format",
     "",
-    "Number each item within its subsection. Assign a priority. Call out",
-    "interdependencies with open items in other documents using the",
-    "format: `-> Depends on: [FR-001 Open Item #2](../functional/FR-001-slug.md#open-items)`.",
+    "Write the review report to",
+    "`<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD.md` (substitute",
+    "the date and a short scope slug). Structure the report as:",
     "",
-    "The `## Open Items` section is **not optional** \u2014 it appears in every",
-    'document, even if a subsection is empty (write "None identified.").',
+    "```markdown",
+    "# Requirements Review: <scope>",
     "",
-    "---",
+    "**Date:** YYYY-MM-DD",
+    "**Scope:** <full audit | category | single document | targeted",
+    "check>",
+    "**Source issue:** #NNN",
     "",
-    "## Reading the Templates and Standards Reference",
+    "## Critical (Must Fix)",
     "",
-    "Before writing any requirement document:",
+    "1. **[<file path>] <short title>** `Critical`",
+    "   <one-paragraph description, citing the specific check that",
+    "   failed>",
     "",
-    "1. **Read the matching template** under `<TEMPLATES_ROOT>` for the",
-    "   category specified in the issue (`_template-FR.md`,",
-    "   `_template-ADR.md`, etc.). Templates are named",
-    "   `_template-{PREFIX}.md`. Every section in the template must",
-    "   appear in the final document.",
+    "## Warning (Should Fix)",
     "",
-    "2. **Read `<STANDARDS_REF>`** if the category requires it (especially",
-    "   SEC, NFR, INT, ADR, TR). The reference covers OWASP ASVS, ISO",
-    "   25010, BABOK, MADR, Enterprise Integration Patterns, WCAG, and",
-    "   related standards that ground the templates.",
+    "1. **[<file path>] <short title>** `Warning`",
+    "   ...",
     "",
-    "Templates and the standards reference ship with this skill \u2014 they",
-    "are the same files for every project that adopts the bundle.",
+    "## Info (Consider)",
     "",
-    "---",
+    "1. **[<file path>] <short title>** `Info`",
+    "   ...",
     "",
-    "## Maintaining the Registry Index",
+    "## Review Summary",
     "",
-    "Each category directory contains a `README.md` (or `_index.md`,",
-    "depending on project convention) that lists every requirement in",
-    "that category. **After writing any new requirement document, update",
-    "the category index:**",
+    "| Severity | Count |",
+    "|---|---|",
+    "| Critical | N |",
+    "| Warning | N |",
+    "| Info | N |",
     "",
-    "1. Read the index file in the same directory as the new requirement.",
-    "2. Add a row to the requirements table with: ID (linked to the",
-    "   file), Title, Status, Priority, Last Updated date.",
-    "3. Insert the row in sequence-number order.",
-    "4. If the index contains a placeholder message, remove it.",
+    "**Categories reviewed:** [list]",
+    "**Documents reviewed:** N",
+    "**Overall assessment:** [Brief 1-2 sentence assessment]",
+    "```",
     "",
-    "If the project has not seeded category READMEs yet, generate one",
-    "from `_template-category-README.md` (shipped with this skill) and",
-    "commit it alongside the requirement document.",
+    "Each finding must cite the file path and the specific check that",
+    'produced it (e.g., "Check 4: Cross-Reference Integrity \u2014 target',
+    "file `../security/SEC-007-audit-logs.md` does not exist on",
+    'disk").',
     "",
     "---",
     "",
-    "## Agent Loop",
-    "",
-    "Run this loop exactly once per session. Never start a second issue.",
+    "## Automated Verification (>10 documents)",
     "",
-    "1. Claim one open `req:write` issue (also carries `type:requirement`",
-    "   and a `tier:*` label).",
-    "2. Transition `status:ready` \u2192 `status:in-progress` and create the",
-    "   branch per your project's branch-naming convention.",
-    "3. Execute the write phase below.",
-    "4. Commit, push, open a PR, and close the issue per your project's",
-    "   PR workflow. Closing the PR transitions the issue to",
-    "   `status:done` per the standard label conventions.",
+    "For audits covering more than 10 documents, **write a Python",
+    "verification script** rather than reading files one by one.",
+    "Manual review of large document sets always misses things \u2014",
+    "especially broken links where the filename is plausible but wrong.",
     "",
-    "---",
+    "Save the script alongside the review report at",
+    "`<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD-verify.py` so",
+    "future reviews can re-run it. The script must be idempotent and",
+    "read-only \u2014 it inspects files, it does not mutate them.",
     "",
-    "## The `req:write` Phase",
+    "At minimum, the script must:",
     "",
-    "**Goal:** Read the proposal that produced this issue, write a single",
-    "requirement document under `<REQUIREMENTS_ROOT>`, and update the",
-    "category index.",
+    "1. **Resolve every markdown link.** For each `[text](path.md)`",
+    "   link in every document in scope, resolve the relative path",
+    "   against the filesystem and verify the target file exists.",
+    "   Do not skip links outside Traceability sections.",
+    "2. **Extract traceability links.** Parse the `## Traceability`",
+    "   section of each document, collect all `[PREFIX-NNN](path)`",
+    "   references, and build a directed link graph.",
+    "3. **Check bidirectionality.** For every (A \u2192 B) link in the",
+    "   graph, verify (B \u2192 A) exists.",
+    "4. **Verify structural sections.** Check for required section",
+    "   headings (`## Open Items`, `## Revision History`,",
+    "   `## Traceability`, etc.) using string matching.",
+    "5. **Check registry sync.** Compare files on disk in each",
+    "   category directory against entries in the directory's",
+    "   `README.md` / `index.md`.",
     "",
-    "**Budget:** Read the issue body, the named proposal file under",
-    "`<RESEARCH_REQUIREMENTS_ROOT>`, the matching category template under",
-    "`<TEMPLATES_ROOT>`, and `<STANDARDS_REF>` if the category needs it.",
-    "Write one requirement document and one category-index update. No web",
-    "searches.",
+    "Present the script's output as the basis for the audit report.",
+    "This ensures reproducible, complete results.",
     "",
-    "### Steps",
+    "---",
     "",
-    "1. **Parse the issue.** The `req:write` issue body must include:",
-    "   - **Category** (`BR`/`FR`/`NFR`/`TR`/`ADR`/`SEC`/`DR`/`INT`/`OPS`/`UX`/`MT`)",
-    "   - **Tier** (`platform`/`industry`/`customer-workflow`/`consumer-app`)",
-    "   - **Output Path** under `<REQUIREMENTS_ROOT>/<category-dir>/<PREFIX>-<NNN>-<slug>.md`",
-    "   - **Inputs / Read** \u2014 the upstream proposals file and any source",
-    "     documents",
-    "   If any of these are missing or contradictory, comment on the",
-    "   issue, add `status:needs-attention`, and stop without writing.",
+    "## Filesystem Durability and Issue-Graph Sequencing",
     "",
-    "2. **Read the proposal.** Open the proposals file referenced in the",
-    "   issue inputs (under `<RESEARCH_REQUIREMENTS_ROOT>`). Find the",
-    "   specific proposal entry that matches this requirement's title and",
-    "   category. Treat the proposal as the authoritative source \u2014 do not",
-    "   invent fields it omits.",
+    "Write the review report to disk **before** opening any follow-up",
+    "issues. The report is the durable record; the issues are pointers",
+    "into it. If the session is interrupted after issues are filed but",
+    "before the report is committed, future runs cannot reconstruct the",
+    "context.",
     "",
-    "3. **Read the matching template** under `<TEMPLATES_ROOT>` for the",
-    "   category. Read `<STANDARDS_REF>` if the category is SEC, NFR,",
-    "   INT, ADR, or TR \u2014 these depend on the standards reference for",
-    "   correct framing.",
+    "Sequence:",
     "",
-    "4. **Pick the next sequence number.** Scan the target category",
-    "   directory under `<REQUIREMENTS_ROOT>` for existing files matching",
-    "   `{PREFIX}-NNN-*.md`. Use the next unused three-digit number.",
+    "1. Read scope from the `req:review` issue.",
+    "2. Read the matching templates from `<TEMPLATES_ROOT>` for every",
+    "   category in scope.",
+    "3. Run the 11 checks. For audits >10 documents, write the",
+    "   verification script to disk first and run it.",
+    "4. Write the report to",
+    "   `<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD.md`.",
+    "5. Commit the report (and verification script, if written).",
+    "6. Open one follow-up issue per actionable finding (Critical or",
+    "   Warning). Every follow-up issue includes the file path, a link",
+    "   to the report, and the specific check that produced it.",
+    "7. Comment on the `req:review` issue with a summary of findings",
+    "   and links to the follow-up issues.",
     "",
-    "5. **Apply the decision-authority rules.** Default to `Status:",
-    "   Draft` for direct-write categories (BR, FR, NFR, SEC, UX). Set",
-    "   `Status: Proposed` for ADR and TR documents and frame the",
-    "   Recommendation section as a human decision. For DR/MT/INT/OPS",
-    "   categories that imply a technology choice, write the requirement",
-    "   directly but spin the technology decision off into a separate",
-    "   `Proposed` ADR or TR \u2014 record the cross-link in the Open Items",
-    "   section of both documents.",
+    "---",
     "",
-    "6. **Write the document.** Fill every section in the template. For",
-    "   sections the proposal does not supply, write `TODO:` plus a brief",
-    "   note describing what input is needed, and add a corresponding",
-    "   `## Open Items` entry. Never leave a template section out.",
+    "## Follow-Up Issues",
     "",
-    "7. **Set frontmatter.** At minimum: `title`, `description`, `tier`.",
-    "   If the project declares optional frontmatter conventions in",
-    "   `docs/project-context.md` (such as `referencedIn.meetings[]`),",
-    "   honor them. Otherwise stop at the minimum.",
+    "Open follow-up issues for **Critical** and **Warning** findings.",
+    "Skip Info findings \u2014 they are guidance, not work items.",
     "",
-    "8. **Update the category index.** If the category directory has a",
-    "   `README.md` or `_index.md` registry, add a row for the new",
-    "   document in sequence order. If no index exists yet, generate one",
-    "   from `_template-category-README.md`.",
+    "Each follow-up issue:",
     "",
-    "9. **Cross-link upstream.** Add `## Traceability` entries pointing",
-    "   to the proposals file (under `<RESEARCH_REQUIREMENTS_ROOT>`),",
-    "   the source documents the proposal cited, and any BCM capability",
-    "   the requirement supports.",
+    "- Carries `type:requirement` (the type owned by the upstream",
+    "  `requirements-analyst` bundle)",
+    "- Carries the appropriate phase label for the work needed:",
+    "  - Structural / content fixes that an existing document needs \u2192",
+    "    `req:write` (the `requirements-writer` agent picks it up to",
+    "    revise the document)",
+    "  - Missing or broken traceability links \u2192 `req:trace` (the",
+    "    `requirements-analyst` agent picks it up to backfill",
+    "    traceability)",
+    "  - A new requirement is needed (e.g., a `Proposed` ADR is missing",
+    "    for a deferred technology choice) \u2192 `req:scan` (the analyst",
+    "    runs a scoped scan to confirm the gap, then drafts the new",
+    "    requirement through the normal pipeline)",
+    "- Sets priority based on finding severity: Critical \u2192",
+    "  `priority:high`; Warning \u2192 `priority:medium`",
+    "- Includes the affected file path in the body and links back to",
+    "  the review report",
+    "- Adds `status:ready` (or `status:blocked` when the finding",
+    "  declares a `Depends on: #N` on another open issue)",
     "",
-    "10. **Quality checks.** Before committing, verify:",
-    "    - [ ] Frontmatter has `title` and `description` (and `tier` if",
-    "          the project uses tier classification)",
-    "    - [ ] Title matches the `# Heading` line",
-    "    - [ ] File name follows `{PREFIX}-{NNN}-{slug}.md`",
-    "    - [ ] Status is `Draft` for direct-write categories or `Proposed`",
-    "          for ADR/TR",
-    "    - [ ] Every template section is present (use `TODO:` or `Not",
-    "          applicable \u2014 <reason>` for unfilled sections)",
-    "    - [ ] `## Traceability` exists with at least one upstream link",
-    "    - [ ] No technology decisions made in direct-write categories \u2014",
-    "          deferred to `Proposed` ADR/TR with cross-links in Open",
-    "          Items",
-    "    - [ ] `## Open Items` is present with Identified Gaps,",
-    "          Follow-up Questions, and Contradictions subsections",
-    "    - [ ] ADR/TR documents include a Recommendation section and an",
-    "          Open Item flagging the human decision required",
-    "    - [ ] Category index updated with a row for the new document",
-    "    - [ ] Tier value matches the issue's `tier:*` label",
-    "    - [ ] Cross-tier traceability entries exist where the document",
-    "          depends on or enables a different tier",
+    "**Do NOT create:**",
     "",
-    "11. **Commit and push.** Use a `docs(<category>):` conventional",
-    "    commit message. The PR closes the `req:write` issue.",
+    "- `req:review` issues \u2014 that would be self-referential",
+    "- `bcm:*`, `people:*`, `company:*`, `software:*`, `research:*`,",
+    "  or `industry:*` issues \u2014 those belong to their respective",
+    "  bundles. If the review surfaces work for one of those bundles,",
+    "  comment on the `req:review` issue with the suggested follow-up",
+    "  and let a human triage it",
     "",
     "---",
     "",
@@ -10920,183 +10938,193 @@ var requirementsWriterSubAgent = {
     "",
     "This agent writes **only** to:",
     "",
-    "- `<REQUIREMENTS_ROOT>/<category-dir>/<PREFIX>-<NNN>-<slug>.md` \u2014 one",
-    "  requirement document per session",
-    "- `<REQUIREMENTS_ROOT>/<category-dir>/README.md` (or `_index.md`) \u2014",
-    "  category index, one row appended per session",
-    "- `<REQUIREMENTS_ROOT>/README.md` (or `_index.md`) \u2014 only if the",
-    "  top-level requirements README does not yet exist; generate from",
-    "  `_template-requirements-README.md` and stop",
-    "",
-    "The pipeline produces **requirement documents**. It does not write",
-    "BCM capability models, people profiles, company profiles, software",
-    "profiles, scan reports, or proposal files \u2014 those belong to",
-    "specialized upstream/downstream agents.",
+    "- `<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD.md` \u2014 one",
+    "  review report per session",
+    "- `<REVIEW_REPORTS_ROOT>/review-<scope>-YYYY-MM-DD-verify.py` \u2014",
+    "  the verification script for audits >10 documents (read-only,",
+    "  idempotent)",
+    "- Follow-up GitHub issues (one per actionable finding)",
+    "- A summary comment on the `req:review` issue",
     "",
-    "**Do NOT create:**",
-    "- `req:scan`, `req:draft`, or `req:trace` issues \u2014 those belong to",
-    "  the `requirements-analyst` bundle",
-    "- `bcm:*` issues \u2014 those belong to the `bcm-writer` bundle",
-    "- `people:*`, `company:*`, `software:*`, `research:*`, or",
-    "  `industry:*` issues \u2014 those belong to their respective bundles",
+    "**Do NOT write to:**",
     "",
-    "If the proposal surfaces work that needs one of the above, comment",
-    "on the `req:write` issue with the suggested follow-up and let a",
-    "human route it.",
+    "- The requirement documents themselves under",
+    "  `<REQUIREMENTS_ROOT>` \u2014 those edits belong to the",
+    "  `requirements-writer` agent picking up a follow-up `req:write`",
+    "  issue",
+    "- The category index files \u2014 those edits belong to the writer",
+    "- The templates at `<TEMPLATES_ROOT>` \u2014 those are owned by the",
+    "  `requirements-writer` bundle source, not by per-project state",
     "",
     "---",
     "",
-    "## Coordination with Other Agents",
+    "## Iterating on Reviews",
     "",
-    "| Direction | Agent | What |",
-    "|-----------|-------|------|",
-    "| Upstream | `requirements-analyst` | Discovers gaps, drafts proposals, and creates `req:write` issues that this agent picks up |",
-    "| Upstream | `bcm-writer` | Provides BCM capability documents that requirements trace back to via `## Traceability` links |",
-    "| Peer | `meeting-analyst` | Provides meeting transcripts that may inform a requirement's traceability extensions (optional) |",
+    "After the report is committed and follow-up issues are filed:",
     "",
-    "**File boundaries:** Reads `<RESEARCH_REQUIREMENTS_ROOT>` (proposals)",
-    "and the source documents the proposals cite. Writes",
-    "`<REQUIREMENTS_ROOT>` and the category index files. Never edits",
-    "proposals, scan reports, BCM documents, or profiles.",
+    "1. Comment on the `req:review` issue with a one-paragraph summary,",
+    "   the severity counts, and links to the report and follow-up",
+    "   issues.",
+    "2. If the user asked for re-review after fixes land, open a fresh",
+    "   `req:review` issue rather than reopening the original. Each",
+    "   review session produces a new dated report.",
     "",
     "---",
     "",
-    "## Rules",
+    "## Working Rules",
     "",
-    "- **One requirement per session.** Never write two documents in one",
-    "  session and never start a second issue.",
-    "- **Templates are authoritative.** Use the shipped template verbatim",
-    "  for the category. Every template section must appear in the final",
-    "  document.",
-    "- **Decision authority is non-negotiable.** Direct-write categories",
-    "  ship as `Draft`. ADR and TR ship as `Proposed` with a Recommendation",
-    "  framed for human decision. Mixed-deferral categories spin",
-    "  technology choices off into separate `Proposed` documents.",
-    "- **Cite, don't invent.** When the proposal omits a stakeholder,",
-    "  metric, threat model entry, or technology option, write `TODO:` and",
-    "  flag the issue with `status:needs-attention`.",
-    "- **Trace upstream.** Every requirement links back to its proposal,",
-    "  the source documents the proposal cited, and the BCM capability",
-    "  it supports (when applicable).",
-    "- **Update the category index every time.** A requirement that",
-    "  exists as a file but is missing from its category index is",
-    "  invisible to anyone browsing the documentation tree.",
-    "- **Write requirements, not capability models or gap reports.**",
-    "  Never open `req:scan`, `req:draft`, `req:trace`, or `bcm:*` issues",
-    "  from this pipeline."
+    "- **One review per session.** Stop after the report is written,",
+    "  follow-up issues are filed, and the summary comment is posted.",
+    "- **Audit only.** Never edit requirement documents, category",
+    "  indexes, or templates. Findings flow through follow-up issues.",
+    "- **Resolve, do not eyeball.** Cross-reference findings only count",
+    "  when the target path is verified missing on disk.",
+    "- **Cite every finding.** Every entry in the report must cite the",
+    "  file path and the numbered check that produced it.",
+    "- **Do not invent traceability rules.** Use the defaults documented",
+    "  above unless the project's `docs/project-context.md` declares a",
+    "  different traceability shape.",
+    "- **Audits >10 documents must use a verification script.** Manual",
+    "  review of large sets always misses broken links."
   ].join("\n")
 };
-var writeRequirementSkill = {
-  name: "write-requirement",
-  description: "Write one formal requirement document (BR / FR / NFR / TR / ADR / SEC / DR / INT / OPS / UX / MT) using the shipped category template and decision-authority rules. Picks up a req:write issue created by the upstream requirements-analyst pipeline (or kicked off ad hoc) and dispatches the requirements-writer agent.",
+var reviewRequirementsSkill = {
+  name: "review-requirements",
+  description: "Audit existing requirement documents (BR / FR / NFR / TR / ADR / SEC / DR / INT / OPS / UX / MT) for structural compliance, categorization, traceability, cross-reference integrity, sequence integrity, content quality, registry sync, decision-authority compliance, tier classification, and cross-referencing conventions. Supports four scopes (full audit, category, single document, targeted check) and dispatches the requirements-reviewer agent. Audits documents \u2014 never writes them. Soft dependency: expects requirement templates at `" + REQUIREMENTS_WRITER_PATHS.templatesRoot + "`, shipped by the requirements-writer bundle.",
   disableModelInvocation: true,
   userInvocable: true,
   context: "fork",
-  agent: "requirements-writer",
+  agent: "requirements-reviewer",
   platforms: { cursor: { exclude: true } },
-  referenceFiles: REQUIREMENTS_WRITER_REFERENCE_FILES,
   instructions: [
-    "# Write Requirement",
+    "# Review Requirements",
     "",
-    "Write one formal requirement document using the 11-category taxonomy",
-    "(BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) and the",
-    "decision-authority rules (direct-write vs. propose-only ADR/TR).",
-    "Dispatches the `requirements-writer` agent.",
+    "Audit existing requirement documents for structural compliance,",
+    "traceability, categorization, and content quality. Dispatches the",
+    "`requirements-reviewer` agent.",
+    "",
+    "## Soft Dependency",
+    "",
+    "This skill reads requirement category templates from",
+    `\`${REQUIREMENTS_WRITER_PATHS.templatesRoot}\`,`,
+    "which is shipped by the `requirements-writer` bundle. If your",
+    "project does not use the `requirements-writer` bundle, supply",
+    "equivalent templates at the same path before running a review.",
     "",
     "## Usage",
     "",
-    "/write-requirement <category> <short-title>",
+    "/review-requirements <scope>",
     "",
-    "Where `<category>` is one of `BR`, `FR`, `NFR`, `TR`, `ADR`, `SEC`,",
-    "`DR`, `INT`, `OPS`, `UX`, `MT`.",
+    "Where `<scope>` is one of:",
+    "",
+    "- `full` \u2014 audit every requirement document under",
+    "  `<REQUIREMENTS_ROOT>` across all categories",
+    "- `category:<slug>` \u2014 audit one category directory (e.g.,",
+    "  `category:functional` audits every FR)",
+    "- `doc:<path>` \u2014 audit one specific requirement file",
+    "- `check:<n>[,<n>...]` \u2014 run one or more checks (1\u201311) across the",
+    "  documents in scope (e.g., `check:4` runs cross-reference",
+    "  integrity only)",
     "",
     "Optional extensions in the issue body:",
-    "- `tier: platform | industry | customer-workflow | consumer-app` \u2014",
-    "  the architectural tier (default: `platform`)",
-    "- `prefix: <PROJECT_PREFIX>` \u2014 override the default category prefix",
-    "  with a project-specific one declared in `docs/project-context.md`",
-    "- `customer: <link-or-slug>` \u2014 link the requirement to a customer",
-    "  profile (expected for Customer Workflow / Consumer Application",
-    "  tiers in projects that track customer profiles)",
-    "- `proposal: <path>` \u2014 pin the upstream proposal file under",
-    "  `<RESEARCH_REQUIREMENTS_ROOT>` (default: derived from the issue",
-    "  context)",
-    "- `output: <path>` \u2014 override the default Output Path",
+    "",
+    "- `output: <path>` \u2014 override the default report path",
+    "- `requirements-root: <path>` \u2014 override `<REQUIREMENTS_ROOT>`",
+    "- `targets: <glob>` \u2014 restrict the document set with a glob",
+    "  pattern relative to `<REQUIREMENTS_ROOT>`",
     "",
     "## Default Paths",
     "",
     "If the project has no override in `docs/project-context.md` or",
     "`agentConfig.rules`, outputs land under:",
     "",
-    "- `docs/requirements/<category-dir>/<PREFIX>-<NNN>-<slug>.md`",
-    "- `docs/requirements/<category-dir>/README.md` (registry update)",
-    "- `docs/requirements/README.md` (top-level README, generated on",
-    "  first use only)",
-    "",
-    "Templates and the standards reference ship with this skill under",
-    "`_references/templates/` and `_references/standards-and-frameworks.md`.",
+    "- `docs/research/reviews/review-<scope>-YYYY-MM-DD.md` \u2014 the",
+    "  review report",
+    "- `docs/research/reviews/review-<scope>-YYYY-MM-DD-verify.py` \u2014",
+    "  the Python verification script (only for audits >10 documents)",
     "",
     "## Steps",
     "",
-    "1. Create a `req:write` issue with `type:requirement`,",
-    "   `priority:medium`, `status:ready`, and the matching `tier:*` label.",
-    "   Body must include the category, tier, output path, and a pointer",
-    "   to the upstream proposal (or a direct user description if no",
-    "   proposals file exists).",
-    "2. Execute the write phase of the requirements-writer agent.",
-    "3. The agent writes one requirement document, updates the category",
-    "   index, opens a PR, and closes the issue.",
+    "1. Create a `req:review` issue with `type:requirement`,",
+    "   `priority:medium`, and `status:ready`. Body must include the",
+    "   scope, the requirements root (or accept the default), and the",
+    "   output path.",
+    "2. Execute the review phase of the requirements-reviewer agent.",
+    "3. The agent runs the 11-check audit, writes a structured report",
+    "   grouped by Critical / Warning / Info, files follow-up issues",
+    "   for actionable findings, and comments on the `req:review`",
+    "   issue with the summary.",
+    "",
+    "## Audits >10 Documents",
+    "",
+    "For audits covering more than 10 documents, the agent writes a",
+    "Python verification script alongside the report and uses its",
+    "output as the basis for the audit. The script is read-only and",
+    "idempotent \u2014 it can be re-run after fixes land to confirm",
+    "remediation. The script is generated per-audit; it is not shipped",
+    "as a static asset.",
     "",
     "## Output",
     "",
-    "- One requirement document under `<REQUIREMENTS_ROOT>` following the",
-    "  shipped category template, with `Status: Draft` for direct-write",
-    "  categories or `Status: Proposed` for ADR/TR",
-    "- A category-index row pointing at the new document",
-    "- (First-time only) a top-level requirements README derived from",
-    "  `_template-requirements-README.md`"
+    "- One review report under `<REVIEW_REPORTS_ROOT>` grouped by",
+    "  Critical / Warning / Info severity",
+    "- One verification script under `<REVIEW_REPORTS_ROOT>` (only",
+    "  for audits >10 documents)",
+    "- Follow-up GitHub issues for every Critical and Warning finding,",
+    "  carrying the appropriate phase label (`req:write`, `req:trace`,",
+    "  or `req:scan`) for the downstream agent that should act",
+    "- A summary comment on the originating `req:review` issue"
   ].join("\n")
 };
-var requirementsWriterBundle = {
-  name: "requirements-writer",
-  description: "Requirements writer agent bundle. Authors formal requirement documents from upstream proposals using the 11-category taxonomy (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT), the four-tier classification, and decision-authority rules (direct-write vs. propose-only). Ships 13 templates plus a standards-and-frameworks reference.",
+var requirementsReviewerBundle = {
+  name: "requirements-reviewer",
+  description: "Requirements reviewer agent bundle. Audits existing requirement documents (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) for structural compliance, categorization, traceability, cross-reference integrity, sequence integrity, content quality, registry sync, decision-authority compliance, tier classification, and cross-referencing conventions. Reads templates from the requirements-writer bundle's reference directory; ships no templates of its own.",
   appliesWhen: () => true,
   rules: [
     {
-      name: "requirements-writer-workflow",
-      description: "Describes the requirements-writer pipeline, the req:write phase label, the four tier:* labels, and the boundary with the upstream requirements-analyst and bcm-writer bundles.",
+      name: "requirements-reviewer-workflow",
+      description: "Describes the requirements-reviewer pipeline, the req:review phase label, the four review scopes, the soft dependency on the requirements-writer bundle's templates, and the boundary with the writer and analyst bundles.",
       scope: AGENT_RULE_SCOPE.ALWAYS,
       content: [
-        "# Requirements Writer Workflow",
+        "# Requirements Reviewer Workflow",
         "",
-        "Use `/write-requirement <category> <short-title>` to author one",
-        "formal requirement document. The writer runs in a single phase",
-        "tracked by a GitHub issue labeled `req:write` plus the matching",
-        "`tier:*` label. Issues also carry `type:requirement` (declared",
-        "by the upstream `requirements-analyst` bundle).",
+        "Use `/review-requirements <scope>` to audit existing requirement",
+        "documents. The reviewer runs in a single phase tracked by a",
+        "GitHub issue labeled `req:review`. Issues also carry",
+        "`type:requirement` (declared by the upstream",
+        "`requirements-analyst` bundle).",
         "",
-        "The pipeline produces **requirement documents only** \u2014 capability",
-        "models are written by the `bcm-writer` agent and gap discovery is",
-        "the responsibility of the `requirements-analyst` agent. The",
-        "writer never opens `req:scan`, `req:draft`, `req:trace`, or",
-        "`bcm:*` issues.",
+        "The pipeline produces **review reports and follow-up issues** \u2014",
+        "it never edits requirement documents, capability models, or",
+        "research notes. Authoring is the responsibility of the",
+        "`requirements-writer` (requirement docs) and `bcm-writer`",
+        "(capability models) bundles; gap discovery is the responsibility",
+        "of the `requirements-analyst` bundle. The reviewer never opens",
+        "`req:scan`, `req:draft`, `req:trace`, `req:write`, or `bcm:*`",
+        "issues directly \u2014 instead it files follow-up issues with the",
+        "appropriate phase label (`req:write`, `req:trace`, or",
+        "`req:scan`) for the downstream agent to pick up.",
         "",
-        "Documents follow the 11-category taxonomy (BR, FR, NFR, TR, ADR,",
-        "SEC, DR, INT, OPS, UX, MT) and the four-tier classification",
-        "(Platform, Industry, Customer Workflow, Consumer Application).",
-        "Templates and a standards-and-frameworks reference ship with the",
-        "skill \u2014 they are the same files for every project that adopts",
-        "the bundle.",
+        "Four review scopes are supported: `full` (every document),",
+        "`category:<slug>` (one category directory), `doc:<path>` (one",
+        "specific document), and `check:<n>` (one or more of the 11",
+        "checks across the documents in scope).",
         "",
-        "Decision-authority rules are non-negotiable: BR / FR / NFR /",
-        "SEC / UX ship as `Status: Draft`; ADR and TR ship as",
-        "`Status: Proposed` with a Recommendation framed for human",
-        "decision; DR / MT / INT / OPS spin technology choices off into",
-        "separate `Proposed` ADR or TR documents.",
+        "**Soft dependency on the `requirements-writer` bundle.** The",
+        "reviewer reads category templates from",
+        `\`${REQUIREMENTS_WRITER_PATHS.templatesRoot}\`,`,
+        "which is shipped by the `requirements-writer` bundle. Projects",
+        "that disable the writer bundle but keep the reviewer must",
+        "supply equivalent templates at the same path.",
         "",
-        "See the `requirements-writer` agent definition for full workflow",
-        "details, configurable paths, decision-authority rules, and",
-        "phase-by-phase instructions."
+        "For audits covering more than 10 documents, the reviewer writes",
+        "a read-only Python verification script alongside the report and",
+        "uses its output as the basis for findings \u2014 manual review of",
+        "large document sets always misses broken links.",
+        "",
+        "See the `requirements-reviewer` agent definition for full",
+        "workflow details, configurable paths, the 11-check catalog, the",
+        "severity ladder, and reporting format."
       ].join("\n"),
       platforms: {
         cursor: { exclude: true }
@@ -11104,33 +11132,13 @@ var requirementsWriterBundle = {
       tags: ["workflow"]
     }
   ],
-  skills: [writeRequirementSkill],
-  subAgents: [requirementsWriterSubAgent],
+  skills: [reviewRequirementsSkill],
+  subAgents: [requirementsReviewerSubAgent],
   labels: [
     {
-      name: "req:write",
-      color: "FEF2C0",
-      description: "Phase: write a formal requirement document using the requirements-writer skill"
-    },
-    {
-      name: "tier:platform",
-      color: "EDEDED",
-      description: "Architectural tier: core platform (shared infrastructure, APIs, auth, tenant isolation)"
-    },
-    {
-      name: "tier:industry",
-      color: "EDEDED",
-      description: "Architectural tier: industry vertical (capabilities not every tenant needs)"
-    },
-    {
-      name: "tier:customer-workflow",
-      color: "EDEDED",
-      description: "Architectural tier: customer-configured workflow (business logic tenants configure within the platform)"
-    },
-    {
-      name: "tier:consumer-app",
-      color: "EDEDED",
-      description: "Architectural tier: consumer application (UI/UX and integrations in external front-ends/systems)"
+      name: "req:review",
+      color: "FBCA04",
+      description: "Phase: audit existing requirement documents using the requirements-reviewer skill"
     }
   ]
 };
@@ -16577,6 +16585,7 @@ export {
   PROD_DEPLOY_NAME,
   PnpmWorkspace,
   ProjectMetadata,
+  REQUIREMENTS_WRITER_PATHS,
   ROOT_CI_TASK_NAME,
   ROOT_TURBO_TASK_NAME,
   ResetTask,