task_implement

task_implement

<task_implement_skill>

<when_to_activate> Activate when the user points at one task in tasks/ and wants it built now:

• "Implement this task" / "implement <task-file>."
• "Do task X" / "build the thing described in <task>" / "make task Y happen."

Route elsewhere when the user wants to create a task (task_create or the base task skill), assess a task's readiness before building (task_check), automatically repair readiness issues before building (task_auto_check), choose what to work on next (task_select), verify a believed-done task against the codebase (task_audit), or close and archive a task (task_finish). </when_to_activate>

<path_resolution> The bundled scripts (discover_tasks.sh, lint.py) ship in scripts/ next to the base task skill's SKILL.md, not next to this one. After reading that base SKILL.md (per <authority>), resolve each script's absolute path by combining the directory you loaded it from with scripts/<script-name> and invoke that absolute path, never a bare scripts/..., which resolves against the current working directory (the target project) rather than the skill, and so finds the project's own scripts/ or nothing. If the first invocation reports a missing file, re-resolve the absolute path once before treating the script as failed. </path_resolution>

1. Read the task end-to-end. Read its status first. The base skill's <lifecycle_responsibility> ready-before-build rule is the admission criterion: proceed when status is ready, or when status is implemented and named gaps from a prior task_audit report are in context or supplied by the user. Stop before any edit when status is open or checked: name the status, point to task_check / task_auto_check, and change nothing. Stop before any edit when status is implemented and no such named gaps are in context or supplied: name the status, route per task_audit (repair via task_implement only with those named gaps; other routing as the base <status_discipline> follow-up rule directs), and change nothing. A task at audited, or archived as finished or deferred, is past implementation, and the base skill's <backward_move_guard> refuses an implemented stamp over it, so stop before any edit and name the status. Route a suspected gap on an audited task to task_audit, whose re-audit re-opens the task to implemented when it confirms the gap, and route other new work as the base <status_discipline> follow-up rule directs. Then understand the desired behaviour, the ## Approach, the context pointers, and the scope and any Out of scope block. The base skill writes each task to be self-sufficient. The file on its own is enough to implement, and you draw on everything actually available alongside it: the codebase, the project's standing instructions, the user. Treat the file as that contract, and restate your understanding before writing any code.
2. Check task dependencies before building. Before loading the guardrails or reading the codebase, apply the base task skill's <dependency_signals> taxonomy to the task at hand in both directions: the outbound signals in its own body, and the inbound ordering declarations authored in other live eligible tasks that point at it, meaning a live task whose body names a first-ship order over it or forward-references an artefact it creates. Count only the live eligible prerequisites the taxonomy's prerequisite rule defines; this step makes no code edit and no status change while it runs. When the task has one or more hard prerequisites, list them in dependency order (a prerequisite's own live prerequisites named first), give the evidence for each (the signal, and the task file it came from), surface any soft companion relationships alongside without letting them force the stop, ask whether the task at hand should really be built ahead of its prerequisites, and stop with no code edit and no status change until the user answers. Surface a dependency cycle plainly rather than looping on it. On the user's explicit go-ahead, continue into the rest of the workflow; when the gate finds no live prerequisites, continue without interrupting the user.
3. Load the guardrails. Read the governing CLAUDE.md files (repo root, this repo, and the one nearest the work) and hold their conventions as defaults for every edit (pseudo-XML and positive-language authoring, the Make + shell + markdown toolchain, snake_case naming, deployment-agnostic cross-references, and the versioning / plugin-lockstep rules), together with any constraint the task's own ## Approach states.
4. Understand the existing codebase, and confirm the work isn't already done. Read the code and tests already in place around the work, and extend the patterns, conventions, and architecture in use rather than inventing a new shape. Before writing anything, check the current state of the target: whether the artifact already exists, and whether the behaviour (or part of it) is already present. Build on or correct what is there instead of re-implementing it or clobbering it.
5. Implement in order. ## Approach is the plan, the codebase is ground truth. Follow the ## Approach step by step, building everything in scope and skipping everything the task marks out of scope, and name every artifact after the behaviour it delivers. When delivering the Goal or an ## Acceptance item would require crossing a declared Out of scope boundary, quote the conflicting passages, apply the base skill's Decide or label reconcile-or-surface disposition, and hold. Never silently cross the boundary and never silently under-deliver. Where a step's mechanics conflict with what the repo actually requires, do what the codebase requires and report the deviation rather than following the brief literally. When the task leaves a decision open, apply the base skill's Decide or label reconciliation rule against its evidence base (here including the fully real codebase), and when that evidence settles the decision, proceed on the reconciled path and record the rationale in the shipped artifact (a code comment, the SKILL.md body, a doc), not only in chat; when the evidence leaves it unsettled, surface the decision to the user with its options and at least one suggested path and hold, rather than making an arbitrary call. When the work lands, assess whether the delivered change extended the system's design using the base <archive> trigger test, then record the verdict explicitly as design-extended: true or design-extended: false in frontmatter, in the same stamp pass as status: implemented and implemented-by. Write it on every stamp rather than leaving a false verdict implicit: the base <frontmatter> entry makes an absent field read as false so tasks predating the field stay clean, and a stamp that states its verdict shows the assessment happened. Report the assessment either way. This detection-and-recording mandate is independent of the separate docs update step, and it supplies the close-out signal without requiring task_finish to re-derive a code-level judgement. Honor the base skill's <backward_move_guard>, stamp status: implemented, write implemented-by resolved via <user_name_chain>, and bump updated.
6. Build the tests. When TESTING.md exists at the project root, read it for project-specific testing details (stack, runner, layout, thresholds) before choosing the test shape. When it is absent, continue with the repo and task context already loaded. Map every ## Acceptance check that implies a test to a real test, aligning its level, framework, and structure with the repo's testing conventions (for this repo, the tests/<skill>/ Pattern A layout). Tests are required deliverables. A missing test for a stated acceptance check is a gap, not a pass.
7. Cross-check, then run the verifications the acceptance names. Walk every ## Acceptance item and confirm the implementation covers it; resolve any gap before proceeding. Run every verification the task and repo name (make lint, the relevant bundled lint.py, the matching tests/<skill>/script_tests, and any acceptance-named check such as a deploy dry-run) each once per the base <verification_economy> rule, naming the run every "done" conclusion relies on. Fix every failure your change introduces. Report a pre-existing failure that is unrelated to this task as such and keep it out of scope, and report the suite's actual state, naming any part still red rather than implying a clean run.
8. Update docs and versions. Update whatever documentation the task names, and apply the repo's one-bump-per-commit version and plugin-lockstep rules for any skill or plugin artifact touched.