gate-check

Run the project gate checks and report results. Use after completing any feature, before creating a PR, or to verify project health.

Ir para a instalação

Repositório: nesquikm/dev-process-toolkit
Última atividade na origem: 27 de agosto de 2026 às 03:48
Idioma detectado do SKILL.md: inglês
Estrelas: 7
Forks: 0

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

npx skills add https://github.com/nesquikm/dev-process-toolkit --skill gate-check

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

deliver

Full delivery pipeline orchestrator — takes a feature request from idea through specs to shipped, merged milestones by chaining the toolkit's phase skills end-to-end.

2026-08-27

implement

Implement a feature or fix end-to-end. Analyzes the request, builds in TDD order, runs gate checks, self-reviews with bounded loops, and reports for human approval before committing.

2026-08-27

spec-archive

Manually archive user-selected FRs or milestones by `git mv` into `specs/frs/archive/` (and optionally `specs/plan/archive/`) with a diff approval gate. Accepts ULID, tracker ID/URL, or `M<N>`. Escape hatch for /implement Phase 4 auto-archival gaps.

2026-08-26

Ver todas deste repositório

SKILL.md

Instruções da origem · Visualização somente leitura

name	gate-check
description	Run the project gate checks and report results. Use after completing any feature, before creating a PR, or to verify project health.
argument-hint	[--fix to auto-fix lint issues]

Gate Check

Run the project's gating checks and report a clear pass/fail for each.

Layout + Tracker Mode Probes

Tracker Mode Probe — Before running any commands, run the Schema L probe (see docs/patterns.md § Tracker Mode Probe). If CLAUDE.md has no ## Task Tracking section, mode is none and tracker-mode hooks skip. If a tracker mode is active:
- Run the 2-tier ticket-binding resolver and mandatory confirmation prompt per docs/ticket-binding.md. Decline exits cleanly with zero side effects. Re-fetch the ticket's updatedAt and warn on mismatch against the value recorded at /implement start; do NOT run bidirectional AC sync resolution here.
- On gate pass, push the AC toggle via the active adapter's push_ac_toggle (capability permitting; missing capability degrades with a canonical-shape warning otherwise). See docs/gate-check-tracker-mode.md for the full tracker-mode flow.
Skip baseline capture — On a clean tree standing on trunk (main), run the capture below: a clean trunk checkout under /gate-check is the only path that records a skip baseline with no operator step, and the capture measures the count by running the suite itself. Off trunk, or with a dirty tree, it declines and writes nothing — report the reason it names, verbatim; a skip that reports nothing is the defect this closes.
```
bun run "${CLAUDE_PLUGIN_ROOT}/adapters/_shared/src/capture_skip_baseline.ts" "<projectRoot>"
```

Conformance Probes (NFR-15)

Run these deterministic layout-invariant probes in addition to the normal gate:

Filename ↔ frontmatter convention (strict) — for every specs/frs/**/*.md, resolve Provider once (same rule as /implement), parse the YAML frontmatter, and compute the expected base name via Provider.filenameFor(spec). Every base name must equal Provider.filenameFor(spec); any mismatch → GATE FAILED naming the file, the actual basename, and the expected name.
Required frontmatter fields — every FR file must have the mode-invariant Schema Q keys title, milestone, status, archived_at, created_at present. The id and tracker keys are mode-conditional (required in mode: none and tracker mode respectively, absent in the other), enforced by probe #13 identity_mode_conditional. Missing a field → GATE FAILED naming the file and field.
Stale lock scan — list every .dpt/locks/<ulid> entry whose branch field names a merged-into-main or deleted branch. Each stale lock → GATE PASSED WITH NOTES. Offer $ARGUMENTS --cleanup-stale-locks action that deletes them in a single commit.
Plan post-freeze edit scan — for each specs/plan/<M#>.md with status: active + non-null frozen_at, scan git log --follow for commits to that path authored after frozen_at. Each post-freeze commit → GATE PASSED WITH NOTES listing the SHA. No auto-revert — user decides.
Stale release marker scan — grep specs/requirements.md for markers of the form (in flight — v<X.Y.Z>) or (planned — v<X.Y.Z>). For each captured version, check whether CHANGELOG.md already contains a ## [X.Y.Z] header (i.e., that version has shipped). Every match where the CHANGELOG says shipped → GATE PASSED WITH NOTES listing the stale marker + its line number + the shipped release so the operator can rewrite the overview to past-tense. Warn-only, never GATE FAILED — prose drift shouldn't block the gate.

