PROOF AT EVERY GATE

GateReeve

A gate-based, artifact-driven workflow for agent-assisted software development.

THE WORKFLOW

What is GateReeve?

GateReeve takes an idea from discovery through design, specification, implementation, review, and closeout while preserving the reasoning and evidence needed to trust the result. Another way to read it is as a set of nested execution, delivery, learning, and stewardship loops that let agents work autonomously while still improving under human governance.

The name borrows from the historical reeve: the local official who enforced standards and kept order on the community's behalf. A gate-reeve keeps the gates — and in this workflow every gate is a decision point with explicit pass conditions that work must clear before it moves on.

GateReeve runs the gates.

You own the judgment.

The premise. The core premise is simple: human judgment belongs at the boundaries. The developer clarifies intent up front, gives the agent enough context and autonomy to execute, then validates the result with tests, rubric checks, pattern review, adversarial judge review, and human review.

Gates and artifacts. The workflow is gate-based and artifact-driven. Each stage leaves durable records: intent, specifications, plans, decisions, verification evidence, review results, and closeout notes. Those artifacts keep the work inspectable and prevent important context from disappearing into chat history.

Learning and stewardship. The outer loops are still under development, but they are central to the direction of the workflow. The learning loop turns mistakes into better guidelines, checks, or tools; the stewardship loop periodically reviews whether those rules, skills, and tools still fit the way the models and workflow are evolving. Pattern review is the beginning of the learning loop, evaluating code against durable coding-standard patterns so recurring problems can be prevented instead of rediscovered.

How to read this page. Read this as both a philosophy and a model. The opening sections explain the operating principles; the diagrams that follow use a compact key to show the gate spine, workflow layers, artifact flow, nested loop view, and supporting skills that make the process repeatable. In practice, the workflow is implemented through user-level agent skills that drive the gates, artifacts, reviews, and closeout steps described below.

The Philosophy: Structure, Autonomy, Proof

The workflow works because human attention is concentrated where judgment changes the outcome. The developer leads the setup, lets the agent move with autonomy inside clear boundaries, then owns the proof that the result is ready for another human to spend time on.

Phase 1 Human-led

Specify clearly

Define the rails before execution

Clarify intent, pressure-test assumptions, write acceptance criteria, and turn the work into observable pass/fail conditions. The agent should start with enough context to solve the right problem.

Phase 2 Human on the loop

Let the agent execute

Observe direction, not every keystroke

The agent inspects, edits, runs tools, tests, and advances the work. The human watches the trajectory and steps in for judgment calls, changed direction, or scope decisions. This is oversight without approving every small move.

Phase 3 Human-led

Validate hard

Prove readiness before handoff

Run focused tests, evaluate the rubric, inspect the diff, review patterns, run an independent LLM-as-judge pass, and close the loop on findings. The output should carry concrete evidence before it reaches a human reviewer.

Workflow Loops

The workflow can also be read as four nested loops operating at different time scales: execution inside the current task, delivery through gated branch workflow, learning from misses, and periodic stewardship of the whole agentic system.

Stewardship loop Maintain the system

Learning loop Learn from misses

Delivery loop Deliver reviewable work

Execution loop Agent executes

Inspect Edit Test Reflect

Design Spec Plan Implement Review

Capture miss Propose rule Human promote Prevent recurrence

Audit skills Run broad scans Retire obsolete rules Update tools

Execution loop

The agent works inside the current task: reading files, changing code, running tools, testing, and correcting course. The human stays on the loop: watching direction, supplying judgment, and steering when scope, risk, or priority changes.

Delivery loop

The branch moves through explicit exit gates: design approval, spec validation, implementation verification, PR boundary, human review, and completion proof.

Learning loop

Pattern Review and learning events turn repeated misses into inspectable proposals that a human can promote into future rules.

Stewardship loop

Periodically inspect the health of the whole agentic system: run rules and skills for continued value, retire obsolete guidance, and update tools as model capabilities improve.

The Workflow Model

After the loop framing, the rest of this page turns the philosophy into an inspectable model. The key below defines the diagram grammar, and the sections that follow show different structural views of the same workflow: the gate sequence, the layered workflow, the artifact flow, and the concrete checks that happen at each boundary. Read them as complementary lenses, not separate processes.

Diagram key

Activity

Work performed

