@brainervirus/workit-claude-code 4.0.0 → 5.0.0

package/skills/verify-app/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: verify-app
+description: Generate or maintain the project's own verify-<app> skill that launches, drives and observes the real app (CLI, web, API) so agents prove features work. Use for verify the app, run it, smoke test, prove it works, set up verification.
+---
+
+# Generate a verify-<app> skill
+
+Tests show branch behavior. A verifier also needs to drive the real thing, the
+way a user would. This skill writes a project-local `verify-<app>` skill that
+says exactly how, then proves it once.
+
+## Generate
+
+0. **Reuse first.** If any `verify-*` skill already exists in the repo's skills
+   directories, never overwrite it: go to Maintain.
+1. **Inspect the surface.** package.json scripts and `bin`, Makefile or
+   justfile, Dockerfile and compose files, framework config, existing e2e
+   (Playwright, Cypress), the README's run section, `.env.example`. Classify:
+   CLI, web UI, HTTP API, library, or several.
+2. **Write the skill** from `references/template.md` in the directory where
+   this host reads project skills (Claude Code `.claude/skills/`, Cursor
+   `.cursor/skills/`; other hosts: the directory their docs name). If the repo
+   already has a project skills directory, use it:
+   - **Launch:** one command, its ready signal (log line, port, exit 0), a timeout.
+   - **Doctor:** each precondition and its fix (deps, env vars, ports, services).
+   - **Drive:** how to exercise it: CLI invocations, `curl` against routes, a
+     browser tool for UI, with fixture data.
+   - **Evidence:** what to capture (exit code, response body, screenshot path)
+     and the command that records it.
+   - **Cleanup:** stop processes, remove temp data.
+   - **Feature map:** feature, how to drive it, expected observation.
+3. **Prove it end-to-end once:** launch, drive one feature, capture evidence,
+   clean up. Fix the skill until that run is clean. A generated skill that was
+   never run is a guess; do not hand it off.
+4. **Make the driver a named check** when it is cheap and deterministic. A
+   named check is one command without shell syntax (put pipes and setup in a
+   script). Add `"verify": "<driver>"` to `checks` in `workit.checks.json`; if
+   the file does not exist yet, first copy in every check the repo already runs
+   (test, lint, typecheck), because the file replaces the detected defaults.
+   `workit check verify` then records it, and it joins the verification gate
+   unless `gates.verification` names the checks explicitly. Until then,
+   `workit check --name verify-<app> -- <driver>` is ad-hoc: evidence for a
+   verdict, never a gate.
+
+## Maintain
+
+When scripts, ports, routes or features change, or a verifier reports a wrong
+step: re-inspect, edit only that skill's directory, re-run the proof, and
+report `clean`, `changed` (what) or `blocked` (why).
+
+## Example
+
+Bad: "Verify by running the tests." (that is not the real surface)
+
+Good: "Launch `bun run dev` (ready: `listening on :5173`, 30 s). Drive:
+`curl -s localhost:5173/api/health` returns `{"ok":true}`. Evidence:
+`workit check --name verify-web -- bun scripts/smoke.ts` exit 0."
+
+## Check
+
+```sh
+workit check verify   # or: workit check --name verify-<app> -- <driver>
+```

package/skills/verify-app/references/template.md

