Skip to content
Back to skills

Pre Execution Review

ASecurity

Internal owner of the pre-execution review cycle and the planning ledgers: independence, unioned findings, counter-evidence dismissal, no-progress, `CONVERGENCE-ANOMALY`, and the evidence/obligation/findings tables. Consumed by `execute-phase`, `review-change`, and the lane's authoring steps for the **planning-ledger shapes and ownership**; the pre-execution verdict owners (`review-spec`/`review-plan`) were retired by feature 61. Not a menu entry.

  • 21 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 2, 2026
ai-agentsrustrailsgit

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned September 25, 2026

npx -y skills add gtrabanco/agentic-workflow --skill pre-execution-review --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Pre Execution Review?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Pre Execution Review
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/gtrabanco-pre-execution-review-agentic-workflow/badge)](https://www.skillsdirectory.com/skills/gtrabanco-pre-execution-review-agentic-workflow)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: pre-execution-review
user-invocable: false
version: 2.6.0
author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
license: MIT
description: >
  Internal owner of the pre-execution review cycle and the planning ledgers:
  independence, unioned findings, counter-evidence dismissal, no-progress,
  `CONVERGENCE-ANOMALY`, and the evidence/obligation/findings tables. Consumed by
  `execute-phase`, `review-change`, and the lane's authoring steps for the
  **planning-ledger shapes and ownership**; the pre-execution verdict owners
  (`review-spec`/`review-plan`) were retired by feature 61. Not a menu entry.
---

# Pre-Execution Review Policy (internal)

One owner for the rules that both pre-execution reviewers apply, so a Product
review and a Plan review cannot drift into two different definitions of
independence, union, or convergence. It states **policy**; it runs nothing,
writes nothing, and emits no verdict of its own.

```text
evidence-grounding  = how an author prepares and self-checks an artifact.
pre-execution-review = how any pre-execution reviewer judges it, and what the
                       frozen ledgers look like.
lane (design/plan/review steps) = the surviving pre-execution path; feature 61
                       P8b retired the standalone review-spec / review-plan
                       verdict skills, so this pack now owns the ledger shapes
                       the lane and execute-phase consume, not a verdict gate.
```

## When to use

- The lane's `plan`/`review` steps — when writing the ledgers and when a review
  comes back failed.
- Nothing else. Candidate-source review (`review-change`), merge gating
  (`audit-pr`) and execution (`execute-phase`) keep their own contracts; this
  skill adds no authority over them.

## Hard rule — no verdicts, no edits

This skill never prints `SPEC-REVIEW-PASS`, `PLAN-REVIEW-PASS`,
`SPEC-REVIEW-FAIL`, `PLAN-REVIEW-FAIL` or `NEEDS-DESIGN` as a result of its own
reading, and it never writes a unit artifact. Quoting a verdict shape here is a
definition, not an issuance. A policy summary that reads like an approval is a
contract violation — the verdict belongs to the reviewer turn that binds the
snapshot.

## The three references

| Condition now | LOAD |
|---|---|
| Running or repairing a pre-execution review | [references/POLICY.md](references/POLICY.md) — independence, union, dismissal, diversity labels, author exclusion, untrusted content, critique/synthesis/arbitration bounds, no quorum, no-progress, batch repair, `CONVERGENCE-ANOMALY`, write-then-report |
| Building or re-checking a snapshot digest | [references/SNAPSHOT.md](references/SNAPSHOT.md) — the one executable recipe (`scripts/pre-execution-snapshot.mjs`), what each stage binds, how a consumer re-verifies a receipt, and why a snapshot digest is not a git blob id |
| Writing or validating a Plan-stage artifact | [references/LEDGERS.md](references/LEDGERS.md) — the planning-evidence table, the obligation ledger, the stage-aware `planning-findings.md`, the durable review mark, and who may write each |

## Guardrails

- **Single owner.** A caller may restate a rule only as a one-line pointer plus
  the stage-specific detail it adds. Two copies of the union rule, the dismissal
  rule, or the convergence fields is the drift this skill exists to prevent.
- **Policy is not a receipt.** Reading this file proves nothing about any
  artifact; only a reviewer turn that binds a snapshot does.
- **No weakening.** The bounds here are ceilings *and* floors: a cycle may be
  shorter than the budget allows, never looser than the policy allows.
- **Vocabulary is closed.** Severity, class, role, verdict and status words are
  exactly those named in the references. Inventing `accepted`, `waived`,
  `mitigated`, or a fourth verdict is a contract break.
- Docs-language and commit conventions per the project's Workflow conventions.

## Done when

- Every pre-execution reviewer and authoring caller points here for the shared
  cycle and ledger rules instead of restating them, and each stage file keeps
  only the detail that is genuinely stage-specific.

Files in this skill

  • SKILL.md3.8 KB
  • references/LEDGERS.md11.4 KB
  • references/POLICY.md10.5 KB
  • references/SNAPSHOT.md6.8 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…