Interviewing, drafting, implementation, review, remediation, and closeout. Activities consume context and produce artifacts or evidence.

Artifact

Durable record

Markdown docs, reports, trackers, learning events, and PR descriptions. Artifacts carry knowledge forward and provide evidence for gates.

Gate

Proceed or loop

A decision point with explicit pass conditions. Gates may be human, deterministic, agentic, or mixed, but they should leave a traceable result.

Gate Spine

The gate spine shows the enforced sequence at a glance: where work can move forward, where it must loop back, and what kind of evidence is required to proceed. Select a gate to see its purpose, inputs, outputs, and pass condition inline.

Design Intent is interrogated and the design is approved. Spec Acceptance criteria and rubric become testable. Branch Readiness Plan, issues, tracker, and decision logs are aligned. Implementation Build, test, amend, and record decisions. PR Boundary Definition-of-done, eval, pattern review, adversarial /judge, review checks, and explain-diff pass. Human Review External reviewer feedback is resolved or waived. Completion All rubric items are proven and the work is closed out.

Workflow Layers

The same sequence is split into activity, output artifacts, and exit gate lanes. This view makes the workflow mechanics explicit: what work happens, what durable records are produced, and where a proceed-or-loop decision is required. Select the boundary review activity or an exit gate to inspect its detail in place.

Activity

Grill Me interview and discovery synthesis

Draft acceptance criteria and binary rubric

Initialize branch docs and issue plan

Implement scoped issues and tests

Run boundary review sequence

Respond to human review

Finalize evidence and closeout

Output Artifacts

interview.md
design.md
codebase context

spec.md
rubric table
architecture contracts

plan.md
issues.md
tracker.md
repo shape

scratchpad.md
tests and code changes

current diff
Pattern Review
judge result
PR Review
explain-diff
learning events

PR comments
updated issues

final tracker
checkpoint

Exit Gates

Design approval Spec validation Branch readiness Local verification loop PR boundary Review acceptance Completion proof

Artifact Flow

Artifact Flow shows how durable context accumulates as the work advances: interview answers become design intent, design intent becomes acceptance criteria, implementation creates decision memory, and the PR boundary converts the full branch context plus current diff into review evidence. The live codebase and current diff are living source context rather than static artifacts, but they remain essential inputs to later decisions.

Design Synthesis

Interview output becomes approved intent.

Uses accumulated context

interview.md existing codebase

Creates

design.md

Spec Drafting

Intent becomes acceptance criteria and a binary rubric.

Uses accumulated context

interview.md design.md existing codebase architecture contracts

Creates

spec.md

Planning

Requirements become an executable route and task ledger.

Uses accumulated context

interview.md design.md spec.md repo structure tests and commands

Creates

plan.md issues.md tracker.md

Implementation Memory

Work adds decisions, evidence, and changed code.

Uses accumulated context

design.md spec.md plan.md issues.md live codebase

Creates

scratchpad.md decisions.md

PR Boundary

The full branch context plus diff becomes review evidence.

Uses accumulated context

interview.md design.md spec.md plan.md issues.md tracker.md decisions.md current diff verification output

Creates

Pattern Review judge report PR Review explain-diff

Decision memory

interview.md captures design-phase answers and rationale; scratchpad.md captures implementation-time decisions; human-promoted decisions move into decisions.md.

Reports

Pattern Review, judge, PR-review, explain-diff, and completion reports are evidence, not replacements for the source artifacts.

Learning events

Downstream misses become normalized learning events that feed pattern-learn. This is the meta loop: misses become structured learning inputs rather than one-off review comments.

Pattern Rules and the Learning Loop

Pattern Review is the concrete meta loop in the workflow. Repeated mistakes, review comments, coding standards, and project-specific conventions become durable rules. Those rules are then applied at PR boundaries so the same class of problem is caught earlier the next time.

This is deliberately hybrid. Deterministic code owns the mechanics: schemas, lifecycle buckets, rule storage, path scoping, trigger matching, and persisted reports. The probabilistic AI handles the judgment-heavy part: deciding whether a rule really applies to a particular diff and explaining the evidence. That balance is a useful pattern for agentic skills generally.

Rules as validation

Current diff The branch changes define the concrete review surface.

Active rules rules.yaml contains the durable standards to apply.

