ma-agents 3.5.0 → 3.5.2

package/README.md

@@ -128,8 +128,8 @@ These domain-expert agents are installed alongside BMAD-METHOD and provide guide
 | SRE Agent | Alex | `_bmad/skills/sre/` | `_bmad/bmm/agents/sre.md` |
 | DevOps Agent | Amit | `_bmad/skills/devops/` | `_bmad/bmm/agents/devops.md` |
 | Cyber Analyst | Yael | `_bmad/skills/cyber/` | `_bmad/bmm/agents/cyber.md` |
-| MIL-STD-498 Expert | Joseph | `_bmad/skills/mil498/` | `_bmad/bmm/agents/mil498.md` |
 | ML Scientist | Demerzel | `_bmad/skills/demerzel/` | `_bmad/bmm/agents/demerzel.md` |
+| SQA & Standards Expert | Gad | `_bmad/skills/sqa/` | `_bmad/bmm/agents/qa.md` |
 
 ## Available Skills
 
@@ -173,7 +173,7 @@ These skills are installed into your coding tool of choice and provide reusable
 | `docker-image-signing` | Security | Automated cryptographic signing for Docker images |
 | `docker-hardening-verification` | Security | Audits images for least-privilege and OpenShift compatibility |
 
-### Agent Workflows (24)
+### Agent Workflows (34)
 
 These workflows are installed as part of the BMAD agent system and are invoked through the agent's menu (not installed individually):
 
@@ -192,8 +192,18 @@ These workflows are installed as part of the BMAD agent system and are invoked t
 | `ml-revision` | ML Scientist | Amend hypothesis and requirements based on experiment findings |
 | `ml-advise` | ML Scientist | Search past experiments, surface findings and failure warnings |
 | `ml-retrospective` | ML Scientist | Capture session learnings and update project context |
-| **MIL-STD-498 (Joseph)** | | |
-| `mil498-requirement-quality` | MIL-STD-498 Expert | Evaluate requirements against 14 quality criteria — produces per-requirement audit table, Missing Elements report, and Overall Quality Score |
+| **SQA & MIL-STD-498 (Gad)** | | |
+| `sqa-audit` | SQA & Standards Expert | Multi-dimensional project quality audit: code↔story traceability, stories↔architecture/PRD alignment, process compliance, sprint health, release state — saves audit report and optional remediation plan |
+| `sqa-ieee12207` | SQA & Standards Expert | IEEE/ISO/IEC 12207:2017 compliance assessment across 23 process areas in 4 groups — produces compliance matrix, gap analysis, and optional remediation plan |
+| `sqa-requirements-quality` | SQA & Standards Expert | Requirements quality audit against 14 criteria with scope selection (PRD FRs, NFRs, epics, stories) — per-requirement audit table, critical-fail detection, Overall Quality Score, and optional remediation plan |
+| `mil498-srs` | SQA & Standards Expert | Generate Software Requirements Specification (SRS) per MIL-STD-498 DID |
+| `mil498-sdd` | SQA & Standards Expert | Generate Software Design Description (SDD) per MIL-STD-498 DID |
+| `mil498-sdp` | SQA & Standards Expert | Generate Software Development Plan (SDP) per MIL-STD-498 DID |
+| `mil498-ocd` | SQA & Standards Expert | Generate Operational Concept Description (OCD) per MIL-STD-498 DID |
+| `mil498-sss` | SQA & Standards Expert | Generate System/Subsystem Specification (SSS) per MIL-STD-498 DID |
+| `mil498-std` | SQA & Standards Expert | Generate Software Test Description (STD) per MIL-STD-498 DID |
+| `mil498-ssdd` | SQA & Standards Expert | Generate System/Subsystem Design Description (SSDD) per MIL-STD-498 DID |
+| `mil498-requirement-quality` | SQA & Standards Expert | Evaluate requirements against 14 quality criteria — per-requirement audit table, Missing Elements report, and Overall Quality Score (MIL-STD-498 context) |
 | **Sprint Management** | | |
 | `bmad-sprint-planning` | Scrum Master | Bootstrap or refresh the unified `sprint-status.yaml` from epics and bug stories |
 | `generate-backlog` | Scrum Master | Generate or refresh the `backlog` section of `sprint-status.yaml` from epics |
