Skip to content

Feature Pages

Jump to bottom
amirbena edited this page Sep 17, 2026 · 3 revisions

Feature Pages

One lightweight Wiki page per mature, user-visible capability of either Skill — what it does, why it exists, when it applies, and where its canonical source lives. This index lists every feature page that exists today and the reusable template they all follow.

Canonical/Wiki boundary

A feature page never duplicates shared/policies/* or a Skill's own policies/* semantics; it summarizes and links. Contracts, exact behavior, schemas, and options stay in the repository — a feature page is discovery and orientation only. This is the same rule Repository-Documentation-Map states for the Wiki as a whole, applied specifically to this pattern: if a feature page and its canonical source ever appear to disagree, the canonical source is correct and the page has a bug.

The feature pages

Feature page Feature (docs/features/) Skill(s) Default / conditional / requested Canonical semantics
Feature-Runtime-Validation-Evidence runtime-validation.md both conditional — needs a declared command or an eligible suspected finding and a verified isolation boundary, or an explicit out-of-band trusted-host authorization when isolation is unavailable runtime-validation.md · trusted-host-execution.md
Feature-Requirement-Coverage requirement-coverage.md both conditional — activates only when authoritative requirements or acceptance criteria are supplied requirement-coverage.md
Feature-Delta-Re-Review delta-re-review.md github-pr-review (local review reconciles a PR reference instead) conditional — same reviewer + a reliable prior reviewed SHA reviewer-delta-review.md
Feature-GitHub-Publication-and-Authorization github-review-publication.md github-pr-review default is non-mutating PASSIVE; an explicit ACTIVE request is itself sufficient authorization to publish, subject to reviewer independence + GitHub permission review-action-authorization.md
Feature-Human-Style-Review-Output human-review-output.md both explicitly requested in natural language; presentation only invocation-options.md

This is the first batch, chosen for maturity, existing canonical documentation, cross-Skill representativeness, and no prior dedicated Wiki page. It intentionally excludes parallel-review.md, fix-prompt.md, severity-description.md, and reviewer-brief.md for now — see the full capability catalog at docs/features/README.md for every optional/advanced capability, documented or not yet documented here.

Feature lifecycle rule

A feature gets a new or updated Wiki page when it becomes a meaningful user-visible capability with stable behavior — not on every PR that merely touches it. This is a consideration alongside the documentation-impact check in policies/documentation-policy.md, "Documentation impact for capability changes" — never a mandatory checklist item or a merge blocker, and irrelevant for internal refactors or implementation-only changes with no user-visible effect.

The reusable template

Every feature page follows the same eight sections (headings may be adjusted slightly to fit a feature's own shape, but the sequence and intent stay fixed):

  1. What it does — one-paragraph capability summary.
  2. Why it exists — the problem or use case it addresses.
  3. When it applies — trigger, Skill(s), default / conditional / requested.
  4. How it works — the high-level flow only, not the full policy.
  5. Important options / modes — user-relevant knobs only.
  6. Example — one realistic, short invocation.
  7. Related features — links to adjacent feature pages.
  8. Canonical references — links to the owning shared/policies/* / Skill policies/* file(s) and the matching docs/features/*.md usage guide.

This template is documented once, here — an individual feature page does not restate it.

See also

Wiki Page Map

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.

Clone this wiki locally