Deterministic scoping Paths, triggers, and severity narrow the review to relevant rules.

Agentic review The LLM applies judgment against the scoped rules and changed code.

Gate report pattern-review.md records pass/fail evidence for the PR boundary.

Learning cycle

Learning events Judge findings, PR-review misses, human review comments, and QA feedback become normalized evidence. captures misses

pattern-learn Classify learning events and turn recurring misses into candidate rules. creates proposals

Active pattern rules Human-promoted rules become the durable rule set consumed by future Pattern Review runs. center of the loop

pattern-review Run the PR-boundary gate against the current diff and active rules. prevents recurrence

pattern-extract Bootstrap candidate rules from instruction prose, coding standards, and repo guidance. seeds proposals

pattern-promote A human accepts, edits, defers, or rejects proposals before they become active. governs changes

pattern-init Create the local pattern-review buckets for a repository, worktree, or scope. sets up storage

Rule anatomy

A rule is small, inspectable, and evidence-backed. The important split is between deterministic fields such as scope, trigger, and severity, and the agentic review instruction that tells the LLM what judgment to apply.

- id: client-api-access-through-stores
  title: Client API access must go through stores
  description: Vue components must not call remote APIs directly.
  rationale: Preserves the UI / data-access boundary.
  scope:
    paths:
      - public/**/*.vue
      - public/**/*.js
  trigger:
    mode: diff
    addedContains:
      - "$axios"
  severity: blocker
  review:
    mode: agentic
    instructions: Inspect changed components for direct API access.
  evidence:
    sourceSummary: Repeated PR review finding.
  examples:
    good: Component calls a store action.
    bad: Component calls this.$axios directly.

Deterministic mechanics

Rule files are structured YAML. Scripts can parse them, validate them, match path scopes, compute hashes, and produce consistent reports.

Agentic judgment

The review instruction is where the LLM does useful judgment: reading a real diff, deciding applicability, and producing evidence.

Human governance

Proposals do not become active rules automatically. Promotion is a human-on-the-loop decision so the rule set stays intentional.

sample rules.yamlActive rule examples with scope, triggers, evidence, provenance, and good/bad examples sample pattern-review.mdRendered Pattern Review gate report pattern-reviewRun the validation gate pattern-learnConvert misses into rule proposals pattern-promoteHuman-govern proposed rules pattern-auditInspect rule-set health

PR Boundary Review

The PR boundary turns implementation work into reviewable evidence. It is not a single check. It is a coordinated stack of skills that reconcile the workflow record, evaluate the implementation against the spec, apply durable pattern rules, run adversarial judge review, perform code-review-style inspection, explain the final diff, and preserve the decisions that should survive the branch. This section decomposes that boundary into the concrete review activities and artifacts a human reviewer can trust.

Evidence assembly path

Reconcile Issues, tracker state, decisions, and verification scope are brought up to date. Evaluate The implementation is checked against the spec, acceptance criteria, rubric, and Definition of Done. Pattern review Active rules are applied to the current diff. Judge An independent LLM-as-judge pass looks for gaps, contradictions, and scope drift. PR review A code-review stance looks for bugs, regressions, and residual risks. Explain diff The completed branch is translated into a reviewer-facing walkthrough. Ready evidence The branch has concrete artifacts for human review.

Reconcile

Purpose

Bring the branch record into a coherent state before judging whether the work is ready for review.

What happens

Issues, tracker state, decision logs, and verification scope are reconciled against the current branch diff.

Artifacts

issues.md, tracker.md, scratchpad.md, and decisions.md.

Skills

workflow-pr-boundary and workflow-decision-triage.

Output

The branch record is internally consistent enough for evaluation and review checks to be meaningful.

Evaluate

Purpose

Check the implementation against the spec, acceptance criteria, rubric, and Definition of Done from concrete evidence.

What happens

Verification commands and observed behavior are mapped back to the criteria that should be satisfied by the completed slice.

Artifacts

spec.md and tracker.md.

Skill

workflow-spec-evaluate

Output

Tracker evidence is updated from facts, not optimism.

Pattern review

Purpose

Apply durable coding-standard and project-specific pattern rules to the current diff.

What happens

Active rules are scoped to the changed files and evaluated against the branch diff; findings become a persisted gate report.

Artifacts

rules.yaml and pattern-review.md.

Skill