@@ -283,15 +293,15 @@ npx ma-agents install --yes    # fully offline BMAD install — no network neede
    - **Focus**: Cyber immunity, security auditing, and vulnerability management.
    - **Capabilities**: Immunity estimation (scoring), Vault secret management, and PKI automation.
    - **Integration**: Orchestrates ma-agents security skills for deep scans.
-4. **Joseph (MIL-STD-498)**:
-   - **Focus**: Technical standards compliance and military document generation.
-   - **Capabilities**: Document Data Descriptions (DIDs), requirements traceability, and complex specification writing.
-   - **Workflows**: SRS, SSS, and SSDD generation with strict structural validation.
-   - **Requirements QA**: Built-in `mil498-requirement-quality` skill — evaluates every requirement against 14 quality criteria (Clarity, Single Verb, Sentence Structure, Glossary Presence, Necessity, Implementation-Independence, Unambiguity, Completeness, Feasibility, Testability, Stakeholder Alignment, Convention Conformance, Understandability, Precision). Produces a per-requirement audit table, a Missing Elements report, and an Overall Quality Score. Applies to MIL-STD-498 documents, PRDs, and Epics/Stories.
-5. **Demerzel (ML Scientist)**:
+4. **Demerzel (ML Scientist)**:
    - **Focus**: Hypothesis-driven machine learning lifecycle with scientific rigor.
    - **Capabilities**: EDA, architecture design, locked TechSpec contracts, experiment execution, failure-cost analysis.
    - **Workflows**: 12-stage ML lifecycle from ideation through retrospective, with mandatory review gates.
+5. **Gad (SQA & Standards Expert)**:
+   - **Focus**: Software quality assurance and defense documentation standards — a unified persona covering SQA auditing and MIL-STD-498 document generation.
+   - **SQA Capabilities**: Multi-dimensional project quality audits, IEEE/ISO/IEC 12207:2017 compliance assessments (23 process areas, 4 groups), requirements evaluation against 14 established quality criteria (scope-selectable: PRD FRs, NFRs, epics, stories).
+   - **MIL-STD-498 Capabilities**: Full Data Item Description (DID) generation for SRS, SDD, SDP, OCD, SSS, STD, and SSDD. Requirements quality review tailored to MIL-STD-498 structure and military-standard terminology (CSCI, HWCI, IRS).
+   - **Remediation**: All audit and compliance workflows offer an optional remediation plan (`sqa-remediation-plan-{date}.md`) and per-finding `create-bug-story` integration for critical gaps.
 
 #### Operational Workflows
 The integration includes a suite of specialized playbooks:

package/_bmad-output/implementation-artifacts/16-4-validation-report.md