@@ -0,0 +1,49 @@
+# verify-<app> skill template
+
+Copy into `<skills-dir>/verify-<app>/SKILL.md` and fill every section from what
+you observed in the repo. Delete a section only when it cannot apply (a
+library has no Launch) and say so in one line.
+
+```md
+---
+name: verify-<app>
+description: Launch, drive and observe <app> on its real surface (<cli|web|api>) to prove a feature works. Use to verify a change or reproduce a bug on the running <app>.
+---
+
+# Verify <app>
+
+## Launch
+`<command>` - ready when `<log line | port open | exit 0>`, timeout <n> s.
+
+## Doctor
+| Precondition | Check | Fix |
+| --- | --- | --- |
+| deps installed | `<cmd>` | `<cmd>` |
+| <ENV_VAR> set | `test -n "$<ENV_VAR>"` | copy from `.env.example` |
+| port <n> free | `<cmd>` | `<cmd>` |
+
+## Drive
+- CLI: `<binary> <args>` against `<fixture>`
+- API: `curl -sS -X <METHOD> localhost:<port>/<route> -d '<body>'`
+- UI: open `<url>`, <steps>, using the host's browser tool
+
+## Evidence
+`workit check --name verify-<app> -- <driver command>` records exit code and log.
+Screenshots go to `<tmp dir>/verify-<app>/<feature>.png`; cite the path.
+
+## Cleanup
+`<command>` (stop servers, remove `<tmp dir>`).
+
+## Feature map
+| Feature | Drive | Expect |
+| --- | --- | --- |
+| <feature> | `<command or steps>` | `<observable result>` |
+```
+
+## Rules for the generated skill
+
+- Every command is copy-pasteable and was run once while generating.
+- Ready signals and expectations are literal (a string, a status code, a
+  count), never "works" or "looks right".
+- Keep it under ~80 lines; move long fixtures into the skill's own directory.
+- Maintenance edits only this directory.

package/assets/templates/execution-contract.md

@@ -1,40 +0,0 @@
-Load resolved method skills through the host skill loader when policy selects them. Implement the existing plan; do not re-plan.
-
-**Spec:** <SPEC_PATH>
-**Plan:** <PLAN_PATH>
-**Branch:** <BRANCH>
-
-## Hard gates
-
-- Inspect task state before acting. On OpenCode, Cursor, Codex, and Pi use the eight shared `workit_*` families (`workit_task`, `workit_policy`, `workit_evidence`, `workit_finding`, `workit_decision`, `workit_worker`, `workit_writer`, `workit_state`). On the CLI host use `workit <family> <action>` with the same actions (hyphenated on the CLI).
-- Never use a worktree. Branch changes are in-place through the approved `git.branch_setup` external action (CLI: `workit action git.branch_setup --payload …`).
-- Task metadata lives under `.workit/`; never edit it directly. Record progress, evidence, findings, decisions, and worker state only through the shared operations.
-- Helpers cannot widen scope, record binding decisions, close or pause the task, assign further helpers, or resolve blockers for the lead.
-- On Cursor, pass the active workspace as `workspace_root` on every repository-scoped call.
-
-## Setup
-
-1. If there is no active or paused task, call `workit_task` with `action: "start"` then `workit_policy` with `action: "assess"` (CLI: `workit task start …` then `workit policy assess …`).
-2. Load `workit-plan`, list tasks with `workit_task` `action: "list"`, and mirror visible todo state to the host UI.
-3. When policy requires a feature branch, resolve it with read-only `context.read` and apply `git.branch_setup` only after native approval.
-
-## Remaining-task loop
-
-For each bounded plan task:
-
-1. Mark the item in progress in the host todo UI and record boundary progress with `workit_task` `action: "progress"`.
-2. Route by policy: assign bounded workers with `workit_worker` `action: "assign"` when delegation is available; otherwise implement inline. Acquire product-write ownership with `workit_writer` `action: "acquire"` before repository mutations; release it when done.
-3. Record checks and artifacts with `workit_evidence` `action: "record"`. Record review concerns with `workit_finding` `action: "record"`; resolve or defer them with `finding.resolve`. Blocking findings may trigger at most **two** fix+re-review rounds per task; advisory taste/YAGNI items still use `finding.record` and never pause the loop by direct file edit.
-4. Never advance while a foreign writer is active or blocking findings remain open for the current candidate.
-
-## Final gate
-
-Run repository verification (CLI: `workit doctor`; hosts: approved project verify when policy requires it). **Mandatory:** close the lead task with `workit_task` `action: "close"` (CLI: `workit task close --payload … [--confirm]`) once requirements are satisfied and verification passes — never finish while the task is still `active` or `paused`.
-
-## Task order
-
-<TASK_LIST>
-
-## Quality gate
-
-- Specs/plans follow `templates/spec-template.md` / `templates/plan-template.md`.