pattern-review

Output

Pattern findings are fixed, reviewed, or explicitly waived before human review.

Judge

Purpose

Run an independent adversarial evaluation against the spec, changed files, and workflow evidence.

What happens

The judge looks for gaps, contradictions, scope drift, weak evidence, and rubric criteria that are not actually satisfied.

Artifact

judge.md.

Skill

workflow-judge

Output

Judge failures block review until fixed or explicitly accepted by the human.

PR review

Purpose

Inspect the diff from a code-review stance, prioritizing bugs, regressions, missing tests, and residual risks.

What happens

The review focuses on changed code, file/line evidence, cross-repo contracts, test gaps, and risks that a human reviewer would care about.

Artifact

code-review.md.

Skill

workflow-pr-review

Output

Findings lead with concrete file and line evidence, or the review records residual risks and test gaps.

Explain diff

Purpose

Translate the completed branch diff into a reviewer-facing walkthrough.

What happens

The explanation gives background, intuition, code walkthrough, diagrams, and comprehension checks so the reviewer can understand the change faster.

Artifact

explain-diff.html.

Skill

explain-diff

Output

The reviewer gets a narrative map of the diff, not just a raw file list.

Ready evidence

Purpose

Assemble the final review packet so a human can evaluate the branch without reconstructing context from scratch.

What happens

The PR description, linked reports, tracker state, decisions, and final commit are aligned with the evidence produced by the earlier sub-activities.

Artifacts

PR description, linked reports, promoted decisions, tracker evidence, and the final Git commit.

Skills

workflow-pr-boundary and workflow-commit.

Output

The branch is ready for human review with concrete, linked evidence.

Agentic Development Superpowers

These practices are orthogonal to the workflow diagrams, but they change the practical ceiling of agentic software development. They reduce coordination friction, increase agent autonomy, and keep the developer in the role of facilitator rather than bottleneck.

YOLO Mode

Agent autonomy only pays off when the harness can run commands, edit files, and inspect results without asking for permission at every small step. The exact name varies by harness, but the principle is the same: grant enough trusted local authority for the agent to execute the inner loop at speed, then rely on gates and review to control risk.

Full-stack access

When I find myself mediating between an agent and the system it needs to understand, I stop and connect the agent directly. Give it eyes, ears, and hands across the stack: browser state, logs, CLIs, schemas, queries, tests, and runtime evidence. Then get out of the way.

Git worktrees

Worktrees let separate topic branches run side by side in the same repository without separate full clones. They are the killer Git feature for agentic development because multiple agents can work concurrently without stepping on each other's files, while still sharing the same object database and repository history.

First-party desktop apps

Installed applications from model providers such as OpenAI and Anthropic are increasingly replacing traditional IDE-centered workflows. They are built around managing agentic development sessions, not just chatting in a browser or issuing commands in a terminal.

Voice-to-text

Modern AI dictation is accurate enough to change how software work feels. Speaking is a more natural way to give agents context, much as it is a natural way to work with junior engineers. English is becoming a programming language, and voice is often the fastest input device for that language.

Model and effort choice

Default to the strongest practical model and effort level unless cost, latency, or task simplicity argues otherwise. Token cost has become a practical consideration for next-generation models, so model choice should be treated as a cost-benefit decision. My current daily driver is the Codex desktop application with GPT-5.5 on medium effort.

YOLO Mode

YOLO Mode is a deliberate tradeoff: it increases productivity by giving the agent more autonomy, but it also increases risk. The harnesses warn about this because the agent may be able to edit files, run commands, use the network, or reach systems that normally require explicit approval. Choosing this mode requires extra diligence: decide whether the surrounding guardrails are sufficient, including worktrees, review gates, limited credentials, and whether VPN access to shared stages should be enabled at all.

The disclosure sections below show how to enable the most autonomous mode in each supported harness. The exact label differs by product, but the goal is the same: reduce routine approval prompts enough for the agent to work without constant human mediation.

Visual Studio Code with Claude Code

The Claude Code extension calls this permission level Bypass permissions. The VS Code setting that makes it available is labeled Claude Code: Allow Dangerously Skip Permissions.

Open Visual Studio Code settings from the application menu: Code → Preferences → Settings.

Open settings from the application menu.
Search the settings page for @ext:Anthropic.claude-code.
Enable Claude Code: Allow Dangerously Skip Permissions.

