feature-arch-gate

v2026.09.24

Adversarial pass/fail review gate that enforces the feature-arch skill's React feature-based architecture rules. Use when a diff, branch, PR, or src/ tree must be judged for architecture conformance before merge — feature folder structure, import boundaries, cross-feature isolation, data-fetching, state, testing, and naming rules. A single blind reviewer renders per-rule PASS/FAIL verdicts with cited evidence, and the reviewer's structured output is the verdict fail-closed. Use the feature-arch skill itself to design or migrate an architecture; use this gate to judge whether work conforms to it.

GitHub
Install command
npx skhub add pproenca/feature-arch-gate
Markdown
SKILL.md

Feature-Arch Gate

Enforce React feature-based architecture conformance — a pass/fail gate: a single blind reviewer subagent judges the work against the rules of feature-arch v1.1.0 with an adversarial mandate, and the work passes only when every rule is PASS or N/A. This skill renders verdicts; it never fixes the work.

The gate is self-sufficient: the 33 decidable rules it enforces (of the source's 43) are vendored into this skill's references/ directory as a snapshot of feature-arch v1.1.0, so a review needs nothing outside this folder. references/_rule-evidence.md records the provenance, the evidence that decides each rule, and the 10 source rules excluded as non-decidable.

When to Apply

  • A PR or branch touching a feature-organized React codebase needs an architecture conformance verdict before merge.
  • A migration step from a FEATURE-ARCH-TARGET.md blueprint is claimed complete and needs independent verification.
  • A full src/ tree audit is requested ("does this codebase conform to feature-arch?").
  • Agent-generated feature work needs a gate that is blind to the conversation that produced it.

Do NOT apply this gate to design or migrate an architecture — that is the feature-arch skill's job (it produces the blueprint; this skill judges conformance to the rules).

Review Protocol

Follow these steps exactly — the gate's value is that every review runs the same way.

  1. Identify the target. Pin down exactly what is under review (a diff, a set of files, or a full src/ tree) and note the ref/paths so the review runs against an unambiguous, fixed target. Record two context facts the reviewer needs: does the codebase use React Server Components, and is a query library (TanStack Query etc.) present — two rules are N/A without them.
  2. Load the rules. Read references/_rule-evidence.md and resolve the 33 vendored rule files it lists against this skill's own references/ directory. If any listed rule file is missing or unreadable, STOP and report the error — never proceed with partial rules or silently pass.
  3. Compose the reviewer prompt. Fill references/reviewer-prompt.md with the rule file paths, the target, and (if the target repo has one) its docs/architecture/FEATURE-ARCH-TARGET.md blueprint. The composed prompt must be fully self-contained — a reviewer sees no conversation history, so nothing may refer to context outside the prompt.
  4. Dispatch one blind reviewer. Launch a single Task subagent whose entire input is the composed prompt — no conversation context, no commentary alongside it.
  5. Render fail-closed. The reviewer's structured output is the verdict — there is no merge step. Overall verdict is PASS only when every rule is PASS or N/A; any single FAIL fails the gate. Never average, weigh severity, or waive a rule — a "minor" FAIL is a FAIL.
  6. Render the verdict. Fill assets/templates/verdict.md. On FAIL, aggregate the reviewer's "missing for PASS" suggestions into the fix list, each with its location, ordered by the source skill's category priority (struct → import → bound → fquery → fcomp → fstate → test → name). Every rule whose final result is FAIL must appear in the fix list with a change concrete enough to apply as written — if the reviewer's suggestion only restates the violation, derive the fix from the rule's Correct example before rendering.

If the same rule flips verdicts across re-reviews of an unchanged target, or a human reads the evidence and overrides the verdict, that is a decidability bug in the rule — record it in gotchas.md and sharpen the rule; do not override the gate.

Verdict Format

The reviewer returns, per rule: PASS | FAIL | N/A, evidence (file:line or a quote — required for PASS as well as FAIL), and for every FAIL, the fix that flips the rule to PASS once applied — the named change plus its location, never a restatement of the violation. The final report follows assets/templates/verdict.md.

Rule Categories

The eight categories and their priority order are defined in references/_sections.md; the 33 vendored rule files live alongside it in references/, and references/_rule-evidence.md lists them with the evidence that decides each, plus the 10 excluded source rules (with reasons).

Reference Files

FileDescription
references/reviewer-prompt.mdSelf-contained prompt template for the blind reviewer
assets/templates/verdict.mdVerdict report template
references/_rule-evidence.mdVendoring provenance + per-rule deciding evidence + exclusions
references/_sections.mdCategory definitions and fix-list priority order
references/<category>-*.mdThe 33 vendored rule files (struct/import/bound/fquery/fcomp/fstate/test/name)
metadata.jsonVersion and source references

Related Skills

  • feature-arch — the source distillation skill this gate's rules were vendored from; use it (if available) to design or migrate the target architecture, and to read the 10 judgment-call rules the gate excludes. The gate itself never needs it at review time.
Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.24

Published

Sep 24, 2026

Category

Uncategorized

License

MIT

Source path

skills/.experimental/feature-arch-gate

Default branch

master

Latest commit

cf93c57

Tree SHA

afbb575