requirements-analyzer · git:20260908.9e6261b · 2026-09-08 · sha256 ee1d06ada5024ecf

requirements-analyzer git:20260908.9e6261bA

Immutable. This exact content is served forever at /api/v1/blob/ee1d06ada5024ecf.

---
name: requirements-analyzer
description: >
  Full quality-and-risk analysis of requirement documents (single- or multi-source),
  producing one gap/conflict register with executable P0/P1 verification.
  Triggers: requirements analyzer, requirement quality, gap register, 需求分析,
  需求分析器, 需求评审, 需求缺口. Not for writing a case library (that is
  testcase-generation), constructing test data (testdata-generation), or reviewing
  code (defect-detection / code-reviewer).
license: Apache-2.0
---

# Requirements Analyzer

Human-facing install and method docs: `README.md`, `HOW_IT_WORKS.md`, `KNOWN_LIMITATIONS.md` (and `.zh-CN.md`). Do not load those at runtime.

## When to Use

- Need a complete quality and risk analysis of requirement documents, not just a scope scan or a gap list.
- Materials may be a single PRD or a multi-source pack (stories, APIs, plans, role reports).
- Need one reviewable, assignable, verifiable gap register that can hand off to strategy or case writing.

## Workflow

1. Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
2. Run the fixed pipeline: intake → short-input gate → structure inventory → input audit → quality/smell/NFR → success metrics → behavior plus UX states → trace and goal-feature alignment → dependency grid → single register → risk algorithm → testability and oracles → blockers and next actions. Do not write risks or a “TOP 3” list first.
3. Direct requirement materials remain sufficient for standalone use. If the user supplies role reports with a declared `source_role`, treat them as optional composition inputs and never require installing a role Skill.
4. Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
5. If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
6. Default to Markdown; switch formats only when the user asks.

## Core Constraints

- Produce exactly one gap and conflict register; do not also write “Gaps and Ambiguities”, “Cross-Source Conflicts”, or “Core Analysis Items”.
- Audit credibility and comparability first; never mark stale or incomparable sources as `aligned`.
- Prioritize by risk / business impact — do not treat everything equally.
- Separate confirmed facts, role-report content, working assumptions, and hypotheses to verify.
- Do not invent endpoints, fields, SLAs, environments, or root causes the user did not provide; unknowns become questions.
- Do not fill business decisions for stakeholders, and do not judge whether the ask is worth building; keep both views and a suggested decider on conflicts. If an omission looks intentional, ask first.
- When using a role report, preserve `source_role` item by item; never flatten into anonymous consensus or present a role view as a PRD fact.
- Every P0/P1 item needs executable verification: preconditions, stimulus, expected result, required evidence, `VerifyMethod`, and `RiskClass`. Every P0 needs `FailureMode`.
- Items with no observable failure condition are `untestable` and must not be executable P0. Do not emit a fake RPN, a 0–100 score, or a six-dimension traffic-light scorecard.

## Progressive Disclosure

- Before producing output, read and follow `prompts/requirements-analyzer.md` (minimum coverage, output structure, quality bar).
- When Excel/CSV/JSON/Word is requested: read `output-formats.md` and honor the format.
- When a ready-made template fits: use matching files under `output-templates/`.
- When the user wants examples or alignment with existing assets: read relevant `examples/`.
- For register fields, troubleshooting, or FAQ: read `references/register-fields.md`, `references/troubleshooting.md`, or `references/FAQ.md`.
- For quality-characteristic judgments: read `references/quality-attributes.md`.
- For vague/optional/loophole wording: read `references/requirement-smells.md`.
- For NFR completeness: read `references/nfr-quality-grid.md`.
- For the structure inventory (present/thin/absent): read `references/structure-inventory.md`.
- For success metrics / KPI: read `references/success-metrics.md`.
- For upstream/downstream owner and ready dates: read `references/dependency-grid.md`.
- For missing states/decisions/time/failure paths/UX states: read `references/behavioral-completeness.md`.
- For P0–P3 ranking: read `references/risk-scoring.md`.
- Do not load the whole `references/` directory.
- For format conversion or helper pre-parse: prefer existing TypeScript scripts in `scripts/` (`npx --yes tsx scripts/run_analysis.ts --input <file>`); do not rewrite them in Python.
- For evaluating/regressing this skill: use `evals/` with skill-up.
- For the shortest path: read `quick-start.md`.

## Pre-delivery Checklist

- [ ] Followed the main prompt's 7-section output structure; section 6 was not omitted
- [ ] Produced one register only; questions were not restated in section 7
- [ ] Covered the minimum checklist, or explained omissions
- [ ] High-risk items have P0–P3 with impact / likelihood / detectability
- [ ] Section 2 includes quality-characteristic hits, smell hits, the eight-cell NFR grid, structure inventory, success-metrics grid, and dependency grid
- [ ] P0/P1 items include preconditions, stimulus, expected, evidence, VerifyMethod, and RiskClass; P0 includes FailureMode
- [ ] Items without an oracle were not written as executable P0
- [ ] Did not invent details the user did not provide
- [ ] Assumptions and gaps are marked
- [ ] Role-report findings retain source roles; no role Skill internal file was linked

## Common Pitfalls

- Concatenating three old analysis outlines and repeating gaps, risks, questions, and next steps.
- Marking `aligned` when sources are stale or not comparable.
- Pretending completeness when scope or context is missing.
- Treating every item as equally important, or using filler (“improve communication”) instead of closable questions.
- Listing checkpoints for P0 items without verification steps.
- Writing a weak AC with no oracle as an executable P0, or using a score or traffic-light scorecard for false precision.
- Labeling a missing KPI as NFR, or treating “out of this iteration” as `missing`.