Filter to the Claude Code extension settings, then enable the permission.
Dismiss settings and open a new Claude Code session from the right sidebar.
Open the mode selector at the bottom of the Claude Code prompt box.
Choose Bypass permissions.

Start a new Claude Code session, open the mode selector, and choose Bypass permissions.

Claude Code may sometimes revert to a less permissive mode, especially across new sessions. If approval prompts start appearing again, reopen the mode selector and change the session back to Bypass permissions.

Visual Studio Code with Codex

The Codex extension exposes its approval mode directly in the chat window. To enable YOLO mode, open the approval selector and choose Full access.

Click the current approval mode at the bottom of the Codex chat window, then select Full access.

Open the approval mode menu in the Codex chat window and select Full access.

Cursor

Cursor exposes agent autonomy controls under the Agents settings. For a YOLO-style setup, switch the run mode to unsandboxed execution and allow network access.

Open Cursor settings from the application menu: Cursor → Settings.

Open Cursor settings from the application menu.
Select Agents, open the Run Mode menu, and choose Run Everything (Unsandboxed).

In Agents settings, set Run Mode to Run Everything (Unsandboxed).
Open the Auto-Run Network Access menu and choose Allow All.

Set Auto-Run Network Access to Allow All.

Codex desktop application

The Codex desktop application exposes agent permissions in the ChatGPT desktop settings. Enable full access to let Codex run commands with network access and without approval prompts.

Open ChatGPT settings from the application menu: ChatGPT → Settings.

Open ChatGPT settings from the application menu.
In General, enable the permission toggles: Default permissions, Auto-review, and Full access.

In General settings, enable Default permissions, Auto-review, and Full access.

Claude Code desktop application

The Claude desktop application exposes this through the Claude Code settings. Enable bypass permissions mode to allow Claude Code local sessions to run without repeated approval prompts.

Open Claude settings from the application menu: Claude → Settings.

Open Claude settings from the application menu.
Select Claude Code, then enable Allow bypass permissions mode.

In Claude Code settings, enable Allow bypass permissions mode.

First-party desktop apps

First-party desktop apps are installed applications from model providers such as OpenAI and Anthropic. They make it easier to keep multiple agentic development sessions alive, switch attention when a session needs judgment, and give agents local context that browser chat and terminal-only interfaces do not organize as naturally.

Codex desktop appOpenAI ChatGPT desktop app with Codex Claude Code desktop appAnthropic Claude desktop download CursorCursor desktop download for macOS, Windows, and Linux

Full-stack access

The most productive agent sessions happen when the agent can observe and operate the system directly instead of asking the developer to relay evidence by hand. Bugs and feature work rarely respect layer boundaries. A browser symptom may originate in frontend state, a backend API response, a database row, a queue message, a cloud permission, or a stale deployment. The agent needs access to enough of that stack to follow the evidence.

Browser and UI automation

Playwright is especially valuable because it lets the agent drive a real browser, run end-to-end tests, reproduce user flows, collect screenshots, and verify that fixes work from the user's point of view.

Frontend telemetry

Browser console output, network requests, response payloads, local storage, cookies, and rendered DOM state often explain what the UI is really doing. Without that evidence, the agent is guessing from code alone.

Backend and runtime logs

Local server logs, application logs, queue workers, API traces, and remote runtime logs let the agent connect a frontend symptom to the backend behavior that caused it.

Data and schemas

Database schemas, seed data, migrations, query tools, and safe read-only inspection paths help the agent distinguish a code bug from bad data, missing fixtures, or an unexpected production shape.

Cloud and CLIs

The agent can use the AWS CLI when credentials and guardrails permit, and the same principle applies to any other CLI: GitHub, Docker, database clients, deployment tools, log tools, and custom project commands.

Computer Use

Computer Use is particularly strong in the Codex desktop application. It lets the agent operate normal desktop apps the way a person would: by seeing, clicking, typing, using menus, and moving between windows when there is no clean API, plugin, or CLI path.

The magic is cross-layer diagnosis

Once this is wired up, an agent can run a browser test, watch the console and network tab, inspect backend logs, query local data, and rerun verification without waiting for a human to copy evidence from each layer.

