WIP (Work In Progress)#

Track current session work as a checklist.

Topics#

TopicDescriptionGuideantigravitytask.md artifact-based checklist for Antigravity sessionsantigravity.mdclaudeTodoWrite/TaskCreate API for Claude Code sessionsclaude.mdresumeEnvironment-agnostic task cleanup + remaining-work workflowresume.md

Topic Dependencies#

text

wip (entry — /wip or "task cleanup + remaining work")
  └─→ resume (environment-agnostic workflow)
        ├─→ claude (Claude Code: TaskList/TaskCreate/TaskUpdate/AskUserQuestion)
        └─→ antigravity (Antigravity: task.md artifact + ask.md emulation)

• resume: workflow procedure (cleanup → per-item direction ask → execute). Environment-agnostic.
• claude / antigravity: per-environment tooling. Defines how resume Step 1–3 is implemented in each environment.

Purpose#

Record in-progress work via at least one of:

1. TodoWrite / TaskCreate — in-session tracking
2. checklist.md, fix_plan.md and similar markdown files — persists across sessions
3. Commit — preserve incomplete code with a WIP: tag for later amend/squash

Emitting only a text summary without persistent recording does not satisfy /wip.

When to Use#

• Starting a multi-step task (3+ steps)
• User gives a large task instruction
• Need to show progress to the user
• When you want to record/preserve the current state mid-session
• "task cleanup + remaining work", "task cleanup", "remaining work", "resume" invocations

/wip Entry Procedure (CRITICAL)#

Step 0 — args classification (HARD STOP, MANDATORY before Step 1)#

Before dispatching to any topic, classify the args intent. The /wip skill has two mutually-exclusive dispatch paths — resume workflow vs new-task registration — and the wrong choice wastes user time and misapplies the resume gate.

Read args + call TaskList (Claude Code) or read task.md (Antigravity). Then classify:

SignalModeDispatchargs contains new-work instructions (verbs like write / create / add / record / draft, referring to concrete deliverables), AND (existing tasks are 0 OR the new work is clearly independent)Registration modeRegister new tasks via TaskCreate (Claude) / append lines to task.md (Antigravity). Skip resume workflowargs empty, or contains cleanup/resume keywords only (cleanup / remaining / resume / continue), AND existing tasks ≥1Resume modeFollow 3 steps in resume.mdargs contains new-work instructions AND existing tasks ≥1 with unclear directionMixed mode(a) TaskCreate new work first, (b) then resume workflow on the combined listargs contains new-work instructions AND 0 existing tasksRegistration mode (0-task early exit)TaskCreate only. Do NOT enter resume Step 1 (nothing to clean)

Self-check (before proceeding) — answer all 5:

1. Did I read the args verbatim and identify verbs? (new-work verbs = registration; cleanup verbs = resume)
2. Did I call TaskList / read task.md to count existing tasks?
3. If 0 tasks and args has new-work verbs → am I about to call TaskCreate directly, not resume Step 1?
4. If mixed → am I calling TaskCreate first, then resume?
5. If I cannot classify with confidence → am I calling AskUserQuestion before dispatching?