Este SKILL.md e muito grande, entao o SkillsMP mostra aqui apenas a primeira secao. Ver no GitHub

name	gate-check
description	Run the project gate checks and report results. Use after completing any feature, before creating a PR, or to verify project health.
argument-hint	[--fix to auto-fix lint issues]

Gate Check

Run the project's gating checks and report a clear pass/fail for each.

Layout + Tracker Mode Probes

Tracker Mode Probe — Before running any commands, run the Schema L probe (see docs/patterns.md § Tracker Mode Probe). If CLAUDE.md has no ## Task Tracking section, mode is none and tracker-mode hooks skip. If a tracker mode is active:
- Run the 2-tier ticket-binding resolver and mandatory confirmation prompt per docs/ticket-binding.md. Decline exits cleanly with zero side effects. Re-fetch the ticket's updatedAt and warn on mismatch against the value recorded at /implement start; do NOT run bidirectional AC sync resolution here.
- On gate pass, push the AC toggle via the active adapter's push_ac_toggle (capability permitting; missing capability degrades with a canonical-shape warning otherwise). See docs/gate-check-tracker-mode.md for the full tracker-mode flow.
Skip baseline capture — On a clean tree standing on trunk (main), run the capture below: a clean trunk checkout under /gate-check is the only path that records a skip baseline with no operator step, and the capture measures the count by running the suite itself. Off trunk, or with a dirty tree, it declines and writes nothing — report the reason it names, verbatim; a skip that reports nothing is the defect this closes.
```
bun run "${CLAUDE_PLUGIN_ROOT}/adapters/_shared/src/capture_skip_baseline.ts" "<projectRoot>"
```

Conformance Probes (NFR-15)

Run these deterministic layout-invariant probes in addition to the normal gate:

Filename ↔ frontmatter convention (strict) — for every specs/frs/**/*.md, resolve Provider once (same rule as /implement), parse the YAML frontmatter, and compute the expected base name via Provider.filenameFor(spec). Every base name must equal Provider.filenameFor(spec); any mismatch → GATE FAILED naming the file, the actual basename, and the expected name.
Required frontmatter fields — every FR file must have the mode-invariant Schema Q keys title, milestone, status, archived_at, created_at present. The id and tracker keys are mode-conditional (required in mode: none and tracker mode respectively, absent in the other), enforced by probe #13 identity_mode_conditional. Missing a field → GATE FAILED naming the file and field.
Stale lock scan — list every .dpt/locks/<ulid> entry whose branch field names a merged-into-main or deleted branch. Each stale lock → GATE PASSED WITH NOTES. Offer $ARGUMENTS --cleanup-stale-locks action that deletes them in a single commit.
Plan post-freeze edit scan — for each specs/plan/<M#>.md with status: active + non-null frozen_at, scan git log --follow for commits to that path authored after frozen_at. Each post-freeze commit → GATE PASSED WITH NOTES listing the SHA. No auto-revert — user decides.
Stale release marker scan — grep specs/requirements.md for markers of the form (in flight — v<X.Y.Z>) or (planned — v<X.Y.Z>). For each captured version, check whether CHANGELOG.md already contains a ## [X.Y.Z] header (i.e., that version has shipped). Every match where the CHANGELOG says shipped → GATE PASSED WITH NOTES listing the stale marker + its line number + the shipped release so the operator can rewrite the overview to past-tense. Warn-only, never GATE FAILED — prose drift shouldn't block the gate.

Este SKILL.md e muito grande, entao o SkillsMP mostra aqui apenas a primeira secao. Ver no GitHub

