implement

Files (12)

• SKILL.md
• openai.yaml · agents/
• evals.json · evals/
• README.md · evals/fixtures/setup-pending/
• spec.md · evals/fixtures/setup-pending/docs/specs/password-reset-email/
• package.json · evals/fixtures/setup-pending/
• reset.js · evals/fixtures/setup-pending/src/
• README.md · evals/fixtures/stale-spec/
• spec.md · evals/fixtures/stale-spec/docs/specs/csv-export/
• package.json · evals/fixtures/stale-spec/
• rows.js · evals/fixtures/stale-spec/src/
• trigger-evals.json · evals/

SKILL.md (first lines)

# Implement

This skill requires `tdd`, `babysit-specs`, and `project-knowledge`. Before
doing any work, confirm each one is installed. When one is missing, stop and
report it with its install command,
`npx skills@latest add toy-crane/skills --skill <name>`, using the project's
package manager runner where it pins one.

## Claim the folder when a tracker coordinates it

The input is always the spec folder. When the repository's `AGENTS.md` or
`CLAUDE.md` carries an `## Issue tracker` section, read both files and use the
first found and its linked detailed convention before finding this folder's
issue. An `Issue: <tracker>:<id>` line in `spec.md` names the folder's one
issue; fetch it by that ID and never search the tracker by title. Existing
inline conventions remain valid. Use the convention's ID form, tool, and claim
operation without requiring `setup-issue-tracker` to be installed.
Claiming is the first write of the run, ahead of source, task, or spec edits.
Check the convention's active-work signal before claiming: an issue already in
progress requires the user's explicit request to resume, even when its assignee
is the current account. Assign eligible work to the current tracker account and
apply the convention's active state. Stop without changing source and report
another account's claim, open blockers, an unreadable linked convention, or an
unavailable tracker tool; continue unclaimed only on explicit user instruction.
A folder without an `Issue:` line
proceeds unclaimed; the PR that carries it creates its issue. Without the
section, nothing here applies.

End every commit's message with a `Spec-Folder: docs/specs/<slug>/` trailer so
the pull request that follows can find the folder and close its issue; this trailer is
repository information and is written whether or not a tracker exists.

## Load the current handoff

Treat the selected spec folder as one handoff bundle anchored by `spec.md`.
Before deriving an implementation approach or changing source, identify and
load its current required sources: the spec; every active unfinished task; any
completed or superseded task implicated by current evidence; project decision
contracts explicitly linked by the spec or active tasks, plus any other current
decision contract implicated by repository evidence; and every prototype,
screen, state, or other reference artifact that the spec or an active task
identifies as an approved or selected implementation reference. Read textual
sources and render or otherwise inspect visual artifacts so their operative
content is available before work starts. Presence in the folder alone does not
establish approval. An approved visual reference is a required, complementary
contract for the concrete screens and states it covers; explicit product
contracts retain their stated meaning. If required sources disagree, preserve
them, record the exact sources and affected behavior or screen-state coordinate,
and keep that outcome and its dependents blocked for shaping instead of choosing
a winner.

Non-superseded approved task files form the bundle's current shallow delivery
map: `pending`, `in-progress`, and `blocked` tasks are active unfinished work,
while `completed` tasks are current proof. A `superseded` task is inactive
recovery history; exclude it from the frontier, blockers, reconciliation, and
completion gates, but inspect it when current evidence implicates its prior
implementation. If an active task still names superseded history as a blocker,
reconcile that stale reference before continuing.

Before selecting or starting each outcome, and again after an interruption,
reconstruct current truth from the required handoff sources, code, Git state and
current diff, and verification evidence. Repository evidence outranks
remembered conversation; rerun verification that predates the relevant code.
Preserve completed outcomes whose current evidence still passes, and confirm
ownership before absorbing ambiguous dirty changes. Then work sequentially from
the current unblocked frontier; when no task files exist, implement `spec.md`
directly.

Before changing source for an outcome, check the spec against what the
repository has done since. Compare its assumptions, settled constraints, and
acceptance criteria with the current code and the Git history since the spec
folder's last commit; your own code-plus-task checkpoints advance that
baseline, so each check covers only what happened since the previous outcome.
A mismatch that would change an approved outcome, acceptance criterion,
off-limits area, or other product constraint stops that outcome before any
source change: name the stale point and its evidence, then route it to
`babysit-specs` for this spec folder alone, handing it the stale point and its
evidence; it hands back the revised `spec.md`, which this run reloads before
continuing. Naming the folder keeps the revision on the selected work unit;
you still
never read a sibling spec folder. A stale spec caught here
costs nothing, while the same discovery made mid-implementation discards work
already done.

Derive only the active outcome's technical approach just in time. A task
boundary requires this reload; it does not by itself require a new session,
worker, or reviewer. Keep the spec folder as the single handoff instead of
adding a roadmap, execution ledger, durable implementation plan, or run-state
file.

## Finish outside setup before changing source

When `spec.md` lists items under `## Setup before implementation`, finish them
after any claim and before the first source change. Do what you can of each
item yourself within your current tools and authority, then check every done
condition. If any item remains, report every remaining item at once, with what
is left for the user and its done condition, and stop without changing source.
Resume when the user says they are done and every condition passes; ask the
user to confirm a condition only when you cannot observe it yourself. Never ask
for, accept in chat, or print a secret value: the user places it where the
product reads it, and you check the condition through its observable effect or
the user's confirmation. A `None.` section or a spec without the section needs
nothing here.

## Implement and reconcile one outcome

Map every acceptance criterion of the active outcome to at least one check: an
automated test, runtime evidence, or both. Behavior in the running product
still owes runtime evidence when a test also proves it. Hand the `tdd` skill
the active outcome, the criteria to prove by automated tests, the active
task's constraints and approved references, and `spec.md` as design context;
the handoff does not authorize later or blocked outcomes. `tdd` selects the
public test seams and hands back the code change, each new test tied to its
criterion or named reason with the failing assertion it was seen to produce,
and any handed criterion it could not prove automatically with the reason.
Cover those through runtime evidence or keep them incomplete.
Resolve technical uncertainty through repository evidence;
ask the user only when expected behavior remains unclear or proceeding would
change the agreed product contract.

From toy-crane/skills, MIT.

More from toy-crane/skills