@brainervirus/workit-codex 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,28 @@
1
+ {
2
+ "hooks": {
3
+ "SessionStart": [
4
+ {
5
+ "matcher": "*",
6
+ "hooks": [{ "type": "command", "command": "node ${PLUGIN_ROOT}/dist/workit-hook.js" }]
7
+ }
8
+ ],
9
+ "PreToolUse": [
10
+ {
11
+ "matcher": "*",
12
+ "hooks": [{ "type": "command", "command": "node ${PLUGIN_ROOT}/dist/workit-hook.js" }]
13
+ }
14
+ ],
15
+ "SubagentStart": [
16
+ {
17
+ "matcher": "*",
18
+ "hooks": [{ "type": "command", "command": "node ${PLUGIN_ROOT}/dist/workit-hook.js" }]
19
+ }
20
+ ],
21
+ "SubagentStop": [
22
+ {
23
+ "matcher": "*",
24
+ "hooks": [{ "type": "command", "command": "node ${PLUGIN_ROOT}/dist/workit-hook.js" }]
25
+ }
26
+ ]
27
+ }
28
+ }
package/package.json ADDED
@@ -0,0 +1,43 @@
1
+ {
2
+ "name": "@brainervirus/workit-codex",
3
+ "version": "1.0.0",
4
+ "private": false,
5
+ "description": "Workit Codex CLI and desktop plugin",
6
+ "keywords": [
7
+ "agent",
8
+ "codex",
9
+ "mcp",
10
+ "workflow"
11
+ ],
12
+ "license": "MIT",
13
+ "repository": {
14
+ "type": "git",
15
+ "url": "https://github.com/BrainerVirus/workit.git"
16
+ },
17
+ "bin": {
18
+ "workit-codex-hook": "./dist/workit-hook.js",
19
+ "workit-codex-mcp": "./dist/launch-mcp.js"
20
+ },
21
+ "files": [
22
+ "dist/",
23
+ ".codex-plugin/",
24
+ ".mcp.json",
25
+ "hooks/hooks.json",
26
+ "skills/"
27
+ ],
28
+ "type": "module",
29
+ "main": "./dist/launch-mcp.js",
30
+ "publishConfig": {
31
+ "access": "public"
32
+ },
33
+ "scripts": {
34
+ "build": "bun scripts/build.ts"
35
+ },
36
+ "dependencies": {
37
+ "@brainervirus/workit-core": "^1.0.0",
38
+ "@brainervirus/workit-mcp": "^1.0.0"
39
+ },
40
+ "engines": {
41
+ "node": ">=24"
42
+ }
43
+ }
@@ -0,0 +1,33 @@
1
+ ---
2
+ name: workit-babysit
3
+ description: Use when a PR needs driving to merge-ready, CI is red, or the user says babysit
4
+ ---
5
+
6
+ # Babysit a PR to merge-ready
7
+
8
+ Babysit starts automatically on PR creation unless declined (`--no-babysit`).
9
+ One babysitter per PR; never mutate PR topology (no rebase strategy changes,
10
+ no force-push).
11
+
12
+ ## Before method work
13
+
14
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
15
+ before relying on selected policy rules or other product mutations. Assessment
16
+ selects requirements; do not wait for a rule that can only exist after assess.
17
+
18
+ ## Method
19
+
20
+ 1. Declare mode: drive (fix + merge), watch (report only), or threads-only.
21
+ 2. Work the merge frontier in order: conflicts → review threads → CI.
22
+ 3. Classify CI before retry: flake (rerun once) vs stale base (verify with
23
+ `git merge-base --is-ancestor` before updating) vs real failure (fix).
24
+ 4. Triage bot findings skeptically: reproduce or quote code before acting;
25
+ invalid bots get a reasoned dismissal, never silent ignore.
26
+ 5. Batch fixes into one push wave; re-verify green after every push.
27
+ 6. Merge only when green and approved, honoring `pr` settings (squash +
28
+ delete branch). Stop at the human's line: never merge on explicit hold.
29
+
30
+ ## Completion
31
+
32
+ PR merged per settings, or a status brief (frontier state, next action) when
33
+ blocked on the human. Record evidence for fixes, findings for blockers.
@@ -0,0 +1,53 @@
1
+ ---
2
+ name: workit-behavioral-tdd
3
+ description: Use when policy identifies behavior, side effects, permissions, or data handling that may change and a regression boundary is needed
4
+ ---
5
+
6
+ # Behavioral TDD
7
+
8
+ Test the observable behavior at a stable boundary, not the implementation shape.
9
+ Use this method when assessment selects the `testing` dimension.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Inspect the task requirement, current candidate, intended behavior, and real
20
+ verification entry point with shared `task`, `policy`, and `evidence` operations.
21
+ 2. State one behavior and its observable result. Choose the narrowest stable
22
+ boundary a caller or user depends on; avoid private helpers and incidental
23
+ representations.
24
+ 3. Write one vertical RED slice that fails for the missing behavior, run it, and
25
+ preserve the actual failure as evidence. Implement the smallest change, then
26
+ run the same slice GREEN and record its result. Close enforces the order: a
27
+ testing requirement with GREEN but no preceding RED evidence stays unsatisfied.
28
+ 4. Add only another slice for a distinct behavior or risk. Reconcile stale
29
+ evidence if the candidate changes.
30
+
31
+ ## Reject noisy tests
32
+
33
+ - A dependency/version-pin assertion is not behavioral evidence.
34
+ - A test that mirrors branches, private calls, or exact implementation structure
35
+ is coupled to internals; replace it with the public effect.
36
+ - Duplicate assertions and tests that add no distinct failure signal are noise;
37
+ delete them.
38
+ - Do not claim a passing test satisfies a different requirement.
39
+ - Banned: tautologies (asserts what the code says, not what it must do),
40
+ ghost loops (assert inside a possibly-empty loop), smoke-only renders,
41
+ type-only or CSS-class coupling. If the test still passes when every
42
+ imported function returns undefined, rewrite the assertion or delete it.
43
+
44
+ Use shared `evidence` operations for RED/GREEN results. Do not add a second
45
+ lifecycle, approval chain, or test workflow outside the current task state.
46
+
47
+ ## Common mistakes
48
+
49
+ | Mistake | Correction |
50
+ | --- | --- |
51
+ | "The pin changed, so assert the new string" | Exercise the affected consumer behavior. |
52
+ | "The code is obvious" | A small vertical slice still proves the contract. |
53
+ | Keeping a passing test after the boundary moved | Mark it stale and retest the current candidate. |
@@ -0,0 +1,31 @@
1
+ ---
2
+ name: workit-blast-radius
3
+ description: Use when a small-looking change could break something else, before close or merge
4
+ ---
5
+
6
+ # Blast radius beyond the diff
7
+
8
+ A small diff is not a small risk. Prove the one fact it is safe because of,
9
+ with runnable proof — not assertion.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. List what the change touches: callers, shared state, contracts, config,
20
+ migrations. Grep every caller of each touched function.
21
+ 2. For each: state the one fact it is safe because of (type boundary,
22
+ existing test, unreachable path) plus how to run the proof.
23
+ 3. Run the proofs. Unproven claims stay labeled UNPROVEN in findings —
24
+ never silently treated as safe.
25
+ 4. Fix at the shared root (one guard where all callers route through),
26
+ not per caller.
27
+
28
+ ## Completion
29
+
30
+ Blast-radius note in evidence or review: each risk with fact + proof
31
+ command, or an UNPROVEN finding for what could not be proven.
@@ -0,0 +1,62 @@
1
+ ---
2
+ name: workit-challenge
3
+ description: Use when a proposal is ambiguous, consequential, disputed, or may hide assumptions, coupling, failure modes, or a simpler solution
4
+ ---
5
+
6
+ # Challenge a proposal with a grounded grill
7
+
8
+ Treat the proposal as a hypothesis. Facts are the agent's job; decisions are
9
+ the user's. Use this method when assessment selects the `challenge` or
10
+ `decisions` dimension.
11
+
12
+ ## Before method work
13
+
14
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
15
+ before relying on selected policy rules or other product mutations. Assessment
16
+ selects requirements; do not wait for a rule that can only exist after assess.
17
+
18
+ ## Method
19
+
20
+ 1. Ground first: inspect the task, policy, candidate, evidence, decisions, and
21
+ the repo docs that exist. Never ask what code or docs can answer.
22
+ 2. Diverge once, bounded: when the approach is unknown, offer 3-5 candidate
23
+ directions with evidence and tradeoffs in one advisory burst, without
24
+ critique. Record the burst as artifact evidence when it matters; the user
25
+ steers or mixes.
26
+ 3. Grill one question at a time: each question carries your recommended answer,
27
+ the facts behind it, and at least one rejected alternative. Resolve
28
+ dependency order and recompute after every answer — a wall of questions is
29
+ not an interview.
30
+ 4. Funnel every resolution: the moment a consequential choice settles, bind it
31
+ with a receipt-shaped question (header `Workit decision: <purpose>`, exactly
32
+ `approved`/`rejected`, the approved description carrying the exact content).
33
+ If the user already stated the choice in conversation and no receipt can be
34
+ minted, record it in task progress and reassess so the settled requirement
35
+ retires — never re-ask to mint a receipt, and never leave it for close to
36
+ demand.
37
+ 5. Durability: write or refresh the spec under `docs/<slug>/` only when the
38
+ `durable-spec` requirement fires. No glossary, no second lifecycle.
39
+ 6. Counter-case: each material recommendation carries one strongest
40
+ counter-case (hidden assumption, failure mode, coupling, simpler
41
+ alternative). Stop when a counter-case adds no new constraint.
42
+
43
+ Stop at an empty frontier or three rounds; the cap is the bound. Say directly
44
+ when the proposal is weak, overcomplicated, or solves the wrong problem.
45
+
46
+ ## Guardrails
47
+
48
+ - Do not create a universal spec, plan, approval chain, or second lifecycle.
49
+ - Unknowns that affect the dependent action remain unresolved until evidence or a
50
+ user decision closes them.
51
+ - Use the shared operations for state and provenance; never write task metadata
52
+ directly.
53
+ - An in-session counter-case is never fresh-context review; claim only what it is.
54
+
55
+ ## Common mistakes
56
+
57
+ | Mistake | Correction |
58
+ | --- | --- |
59
+ | Asking what the code or docs already answer | Ground first; the user owns choices, not lookups. |
60
+ | Listing every hypothetical objection | One strongest counter-case, then stop. |
61
+ | Asking "what do you think?" without a recommendation | Recommend an option and explain the tradeoff. |
62
+ | Leaving a settled choice for close to confirm | Funnel it when it resolves; progress plus reassessment if no receipt. |
@@ -0,0 +1,61 @@
1
+ ---
2
+ name: workit-debug
3
+ description: Use when behavior is failing, surprising, contradictory, or regressed and the root cause is not established
4
+ ---
5
+
6
+ # Debug the root cause
7
+
8
+ Debugging is investigation, not a fast symptom patch. Use this method when
9
+ assessment selects `root-cause-investigation` or behavior is failing without an
10
+ established root cause.
11
+
12
+ ## Before method work
13
+
14
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
15
+ before relying on selected policy rules or other product mutations. Assessment
16
+ selects requirements; do not wait for a rule that can only exist after assess.
17
+
18
+ ## Method
19
+
20
+ 1. Inspect task scope, caller authority, candidate identity, existing evidence,
21
+ findings, and worker/writer state with shared `task`, `policy`, `evidence`, and
22
+ `finding` operations.
23
+ 2. Reproduce the failure at a stable behavioral boundary. Record observed facts,
24
+ inferences, and unknowns with references; trace the failing value and all
25
+ relevant callers before editing.
26
+ 3. State the root-cause hypothesis and the smallest in-scope fix. Write a focused
27
+ regression at the boundary when practical, then run RED and GREEN checks.
28
+ 4. Acquire writer authority through `writer` before mutation. Reconcile the
29
+ candidate, evidence, and findings after the change; investigate sibling paths
30
+ and stale conclusions rather than assuming the first patch worked.
31
+
32
+ Honor task status, scope, revisions, and native authority gates. Do not bypass
33
+ them for an incident, create a second lifecycle, or claim a fix from a green
34
+ command that did not exercise the affected behavior.
35
+
36
+ ## Red-capable gate
37
+
38
+ Never hypothesize without a loop that goes red on this exact failure. Build
39
+ the loop first, in this order: failing test → CLI command + fixture →
40
+ request replay → trace. Tighten it until fast, sharp, deterministic, and
41
+ agent-runnable. No loop → stop, list what was tried, ask for the
42
+ environment or artifact; never theorize without it.
43
+
44
+ Minimise: cut one element at a time until every remainder is load-bearing;
45
+ the minimised case becomes the regression test. State hypotheses ranked and
46
+ falsifiable (`If <X> then changing <Y> removes it`), probe one variable at
47
+ a time, tag debug logs for grep cleanup. Write the regression at the seam
48
+ where the real pattern occurs — no correct seam means the finding is the
49
+ architecture, so flag it instead of patching around it.
50
+
51
+ When the host reports writer capability unavailable, do not mutate or delegate
52
+ mutation. Continue inline only if policy and lead authority permit it;
53
+ otherwise report the capability gap.
54
+
55
+ ## Common mistakes
56
+
57
+ | Mistake | Correction |
58
+ | ------------------------------------- | ------------------------------------------------------ |
59
+ | Patching the nearest stack frame | Trace the input, callers, and shared cause. |
60
+ | Reproducing only after editing | Capture the failure before mutation. |
61
+ | Treating one passing command as proof | Verify the affected behavior and record real evidence. |
@@ -0,0 +1,36 @@
1
+ ---
2
+ name: workit-deslop
3
+ description: Use before opening a PR or after implementation to remove AI slop from code and prose
4
+ ---
5
+
6
+ # Deslop code and prose
7
+
8
+ Throughput without quality is slop. Clean it with a minimal diff — deslop
9
+ never refactors behavior.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Code: delete dead helpers, redundant validators, stub references, and
20
+ comments that restate the code. Comments die by default; keep one only
21
+ with proof of an unchangeable constraint, encoded structurally if cheap.
22
+ 2. Prose (PR body, spec, docs): cut filler, keep real symbol names and
23
+ before→after numbers. One doc, one purpose.
24
+ 3. Keep the diff minimal: deslop removes lines, never moves logic. If a
25
+ cleanup wants behavior change, it becomes its own tasked change.
26
+
27
+ ## Completion
28
+
29
+ A smaller diff with identical behavior and green checks. Report lines
30
+ removed, not lines written.
31
+
32
+ Record passing check evidence linked to the `pre-pr-cleanup` requirement id
33
+ from the current policy (`kind: check`, `result: passed`, summary naming what
34
+ was removed). That requirement gates `hosting.pull_request` and close. If the
35
+ change genuinely has nothing to clean, ask for an approved limitation
36
+ decision instead of recording evidence that did not happen.
@@ -0,0 +1,32 @@
1
+ ---
2
+ name: workit-diagram
3
+ description: Use when a spec or plan needs a flow or architecture diagram
4
+ ---
5
+
6
+ # Mermaid when needed, never by default
7
+
8
+ Tables first, ASCII trees second, mermaid only when a flow or architecture
9
+ needs it. Flowchart, sequence, state, or ER only. No renderer, no network.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Syntax rules (mermaid v11)
18
+
19
+ - Fence as ` ```mermaid `, no surrounding prose inside the fence.
20
+ - Quote node labels containing punctuation: `A["input (x, y)"]`.
21
+ - One direction per diagram (`TD` or `LR`); keep nodes under twelve.
22
+ - Name actors exactly as the codebase names them (real symbols only).
23
+
24
+ ## Verify
25
+
26
+ Re-read the fence before commit: balanced quotes/brackets, every node
27
+ reachable, labels match spec terms. If it cannot be verified by reading,
28
+ delete it.
29
+
30
+ ## Completion
31
+
32
+ One diagram that argues a decision, or nothing. Never a diagram suite.
@@ -0,0 +1,29 @@
1
+ ---
2
+ name: workit-green-run
3
+ description: Use to drive a red CI pipeline back to green, usually inside babysit
4
+ ---
5
+
6
+ # The CI loop
7
+
8
+ Watch, classify, fix, push once, re-verify. Host-native (`gh` / GitLab);
9
+ never invent CI APIs.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Read the failing checks, not the summary. Quote the failing log lines.
20
+ 2. Classify each: flake (rerun once, note it) / stale base (update after
21
+ merge-base check) / real failure (reproduce locally, then fix).
22
+ 3. Fix at root cause with a regression test; push one wave.
23
+ 4. Re-verify the same checks green on the new head. A fix without a
24
+ green re-run is not a fix.
25
+
26
+ ## Completion
27
+
28
+ Green pipeline on the merge head, or an escalated finding with the exact
29
+ failing logs when the fix needs the human.
@@ -0,0 +1,43 @@
1
+ ---
2
+ name: workit-handoff
3
+ description: Use when work must continue in another session, host, or agent after interruption, transfer, or compaction
4
+ ---
5
+
6
+ # Handoff durable task state
7
+
8
+ Transfer continuity, not live authority. Use this method when assessment selects
9
+ the `durable-handoff` rule.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Inspect the current task, scope, decisions, policy requirements, candidate,
20
+ evidence, findings, progress, and worker states with shared `task` and `state`
21
+ operations.
22
+ 2. Export the compact state through `state.export`. Preserve the objective,
23
+ exclusions, accepted decisions and reasons, evidence references, open gaps,
24
+ findings, candidate identity, blockers, and next action. Do not include
25
+ credentials, live writer ownership, or host authority.
26
+ 3. Import only through the destination `state.import` operation and its expected
27
+ workspace revision. The destination starts paused or otherwise unauthorised
28
+ until it observes its own host/session and reconciles stale evidence and
29
+ uncertain workers.
30
+ 4. Resume or continue through shared `task`, `policy`, `worker`, `writer`, and
31
+ `evidence` operations. Record what changed instead of copying a transcript.
32
+
33
+ A handoff does not require a formal spec or plan unless those are separate
34
+ selected requirements. Never grant destination authority from imported prose,
35
+ create a second lifecycle, or edit task metadata directly.
36
+
37
+ ## Common mistakes
38
+
39
+ | Mistake | Correction |
40
+ | --- | --- |
41
+ | Sending the whole transcript | Export compact decisions, gaps, evidence, and next action. |
42
+ | Restoring the old writer or credentials | Re-observe authority in the destination. |
43
+ | Calling a handoff complete without reconciliation | Recheck stale files and uncertain workers first. |
@@ -0,0 +1,46 @@
1
+ ---
2
+ name: workit-implement
3
+ description: Use when scoped implementation, helper delegation, or checkout writer coordination is required by the current task policy
4
+ ---
5
+
6
+ # Implement within authority
7
+
8
+ Implement only inside the current task scope and writer boundary. Assignment is
9
+ not launch authority, and a timeout is not proof that a worker stopped.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Inspect task state, requirements, decisions, candidate, capabilities, and
20
+ current workers with shared `task`, `policy`, and `worker` operations.
21
+ 2. If a helper is useful, assign one bounded objective with allowed paths,
22
+ applicable requirements, evidence needed, and a stopping condition. Helpers
23
+ cannot change scope, record binding decisions, close or pause the task, assign
24
+ helpers, or resolve blockers for the lead.
25
+ 3. Observe the native session and worker state. Acquire checkout writer ownership
26
+ through `writer` before any product-mutating command; release it explicitly.
27
+ Cancellation remains uncertain until process exit or explicit recovery.
28
+ 4. Reconcile the helper report and evidence through shared operations. If required
29
+ delegation is unavailable, continue inline only when policy allows it and state
30
+ the capability limitation.
31
+
32
+ Do not edit Workit metadata directly, create nested helper trees, widen paths, or
33
+ create a second lifecycle. Read-only investigation and bounded reports do not
34
+ grant product-write ownership.
35
+
36
+ When the host reports writer capability unavailable, do not mutate or delegate
37
+ mutation. Continue inline only if policy and lead authority permit it;
38
+ otherwise report the capability gap.
39
+
40
+ ## Common mistakes
41
+
42
+ | Mistake | Correction |
43
+ | ---------------------------------------------- | --------------------------------------------------- |
44
+ | "The helper timed out, so the writer is free" | Observe exit or perform explicit recovery. |
45
+ | Letting a helper approve its own exception | Return the decision to the lead/user. |
46
+ | Running a build while another writer is active | Treat builds and tests that mutate state as writes. |
@@ -0,0 +1,28 @@
1
+ ---
2
+ name: workit-mockup
3
+ description: Use when a UI decision needs sketching before implementation
4
+ ---
5
+
6
+ # ASCII mockups before UI code
7
+
8
+ Sketch, don't build. Three genuinely different layout hypotheses maximum,
9
+ ASCII only, no code output.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Fix a legend (`┌─┐ │ └─┘ ░ ≈ [ ] ( )`) and keep sketches 60-80 cols,
20
+ 8-20 rows.
21
+ 2. Per hypothesis: regions, component reuse vs new (named against the
22
+ existing codebase), empty/loading/populated/error states, nav flow.
23
+ 3. Ask at most one clarifying question, then recommend. Flag hi-fi
24
+ escalation when ASCII cannot settle it (density, motion, brand).
25
+
26
+ ## Completion
27
+
28
+ The sketch plus the decision lands in the spec dir. Throwaway by design.
@@ -0,0 +1,66 @@
1
+ ---
2
+ name: workit-plan
3
+ description: Use when dependencies, sequencing, coordination, or resumption make durable next actions useful
4
+ ---
5
+
6
+ # Plan useful coordination
7
+
8
+ Use a compact plan when assessment selects `artifacts` or `continuity`. A plan
9
+ organizes work; it is not a second lifecycle or a prerequisite for implementation.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Inspect current task state, scope, decisions, requirements, candidate, workers,
20
+ findings, and blockers through the shared `task` and `policy` operations.
21
+ 2. Record only the useful sequence: objective, dependency, bounded task, evidence
22
+ needed, owner, and next action. Keep the plan against the existing system.
23
+ 3. If policy separately requires a durable specification, record that behavior
24
+ agreement; otherwise do not invent a spec. A plan without a spec is valid.
25
+ 4. Update the shared task progress at meaningful boundaries. Reassess when facts,
26
+ dependencies, or scope change; preserve unresolved blockers and decisions.
27
+ 5. On steering (new instructions mid-task): apply `workit-steer` — park state
28
+ verbatim, classify same-task / new-task / quick-question, handle, re-anchor.
29
+
30
+ Use shared task/progress and evidence operations. Do not create a universal
31
+ spec-and-plan ceremony, duplicate task state, approval chain, or custom status
32
+ machine. A short paragraph is enough when it captures the required continuity.
33
+
34
+ ## Triage (automatic)
35
+
36
+ Set assessor signals from size facts, not memory (`triageTier` /
37
+ `triageSignals` in policy-resolver):
38
+
39
+ - **Large → spec + full plan:** new/changed observable behavior, open
40
+ ambiguity, cross-package/host contract or auth/data/security surface,
41
+ irreversible migration, or ≥3 subsystems / ≥2 packages touched.
42
+ - **Medium → compact plan-only** (Sequence/Acceptance, ~30-60 lines): known
43
+ approach, single subsystem, 2-8 steps. Step count alone never escalates
44
+ a known single-subsystem run to spec.
45
+ - **Small → neither** (progress + evidence only): single bounded mechanical
46
+ action, no open choices, reversible. Record `Spec: none (reason)`.
47
+
48
+ `task.start` + `policy.assess` stay mandatory at all sizes. The lead may
49
+ re-tier with the reason recorded in progress (override, never silent).
50
+
51
+ ## Decomposition
52
+
53
+ Slice tracer bullets, not layers: each plan task crosses the necessary
54
+ layers to a small demoable behavior with its blocking edges declared.
55
+ Wide refactors use expand–contract (add the new seam, migrate callers,
56
+ delete the old). Per task record Files (create/modify/test, exact paths),
57
+ exact commands with expected output, and one commit. No placeholders —
58
+ an implementer must be able to execute a task with zero extra context.
59
+
60
+ ## Common mistakes
61
+
62
+ | Mistake | Correction |
63
+ | --- | --- |
64
+ | Writing a full packet for a small dependency | Capture the next bounded action and its evidence. |
65
+ | Treating the plan as authority | Authority remains in task scope, decisions, revisions, and caller provenance. |
66
+ | Copying a transcript into the plan | Preserve decisions, gaps, blockers, and next action only. |
@@ -0,0 +1,60 @@
1
+ ---
2
+ name: workit-review
3
+ description: Use when policy requires fresh-context review of a candidate or when an independent correctness and regression check is requested
4
+ ---
5
+
6
+ # Review a candidate
7
+
8
+ Review the real candidate in a stable context. A review is evidence about the
9
+ current candidate, not an author's success summary.
10
+
11
+ ## Before method work
12
+
13
+ If there is no active or paused task, run shared `task.start` then `policy.assess`
14
+ before relying on selected policy rules or other product mutations. Assessment
15
+ selects requirements; do not wait for a rule that can only exist after assess.
16
+
17
+ ## Method
18
+
19
+ 1. Pin or identify the candidate revision before reading conclusions. Inspect the
20
+ task objective, scope, constraints, accepted decisions, changed files, and
21
+ actual checks through shared `task`, `evidence`, and `policy` operations.
22
+ 2. Examine intent, correctness, regression risk, security or data consequences,
23
+ and project standards. Use the actual diff and check output; do not infer
24
+ evidence from a claim.
25
+ 3. Record each concern as a `finding` claim with its affected scope and candidate.
26
+ Investigate it: reproduce or trace the consequence, then fix in scope, dismiss
27
+ with evidence, defer with a reason, or ask the user about a real tradeoff.
28
+ 4. Reconcile conclusions when the candidate changes. Run one substantive review
29
+ and targeted rechecks; do not cycle reviewers indefinitely.
30
+
31
+ If the required independent context is unavailable, record the review method as
32
+ `unavailable` and preserve the gap. Same-session self-review is not independent
33
+ review and must not be relabeled as verified.
34
+
35
+ Use shared `evidence` and `finding` operations. Do not create a parallel review
36
+ lifecycle, universal review panel, or direct metadata files.
37
+
38
+ ## Two axes, pinned
39
+
40
+ Pin the fixed point first (`git diff <base>...HEAD` plus log); review that
41
+ candidate only. Judge on two axes, never merged or reranked:
42
+
43
+ - **Standards:** repo standards plus a smell baseline (mysterious name, long
44
+ method, duplicated logic, refused bequest, and kin); repo rules override
45
+ the baseline; judgement calls only, never tooling-enforced nits.
46
+ - **Spec:** does the diff implement the originating spec/requirement
47
+ faithfully — missing, creep, or wrong, quoting the spec line.
48
+
49
+ Every finding needs proof: the changed hunk, a failing/passing test ref, or
50
+ a before/after. Causal disposition decides the outcome: introduced or
51
+ worsened behavior gets fixed; pre-existing issues become follow-ups;
52
+ inconclusive claims escalate, never silently pass.
53
+
54
+ ## Common mistakes
55
+
56
+ | Mistake | Correction |
57
+ | --- | --- |
58
+ | Reviewing the summary instead of the candidate | Start from the stable candidate and real refs. |
59
+ | Treating every comment as a defect | Investigate the claim and consequence first. |
60
+ | Calling self-review independent | Preserve an unavailable capability gap. |