@@ -0,0 +1,79 @@
+# Story 16.4 Validation Report: Cross-Repo Path Resolution
+
+Generated: 2026-03-28
+
+## Audit Summary
+
+**Result: PASS** - All BMAD workflows are 100% config-driven. No hardcoded `_bmad-output/` paths found.
+
+## Gap Analysis Table
+
+| Workflow | Phase | Path Source | Hardcoded? | Config Key Used | Change Needed |
+|----------|-------|-----------|-----------|----------------|---------------|
+| bmad-product-brief | 1-Analysis | config.yaml | No | planning_artifacts | None |
+| bmad-domain-research | 1-Analysis | config.yaml | No | planning_artifacts | None |
+| bmad-market-research | 1-Analysis | config.yaml | No | planning_artifacts | None |
+| bmad-technical-research | 1-Analysis | config.yaml | No | planning_artifacts | None |
+| bmad-create-prd | 2-Planning | config.yaml | No | planning_artifacts | None |
+| bmad-create-ux-design | 2-Planning | config.yaml | No | planning_artifacts | None |
+| bmad-validate-prd | 2-Planning | config.yaml | No | planning_artifacts | None |
+| bmad-edit-prd | 2-Planning | config.yaml | No | planning_artifacts | None |
+| bmad-create-architecture | 3-Solutioning | config.yaml | No | planning_artifacts | None |
+| bmad-create-epics-and-stories | 3-Solutioning | config.yaml | No | planning_artifacts | None |
+| bmad-check-implementation-readiness | 3-Solutioning | config.yaml | No | planning_artifacts | None |
+| bmad-generate-project-context | 3-Solutioning | config.yaml | No | planning_artifacts | None |
+| bmad-sprint-planning | 4-Implementation | config.yaml | No | implementation_artifacts, planning_artifacts | None |
+| bmad-sprint-status | 4-Implementation | config.yaml | No | implementation_artifacts | None |
+| bmad-create-story | 4-Implementation | config.yaml | No | implementation_artifacts, planning_artifacts | None |
+| bmad-dev-story | 4-Implementation | config.yaml | No | implementation_artifacts | None |
+| bmad-retrospective | 4-Implementation | config.yaml | No | implementation_artifacts | None |
+| bmad-code-review | 4-Implementation | config.yaml | No | planning_artifacts, implementation_artifacts | None |
+| bmad-correct-course | 4-Implementation | config.yaml | No | implementation_artifacts | None |
+| bmad-quick-dev | 4-Implementation | config.yaml | No | implementation_artifacts, planning_artifacts | None |
+| bmad-qa-generate-e2e-tests | 4-Implementation | config.yaml | No | implementation_artifacts | None |
+
+## Config Resolution Chain
+
+All workflows follow this identical pattern:
+1. Load config from `{project-root}/_bmad/bmm/config.yaml`
+2. Resolve `planning_artifacts` and `implementation_artifacts` from config values
+3. Use `{planning_artifacts}/...` and `{implementation_artifacts}/...` for all path references
+
+**Multi-repo resolution:**
+- `planning_artifacts` = `{knowledgebase_path}/_bmad-output/planning-artifacts`
+- `implementation_artifacts` = `{sprint_management_path}/_bmad-output/implementation-artifacts`
+
+**Single-repo resolution (backward compatible):**
+- `planning_artifacts` = `_bmad-output/planning-artifacts`
+- `implementation_artifacts` = `_bmad-output/implementation-artifacts`
+
+## Source-of-Truth Precedence
+
+| File | Role | Authority |
+|------|------|-----------|
+| `_bmad/bmm/config.yaml` | Runtime source of truth | PRIMARY |
+| `_bmad-output/project-layout.yaml` | Agent discovery file | INFORMATIONAL |
+| `_bmad-output/project-context.md` | Agent constitutional doc | INSTRUCTIONAL |
+
+If these disagree, `_bmad/bmm/config.yaml` wins.
+
+## Backward Compatibility (NFR34)
+
+Single-repo mode writes:
+- `knowledgebase_path: "."` and `sprint_management_path: "."`
+- `planning_artifacts: "_bmad-output/planning-artifacts"`
+- `implementation_artifacts: "_bmad-output/implementation-artifacts"`
+
+These values are identical to the pre-Epic-16 default behavior. No workflow changes needed.
+
+## Path Accessibility
+
+Story 16.1 validates external paths at wizard time:
+- `fs.existsSync()` checks for local paths
+- `fs.statSync().isDirectory()` confirms it's a directory
+- Git clone validates remote paths
+- Non-existent paths generate warnings
+
+## Conclusion
+
+**No backlog items needed.** All 21 BMAD workflows already support config-driven path resolution through the `planning_artifacts` and `implementation_artifacts` config keys. Story 16.2's config write (updated during 16.4 validation) now also writes these derived fields, completing the end-to-end resolution chain.

package/_bmad-output/implementation-artifacts/19-1-knowledge-graph-core-library.md