package/skills/babysit/SKILL.md

@@ -1,46 +0,0 @@
----
-name: babysit
-description: Use when the user asks to babysit a PR or explicitly opts in to PR follow-up
----
-
-# Babysit a PR to PR-ready
-
-PR creation does not start babysitting. `babysit:true` opts into this skill;
-omission means no follow-up. A PR URL by itself is not an instruction to drive
-it. When the user asks to babysit a URL from a route Workit did not enforce,
-help without claiming the Workit route was enforced. Never mutate PR topology
-(no rebase strategy changes, no force-push).
-
-
-## Method
-
-1. Default to drive mode for an explicit babysit request: resolve conflicts,
-   address review threads, and get checks green. Watch reports status only;
-   threads-only addresses review threads. Ask about mode only when the choice
-   materially changes the work.
-2. Work toward PR-ready in order: conflicts → review threads → CI. Keep a brief
-   checkpoint when continuity needs it; task progress is optional.
-3. Classify CI before retry: flake (rerun once) vs stale base (verify with
-   `git merge-base --is-ancestor` before updating) vs real failure (fix).
-4. Triage bot findings skeptically: reproduce or quote code before acting;
-   invalid bots get a reasoned dismissal, never silent ignore.
-5. Batch fixes into one push wave; re-verify green after every push.
-6. Stop at PR-ready. A PR creation or babysit request does not authorize merge
-   or release. Continue to merge or release only when the user explicitly sets
-   that delivery endpoint and host authority allows the action.
-
-## Completion
-
-Report PR-ready status with evidence for fixes, or a brief blocker report. If
-the user explicitly authorized merge, honor the configured strategy only after
-checks and required approval. After a squash merge, re-record evidence against
-the new base commit before closing tracked work.
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/behavioral-tdd/SKILL.md

@@ -1,65 +0,0 @@
----
-name: behavioral-tdd
-description: Use when policy identifies behavior, side effects, permissions, or data handling that may change and a regression boundary is needed
----
-
-# Behavioral TDD
-
-Test the observable behavior at a stable boundary, not the implementation shape.
-Use this method when assessment selects the `testing` dimension.
-
-
-## Method
-
-1. Inspect the task requirement, current candidate, intended behavior, and real
-   verification entry point with shared `task`, `policy`, and `evidence` operations.
-2. State one behavior and its observable result. Choose the narrowest stable
-   boundary a caller or user depends on; avoid private helpers and incidental
-   representations.
-3. Write one vertical RED slice that fails for the missing behavior and run it
-   through the CLI so the failure is observed: `workit check test` (the repo's
-   configured `test` check; `npx -y @brainervirus/workit-cli check test` when
-   `workit` is not on PATH). Implement the smallest change, then run the same
-   check GREEN. Close accepts only a fresh passing run of the configured check
-   that `workit check` observed; a recorded "tests pass" is a note, and an
-   ad-hoc `workit check -- <cmd>` never satisfies the gate. If no `test` check
-   is configured or detected, add `workit.checks.json` (committed) with it.
-4. Add only another slice for a distinct behavior or risk. Any edit makes the
-   observed check stale: re-run `workit check test` before closing.
-
-## Reject noisy tests
-
-- A dependency/version-pin assertion is not behavioral evidence.
-- A test that mirrors branches, private calls, or exact implementation structure
-  is coupled to internals; replace it with the public effect.
-- Duplicate assertions and tests that add no distinct failure signal are noise;
-  delete them.
-- Do not claim a passing test satisfies a different requirement.
-- Banned: tautologies (asserts what the code says, not what it must do),
-  ghost loops (assert inside a possibly-empty loop), smoke-only renders,
-  type-only or CSS-class coupling. If the test still passes when every
-  imported function returns undefined, rewrite the assertion or delete it.
-  `workit test-audit --diff` flags these; triage them with workit-test-audit.
-  Turning acceptance criteria into scenarios and seams is workit-bdd.
-
-Run RED/GREEN through `workit check`, which records the observed result on the
-current task; shared `evidence` operations are for notes and non-test evidence.
-Do not add a second lifecycle, approval chain, or test workflow outside the
-current task state.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| "The pin changed, so assert the new string" | Exercise the affected consumer behavior. |
-| "The code is obvious" | A small vertical slice still proves the contract. |
-| Keeping a passing test after the boundary moved | Re-run `workit check test` on the current tree. |
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/blast-radius/SKILL.md

