@brainervirus/workit-claude-code 3.0.0 → 5.0.0

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.