Feature Pages

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

Each page below describes one capability and links its canonical sources under "Canonical references". The full catalog of optional capabilities, including those without a dedicated Wiki page (for example parallel review, fix prompts, and severity descriptions), is docs/features/README.md.

Feature page	Skill(s)	When it applies
Feature-Runtime-Validation-Evidence	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; admitted repository test commands run on the host by default, sandbox-only on explicit request
Feature-Requirement-Coverage	both	conditional — activates only when authoritative requirements or acceptance criteria are supplied
Feature-Delta-Re-Review	github-pr-review (local review reconciles a PR reference instead)	conditional — same reviewer + a reliable prior reviewed SHA
Feature-GitHub-Publication-and-Authorization	github-pr-review	default is non-mutating PASSIVE; an explicit ACTIVE request is itself sufficient authorization to publish, subject to reviewer independence + GitHub permission
Feature-GitHub-Merge-Enforcement	github-pr-review	status publication optional; enforcement detection read-only; required-check setup off and only on an explicit user request (a review never authorizes it) plus ACTIVE mode and reviewer independence
Feature-Human-Style-Review-Output	both	explicitly requested in natural language; presentation only
Feature-Multi-Repository-Review-Target	local-code-review	conditional — activates only when the caller explicitly supplies 2 or more local repository roots; fewer than 2 is unchanged behavior
Feature-Human-Reasoning-Checkpoint	both	conditional — evidence-driven and fail-closed; no invocation option; omitted entirely when no anchorable question exists
Feature-Relationship-Aware-Context	both	always on for relationship questions a fired trigger raises; the host-declared relationship-query capability is optional and falls back to repository search when absent or unable to answer
Feature-Rendered-UI-Inspection	both	conditional and automatic — only when a material rendered-UI change could gain evidence from a render; silent otherwise; no invocation option
Feature-Code-Hygiene-Review	both	conditional and automatic — only when the changed delta adds a tracker-reference comment or a possibly unclear variable name; no invocation option; never changes the Decision
Feature-Dependency-Tree-Inspection	both (github-pr-review API-only mode: supplied output only)	conditional and opt-in — only when dependency review is engaged, the change alters what resolves, and you approve execution or supply the output
Feature-Deployment-and-Infrastructure-Review	both (github-pr-review API-only: no execution, changed files only)	conditional and automatic — only when the change alters a deployment behavior; no invocation option
Feature-Engineering-Design-Review	both (github-pr-review API-only: claims about unchanged files are not checked)	conditional and automatic — only when decision-bearing design content is in the change; no invocation option; adds no verdict or approval state, findings follow the usual severity and Decision rules
Feature-Review-Execution-Telemetry	design record only — not packaged	not a review option; observational and never decision-affecting

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

• Home — overall Wiki navigation.
• Repository-Documentation-Map — where every kind of canonical content lives, including the boundary this page states for feature pages specifically.
• Local-Code-Review-Guide · GitHub-PR-Review-Guide — each links back to the feature pages relevant to that Skill.