work

<!-- work-anti-bypass-protocol:start -->

Anti-bypass protocol (load-bearing — especially Grok Build)

You are the implementation orchestrator for standalone /work and one-shot Step 3:

• FORBIDDEN: Pushing a branch and reporting "done" without /review → /compound → /ship.
• FORBIDDEN: Treating ## Work Phase Complete as a turn boundary when you own the pipeline (see Invocation Mode below).
• REQUIRED (Grok Build): Invoke /review, /compound, /ship via slash commands — never hand-roll ship steps.
• Deliverable: merged PR (standalone) or return to parent one-shot (pipeline mode).

See plugins/soleur/lib/workflow-fidelity.ts (IMPLEMENTATION_TAIL) and Phase 4 Invocation Mode below. <!-- work-anti-bypass-protocol:end -->

"PROPAGATED" IS A MEASUREMENT ACROSS EVERY SITE ASSERTING THE CLAIM — NOT AN OBSERVATION ABOUT THE ONE YOU EDITED. Grep for the OLD claim after correcting it, never for the new one: a residual count over the new text is structurally blind to the sites still carrying the old. A superseded position survives precisely where prose review does not look — machine-readable frontmatter, an operative conclusion far from the edited paragraph, and a DIFFERENT document citing the old position as its own contrast case — so a corrected document containing an uncorrected field clears both the gates and the review. Why: #7349 — a legal record's controllership was corrected in prose while its YAML controller: field FIFTEEN LINES ABOVE still asserted the superseded position, along with the operative balancing conclusion and a sibling document; the signed-off audit had already recorded that propagation as DISCHARGED. Same shape as the measurement rule below, one level up: that rule protects a number's freshness, this one protects a correction's reach. See knowledge-base/project/learnings/2026-08-12-every-blocking-finding-was-the-defect-class-the-pr-existed-to-close.md.

VERIFY A MEASUREMENT ONCE, BEFORE IT PROPAGATES. When a plan's sweep will write the same measured fact into more than one file, verify it at the granularity you are about to CLAIM it — before the first write, not after the last. A false measurement does not stay where you put it: downstream files, issue comments, and review agents all consume it as fact and build on it, so the cost of correcting it scales with how far it spread, and the correction itself has to be swept. Why: #7325 — "cx33 is available in hel1-dc2" was read off a FLEET-WIDE probe and written into 4 files and 2 issue comments. It is false per-datacenter. Six review agents read it and one built its top finding on it (recommending an amendment to a hard-rule exception), so the error had already propagated one level past the diff before a 15-second re-probe falsified it. Project every measurement onto the exact scope you will assert — per datacenter, per host, per environment — and re-probe rather than adjudicating between two readings of the record.

SINGLE-SOURCE THE RATIONALE BEFORE WRITING IT, NOT AFTER REVIEW SAYS SO. Prose is review surface: every restated paragraph is re-read by every agent and can drift independently. Write the reasoning ONCE at the artifact that owns the decision (the ADR for the element, the resource for the resource) and make every other site a one-line pointer anchored on content, not a line number. Why: #7325 — ~300 lines of justification prose across 8 files became the bulk of the review surface for a one-literal change, and two copies of the same probe table DIVERGED INSIDE THE SAME PR (one said "flipped twice", the other "three times") before any reviewer saw them. The review's own conclusion was to delete one copy. A short rationale plus a pointer is both cheaper to review and structurally unable to drift.

A DATED record is APPEND-ONLY. When a plan's sweep touches a probe table, ledger row, dated addendum or post-mortem, correct it by APPENDING a new reading/section that cites the old one — never by editing the old one's body or substituting a cell. Editing in place is what turns a correction into destroyed evidence, and the destroyed datum is disproportionately the one that supported your own claim. Use ## Addendum — YYYY-MM-DD (#N) or > Superseded YYYY-MM-DD (#N):, and put the record in the ADR that OWNS the element rather than the one you happened to be reading. Why: #7309 — a repin overwrote ADR-143's dated cx23 = YES — in stock cell, then asserted "Both read NO here" four lines above it; that deleted YES was the only in-repo evidence for the PR's own headline claim, and restoring it made the argument stronger than the one that replaced it. See knowledge-base/project/learnings/2026-08-06-i-deleted-the-measurement-that-was-my-own-evidence.md.

Work Plan Execution Command

Execute a work plan efficiently while maintaining quality and finishing features.

Introduction

This command takes a work document (plan, specification, or todo file) and executes it systematically. The focus is on shipping complete features by understanding requirements quickly, following existing patterns, and maintaining quality throughout.

Headless Mode Detection

If $ARGUMENTS contains --headless, set HEADLESS_MODE=true. Strip --headless from $ARGUMENTS before processing the remainder as a plan path. Pipeline mode (file path detection) already covers all prompt bypasses for work's own prompts — --headless is only needed for forwarding to child skills in Phase 4.

Input Document

<input_document> #$ARGUMENTS </input_document>

<decision_gate> API budget. This skill executes a work plan iteratively across many phases. Tier A (Agent Teams) carries ~7x per-task token cost; Tier B (Subagent Fan-Out) is moderate; Tier C is single-agent. Total cost scales with plan length, chosen tier, and per-task RED/GREEN/REFACTOR cycles. Soleur does not bill or proxy these calls — Anthropic does, against the key in your session. The Soleur LICENSE (BSL 1.1) disclaims warranty for runtime cost; you operate this loop against your own budget.

The tier offer fires inline at the right phase. Decline if running an unfamiliar plan against a tight budget. </decision_gate>

Execution Workflow

Phase 0: Load Knowledge Base Context (if exists)

Load project conventions:

# Load project conventions
if [[ -f "CLAUDE.md" ]]; then
  cat CLAUDE.md
fi

Clean up merged worktrees (silent, runs in background):

Navigate to the repository root, then run bash ${CLAUDE_PLUGIN_ROOT:-./plugins/soleur}/skills/git-worktree/scripts/worktree-manager.sh cleanup-merged. Report cleanup results: how many worktrees were cleaned up, which branches remain active.

Check for knowledge-base directory and load context:

Check if knowledge-base/ directory exists. If it does:

1. Run git branch --show-current to get the current branch name
2. If the branch starts with feat-, read knowledge-base/project/specs/<branch-name>/tasks.md if it exists

If knowledge-base/ exists:

1. Read CLAUDE.md if it exists - apply project conventions during implementation
2. If # Project Constitution heading is NOT already in context, read knowledge-base/project/constitution.md - apply principles during implementation. Skip if already loaded (e.g., from a preceding /soleur:plan).
3. Detect feature from current branch (feat-<name> pattern)
4. Read knowledge-base/project/specs/feat-<name>/tasks.md if it exists - use as work checklist alongside TodoWrite

4.5. Read lane: from spec.md if present. Guard file existence first:

```bash spec_path="knowledge-base/project/specs/feat-${branch_name}/spec.md" if [[ -f "$spec_path" ]]; then LANE=$(awk '/^lane:/ { gsub(/^lane:[[:space:]]"?|"?$/, ""); print; exit }' "$spec_path") case "$LANE" in single-domain|cross-domain|procedural) ;; "") LANE="" ;; # legacy spec; silent skip in announce ) echo "work: invalid lane value '$LANE' in spec; i