PlaywrightBrowser automation for tests, scripts, and agent workflows Codex Computer UseLet Codex operate desktop apps by seeing, clicking, and typing

Git worktrees

Git worktrees are one of the highest-leverage features for agentic development. They let you create separate working directories for separate branches, so each agent session can have its own files, branch, editor state, and test runs without blocking or overwriting another session.

Why they are better than full clones

A worktree is not a separate full checkout with its own independent repository history. Linked worktrees share the repository's Git object data and metadata, so creating or deleting one is usually much faster and lighter than cloning the whole repository again.

Why agents love them

Agentic work often means several tasks are active at once: one branch is waiting for review, another is debugging a failure, and a third is implementing the next slice. Worktrees keep those contexts isolated so agents do not stomp on each other's files or force constant stashing and branch switching.

Multi-repo products complicate things

Many harnesses can create a worktree automatically when the project is a monorepo. Products that span multiple repos are harder: you may need matching topic branches and worktrees in both frontend and backend repos. It is still worth doing because it preserves isolation across the whole feature, not just one repository.

Git worktree documentationCanonical Git definition and command reference Codex worktreesHow Codex uses Git worktrees in the desktop app Claude Code worktreesRunning parallel Claude Code sessions with worktrees

Voice-to-text

The current generation of AI dictation tools is materially different from old operating-system speech recognition. They handle natural speech, clean up filler, preserve intent, and produce text that is often ready to paste directly into an agent prompt, issue description, review response, or design note.

Why it matters

Agentic development shifts a lot of programming into explaining intent, constraints, examples, and tradeoffs. Speaking that context is usually faster and more natural than typing it. It also reduces wrist load and lowers the friction of giving agents the rich context they need.

English as programming language

If English is becoming a programming language for agents, then voice is one of the best interfaces for writing it. The interaction starts to feel less like typing commands and more like mentoring a junior engineer: explain the goal, describe constraints, answer questions, and refine the result.

My current tool

I currently use Willow Voice. The accuracy is high enough that it is worth paying for, especially when writing longer prompts or design explanations. My referral link is Willow Voice.

Willow VoiceAI dictation for prompts, documents, email, and messaging Wispr FlowCross-platform voice dictation, often heard as “WhisperFlow” SuperwhisperAI voice-to-text for macOS, Windows, and iOS Aqua VoiceFast AI dictation that works across apps MacWhisperWhisper-based transcription and dictation on macOS

Model and effort choice

The default should usually be the strongest model and effort level that is practical for the job. For hard implementation work, review, or ambiguous debugging, the quality gains are often worth the additional time and token cost. For small mechanical edits, simple searches, or low-risk formatting, a cheaper or lower-effort setting may be enough.

Optimize for outcome

Use stronger models when correctness matters, when the codebase is unfamiliar, or when a mistake would create expensive review or rework. The cheaper run is not cheaper if it produces a weak plan, misses context, or needs to be redone.

Tune effort to task shape

Higher effort is best for open-ended design, multi-file changes, adversarial review, and failure diagnosis. Medium effort is often the useful daily-driver setting. Lower effort fits quick edits and well-scoped mechanical follow-through.

Delegate with tuned effort

One of the more exciting features of cutting-edge agentic models is their ability to delegate work to sub-agents and tune the model and effort used by each one to the difficulty of its subproblem. That can preserve a high-performance primary agent without making every supporting task equally expensive.

Watch cost, time, and tokens

Token cost has become a real factor with the newest models, but it depends on how you access them. With direct API use, more tokens means more billable cost. With a subscription plan, it usually means you burn through plan limits faster rather than paying more for that individual task.

Cost-benefit benchmark examples

These examples show why the external benchmark graphs are useful: they make the relationship between quality, effort, time, and task cost visible instead of relying on a single model ranking.

DeepSWE score versus average cost per task graph for coding agent models — Cost-benefit curves make the tradeoff visible. A model can produce a better score while costing more per task, and different effort levels can move the same model along the curve. The practical question is which point gives enough quality for the work at hand.

Artificial Analysis intelligence versus cost per task quadrant chart — Quadrant charts are useful for spotting efficient choices quickly: models in the attractive region combine stronger measured capability with lower cost per task. Treat these charts as decision aids, not absolute truth; your subscription limits, latency, task type, and local workflow still matter.