Step 1 — Resume workflow (only in Resume mode or Mixed mode's second phase)#

Follow the 3 steps in resume.md in order:

1. Cleanup: immediately delete stale completed/in_progress entries (no user confirmation required)
2. Checklist state recovery (Step 1.5): for tasks whose state cannot be verified from the in-context conversation (post-compact / inherited items), Grep/Read fix_plan.md / checklist.md to recover their state before asking
3. Per-item direction ask: for each remaining item, decide proceed / split / merge / hold / defer-to-checklist / delete. defer-to-checklist follows todowrite's file medium convention ( fix_plan.md/ checklist.md) — write the deferred item there rather than leaving it as an orphaned session task
4. Start priority + execute: among items decided as "proceed", choose start priority, mark in_progress, and execute

Step 1 (alt) — Registration path (Registration mode)#

Register BEFORE execute (HARD STOP): TaskCreate must run before any deliverable work — no Read / Edit / Write / Bash on the target artifact until the task exists. "The edit is small / one file / ≤2 steps" is not an exception: an explicit /wip means the user asked for the work to be tracked first. Registering after the edit (or not at all) is the exact violation this path prevents. Reading a file solely to compose the task's registration is fine; editing/producing the deliverable before the task exists is not.

1. Parse args into discrete work items (one per deliverable)
2. TaskCreate (Claude) or append lines to task.md (Antigravity) — one entry per item — as the first execution tool call, before touching the deliverable
3. If ≥2 items, AskUserQuestion for start priority; else mark the sole item in_progress and execute

Don't / Do#

#Don'tDo1Enter resume Step 1 (Cleanup) blindly on every /wip invocationRun Step 0 classification first. 0-task + new-work args = skip resume, go to Registration path2Interpret "3 steps in resume.md must follow" as unconditionalThe 3-step chain applies only when Resume mode is selected (Step 0). Registration mode has its own 3-step path (parse → register → execute)3Force resume workflow onto args that request new deliverablesNew-work verbs → Registration mode. Resume workflow does not apply to work that does not exist yet4Skip TaskList before deciding modeTaskList is the primary source for existing-task count. Guessing from context memory is unreliable5Mixed mode: register new tasks + immediately mark in_progress without resume Step 2 direction ask on existingMixed mode: (a) register new, (b) then run resume on the combined list — old tasks may still need per-item direction6Treat an explicit /wip <small edit> as a Skip-Condition case and go straight to Read/ Edit of the deliverableExplicit /wip = registration requested. Run Step 0 → Registration/Resume path → TaskCreate first, then execute. Skip Conditions gate self-invocation, not explicit calls7Interrupt-stacked instructions arrive right after a registration-mode /wip (a newer directive: reword, investigate, etc.) → pivot to the newest instruction and never register the original /wip argsThe original /wip args still require TaskCreate first. Register them before pivoting to any interrupt-stacked instruction — including Bash investigation for the newer directive. The register-before-execute guard hook only covers the case where /wip is the last user turn; the interrupt-stacked case (a newer non- /wip turn follows) is caught only by this discipline

Environment implementations:

• Claude Code → claude.md (TaskList/TaskCreate/AskUserQuestion)
• Antigravity → antigravity.md (task.md + ask.md)

Prior violations: see ~/.claude/skills/cleanup/data/failed-attempts.md under keywords "wip resume dispatch", "wip cleanup skip", "wip registration vs resume".

Quick Reference#

Resume (environment-agnostic)#

/wip or "task cleanup + remaining work" → Step 1 cleanup → Step 1.5 checklist state recovery (context-opaque tasks) → Step 2 per-item direction ask → Step 3 execute. Per-environment tooling lives in claude / antigravity.

See detailed guide.

Claude#

Use TodoWrite for sequential steps, TaskCreate for parallel tasks with dependencies. After compact, restore prior work: show summary → multiSelect → re-register via TodoWrite.

See detailed guide.

Antigravity#

Use task.md artifact with standard markdown checkboxes ( - [ ], - [/], - [x]). Do NOT wrap checkboxes in backticks.

See detailed guide.

Skip Conditions#

Scope (HARD STOP) — these gate the auto-decision of whether to reach for /wip unprompted. They do NOT override an explicit /wip invocation. When the user explicitly types /wip (or "task cleanup / remaining work / register task"), registration is already requested → run Step 0 classification and the Registration/Resume path; do NOT skip TaskCreate because the work "looks trivial / is one file / is ≤2 steps". "Tasks with 2 or fewer steps" is a reason not to self-invoke /wip, never a reason to skip registration once /wip was invoked.

WIP tracking is unnecessary (do not self-invoke /wip) for:

• Single command execution (kubectl get, ls, etc.)
• Tasks with 2 or fewer steps
• Read-only queries
• User explicitly says "keep it simple"

Rules (Sequential Flow)#

• One in_progress at a time — applies to ordered/sequential tracking (TodoWrite/checklist mode)
• Update immediately on completion — mark completed as soon as done
• No skipping — proceed in order, don't start next step before completing current