docs/README.md nav contract — docs-mode only (skipped when readDocsConfig(CLAUDE.md) reports both user_facing_mode and packages_mode false). Call runNavContractProbe(projectRoot) from adapters/_shared/src/docs_nav_contract.ts. The probe (a) reads the ## Docs section to decide whether to run, (b) parses docs/README.md, and (c) asserts exactly four ##-level headings carrying the canonical {#tutorials}, {#how-to}, {#reference}, {#explanation} anchors, each with a relative link resolving to an existing file or directory. Missing anchor, extra ##-level heading, or broken subdirectory reference → GATE FAILED, one note per violation in file:line — reason shape, with the NFR-10 remedy:

/gate-check: docs/README.md nav contract violation.
Remedy: docs/README.md must contain exactly four ##-level headings with {#tutorials}, {#how-to}, {#reference}, {#explanation} anchors, each linking to an existing file or directory. Run /docs --full to regenerate the canonical tree.
Context: mode=<docs-mode>, skill=gate-check

Ticket-state drift — active side — mirrors probe #8 symmetrically with two carve-outs. For every FR file under specs/frs/*.md (excluding archive/**) whose frontmatter has status: active AND a non-null tracker.<key> binding, resolve Provider once (same rule as /implement / probe #8) and call Provider.getTicketStatus(<tracker-ref>). Then read the FR's milestone plan state via readPlanTaskState(specsDir, milestone) from adapters/_shared/src/plan_task_state.ts and decide via activeTicketDriftPasses(summary, planTaskState, statusMapping, currentUser) from adapters/_shared/src/active_ticket_drift_predicate.ts. The composed predicate passes if (a) the ticket is in the status_mapping.in_progress lane AND assignee == currentUser, OR (b) the single-FR-clean (STE-151) exemption applies — ticket=done, plan=active, plan has at least one [ ] task remaining, OR (c) the fully-checked-single-FR (STE-180) exemption applies — ticket=done, plan=active, plan has zero [ ] tasks AND at least one task total. Both exemptions recognise the canonical mid-canonical-chain state where /implement <FR-id> Phase 4 Close transitioned the ticket to Done but the FR file intentionally stays status: active per the milestone-bulk-archive design (skills/implement/SKILL.md § Invocation forms). Truth table:

