-
Notifications
You must be signed in to change notification settings - Fork 2
Feature Requirement Coverage
A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.
When you supply requirements or acceptance criteria, both Skills add a
requirement-by-requirement coverage section: each obligation is reported
as implemented, partially_evidenced, not_evidenced, or
not_applicable, with concrete code/test evidence, plus an overall
complete / incomplete signal relative to that task.
A review can be defect-free and still leave part of the task undone. This capability makes task-relative completeness visible and evidenced, separately from code-quality findings — so "no bugs found" is never confused with "the task is finished."
Conditional — activates automatically only when the resolved Review Context includes authoritative requirements or acceptance criteria. With no such contract, it is completely inert: no empty section, prompt, signal, or false finding appears. Applies to both Skills identically.
Each coverage row cites the originating clause plus the concrete implementation or test evidence used for its status. This is separate from review severity: missing coverage becomes a P0/P1/P2 finding only when it independently meets the normal evidence, scope, and severity rules — the mechanical review decision still depends only on P0/P1 findings, never on coverage status by itself.
No flag — supply the contract as review context (free text, or a
resolved Jira/GitHub Issue reference; see Review-Context-and-Existing-Evidence).
Only authoritative requirement / acceptance_criteria context
activates it; discussion or historical notes never do. not_applicable
distinguishes an explicitly excluded obligation from one whose
applicability can't be resolved from an ambiguous contract — the latter
carries an explicit ambiguity marker and keeps aggregate coverage
incomplete.
review my local changes against these acceptance criteria:
- validate every write before persistence
- reject writes while the record is locked
review PR #812 against GitHub Issue #799
- Feature-Runtime-Validation-Evidence — a separate, also-conditional evidence dimension (runtime behavior rather than task completeness).
- Review-Context-and-Existing-Evidence — the broader context-resolution mechanism that requirement coverage builds on.
- Usage guide:
docs/features/requirement-coverage.md - Canonical semantics:
shared/policies/requirement-coverage.md - Skill guides: Local-Code-Review-Guide · GitHub-PR-Review-Guide
| Page | What it covers |
|---|---|
| Home | Wiki entry point: what the two Skills are and where to go next. |
| Getting-Started | First steps to package and run either Skill. |
| Choosing-a-Review-Skill | How to decide between local-code-review and github-pr-review. |
| How-the-Review-Model-Works | Concept-level walkthrough of the review pipeline shared by both Skills. |
| Architecture-Overview | Component-level map of how the repository's pieces fit together. |
| Specialist-Depth-Review | When and how a review goes deeper than its base pass. |
| Local-Code-Review-Guide | Usage guide for reviewing local, not-yet-PR'd Git changes. |
| GitHub-PR-Review-Guide | Usage guide for reviewing an existing GitHub Pull Request. |
| Review-Context-and-Existing-Evidence | How optional requirements/context and prior review evidence are supplied. |
| Feature-Pages | Index of per-feature capability pages and their shared template. |
| Feature-Delta-Re-Review | How a re-review scopes itself to only what changed since the last pass. |
| Feature-GitHub-Publication-and-Authorization | What a PR review publishes to GitHub and under what authority. |
| Feature-Human-Style-Review-Output | The senior-engineer-voice prose summary output option. |
| Feature-Requirement-Coverage | How supplied requirements are checked and reported as covered or not. |
| Feature-Runtime-Validation-Evidence | How a review can execute commands or reproductions as evidence. |
| Severity-and-Decision-Model | The P0/P1/P2 severity levels and how the merge decision is derived. |
| Packaging-and-Portability | How the Skills go from source repository to a standalone archive. |
| Development-Workflow | Contributor guide for working on this repository itself. |
| Benchmark-Testing | Orientation to this repository's own review-quality benchmark pipeline. |
| Repository-Documentation-Map | Where each concern's canonical, authoritative source lives. |
| AI-Code-Review-Landscape | Neutral snapshot comparing this project against other AI code-review products. |
| FAQ | Short, practical answers to common questions. |