← ClaudeAtlas

taskforge-refinelisted

The universal entry point of the taskforge workflow - assess whether a task is executable and produce its Specification, or route it. Use whenever the user says to refine, spec, scope, groom, or prepare a taskforge task, asks "what's next for TASK-x", or wants to move a new task forward - and whenever a task's readiness is "refine" (including after escalations or invalidation cascades). Four modes - adopt a well-written task nearly verbatim, elaborate an underspecified one, generate blocking clarification prerequisites, or escalate to taskforge-explore for an architectural decision.
hashirventhodi/taskforge-skills · ★ 0 · AI & Automation · score 75
Install: claude install-skill hashirventhodi/taskforge-skills
# taskforge-refine Answer one question — **is this task executable?** — and let the answer route. Refine produces Specifications; it never makes architectural decisions and never implements. **Prerequisites**: read `taskforge/CONTRACTS.md` this session; resolve `$SCRIPT`; guard on readiness (`refine` required — otherwise report actual state and the right skill; ask before re-refining a `run`-ready task). ## 1. Gather binding context `python3 $SCRIPT show <id>`: * The immutable `description` is the ground truth of what was asked. * `decision_ref` set → read that pinned version on the parent (`show <parent-id>`). It is **binding**: specify within it; do not re-open it; do not escalate for a decision that exists. Same for an active local decision. * Escalated back from run? The superseded spec's `superseded_reason` and the rejected review's `findings` are your work order — a re-refined spec that doesn't visibly address them will bounce again. ## 2. Choose a mode — first match wins **ADOPT** — could run start from the description as-is, without one question? Then the spec *is* the description, minimally restructured: `scope` close to original wording; `acceptance_criteria` extracted (or minimally inferred), not invented; `adopted_from_source: true`. **Over-elaborating a good task is a failure mode, not diligence.** If your spec is much longer than a well-written description, you are doing it wrong: no added constraints, edge cases, or unrequested "improvements".