@@ -0,0 +1,239 @@
+# Story 19.1: Knowledge Graph Core Library (`emitToGraph`)
+
+Status: ready-for-dev
+
+## Story
+
+As a **Chief Architect**,
+I want a shared `emitToGraph()` utility function in the BMAD extension module,
+so that all BMAD skills can emit nodes and edges to the knowledge graph using a single consistent API without duplicating file I/O logic.
+
+## Acceptance Criteria
+
+1. **Given** the function `emitToGraph(projectRoot, emission)` is called with a valid emission payload
+   **When** `_bmad-output/knowledge-graph.json` does not yet exist
+   **Then** the function creates the file with a valid four-section structure: `meta`, `files`, `nodes`, `edges`
+   **And** `meta` contains `schema_version: "1.0"`, `generated_at` (ISO timestamp), `project` (derived from package.json name or directory name), `file_count: 0`, `node_count: 0`, `edge_count: 0`
+   **And** `files`, `nodes`, `edges` are initialized as empty object, empty array, empty array respectively
+
+2. **Given** `knowledge-graph.json` already exists with prior content
+   **When** `emitToGraph()` is called
+   **Then** it reads the existing file, appends new files/nodes/edges, updates counts in `meta`, and writes the result back atomically
+   **And** no existing nodes, edges, or file registrations are deleted or overwritten
+
+3. **Given** an emission payload includes a `files` entry with `pointer_type: "relative_path"`
+   **When** that file-id does not yet exist in the `files` table
+   **Then** the file is registered: `files[file-id] = { pointer, title, pointer_type }`
+   **And** if the file-id already exists, registration is skipped (first-write-wins)
+
+4. **Given** an emission payload includes a node with id `file-id#heading-anchor`
+   **When** a node with that id already exists in `nodes`
+   **Then** the node is not duplicated (title update is allowed; all other fields preserved)
+
+5. **Given** an emission payload includes an edge with `(from, to, type)` triple
+   **When** an edge with the same `(from, to, type)` already exists in `edges`
+   **Then** the edge is not duplicated (provenance of the first edge is preserved; `created_at`/`agent` fields may be updated)
+
+6. **Given** the function writes the updated graph
+   **When** the write operation completes
+   **Then** `meta.file_count`, `meta.node_count`, `meta.edge_count` reflect the total counts in the file
+   **And** `meta.last_updated` is set to the current ISO-8601 timestamp
+
+## Tasks / Subtasks
+
+### Task 1: Create the `lib/knowledge-graph/` module (AC: 1, 2, 3, 4, 5, 6)
+
+- [ ] 1.1 Create directory `lib/knowledge-graph/`
+- [ ] 1.2 Create `lib/knowledge-graph/emit.js` implementing `emitToGraph(projectRoot, emission)`:
+  - Initialize graph if `knowledge-graph.json` does not exist: `{ meta: initMeta(projectRoot), files: {}, nodes: [], edges: [] }`
+  - Read and parse existing JSON if file exists
+  - Apply emission: register files (first-write-wins), add nodes (no duplicate by `id`; title update allowed), add edges (no duplicate by `from+to+type`; created_at/agent update allowed)
+  - Update `meta.file_count`, `meta.node_count`, `meta.edge_count`, `meta.last_updated`
+  - Write result as `JSON.stringify(graph, null, 2)` to `path.join(projectRoot, '_bmad-output', 'knowledge-graph.json')`
+  - Use synchronous I/O: `fs.existsSync`, `fs.readFileSync`, `fs.writeFileSync`
+- [ ] 1.3 Implement `initMeta(projectRoot)` helper:
+  - Reads `package.json` name if present at `projectRoot`; falls back to `path.basename(projectRoot)`
+  - Returns `{ schema_version: "1.0", project: <name>, generated_at: <ISO>, last_updated: <ISO>, file_count: 0, node_count: 0, edge_count: 0 }`
+- [ ] 1.4 Implement and export `headingToAnchor(heading)` utility function (used by all emitting skills):
+  ```javascript
+  function headingToAnchor(heading) {
+    return heading
+      .toLowerCase()
+      .replace(/[^\w\s-]/g, '')
+      .replace(/\s+/g, '-')
+      .replace(/-+/g, '-')
+      .trim();
+  }
+  ```
+- [ ] 1.5 Export both functions: `module.exports = { emitToGraph, headingToAnchor }`
+
+### Task 2: Verify the emission data contract (AC: 1–6)
+
+- [ ] 2.1 Manually verify (or write a quick smoke test in `tests/knowledge-graph/smoke.test.js`) that:
+  - First call creates a valid JSON file with the four sections
+  - Second call with the same payload is idempotent (counts unchanged)
+  - Second call with new nodes/edges appends correctly
+  - Counts in `meta` always match actual array/object sizes
+
+### Task 3: Verify module is importable by other skills (AC: none — integration readiness)
+
+- [ ] 3.1 Confirm the module path `../../lib/knowledge-graph/emit.js` (relative from a skill like `lib/bmad-extension/skills/open-graph/`) resolves correctly
+- [ ] 3.2 Confirm no circular dependencies are introduced
+
+## Dev Notes
+
+### CRITICAL: Two Deployment Pipelines — Where This Module Lives
+
+This story creates a **shared utility module** in `lib/knowledge-graph/`, NOT a skill. It is NOT deployed by the installer and NOT a BMAD extension skill. It is a Node.js module imported by other skills at runtime.
+
+**Module location:** `lib/knowledge-graph/emit.js`
+**Imported by:** All 7 emitting skills (Stories 19.2–19.4 wire them in)
+
+### Graph File Location
+
+Always: `path.join(projectRoot, '_bmad-output', 'knowledge-graph.json')`
+
+The `projectRoot` parameter is passed by each skill. Skills can derive `projectRoot` from their own `__dirname` by traversing up to the repo root, or from the BMAD config `_bmad/bmm/config.yaml`.
+
+### JSON Schema — Four-Section Structure
+
+```json
+{
+  "meta": {
+    "schema_version": "1.0",
+    "project": "<name>",
+    "generated_at": "<ISO>",
+    "last_updated": "<ISO>",
+    "file_count": 4,
+    "node_count": 127,
+    "edge_count": 89
+  },
+  "files": {
+    "prd": {
+      "pointer": "_bmad-output/planning-artifacts/prd.md",
+      "title": "Product Requirements Document",
+      "pointer_type": "relative_path"
+    }
+  },
+  "nodes": [
+    {
+      "id": "prd#functional-requirements",
+      "file": "prd",
+      "anchor": "functional-requirements",
+      "title": "Functional Requirements",
+      "type": "prd"
+    }
+  ],
+  "edges": [
+    {
+      "from": "arch#decision-p3-1-bmad-knowledge-graph",
+      "to": "prd#functional-requirements",
+      "type": "implements",
+      "label": "implements knowledge graph data model requirement",
+      "created_by": "Alon",
+      "agent": "claude-code",
+      "created_at": "2026-04-07T10:00:00Z"
+    }
+  ]
+}
+```
+
+### Heading Anchor Algorithm
+
+GitHub slug algorithm (same as VSCode internal link resolution):
+```javascript
+heading.toLowerCase().replace(/[^\w\s-]/g, '').replace(/\s+/g, '-').replace(/-+/g, '-').trim()
+```
+Example: `"Decision P3-1: BMAD Knowledge Graph"` → `"decision-p3-1-bmad-knowledge-graph"`
+
+### emitToGraph() Pseudocode (Architecture-Authoritative)
+
+```javascript
+async function emitToGraph(projectRoot, emission) {
+  const graphPath = path.join(projectRoot, '_bmad-output', 'knowledge-graph.json');
+  const graph = fs.existsSync(graphPath)
+    ? JSON.parse(fs.readFileSync(graphPath, 'utf8'))
+    : { meta: initMeta(projectRoot), files: {}, nodes: [], edges: [] };
+
+  // Register files (first-write-wins for pointer_type; pointer/title always update)
+  for (const [fileId, fileEntry] of Object.entries(emission.files || {})) {
+    if (!graph.files[fileId]) graph.files[fileId] = fileEntry;
+    else { graph.files[fileId].pointer = fileEntry.pointer; graph.files[fileId].title = fileEntry.title; }
+  }
+  // Add nodes (no duplicates by id; title update allowed)
+  for (const node of (emission.nodes || [])) {
+    const existing = graph.nodes.find(n => n.id === node.id);
+    if (!existing) graph.nodes.push(node);
+    else existing.title = node.title;
+  }
+  // Add edges (no duplicates by from+to+type; created_at/agent update allowed)
+  for (const edge of (emission.edges || [])) {
+    const existing = graph.edges.find(e => e.from === edge.from && e.to === edge.to && e.type === edge.type);
+    if (!existing) graph.edges.push(edge);
+    else { existing.created_at = edge.created_at; existing.agent = edge.agent; }
+  }
+  // Update counts
+  graph.meta.file_count = Object.keys(graph.files).length;
+  graph.meta.node_count = graph.nodes.length;
+  graph.meta.edge_count = graph.edges.length;
+  graph.meta.last_updated = new Date().toISOString();
+
+  fs.writeFileSync(graphPath, JSON.stringify(graph, null, 2), 'utf8');
+}
+```
+
+### I/O Choice: Synchronous
+
+Use synchronous `fs` APIs (`readFileSync`, `writeFileSync`, `existsSync`). Graph updates occur as a post-artifact step — not in any hot path. Synchronous I/O is simpler and avoids async coordination between concurrent skill calls (not a concern since skills run sequentially under a single agent session).
+
+### Edge Type Vocabulary
+
+| Type | Usage |
+|------|-------|
+| `implements` | arch decision → PRD requirement |
+| `derives-from` | epic → PRD requirement |
+| `traces-to` | story → epic |
+| `informed-by` | any cross-document influence (non-hierarchical) |
+| `validates` | review/validation report → artifact |
+| `refines` | dev-story implementation notes → story spec |
+
+### LLM-Writability Contract (NFR39)
+
+The flat structure is deliberately copy-pattern-friendly. A model with no prior schema knowledge can correctly extend the graph by observing the first entry in `files`, `nodes`, and `edges` and copying the pattern. Do NOT add nesting beyond 2 levels. Do NOT introduce computed or derived fields inside the JSON.
+
+### File Structure Reference
+
+```
+lib/
+└── knowledge-graph/
+    └── emit.js    ← NEW: emitToGraph() + headingToAnchor() exports
+```
+
+### Dependencies
+
+No new npm packages required. Uses only Node.js built-ins: `fs`, `path`.
+
+### Project Structure Notes
+
+- `lib/knowledge-graph/` is a new directory under `lib/` alongside `lib/bmad-extension/`, `lib/installer.js`, etc.
+- This module is NOT registered in `module-help.csv` — it is a utility, not a skill.
+- No `skill.json`, no `SKILL.md` — plain Node.js module.
+
+### References
+
+- Architecture Decision P3-1: `_bmad-output/planning-artifacts/architecture.md#decision-p3-1-bmad-knowledge-graph`
+- FRs: FR141–FR148 — node/edge/file/meta schema definitions
+- NFR39 (LLM-writability), NFR40 (additive-only)
+- Downstream stories that wire in emission: 19.2, 19.3, 19.4 (require this module to exist first)
+
+## Dev Agent Record
+
+### Agent Model Used
+
+_to be filled by dev agent_
+
+### Debug Log References
+
+### Completion Notes List
+
+### File List