FR status	Ticket status	Assignee	Plan tasks	Plan status	Outcome
active	in_progress	currentUser	any	any	pass
active	done	any	unchecked > 0	active	pass (single-FR clean — STE-151 carve-out)
active	done	any	all checked + total > 0	active	pass + advisory (fully-checked — STE-180 carve-out)
active	done	any	total = 0	active	fail (empty/malformed plan, strict fallback)
active	done	any	any	missing	fail (strict fallback)
active	done	any	any	archived	vacuous (probe #27 owns)
active	backlog/etc.	any	any	any	fail (drift)
active	in_progress	!= current	any	any	fail (drift)

Advisory (STE-180 carve-out only). When the fully-checked branch fires, render exactly this advisory line in the gate-check report (severity = note, NOT GATE FAILED): M<N> plan fully checked but not archived — run /spec-archive M<N> or /implement M<N> to close. The probe returns { ok: true, advisory: { kind: "milestone_ready_to_close", milestone: "M<N>" } } and the renderer formats it; carve-out provenance is logged via carve_out: fully_checked_milestone (vs. STE-151's carve_out: partial_milestone). One advisory per affected milestone, deduplicated — if FRs A and B both target M5 and both fire the carve-out, render once mentioning M5.

Every drifted ticket → GATE FAILED reporting a row with the FR's ULID + tracker ID + observed status vs. expected in_progress + observed assignee vs. expected currentUser so the operator can manually transition, reassign, or rerun /implement Phase 1 step 0.c. The failure-row shape is unchanged across the strict and relaxed branches — callers see the same row format. Skipped for mode: none — LocalProvider.getTicketStatus returns the local-no-tracker sentinel and there's nothing to compare. The probe is over observed tracker state, not over call-history: the already-ours claim shape (in_progress + currentUser) passes regardless of whether this session or a prior one called claimLock. Catches the regression where /implement Phase 1 step 0.c is skipped entirely (an early dogfood case had a ticket sitting at Backlog while implementation proceeded) and symmetrically completes the archive-side ticket-state probe. Both carve-outs strictly weaken the predicate — every prior failing case where the drift was real still fails (Phase 1 step 0.c skipped, wrong assignee, missing plan, archived plan vacuous to probe #27).

Tolerance wrapper integration (STE-305). The in_progress-lane membership check is routed through withTolerance(...) from adapters/_shared/src/tracker_tolerance.ts rather than a bare strict-equality match against status_mapping.in_progress. The wrapper maps the observed tracker label to its canonical role via specs/tracker-config.yaml roles:; when the mapped role equals in_progress the lane check passes, and when the mapped role does not match the expected role the probe surfaces genuine drift and GATE FAILED with the row shape above (mismatch in mapped role is preserved as a hard failure — the wrapper relaxes label-shape brittleness, not the semantic predicate). Under non-tty (claude -p) execution the wrapper additionally routes any non-fatal label-shape advisory through the closing-summary capability token tracker_status_advisory_non_tty — the row is rendered as ADVISORY (not GATE FAILED) so harness runs are not blocked by transient label-shape signals while the byte-checkable capability key preserves audit traceability.

tracker-project-milestone-attached — call runTrackerProjectMilestoneAttachedProbe(projectRoot, deps) from adapters/_shared/src/tracker_project_milestone_attached.ts. For each status: active FR with a tracker block, fetch the issue via deps.getIssue(<ticket-id>) and verify the milestone landed on the ticket. The verification surface is adapter-aware, selected by deps.milestoneBinding (a field on the deps object the caller supplies — no adapter key is parsed for it; defaults to object when absent): the object binding (Linear; mcp__linear__get_issue) asserts the issue's projectMilestone.name byte-equals the canonical local heading (parsed from specs/plan/M<N>.md's H1, anchor stripped); the epic binding (Jira's primary path; mcp__atlassian__getJiraIssue) routes through milestoneBindingPresent(issue, heading, "epic") — the parent-Epic check, asserting the ticket's parent sanitizes back to the Epic-keyed milestone token M_<epic-key>, degrading to the label surface for grandfathered numeric M<N> milestones; the label binding (Jira's legacy fallback; same MCP) asserts the issue's labels array contains milestone-<M-token> (the leading milestone token of that same canonical heading — numeric M<N> or Epic-keyed M_<epic-key> per the union grammar) — labels are Jira's create-on-write milestone surface, since the atlassian MCP exposes no milestone object. Vacuous when mode: none, the FR is archived, the FR has no tracker block, or the plan file is missing (probe #27 owns that diagnostic). Missing or mismatched binding (object: name mismatch; epic: no parent Epic sanitizing to the expected token, label fallback also absent; label: the expected milestone-<M-token> absent) → GATE FAILED rendering the offending names/labels byte-by-byte (em-dash drift visible) plus a binding-aware NFR-10 remedy that names only operations that exist. The MISMATCH kind reaches only the object binding (its sole call site sits inside attached !== heading, and attached comes only from projectMilestone.name), so its remedy is scoped there: rename the tracker milestone to the canonical heading via mcp__linear__save_issue, or — when the tracker side is the correct one — edit the specs/plan/M<N>.md heading to match. An earlier wording also offered mcp__atlassian__editJiraIssue "on the label binding", which was false twice: that arm is unreachable, and there is no tracker milestone to rename on the label surface, since labels ARE the milestone surface there. Under the epic binding a name mismatch is not a binding failure at all — the Epic is resolved by its KEY, never its summary — so the missing-binding remedy names the absent Epic key instead. No rename flag has ever existed on /spec-write; the remedy this replaced ordered one that never shipped. The Epic-keyed epic binding is the exception: the Epic is resolved by KEY and its summary is never read, so a name mismatch is not a binding failure there — its remedy names the absent Epic key (the one a candidate Epic's key would sanitize to, e.g. GF-78 → M_GF_78) and the mcp__atlassian__editJiraIssue additional_fields.parent write that binds it, never a rename of anything.

Capability-gap downgrade (STE-194 + STE-214). When the FR's ## Notes section contains a word-bounded match of any of the three milestone-attach capability keys emitted by /spec-write per skills/spec-write/SKILL.md § Step 7 — milestone_attach_skipped_adapter_limit (canonical), milestone_attach_unavailable (deprecated alias per STE-198, honored for one minor-version cycle), or milestone_create_required — AND the ticket has no projectMilestone binding, the missing-binding outcome routes to ADVISORY (severity = note, NOT GATE FAILED) with the canonical prose milestone-attach skipped — capability gap declared in FR Notes (<key-found>). Detection rule: case-sensitive, word-bounded match (\b<key>\b) scoped to the FR's ## Notes body — substring matches (xmilestone_attach_skipped_adapter_limitX) and matches in other sections (## Acceptance Criteria, ## Technical Design) do NOT count. Mismatched bindings still hard-fail; the token only excuses absence, not divergence. Token-present + binding-present is PASS (binding wins; the token is informational). The advisory closes the smoke-driver false-positive surface where Linear-mode runs created tickets in a project with zero milestones by construction. Decision table:

`## Notes` contains any milestone-attach capability key	`projectMilestone` set on tracker	Probe #26 outcome
no	yes	PASS
no	no	GATE FAILED
yes	yes	PASS (binding wins; token informational)
yes	no	ADVISORY (capability-gap downgrade — prose names the specific key found)

Recognized key set: milestone_attach_skipped_adapter_limit (canonical), milestone_attach_unavailable (deprecated alias), milestone_create_required.

Skip-reason rendering (STE-238 AC-STE-238.8). When this probe skips for a vacuous cause (mode: none, FR archived, FR has no tracker: block, plan file missing), the rendered skip-reason MUST route through renderProbeSkipReason(...) from adapters/_shared/src/tracker_probe_skip_reason.ts and MUST NOT contain the literal substring require Linear MCP (the F9 LLM-paraphrase regression caught by /conformance-loop iteration 1, 2026-05-07). The helper produces an accurate cause-named line — mode: none → skipped — \mode: none`…; archived/no-tracker FR → skipped — active FR has no `tracker:` block (); etc. — so the operator sees the structural cause, not a vendor-MCP paraphrase. Vendor-neutral by construction: the helper handles Linear and Jira identically. Unit-tested at adapters/_shared/src/tracker_probe_skip_reason.test.ts`.

Test coverage: tests/gate-check-tracker-project-milestone-attached.test.ts.

cross-cutting-spec-stale-file-refs — call runCrossCuttingSpecStaleFileRefsProbe(projectRoot) from adapters/_shared/src/cross_cutting_spec_stale_file_refs.ts. Severity: warning (NotesOnly, never GATE FAILED). Walks specs/technical-spec.md and specs/testing-spec.md for path-references whose tokens contain / (full paths), in two shapes tagged on each row as kind: directory-tree leaves inside triple-backtick fences (treeLeaf) and prose mentions outside any fence (proseMention). Accept-list (TREE_FENCE_INFO_ACCEPT_LIST) — the scan is restricted to fences whose info string is empty (bare), text, or tree. Fences carrying a language-tagged info string (dart, sh, yaml, typescript, …) are out of scope and are never scanned, because they are code, not directory trees; that exclusion closes three false-positive classes seen on a real consumer project — package-prefixed imports, app-relative asset literals, and shell path arguments. Bare stays the canonical form every directory tree in this repo already uses; text and tree are accepted so authors who tag for their renderer are not punished. A token resolves if it exists under the project root OR under any plugins/<name>/ sub-root carrying a .claude-plugin/plugin.json manifest, because a marketplace repo's specs address plugin-relative paths; <placeholder>-templated expressions resolve nowhere for anyone and are skipped rather than reported. Tokens that don't resolve to an existing path on disk surface as ADVISORY rows in file:line — reason shape. Bare-basename references (no /) are skipped — no parent context. Prose rows carry their own reason and remedy wording, never the directory-tree sentence, because prose is operator judgment surface: it is reported for amendment, never rewritten mechanically. Defense-in-depth read-side check for paths that bypass /implement Phase 4b's cross-cutting-spec propagation step (manual deletes, git rm, downstream toolkit consumers). Vacuous when both spec files are absent. Test coverage: tests/gate-check-cross-cutting-spec-stale-file-refs.test.ts. (STE-215 AC-STE-215.5)

tracker_local_reconciliation_drift — call runTrackerLocalReconciliationDriftProbe(projectRoot, { provider }) from adapters/_shared/src/tracker_local_reconciliation_drift.ts. Severity tiered: info (no drift), warning (any drift — tracker-orphan / unbound local FR / milestone-mismatch), error (hard FR-id collisions — same tracker ID bound by two or more local files OR local FR's tracker: value points at an FR id absent from the tracker's active set). Wraps reconcileTrackerLocal from adapters/_shared/src/reconcile_tracker_local.ts and adds a local-side scan for the duplicate-binding shape the helper cannot see by construction (both files carry a binding, so neither is an orphan). Mode-aware via the helper: LocalProvider (mode: 'none') reconciles to three empty lists and the probe surfaces info/zero-violations on every local-only project. Read-side: never writes, never throws on missing specs/ directories. Closes the 2026-05-13 partial-scan trap shape where a milestone existed on the tracker but had no local plan file. Test coverage: tests/gate-check-tracker-local-reconciliation-drift.test.ts. (STE-284 AC-STE-284.4)

Capability-key roll-up (STE-284 AC-STE-284.5). Probe #49 surfaces three byte-checkable capability keys into the closing summary so the operator sees the reconciliation outcome without scrolling probe output. Owner skill: /spec-write (preamble reconcile is the canonical emission site); /gate-check mirrors the keys here so the conformance probe at #44 (closing_summary_capability_keys) and the future cross-skill audit can find them in either surface. The plain-language rendering tracks /spec-write § 7's static map row of the same name:

tracker_local_reconciled — emitted whenever the preamble auto-import path reconciled ≥ 1 FR or milestone from the tracker into local files. Render: tracker → local reconciliation imported N FR(s) and M milestone(s) — see specs/frs/<id>.md and specs/plan/<M>.md for the imported content.
tracker_local_orphan_local — emitted per offending entity when a local FR file carries no tracker: binding. Render: local FR <id> has no tracker binding — run /spec-write <id> --push-to-tracker to sync, or remove the local file if abandoned.
milestone_local_orphan — emitted per offending entity when a local specs/plan/M<N>.md has no matching tracker milestone (the partial-scan trap inverse). Render: local milestone M<N> has no tracker milestone — auto-create via Provider.attachProjectMilestone(M<N>), or remove if abandoned. Scaffolding exclusion: a plan whose frontmatter declares kind: scaffolding — the bootstrap plan /setup writes — is never reported here, because it has no tracker milestone by design and a freshly bootstrapped project would otherwise gate with a warning it can do nothing about. The carve-out is one-directional: it drops the local side only (a tracker milestone with no local plan still reports), it keys on the reconcile item's structural side field rather than on the render prose, and it reads kind: through the shared frontmatter parser, so CRLF- and BOM-prefixed plans are recognised too.

The three keys MUST appear verbatim in the closing summary; paraphrased prose is insufficient (STE-220 lesson). Vacuous in mode: none.

gate-check

Informações da origem

Opções de instalação

Revise os arquivos de origem

Mais deste repositório

Mais deste repositório

Gate Check

Layout + Tracker Mode Probes

Conformance Probes (NFR-15)

Gate Check

Layout + Tracker Mode Probes

Conformance Probes (NFR-15)