@@ -1,35 +0,0 @@
----
-name: blast-radius
-description: Use when a small-looking change could break something else, before close or merge
----
-
-# Blast radius beyond the diff
-
-A small diff is not a small risk. Prove the one fact it is safe because of,
-with runnable proof — not assertion.
-
-
-## Method
-
-1. List what the change touches: callers, shared state, contracts, config,
-   migrations. Grep every caller of each touched function.
-2. For each: state the one fact it is safe because of (type boundary,
-   existing test, unreachable path) plus how to run the proof.
-3. Run the proofs. Unproven claims stay labeled UNPROVEN in findings —
-   never silently treated as safe.
-4. Fix at the shared root (one guard where all callers route through),
-   not per caller.
-
-## Completion
-
-Blast-radius note in evidence or review: each risk with fact + proof
-command, or an UNPROVEN finding for what could not be proven.
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/challenge/SKILL.md

@@ -1,56 +0,0 @@
----
-name: challenge
-description: Use when requirements or consequences leave a real decision open
----
-
-# Challenge open choices with evidence
-
-Skip this method for a precise, settled request.
-
-## Method
-
-1. Ground the outcome, constraints, evidence, and important unknowns. Inspect
-   code and project docs before asking about facts they can answer.
-2. Separate observations, inferences, and proposals. Test assumptions that
-   could change the recommendation.
-3. When viable alternatives exist, present two or three genuinely different
-   approaches. Recommend one; for each, give its benefit, cost or risk, when it
-   fits, and the smallest useful validation. Do not invent a weak alternative.
-4. Ask only consequential questions, in dependency order. Group independent
-   choices into one small round. If an authorized reversible default works,
-   state it and proceed.
-5. Record a settled choice once in the existing conversation or task context.
-   A discussion decision is knowledge; never fabricate a native permission
-   receipt or reopen it without new evidence.
-6. Create durable documentation only when requested or when the decision needs
-   a future reader. Brainstorming alone does not require a spec.
-
-Say directly when evidence shows a proposal is weak, overcomplicated, or solves
-the wrong problem. Raise a counter-case only when it adds a real constraint.
-
-## Guardrails
-
-- Do not create a universal spec, plan, approval chain, or second lifecycle.
-- Unknowns that affect an action remain unresolved until evidence or a user
-  decision closes them.
-- Use shared operations for tracked state and provenance; never write task
-  metadata directly.
-- An in-session counter-case is not fresh-context review.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Asking what code or docs already answer | Ground first; the user owns choices, not lookups. |
-| Listing every hypothetical objection | Raise only objections that can change the decision. |
-| Asking for agreement without a recommendation | Recommend an option and explain the tradeoff. |
-| Treating a discussion decision as permission | Record it as knowledge; preserve native host authority. |
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/diagram/SKILL.md