package/_bmad-output/implementation-artifacts/19-2-graph-emission-create-prd.md

@@ -0,0 +1,171 @@
+# Story 19.2: Graph Emission — `create-prd` (Graph Seed)
+
+Status: ready-for-dev
+
+## Story
+
+As a **Product Manager**,
+I want the `create-prd` skill to automatically seed the knowledge graph when a PRD is generated,
+so that the PRD becomes the root of the project knowledge graph without any user action.
+
+## Acceptance Criteria
+
+1. **Given** the `create-prd` skill completes generation of `_bmad-output/planning-artifacts/prd.md`
+   **When** the artifact write step finishes
+   **Then** `emitToGraph()` is called silently as the final step — no user prompt, no output message
+   **And** the PRD file is registered in the `files` table as `{ pointer: "_bmad-output/planning-artifacts/prd.md", title: "Product Requirements Document", pointer_type: "relative_path" }` with file-id `prd`
+
+2. **Given** the PRD contains top-level `##` headings (e.g., `## Executive Summary`, `## Functional Requirements`)
+   **When** emission runs
+   **Then** one node is emitted per `##` heading: `{ id: "prd#<anchor>", file: "prd", anchor: "<anchor>", title: "<heading text>", type: "prd" }`
+
+3. **Given** the graph is seeded from a new PRD
+   **When** the `knowledge-graph.json` file is inspected
+   **Then** it contains no edges (PRD is the root — it does not reference other documents yet)
+   **And** `meta.node_count` equals the number of `##` headings in the PRD
+
+4. **Given** `create-prd` runs on a project where `knowledge-graph.json` already exists
+   **When** emission runs
+   **Then** only new headings (not yet present as nodes) are added — re-runs are idempotent
+
+## Tasks / Subtasks
+
+### Task 1: Add emission call to `create-prd` workflow (AC: 1, 2, 3, 4)
+
+**IMPORTANT:** The `create-prd` skill exists in TWO locations — IDE skill and BMAD extension skill (see Dev Notes). Both must be updated.
+
+- [ ] 1.1 Locate the IDE skill source: `skills/bmad-create-prd/SKILL.md`
+- [ ] 1.2 Locate the BMAD extension skill source: `lib/bmad-extension/skills/bmad-create-prd/SKILL.md`
+- [ ] 1.3 In both SKILL.md files, add a final step after the artifact write:
+  - **Step: Silent graph emission** (no user output)
+  - Scan the generated PRD markdown for `## ` lines (level-2 headings only)
+  - For each heading, derive anchor using `headingToAnchor()` from `lib/knowledge-graph/emit.js`
+  - Build emission payload:
+    ```javascript
+    const emission = {
+      files: {
+        prd: {
+          pointer: "_bmad-output/planning-artifacts/prd.md",
+          title: "Product Requirements Document",
+          pointer_type: "relative_path"
+        }
+      },
+      nodes: headings.map(h => ({
+        id: `prd#${headingToAnchor(h)}`,
+        file: "prd",
+        anchor: headingToAnchor(h),
+        title: h,
+        type: "prd"
+      })),
+      edges: []  // PRD seeding emits no edges — it is the root
+    };
+    ```
+  - Call `emitToGraph(projectRoot, emission)` silently (no output to user)
+- [ ] 1.4 Determine `projectRoot` in each skill context:
+  - For BMAD extension skill: derive from `_bmad/bmm/config.yaml` path or `process.cwd()`
+  - For IDE skill: use `process.cwd()` (the project root where the skill is invoked)
+
+### Task 2: Verify idempotency (AC: 4)
+
+- [ ] 2.1 After implementing, manually verify that invoking `create-prd` twice on the same project results in the same node count (no duplicates)
+- [ ] 2.2 Confirm `meta.node_count` equals the actual number of nodes in the `nodes` array
+
+### Task 3: Verify emission is truly silent (AC: 1)
+
+- [ ] 3.1 Confirm no `console.log`, no output to user, no prompt is added for the emission step
+- [ ] 3.2 Confirm error from `emitToGraph()` (e.g., write permission failure) does not propagate to the user as a skill failure — log to stderr at most, do not abort the skill
+
+## Dev Notes
+
+### CRITICAL: Two Deployment Pipelines
+
+The `create-prd` skill (like all BMAD skills in this project) exists in two locations:
+1. **IDE skill source:** `skills/bmad-create-prd/SKILL.md` — deployed by `lib/installer.js` to all IDE agent directories
+2. **BMAD extension skill source:** `lib/bmad-extension/skills/bmad-create-prd/SKILL.md` — deployed by `lib/bmad.js` to `_bmad/extensions/ma-agents-skills/`
+
+**Both files must be updated.** Do NOT edit installed copies at `.claude/skills/bmad-create-prd/` or `_bmad/extensions/ma-agents-skills/skills/bmad-create-prd/`.
+
+### Prerequisite: Story 19.1 Must Be Complete
+
+This story requires `lib/knowledge-graph/emit.js` to exist (created in Story 19.1). Do NOT begin implementation until Story 19.1 is done.
+
+### Heading Extraction — Level-2 Only
+
+Extract only `## ` (two hashes + space) headings from the PRD. Level-3+ headings (`###`, `####`) create noise without adding navigation value. The regex pattern:
+```javascript
+const headings = content.match(/^## (.+)$/gm)?.map(line => line.replace(/^## /, '')) || [];
+```
+
+### PRD is the Only Emission With Zero Edges
+
+This is the only skill in the 7-skill emission chain that emits zero edges. All other skills emit edges pointing back to PRD nodes. The knowledge graph is a directed graph rooted at the PRD.
+
+### Emission Payload Shape
+
+```javascript
+{
+  files: {
+    "prd": { pointer: "_bmad-output/planning-artifacts/prd.md", title: "Product Requirements Document", pointer_type: "relative_path" }
+  },
+  nodes: [
+    { id: "prd#executive-summary", file: "prd", anchor: "executive-summary", title: "Executive Summary", type: "prd" },
+    { id: "prd#functional-requirements", file: "prd", anchor: "functional-requirements", title: "Functional Requirements", type: "prd" }
+    // ... one per ## heading
+  ],
+  edges: []
+}
+```
+
+### Silent Emission Contract
+
+The emission step MUST be silent:
+- No output to user (no `console.log`, no markdown output in SKILL.md steps)
+- Emission failures (e.g., disk write error) must NOT abort the skill — the PRD is already written; a graph update failure is non-critical
+- Wrap the `emitToGraph()` call in try/catch; log to stderr on failure, do not re-throw
+
+### Idempotency
+
+The `emitToGraph()` function from Story 19.1 already handles idempotency (no duplicate nodes by id). However, the skill must also ensure it does not re-extract headings if the PRD content is the same. Since `emitToGraph` is idempotent, calling it twice with the same payload is always safe.
+
+### File Structure Reference
+
+```
+skills/
+└── bmad-create-prd/
+    └── SKILL.md    ← MODIFY: add emission step at end
+
+lib/
+└── bmad-extension/
+    └── skills/
+        └── bmad-create-prd/
+            └── SKILL.md    ← MODIFY: add emission step at end
+
+lib/
+└── knowledge-graph/
+    └── emit.js    ← IMPORT from here (Story 19.1 output)
+```
+
+### Project Structure Notes
+
+- No new files are created by this story — only modifications to existing SKILL.md files.
+- The `lib/knowledge-graph/emit.js` module (Story 19.1) must be importable from both SKILL.md contexts.
+- For BMAD extension skills (SKILL.md workflow files): the emission call is expressed as a workflow instruction in markdown, not literal JavaScript. The dev agent executes the instruction. The `lib/knowledge-graph/emit.js` code is what actually runs when a JavaScript execution context is available. In pure markdown SKILL.md context (no JS runtime), document the emission payload and call as a clear instruction.
+
+### References
+
+- Story 19.1: `_bmad-output/implementation-artifacts/19-1-knowledge-graph-core-library.md` — `emitToGraph()` implementation
+- Architecture Decision P3-1: `_bmad-output/planning-artifacts/architecture.md#decision-p3-1-bmad-knowledge-graph`
+- Epics source: `_bmad-output/planning-artifacts/epics.md#story-192-graph-emission--create-prd-graph-seed`
+- FRs: FR149 (automatic emission), FR150 (file registration), FR152 (additive-only, no duplicates)
+
+## Dev Agent Record
+
+### Agent Model Used
+
+_to be filled by dev agent_
+
+### Debug Log References
+
+### Completion Notes List
+
+### File List