Help us improve
Share bugs, ideas, or general feedback.
From rust-development-pipeline
Merged Stage 1+2 — define success criteria, explore against real fixtures, validate, implement, and produce a forensic record. One continuous session with a checkpoint in the middle. Use when the user says "/drive-outcomes <plan-path>", "drive the outcomes for this phase", after /define-outcomes completes, or when a phase plan is already ready for ODD-driven implementation.
npx claudepluginhub tonywu20/my-claude-marketplace --plugin rust-development-pipelineHow this skill is triggered — by the user, by Claude, or both
Slash command
/rust-development-pipeline:drive-outcomesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Merges outcome-definition (Stage 1) and implementation (Stage 2) into one
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Share bugs, ideas, or general feedback.
Merges outcome-definition (Stage 1) and implementation (Stage 2) into one continuous session with a checkpoint. This eliminates cold-start information loss between planning and implementation — the agent that validates criteria against real data is the same agent that implements production code.
Session A (define + explore) produces a forensic TASKS.md. The user reviews and
may /clear or continue. Session B (implement on branch) reads that artifact,
refactors exploratory snippets into production code, and commits.
/drive-outcomes <plan-path>
Where <plan-path> is the path to PHASE_PLAN.md (the output of /init-project
or /define-outcomes).
The target project MUST have a CONTEXT.md (produced by /init-project). If none
exists, prompt the user to run /init-project first and stop.
fd instead of findrg instead of grepnotes/plans/<phase-slug>/DECISIONS.md — design decisions from the grillnotes/plans/<phase-slug>/TASKS.md — forensic task breakdown with success criteria# Set stage marker and session start for metrics tracking
echo "drive-outcomes" > .claude/.current_stage
date +%s%3N > .claude/.session_start
# Determine phase slug from plan path
PHASE_SLUG=$(basename $(dirname <plan-path>))
mkdir -p notes/plans/$PHASE_SLUG
# Ensure pipeline state directory is gitignored
grep -qx '.claude/' .gitignore 2>/dev/null || echo '.claude/' >> .gitignore
Read the constitution, plan, deferred items, and failure patterns:
# Read the constitution
cat CONTEXT.md
cat CONTEXT-MAP.md 2>/dev/null || echo "NO_CONTEXT_MAP"
fd -e md . docs/adr/ 2>/dev/null | sort | while read f; do
echo "=== $f ===" && cat "$f" && echo ""
done
# Read the plan
cat <plan-path>
# Read deferred improvements from prior phases
fd deferred.md notes/pr-reviews/ | while read f; do echo "=== $f ==="; cat "$f"; done
# Read failure patterns
cat notes/failure-patterns.md 2>/dev/null || echo "No failure patterns catalog yet"
# Read the ODD pattern reference
cat "${CLAUDE_PLUGIN_ROOT}/skills/drive-outcomes/references/odd-pattern.md"
Launch a grill-me subagent that interviews the user about:
The agent references odd-pattern.md for placebo test detection and fixture
anchoring protocol. It does NOT discuss implementation details (those are discovered
in Steps 5-6).
Output: notes/plans/<slug>/DECISIONS.md with:
For each set of criteria declared in the grill:
This step is interactive — findings are reported to the user as they happen.
Write notes/plans/<slug>/TASKS.md following the forensic-tasks-spec.md format.
This is the checkpoint artifact. It includes:
Source-audit requirement (anti-speculation gate): For each task that
cites a reference implementation source file (e.g., CASTEP
ion_atom.f90:5641-5876), you MUST read the cited source lines BEFORE
writing the task description. Base the algorithm description on what the
code actually does — not on general domain knowledge or assumed algorithm
structure. Document key findings inline in the task description:
If a task cites or implies a reference implementation but has no source citation, search the reference source tree to find and read the relevant code before writing the description. Do NOT write speculative algorithm descriptions under any circumstance.
Rationale (failure-patterns.md: 2026-05-16, pattern:
source-citation-without-reading): Task descriptions written from general knowledge are routinely wrong — sometimes every line is wrong (3-point finite-difference log-grid vs. spherical Bessel + DSYGV). The source citation exists precisely to prevent this; treating it as decorative context undermines the entire pipeline.
Present the forensic TASKS.md to the user for review:
"Forensic TASKS.md written at
notes/plans/{slug}/TASKS.md. {N} tasks in {M} groups.Success criteria are anchored to:
- {N} fixture files declared
- {N} criteria with concrete expected values
- {N} criteria adjusted during exploration
Review the TASKS.md. When you're satisfied, reply 'continue' to proceed to implementation. You may also
/clearand re-invoke with/drive-outcomes --resume.
Commit the checkpoint:
git add notes/plans/$PHASE_SLUG/
git add .gitignore
git commit -m "docs: add forensic TASKS.md for $(basename $PHASE_SLUG)"
If continuing in the same session, proceed to Step 6. If resumed after /clear:
# Restore state
echo "drive-outcomes" > .claude/.current_stage
PHASE_SLUG=$(basename $(dirname <tasks-path>))
# Read checkpoint
cat notes/plans/$PHASE_SLUG/TASKS.md
cat notes/plans/$PHASE_SLUG/DECISIONS.md
Determine the feature branch for this phase (creating it from main if needed), then create a per-group sub-branch for the task group:
FEATURE_BRANCH="feat/$(basename $PHASE_SLUG)"
# Ensure feature branch exists (no-op on resume)
if ! git show-ref --verify --quiet "refs/heads/$FEATURE_BRANCH"; then
git checkout -b "$FEATURE_BRANCH" main
else
git checkout "$FEATURE_BRANCH"
fi
# Create per-group sub-branch
git checkout -b "impl/$(basename $PHASE_SLUG)/<group-id>"
For each task in the group, dispatch to the implementation-executor subagent. Do NOT implement directly — delegate every task to the specialist agent.
Extract the task's section from TASKS.md (including its success criteria, files, changes, and acceptance commands). Pass it as the agent's instructions along with the project path and workflow flag:
Model discipline: The implementation-executor agent definition specifies
model: haiku. Do NOT pass a model override in the Agent() call — not
opus, not sonnet. The edit→check→fix loop is well-served by haiku.
Passing opus wastes 10-50× cost for zero quality gain and violates the
pipeline's resource discipline.
No re-speculation: The task description in the dispatch prompt must come verbatim from the source-audited TASKS.md written in Step 5. Do NOT add, rephrase, or extrapolate algorithm details from general knowledge at dispatch time. If the TASKS.md description feels underspecified, read the cited source yourself (following the Step 5 protocol) and include the actual source findings in the prompt — never invent.
Source citation carry-forward: If the task cites a reference source
file (e.g., CASTEP ion_atom.f90:5641-5876), include the exact citation
in the prompt AND instruct the subagent to read the cited lines before
writing any code. The citation is a read instruction, not decoration.
kind: lib-tdd — dispatch with workflow: 'odd':
description: the task description, success criteria, test codePROJECT_PATH: the project rootworkflow: 'odd'odd_pattern_path: path to odd-pattern.md referencefeat(<slug>): <task-id> (ODD): <desc>kind: direct — dispatch with workflow: 'direct':
description: the task changes and acceptance commandsPROJECT_PATH: the project rootworkflow: 'direct'Auto-review before commit (both kinds, done by the subagent):
if/when/case/early-return in the
reference function must have a corresponding condition in our implementation
or an explicit justification why it's not needed. Source both the reference
line and the justification.After the subagent returns, verify the commit was made. Then update the resume note:
# Resume: <slug>/<group-id>
**Tasks done**: TASK-1, TASK-2
**Next task**: TASK-3
**Status**: in-progress
After all tasks in a group complete:
cd "${CLAUDE_PROJECT_DIR}" && cargo check --workspace 2>&1
cd "${CLAUDE_PROJECT_DIR}" && cargo clippy --workspace -- -D warnings 2>&1
cd "${CLAUDE_PROJECT_DIR}" && cargo test --workspace 2>&1 | tail -40
FEATURE_BRANCH="feat/$(basename $PHASE_SLUG)"
git checkout "$FEATURE_BRANCH"
git merge --ff-only "impl/$(basename $PHASE_SLUG)/<group-id>"
git branch -d "impl/$(basename $PHASE_SLUG)/<group-id>"
Workspace validation again on the feature branch:
cd "${CLAUDE_PROJECT_DIR}" && cargo check --workspace 2>&1
cd "${CLAUDE_PROJECT_DIR}" && cargo clippy --workspace -- -D warnings 2>&1
cd "${CLAUDE_PROJECT_DIR}" && cargo test --workspace 2>&1 | tail -40
Clean up resume note:
rm -f "${CLAUDE_PROJECT_DIR}/.claude/resume-<slug>-<group-id>.md"
CLAUDE_PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT}" CLAUDE_PROJECT_DIR="${CLAUDE_PROJECT_DIR}" \
uv run --directory "${CLAUDE_PLUGIN_ROOT}" python \
"${CLAUDE_PLUGIN_ROOT}/scripts/eval-session-metrics.py" drive-outcomes
"Outcomes driven for phase "{Phase Name}".
{N} tasks implemented, criteria anchored to {M} fixture files. Exploration adjusted {K} criteria during validation.
Next step:
/make-judgement notes/plans/{slug}/TASKS.mdfor cross-group review."
Will:
Will not: