用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/edwinhu/workflows --skill dev-implement命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | dev-implement |
| description | Internal /dev execution adapter for authenticated generated plans. |
| user-invocable | false |
| disable-model-invocation | true |
| hooks | {"PostToolUse":null,"PreToolUse":[{"matcher":"Write|Edit|MultiEdit|NotebookEdit","hooks":[{"type":"command","command":"bun ${CLAUDE_PLUGIN_ROOT}/hooks/orchestrator-mutation-guard.ts --workflow dev"}]},{"matcher":"Bash","hooks":[{"type":"command","command":"bun ${CLAUDE_PLUGIN_ROOT}/hooks/orchestrator-mutation-guard.ts --workflow dev"}]},{"matcher":"Agent|Workflow","hooks":[{"type":"command","command":"bun ${CLAUDE_PLUGIN_ROOT}/hooks/approved-artifact-gate.ts --workflow dev"}]}]} |
!bun ${CLAUDE_SKILL_DIR}/../../scripts/load-constraints.ts dev-implement
/dev is an adapter over the shared IMPLEMENT beat. Its sole planning authority is the exact,
receipt-selected generated {planFile, planHash}. Never read, mutate, compile, or resume a fixed
PLAN.md; do not create run.js, progress.md, STATE.md, SPEC.md, or LEARNINGS.md.
.planning/.state/review.json; require exact
{planFile, planHash} and reject missing, stale, mismatched, or pending identity.plan_task_id, dependencies, work, criteria, outputs,
writablePaths, first failing test, verify command, instruction files, model, and effort.(planHash, plan_task_id, item_kind) identity:
superseded with superseded_by_plan_hash;
delete only untouched, finding-free work.Load and follow ${CLAUDE_SKILL_DIR}/../beat-implement/SKILL.md. Keep one bounded /goal tied to
{planFile, planHash}. Only the top-level session may activate or clear it:
bun ${CLAUDE_SKILL_DIR}/../../scripts/goal-self-send.ts "/goal <condition>"
bun ${CLAUDE_SKILL_DIR}/../../scripts/goal-self-send.ts "/goal clear"
Proceed only after status: delivered or the user explicitly confirms the goal is active; otherwise
print the literal command and stop. Invoke the shared runner with the complete ready wave and exact identity:
Load and follow ${CLAUDE_SKILL_DIR}/../beat-implement/SKILL.md; it owns dispatch. Route the wave by
shape first, then dispatch what the route says — one task goes to a single subagent, a fan-out is
compiled into a generated workflow under .claude/workflows/.
# ONE call. The preflight authenticates the approval, validates every task against the shared
# contract, canonicalises writable paths, binds a per-task approval, DERIVES THE ADJUDICATION
# EXPECTATION the observation hooks read, routes by shape, and emits the script when one is warranted.
echo "$PREFLIGHT_REQUEST_JSON" | bun ${CLAUDE_SKILL_DIR}/../../scripts/beat/preflight.ts
PREFLIGHT_REQUEST_JSON is {"projectDir": "<absolute project path>", "workflow": "dev", "planReset": {"planFile": "<receipt plan_file>", "planHash": "<receipt plan_hash>"}, "phases": [...], "readyWave": [...]}.
Do NOT call route-implementation.ts or emit-implementation-workflow.ts yourself. They are the
preflight's internals. Calling them directly skips the approval authentication and — the silent part —
skips the expectation file, so every dispatch is adjudicated against no bounds at all and the run
looks clean because nothing was ever checked. scripts/beat/implement-gate.ts then refuses the wave
with reason no-expectation, whose remedy reads "the preflight never ran".
Workflow({ scriptPath: "<path returned by the generator>", args: {} })
The domain supplies phases and each task's prompt; planFile and planHash come from the
receipt-selected plan and bind the generated script to it. There is no checked-in runner script to
invoke — the script is generated per plan, and a new plan hash produces a new script.
The runner dispatches mutations sequentially. Do not hand-dispatch an alternative compiler runner. For a retry, send only previously attempted task IDs and their returned attempt records.
Every dev task MUST declare redCommand — the exact command that fails before the task is
implemented and passes after. The preflight refuses a dev wave without one, and it is bound into the
wave fingerprint, so it cannot be swapped after approval.
It is not evidence you report. The observation hook EXECUTES it on both sides of the dispatch and
records the exit codes; implement-gate then requires nonzero before and zero after. Three ways a
task fails on it, each named distinctly:
| Verdict | Meaning |
|---|---|
red-unproven | the command never ran, timed out, or a different command was run |
red-not-red | it PASSED before implementation — the test does not pin the behavior being built |
green-not-green | it still fails after implementation |
red-not-red is the one worth understanding: a test that already passed proves nothing about the
work, and no self-reported "RED confirmed" can rule that out. This is why the command is read from
the authenticated expectation, which the implementing agent never sees and cannot edit.
redCommand must be ONE INVOCATION, not a shell program. Shell operators — ; & | `
$ > < ( ) { } — are rejected by the task contract. Flags and quotes are fine:
pytest tests/x.py -k "a or b" is valid, test -f /tmp/m || { touch /tmp/m; exit 1; } is not. The
hook executes this string, so an unconstrained one is arbitrary code execution with the hook's
authority; an adversarial review built four separate bypasses out of it, and every one needed an
operator — fabricating RED with a marker file, alternating a counter across a wave, mutating a
declared output after adjudication, and exfiltrating while looking like a test run.
What this does not close. The command still loads code the implementer may control — a test
file, a conftest.py, a fixture. Authenticating the command string does not authenticate what it
transitively imports, so an implementer permitted to edit the test it is judged by can still run
code inside the probe. Narrow the task's writablePaths when that matters. The probe also runs
after the post-dispatch observation, so a tree mutation there is detected and reported as a
violation rather than silently adjudicated against stale bytes.
Every task's work and criteria also require: write and run the named test against missing
behavior; observe and report a valid RED; only then implement; run the exact verify command to
GREEN; report changed files and raw evidence. A doer never verifies its own task. An independent fresh verifier
checks each criterion and named evidence after the runner returns. On failure, create or update the
corresponding TaskList finding/retry dependency and resume only affected attempted work.
After all current-hash implementation items independently pass, run dev-test-gaps. Its returned
requirement-to-test matrix, not a visible validation ledger, is the quality-gate result. Clear the
goal after terminal verification PASS, then continue to dev-verify.
redCommand: STOP — the preflight refuses the wave, and a
test-first workflow that takes the test on trust is not test-first.Use for feature development and engineering changes.
This skill should be used when the user asks to 'start data analysis', 'plan a data project', 'explore this dataset', 'what should I analyze', 'set up a new study', or needs the data-science workflow.
Use when the user asks to 'run a work workflow', 'do this properly', 'clarify, plan, and verify this', 'small structured task', or 'don't just wing it' for a bounded task too small for a specialized workflow.