@@ -1,36 +0,0 @@
----
-name: diagram
-description: Use when a spec or plan needs a flow or architecture diagram
----
-
-# Mermaid when needed, never by default
-
-Tables first, ASCII trees second, mermaid only when a flow or architecture
-needs it. Flowchart, sequence, state, or ER only. No renderer, no network.
-
-
-## Syntax rules (mermaid v11)
-
-- Fence as ` ```mermaid `, no surrounding prose inside the fence.
-- Quote node labels containing punctuation: `A["input (x, y)"]`.
-- One direction per diagram (`TD` or `LR`); keep nodes under twelve.
-- Name actors exactly as the codebase names them (real symbols only).
-
-## Verify
-
-Re-read the fence before commit: balanced quotes/brackets, every node
-reachable, labels match spec terms. If it cannot be verified by reading,
-delete it.
-
-## Completion
-
-One diagram that argues a decision, or nothing. Never a diagram suite.
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/green-run/SKILL.md

@@ -1,33 +0,0 @@
----
-name: green-run
-description: Use to drive a red CI pipeline back to green, usually inside babysit
----
-
-# The CI loop
-
-Watch, classify, fix, push once, re-verify. Host-native (`gh` / GitLab);
-never invent CI APIs.
-
-
-## Method
-
-1. Read the failing checks, not the summary. Quote the failing log lines.
-2. Classify each: flake (rerun once, note it) / stale base (update after
-   merge-base check) / real failure (reproduce locally, then fix).
-3. Fix at root cause with a regression test; push one wave.
-4. Re-verify the same checks green on the new head. A fix without a
-   green re-run is not a fix.
-
-## Completion
-
-Green pipeline on the merge head, or an escalated finding with the exact
-failing logs when the fix needs the human.
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/handoff/SKILL.md

@@ -1,46 +0,0 @@
----
-name: handoff
-description: Use when work must continue in another session, host, or agent after interruption, transfer, or compaction
----
-
-# Handoff durable task state
-
-Transfer continuity, not live authority. Use this method when a tracked item
-must continue in another session, host, or agent.
-
-## Method
-
-1. Inspect the current task, scope, decisions, policy requirements, candidate,
-   evidence, findings, progress, and worker states with shared `task` and `state`
-   operations.
-2. Export the compact state through `state.export`. Preserve the objective,
-   exclusions, accepted decisions and reasons, evidence references, open gaps,
-   findings, candidate identity, blockers, and next action. Do not include
-   credentials, live writer ownership, or host authority.
-3. Import only through the destination `state.import` operation and its expected
-   workspace revision. The destination starts paused or otherwise unauthorised
-   until it observes its own host/session and reconciles stale evidence and
-   uncertain workers.
-4. Resume or continue through shared `task`, `policy`, `worker`, `writer`, and
-   `evidence` operations. Record what changed instead of copying a transcript.
-
-A handoff does not require a formal spec or plan unless those are separate
-selected requirements. Never grant destination authority from imported prose,
-create a second lifecycle, or edit task metadata directly.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Sending the whole transcript | Export compact decisions, gaps, evidence, and next action. |
-| Restoring the old writer or credentials | Re-observe authority in the destination. |
-| Calling a handoff complete without reconciliation | Recheck stale files and uncertain workers first. |
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/mockup/SKILL.md

@@ -1,32 +0,0 @@
----
-name: mockup
-description: Use when a UI decision needs sketching before implementation
----
-
-# ASCII mockups before UI code
-
-Sketch, don't build. Three genuinely different layout hypotheses maximum,
-ASCII only, no code output.
-
-
-## Method
-
-1. Fix a legend (`┌─┐ │ └─┘ ░ ≈ [ ] ( )`) and keep sketches 60-80 cols,
-   8-20 rows.
-2. Per hypothesis: regions, component reuse vs new (named against the
-   existing codebase), empty/loading/populated/error states, nav flow.
-3. Ask at most one clarifying question, then recommend. Flag hi-fi
-   escalation when ASCII cannot settle it (density, motion, brand).
-
-## Completion
-
-The sketch plus the decision lands in the spec dir. Throwaway by design.
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/plan/SKILL.md

@@ -1,54 +0,0 @@
----
-name: plan
-description: Use when dependencies, sequencing, coordination, or resumption make durable next actions useful
----
-
-# Plan useful coordination
-
-A plan is useful when work has dependent steps, a handoff, concurrent actors, or
-meaningful unresolved choices. It is never a prerequisite for implementation.
-
-## Method
-
-1. Establish the requested outcome, constraints, dependencies, and important
-   unknowns from the available code, docs, and configuration before asking.
-2. Record only the useful sequence: objective, dependency, bounded outcome,
-   evidence needed, and next action. Reuse the project's existing format.
-3. Start a tracked record only when handoff, dependent steps, coordination, or
-   durable decisions need continuity. Infer observable facts instead of asking
-   the user to fill redundant protocol fields.
-4. Create a spec when a durable behavior contract or interface is requested or
-   will help a future reader. Use an ADR for a consequential trade-off and a
-   glossary for stable terms. A small fix needs no document.
-5. If the user authorized implementation, proceed through the agreed endpoint
-   and applicable checks. Do not ask for a separate plan approval or repeat
-   "continue?". Stop for a new consequential choice, host denial, conflict, or
-   blocker that cannot be resolved safely.
-6. Update a checkpoint at meaningful boundaries when another session may need
-   to resume. Keep settled decisions, changed files, actual checks, blockers,
-   and the next action; omit transcript and process trivia.
-
-## Shape
-
-Plan slices as small end-to-end outcomes with explicit dependencies and checks.
-Keep repo policy and native host authority separate. Preserve the user's branch
-and commit conventions. Do not prescribe one commit per step or create a second
-approval chain unless the user asked for that delivery format.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Writing a packet for a bounded reversible change | Leave the change undocumented. |
-| Asking what repository state or code can answer | Inspect it first. |
-| Treating the plan as authority | Follow the user's scope and native host permissions. |
-| Copying a transcript into the plan | Keep decisions, evidence, gaps, and next action only. |
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.

package/skills/steer/SKILL.md

@@ -1,48 +0,0 @@
----
-name: steer
-description: Use when new instructions, interruptions, or forgotten items change substantial ongoing work
----
-
-# Steer without forced lifecycle
-
-Classify new input as a quick question, a same-task adjustment, or a separate
-request. Preserve continuity when it helps; do not manufacture task mutations.
-
-## Method
-
-1. Answer a quick question from current context. Do not pause, resume, create,
-   assess, or close a task just to answer it.
-2. For a same-task adjustment, update only affected constraints and next actions.
-   Keep an existing checkpoint when it helps; reassess policy only when evidence
-   or constraints changed enough to affect a rule.
-3. For a separate request, do not silently resume an old objective. Park a
-   concise checkpoint only when substantial work needs to continue later. Start
-   a distinct tracked record only if the new work benefits from continuity,
-   dependencies, coordination, or durable decisions. For work spanning repos,
-   checkpoint each unfinished item with its checkout, branch, requested
-   deliverables, and delivery endpoint. Keep explicitly held items parked with
-   their resume condition until the user resumes them. A conversational
-   checkpoint is sufficient when no task record is needed.
-4. Before resuming a named tracked task, reconcile its checkout, branch, dirty
-   state, current policy, stale evidence, uncertain effects, and ownership. Do
-   not change branches, stash, fetch large histories, or seize ownership just
-   to display a history choice.
-5. Continue to the user's authorized endpoint with applicable checks. Ask only
-   about consequential choices the code and available context cannot resolve.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Treating a quick question as interruption | Answer without changing task state. |
-| Auto-resuming an old objective | Wait for the user's direction to resume it. |
-| Rebuilding continuity from a transcript | Keep a compact checkpoint with evidence and next action. |
-
-
-## In Claude Code
-
-Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
-the `workit` CLI on the Bash tool: `workit <family> <action> --json`
-(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
-and `implementer` agents take independent verification, fresh-context
-review and isolated implementation.