{"id":20462,"plugin_id":"plugins_6aa375d1f1d48191b6a2a5f95e1b8a64","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:16:15.050Z","digest":"54b111f878e5ed41a1e35f26a4a8f82b05949882725e919ab0a941da4106f867","against":null,"payload":{"description":"Use when an active SDLC run needs feature requirements, typed fact-to-claim reconciliation, user stories, acceptance criteria, business rules, validation, edge cases, assumptions, open questions, or traceability.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":207},{"relative_path":"references/output-example.md","size_in_bytes":3650},{"relative_path":"references/requirements-contract.md","size_in_bytes":3571},{"relative_path":"references/role-contract.md","size_in_bytes":2035}],"name":"sdlc-ba","skill_md_contents":"---\nname: sdlc-ba\ndescription: Use when an active SDLC run needs feature requirements, typed fact-to-claim reconciliation, user stories, acceptance criteria, business rules, validation, edge cases, assumptions, open questions, or traceability.\n---\n\n# SDLC Business Analysis\n\nFor a saved Compact run, follow the [Compact specification path](../sdlc-pm/references/compact-workflow.md): author one semantic specification through `compact-spec`, and let the runtime derive fact claims and acceptance views. The seven-document envelope below applies to Full/legacy evaluator work. Compact still requires approved facts, complete acceptance coverage, and PM review; never silently omit unresolved facts.\n\nKeep business requirements tied to real user outcomes. Runtime 1.0.0 allows several distinct technical capabilities to reference the same `REQ-*`; do not split or renumber requirements merely to satisfy the five backend capability slots. Fact/claim reconciliation and acceptance traceability remain required.\n\nCreate reviewable requirements from the run's typed facts; Product Owner and PM approval remain separate decisions.\n\n1. Read the active run manifest, assigned BA task, immutable request, PM intake artifacts including `facts.yaml`, `.sdlc/project.yaml`, applicable `AGENTS.md`, policies, workflow, and templates. If project documentation is configured in another repository, resolve `resources.documentation` through `.sdlc/local.yaml`; cite it as source material while keeping authoritative BA run artifacts in the coordinator repository.\n2. Read [role contract](references/role-contract.md), [requirements contract](references/requirements-contract.md), and [output example](references/output-example.md).\n3. Render the seven required BA outputs as separate file-shaped sections in this order: the six Markdown templates, then `artifacts/ba/semantic-claims.yaml`. Give every Markdown artifact its own exact metadata block.\n4. Treat `facts.yaml` as the deterministic input truth. Mirror every `approved` or `unresolved` `FACT-*` exactly once as a `CLAIM-*` with the same `source_fact_id`, subject, relation, typed value, and status. Never infer an approved claim from prose, promote an unresolved/proposed fact, cite a missing fact, or create a second claim for one fact.\n5. Link claims through the human-readable package: acceptance criteria use `claim_ids`; business-rule, validation-rule, and edge-case rows use `Claim IDs`; traceability maps each requirement to both acceptance criteria and the same claims. A referenced claim must include that row's `REQ-*` in `requirement_ids`.\n6. Use stable `REQ-*`, `AC-*`, `BR-*`, `VAL-*`, `EDGE-*`, `CLAIM-*`, `ASM-*`, and `Q-*` IDs. Unresolved claims cite their exact Product Owner `Q-*` entries; approved claims have no question IDs.\n7. End with exactly `## Assumptions`, `## Open questions for Product Owner`, `## Required output paths`, and `## Transition request`. List all seven canonical paths and request only `BA-001 running -> awaiting_review` with PM review. Never request or claim `completed`.\n\nStructured claims are authoritative when explanatory prose conflicts with them. Report any prose defect for correction; never alter a claim to match unsupported prose.\n\nNever modify product code, the manifest, facts, policy, schema, workflow, template, or approval state. Never self-approve requirements.\n\n## Red flags — stop and repair\n\n- Fewer or more than seven artifact sections, a preface, or trailing prose\n- Missing, duplicate, invented, promoted, or structurally changed fact claim\n- Rule-bearing entry without a compatible claim and traceability link\n- Unresolved claim without a Product Owner question\n- Combined artifact, renamed template column, unstable ID, or malformed YAML\n- Any transition other than the PM-review `awaiting_review` handoff\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}