Taskforge implement

Skill hashirventhodi/taskforge-skills/taskforge-implement

Implement a taskforge task against its active Specification and emit only the implementation — the build half of the split run workflow (docs/ADR-0001 Phase 6). Use when a task's readiness is "run" (ready to build). Produces one implementation artifact; it does NOT review its own work — an independent taskforge-review follows. Escalates upstream defects (spec unimplementable, approach wrong, spec premise provably false) instead of pushing through. Tasks without an active specification route to taskforge-refine.From its SKILL.md

Install

npx -y skills add hashirventhodi/taskforge-skills --skill taskforge-implement

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.6 KB, 465 tokens by cl100k_base, as published. Nobody here has run it

taskforge-implement

Build the active Specification and hand the diff off for independent review. Implement owns exactly one responsibility: turn the spec into an implementation. It never reviews its own work (that is taskforge-review, reached because the kernel derives review readiness from an implementation awaiting review) and it never declares the task done.

Prerequisites: read taskforge/CONTRACTS.md this session; resolve $SCRIPT; guard on readiness (run required — an active spec, no unreviewed implementation).

1. The spec is the contract

python3 $SCRIPT show <id>. The active specification is what you implement. Spec vs description conflict → the spec wins; note it in your report. Record the spec's version; cite it in the artifact.

2. Implement

Work on the task's delivery line (branch per DESIGN §10.19). Run the tests. Scope discipline is binding — adjacent problems become follow_up entries, never extra diff.

Upstream discoveries end the attempt — don't push through a broken contract:

spec ambiguous/contradictory/unimplementable → signal: escalate_refine;
the spec's factual premise is provably false and you have a reproduction → signal: spec_invalidated, signal_reason the claim, plus invalidation {reproduction, observed} (the kernel verifies before routing to refine);
the approach itself cannot work → signal: escalate_explore;
blocked on something only a human can resolve → signal: block_on_human.

3. Emit

Emit one implementation artifact (summary, diff_ref, test_results) with signal: none and a fresh result_id; validate then apply with --actor implement. The kernel derives review readiness — stop; the review is a separate, independent step. Report per references/reporting.md.

Quality bar

One implementation artifact; no review artifact, no done signal.
The diff contains nothing the spec didn't ask for.
Upstream defects escalate; they are never worked around.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.