Artificial Analysis Coding Agent BenchmarksCompares coding-agent performance, token usage, cost per task, and execution time

Design

Purpose

Resolve intent, scope, and constraints before requirements are written.

Inputs

Developer seed, existing codebase, existing docs, tracker issue, and known stakeholder constraints.

Outputs

interview.md, design.md, and relevant decisions.

Pass condition

The developer explicitly approves the design, or the branch is stopped before downstream artifacts are created.

Spec

Purpose

Convert approved design into observable acceptance criteria and a binary rubric.

Inputs

design.md controls; interview.md explains provenance and intent; the current codebase constrains feasible contracts, architecture, and test strategy.

Checks

Spec linting, ambiguity review, missing-rubric checks, and explicit amendment rules.

Pass condition

Every requirement is testable, every rubric item is binary, and implementation planning can proceed without inventing requirements.

Branch Readiness

Purpose

Make implementation executable and auditable before code changes begin.

Outputs

plan.md, issues.md, tracker.md, scratchpad.md, and decisions.md.

Checks

Plan maps to rubric; issues map to plan; tracker starts with known status; decision log exists; implementation steps match the actual repository shape.

Pass condition

The work can be executed issue-by-issue without changing the spec by accident.

Implementation Loop

Ongoing activity

Implement scoped issues, run targeted tests, update tracker evidence, keep the live codebase aligned with the spec, and record decisions when triggers fire.

Normal loopbacks

Failed tests return to implementation; new requirements return to spec amendment; design mismatch returns to design amendment.

Artifacts

Code changes, current diff, test evidence, scratchpad.md, updated issues.md, and tracker evidence.

PR Boundary

Purpose

Ensure the PR is reviewable, verified, and aligned with the spec before human review.

Sequence

Reconcile issues and tracker, inspect the current diff, run definition-of-done checks, evaluate the spec, pattern-review, adversarial /judge, PR-review, explain-diff, and decision triage.

Outputs

Verification matrix, Pattern Review, judge result, PR Review, explain-diff, normalized learning events, and PR description. These outputs are grounded in both the artifact stack and the current diff.

Pass condition

Blocking findings are fixed or explicitly waived with evidence.

Human Review

Purpose

Incorporate external review after the work has already passed the internal workflow gates.

Failure path

Review comments become reopened or new issues, and the work returns to implementation plus the PR boundary checks.

Learning path

Downstream misses become learning events so pattern-review can improve.

Completion

Purpose

Prove the complete feature satisfies all acceptance criteria and is ready to merge or promote.

Checks

Full verification, final judge, final tracker lint, decision triage, and completion report.

Pass condition

Zero NOT YET and zero FAIL; manual checks are explicitly identified or complete.

Supporting Reference

These sections provide direct access to the skill and artifact examples used throughout the workflow. They complement the gate sequence without being additional gate-detail panels.

Skill Library

Local copies of the skills referenced by the workflow. These links open pre-rendered HTML views of each copied SKILL.md.

Artifact Examples

These examples come from completed workflows and show the kinds of durable records the process produces at each stage.

interview.mdGrill Me working record design.mdApproved design gate artifact spec.mdAcceptance criteria and binary rubric plan.mdRubric-mapped implementation plan issues.mdOperational task breakdown and status tracker.mdRubric evidence and PR state scratchpad.mdAppend-only decision capture decisions.mdPromoted permanent decisions rules.yamlPattern Review active rule examples completion-report.mdDefinition-of-done proof and honest limitations pattern-review.mdDeterministic pattern gate report code-review.mdPR boundary code review judge.mdIndependent LLM-as-judge verdict verification.mdBoundary verification evidence spec-evaluation.mdSpec compliance evaluation explain-diff.htmlInteractive PR walkthrough Workflow overviewRendered Mermaid process diagram Grill Me overviewRendered explainer and PDF link

The Philosophy: Structure, Autonomy, Proof

Specify clearly

Let the agent execute

Validate hard

Workflow Loops

The Workflow Model

Diagram key

Activity

Artifact

Gate

Gate Spine

Workflow Layers

Artifact Flow

Pattern Rules and the Learning Loop

Rules as validation

Learning cycle

Rule anatomy

PR Boundary Review

Evidence assembly path

Agentic Development Superpowers

Workflow Skills

Pattern Review Skills

General Process Skills

Platform And Runtime Skills