Taskforge review

Skill hashirventhodi/taskforge-skills/taskforge-review

taskforge-skills — an Agent Skills framework for the durable-Task AI engineering workflow: skills reason, a deterministic engine is the only writer of task state

Install

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

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

2 things to look at

14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
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 author says it does

Copied from the file, not written here

Independently review a taskforge task's implementation against its Specification and emit only the verdict — the review half of the split run workflow (docs/ADR-0001 Phase 6). Use when a task's readiness is "review" (an implementation awaits review). Runs in fresh context against the recorded reviewer prompt; produces one review artifact (approved, or rejected with a root_cause). The KERNEL routes on the verdict (approved -> done, rejected -> refine/explore/retry) — the review never emits a done or escalate signal.

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, as published. Nobody here has run it

taskforge-review

Judge an implementation against its Specification, independently, and emit a verdict. Review owns exactly one responsibility: decide whether the diff satisfies the spec. It does not route the task — the kernel derives the next phase from the verdict (approved → done; rejected → refine/explore/retry by root_cause), exactly as it does for every other transition. So the review emits only the review artifact, never a done or escalate signal.

Prerequisites: read taskforge/CONTRACTS.md this session; resolve $SCRIPT; guard on readiness (review required — an implementation with no review at or after it).

1. Independent review — recorded, isolated, non-negotiable

Follow taskforge/references/reviewer-prompt.md exactly: build the prompt with build-review-prompt <id> --diff <diff> --results <results> (it renders the active spec verbatim and records it for audit-review); judge in a fresh context — no implementer narrative, plan, or chat history may enter. If no fresh context is available, stop and say so — a self-review is never recorded as a review.

2. Emit the verdict

Emit one review artifact with signal: none, a fresh result_id; validate then apply with --actor review:

every acceptance criterion in criteria_results, explicit pass/fail;
verdict: approved — the kernel completes the task (done);
verdict: rejected with root_cause:
- implementation → the kernel bounces it back to build (retry, budget- enforced); feed the findings forward;
- specification → the kernel routes to refine;
- architecture → the kernel routes to explore (and escalates a child's parent).

Record the verdict verbatim; disagree in the report, never in the record. Report per references/reporting.md; stop.

Quality bar

One review artifact; no done, no escalate signal — routing is the kernel's.
Recorded reviewer prompt passes audit-review (criteria verbatim; no implementation summary).
Every acceptance criterion appears in criteria_results with pass/fail.