@brainervirus/workit-claude-code 2.6.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.
- package/.claude-plugin/plugin.json +19 -0
- package/README.md +46 -0
- package/agents/implementer.md +26 -0
- package/agents/reviewer.md +23 -0
- package/agents/verifier.md +26 -0
- package/assets/templates/execution-contract.md +40 -0
- package/assets/templates/headers.md +3 -0
- package/assets/templates/hygiene/.editorconfig +8 -0
- package/assets/templates/hygiene/.gitattributes +3 -0
- package/assets/templates/hygiene/CHANGELOG.md +14 -0
- package/assets/templates/hygiene/CONTRIBUTING.md +3 -0
- package/assets/templates/hygiene/LICENSE +21 -0
- package/assets/templates/hygiene/README.md +3 -0
- package/assets/templates/issue-update.md +5 -0
- package/assets/templates/plan-template.md +27 -0
- package/assets/templates/spec-template.md +63 -0
- package/assets/templates/workit-contract.md +12 -0
- package/bin/workit +24 -0
- package/bin/workit-hook.mjs +51 -0
- package/dist/workit-hook.js +165 -0
- package/dist/workit.js +78195 -0
- package/hooks/hooks.json +68 -0
- package/package.json +48 -0
- package/skills/babysit/SKILL.md +46 -0
- package/skills/behavioral-tdd/SKILL.md +57 -0
- package/skills/blast-radius/SKILL.md +35 -0
- package/skills/challenge/SKILL.md +56 -0
- package/skills/debug/SKILL.md +48 -0
- package/skills/deslop/SKILL.md +40 -0
- package/skills/diagram/SKILL.md +36 -0
- package/skills/green-run/SKILL.md +33 -0
- package/skills/handoff/SKILL.md +46 -0
- package/skills/implement/SKILL.md +57 -0
- package/skills/mockup/SKILL.md +32 -0
- package/skills/plan/SKILL.md +54 -0
- package/skills/review/SKILL.md +64 -0
- package/skills/steer/SKILL.md +48 -0
package/hooks/hooks.json
ADDED
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
{
|
|
2
|
+
"description": "Workit host hooks: task context on session start (incl. compaction restore and forks) and when it changes per turn, branch policy on git shell commands, and worktree guidance for subagents. Only events that change Claude's behavior are registered.",
|
|
3
|
+
"hooks": {
|
|
4
|
+
"SessionStart": [
|
|
5
|
+
{
|
|
6
|
+
"matcher": "startup|resume|clear|compact|fork",
|
|
7
|
+
"hooks": [
|
|
8
|
+
{
|
|
9
|
+
"type": "command",
|
|
10
|
+
"command": "node",
|
|
11
|
+
"args": ["${CLAUDE_PLUGIN_ROOT}/bin/workit-hook.mjs"],
|
|
12
|
+
"timeout": 10
|
|
13
|
+
}
|
|
14
|
+
]
|
|
15
|
+
}
|
|
16
|
+
],
|
|
17
|
+
"UserPromptSubmit": [
|
|
18
|
+
{
|
|
19
|
+
"hooks": [
|
|
20
|
+
{
|
|
21
|
+
"type": "command",
|
|
22
|
+
"command": "node",
|
|
23
|
+
"args": ["${CLAUDE_PLUGIN_ROOT}/bin/workit-hook.mjs"],
|
|
24
|
+
"timeout": 5
|
|
25
|
+
}
|
|
26
|
+
]
|
|
27
|
+
}
|
|
28
|
+
],
|
|
29
|
+
"PreToolUse": [
|
|
30
|
+
{
|
|
31
|
+
"matcher": "Bash",
|
|
32
|
+
"hooks": [
|
|
33
|
+
{
|
|
34
|
+
"type": "command",
|
|
35
|
+
"if": "Bash(git *)",
|
|
36
|
+
"command": "node",
|
|
37
|
+
"args": ["${CLAUDE_PLUGIN_ROOT}/bin/workit-hook.mjs"],
|
|
38
|
+
"timeout": 5
|
|
39
|
+
}
|
|
40
|
+
]
|
|
41
|
+
},
|
|
42
|
+
{
|
|
43
|
+
"matcher": "PowerShell",
|
|
44
|
+
"hooks": [
|
|
45
|
+
{
|
|
46
|
+
"type": "command",
|
|
47
|
+
"if": "PowerShell(git *)",
|
|
48
|
+
"command": "node",
|
|
49
|
+
"args": ["${CLAUDE_PLUGIN_ROOT}/bin/workit-hook.mjs"],
|
|
50
|
+
"timeout": 5
|
|
51
|
+
}
|
|
52
|
+
]
|
|
53
|
+
}
|
|
54
|
+
],
|
|
55
|
+
"SubagentStart": [
|
|
56
|
+
{
|
|
57
|
+
"hooks": [
|
|
58
|
+
{
|
|
59
|
+
"type": "command",
|
|
60
|
+
"command": "node",
|
|
61
|
+
"args": ["${CLAUDE_PLUGIN_ROOT}/bin/workit-hook.mjs"],
|
|
62
|
+
"timeout": 5
|
|
63
|
+
}
|
|
64
|
+
]
|
|
65
|
+
}
|
|
66
|
+
]
|
|
67
|
+
}
|
|
68
|
+
}
|
package/package.json
ADDED
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@brainervirus/workit-claude-code",
|
|
3
|
+
"version": "2.6.0",
|
|
4
|
+
"private": false,
|
|
5
|
+
"description": "Workit Claude Code plugin — session and per-turn task context, branch policy on git shell commands, workit method skills, and verifier/reviewer/implementer agents",
|
|
6
|
+
"keywords": [
|
|
7
|
+
"agentic-coding",
|
|
8
|
+
"ai-agents",
|
|
9
|
+
"claude-code",
|
|
10
|
+
"hooks",
|
|
11
|
+
"plugin",
|
|
12
|
+
"skills",
|
|
13
|
+
"workflow"
|
|
14
|
+
],
|
|
15
|
+
"homepage": "https://github.com/BrainerVirus/workit#readme",
|
|
16
|
+
"bugs": {
|
|
17
|
+
"url": "https://github.com/BrainerVirus/workit/issues"
|
|
18
|
+
},
|
|
19
|
+
"license": "MIT",
|
|
20
|
+
"repository": {
|
|
21
|
+
"type": "git",
|
|
22
|
+
"url": "https://github.com/BrainerVirus/workit.git"
|
|
23
|
+
},
|
|
24
|
+
"files": [
|
|
25
|
+
".claude-plugin/",
|
|
26
|
+
"hooks/hooks.json",
|
|
27
|
+
"bin/",
|
|
28
|
+
"agents/",
|
|
29
|
+
"skills/",
|
|
30
|
+
"assets/",
|
|
31
|
+
"dist/",
|
|
32
|
+
"README.md"
|
|
33
|
+
],
|
|
34
|
+
"type": "module",
|
|
35
|
+
"publishConfig": {
|
|
36
|
+
"access": "public"
|
|
37
|
+
},
|
|
38
|
+
"scripts": {
|
|
39
|
+
"build": "bun scripts/build.ts"
|
|
40
|
+
},
|
|
41
|
+
"devDependencies": {
|
|
42
|
+
"@brainervirus/workit-cli": "^2.6.0",
|
|
43
|
+
"@brainervirus/workit-core": "^2.6.0"
|
|
44
|
+
},
|
|
45
|
+
"engines": {
|
|
46
|
+
"node": ">=24"
|
|
47
|
+
}
|
|
48
|
+
}
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: babysit
|
|
3
|
+
description: Use when the user asks to babysit a PR or explicitly opts in to PR follow-up
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Babysit a PR to PR-ready
|
|
7
|
+
|
|
8
|
+
PR creation does not start babysitting. `babysit:true` opts into this skill;
|
|
9
|
+
omission means no follow-up. A PR URL by itself is not an instruction to drive
|
|
10
|
+
it. When the user asks to babysit a URL from a route Workit did not enforce,
|
|
11
|
+
help without claiming the Workit route was enforced. Never mutate PR topology
|
|
12
|
+
(no rebase strategy changes, no force-push).
|
|
13
|
+
|
|
14
|
+
|
|
15
|
+
## Method
|
|
16
|
+
|
|
17
|
+
1. Default to drive mode for an explicit babysit request: resolve conflicts,
|
|
18
|
+
address review threads, and get checks green. Watch reports status only;
|
|
19
|
+
threads-only addresses review threads. Ask about mode only when the choice
|
|
20
|
+
materially changes the work.
|
|
21
|
+
2. Work toward PR-ready in order: conflicts → review threads → CI. Keep a brief
|
|
22
|
+
checkpoint when continuity needs it; task progress is optional.
|
|
23
|
+
3. Classify CI before retry: flake (rerun once) vs stale base (verify with
|
|
24
|
+
`git merge-base --is-ancestor` before updating) vs real failure (fix).
|
|
25
|
+
4. Triage bot findings skeptically: reproduce or quote code before acting;
|
|
26
|
+
invalid bots get a reasoned dismissal, never silent ignore.
|
|
27
|
+
5. Batch fixes into one push wave; re-verify green after every push.
|
|
28
|
+
6. Stop at PR-ready. A PR creation or babysit request does not authorize merge
|
|
29
|
+
or release. Continue to merge or release only when the user explicitly sets
|
|
30
|
+
that delivery endpoint and host authority allows the action.
|
|
31
|
+
|
|
32
|
+
## Completion
|
|
33
|
+
|
|
34
|
+
Report PR-ready status with evidence for fixes, or a brief blocker report. If
|
|
35
|
+
the user explicitly authorized merge, honor the configured strategy only after
|
|
36
|
+
checks and required approval. After a squash merge, re-record evidence against
|
|
37
|
+
the new base commit before closing tracked work.
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
## In Claude Code
|
|
41
|
+
|
|
42
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
43
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
44
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
45
|
+
and `implementer` agents take independent verification, fresh-context
|
|
46
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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
|
+
|
|
12
|
+
## Method
|
|
13
|
+
|
|
14
|
+
1. Inspect the task requirement, current candidate, intended behavior, and real
|
|
15
|
+
verification entry point with shared `task`, `policy`, and `evidence` operations.
|
|
16
|
+
2. State one behavior and its observable result. Choose the narrowest stable
|
|
17
|
+
boundary a caller or user depends on; avoid private helpers and incidental
|
|
18
|
+
representations.
|
|
19
|
+
3. Write one vertical RED slice that fails for the missing behavior, run it, and
|
|
20
|
+
preserve the actual failure as evidence. Implement the smallest change, then
|
|
21
|
+
run the same slice GREEN and record its result. Close enforces the order: a
|
|
22
|
+
testing requirement with GREEN but no preceding RED evidence stays unsatisfied.
|
|
23
|
+
4. Add only another slice for a distinct behavior or risk. Reconcile stale
|
|
24
|
+
evidence if the candidate changes.
|
|
25
|
+
|
|
26
|
+
## Reject noisy tests
|
|
27
|
+
|
|
28
|
+
- A dependency/version-pin assertion is not behavioral evidence.
|
|
29
|
+
- A test that mirrors branches, private calls, or exact implementation structure
|
|
30
|
+
is coupled to internals; replace it with the public effect.
|
|
31
|
+
- Duplicate assertions and tests that add no distinct failure signal are noise;
|
|
32
|
+
delete them.
|
|
33
|
+
- Do not claim a passing test satisfies a different requirement.
|
|
34
|
+
- Banned: tautologies (asserts what the code says, not what it must do),
|
|
35
|
+
ghost loops (assert inside a possibly-empty loop), smoke-only renders,
|
|
36
|
+
type-only or CSS-class coupling. If the test still passes when every
|
|
37
|
+
imported function returns undefined, rewrite the assertion or delete it.
|
|
38
|
+
|
|
39
|
+
Use shared `evidence` operations for RED/GREEN results. Do not add a second
|
|
40
|
+
lifecycle, approval chain, or test workflow outside the current task state.
|
|
41
|
+
|
|
42
|
+
## Common mistakes
|
|
43
|
+
|
|
44
|
+
| Mistake | Correction |
|
|
45
|
+
| --- | --- |
|
|
46
|
+
| "The pin changed, so assert the new string" | Exercise the affected consumer behavior. |
|
|
47
|
+
| "The code is obvious" | A small vertical slice still proves the contract. |
|
|
48
|
+
| Keeping a passing test after the boundary moved | Mark it stale and retest the current candidate. |
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
## In Claude Code
|
|
52
|
+
|
|
53
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
54
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
55
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
56
|
+
and `implementer` agents take independent verification, fresh-context
|
|
57
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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
|
+
|
|
12
|
+
## Method
|
|
13
|
+
|
|
14
|
+
1. List what the change touches: callers, shared state, contracts, config,
|
|
15
|
+
migrations. Grep every caller of each touched function.
|
|
16
|
+
2. For each: state the one fact it is safe because of (type boundary,
|
|
17
|
+
existing test, unreachable path) plus how to run the proof.
|
|
18
|
+
3. Run the proofs. Unproven claims stay labeled UNPROVEN in findings —
|
|
19
|
+
never silently treated as safe.
|
|
20
|
+
4. Fix at the shared root (one guard where all callers route through),
|
|
21
|
+
not per caller.
|
|
22
|
+
|
|
23
|
+
## Completion
|
|
24
|
+
|
|
25
|
+
Blast-radius note in evidence or review: each risk with fact + proof
|
|
26
|
+
command, or an UNPROVEN finding for what could not be proven.
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
## In Claude Code
|
|
30
|
+
|
|
31
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
32
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
33
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
34
|
+
and `implementer` agents take independent verification, fresh-context
|
|
35
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: challenge
|
|
3
|
+
description: Use when requirements or consequences leave a real decision open
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Challenge open choices with evidence
|
|
7
|
+
|
|
8
|
+
Skip this method for a precise, settled request.
|
|
9
|
+
|
|
10
|
+
## Method
|
|
11
|
+
|
|
12
|
+
1. Ground the outcome, constraints, evidence, and important unknowns. Inspect
|
|
13
|
+
code and project docs before asking about facts they can answer.
|
|
14
|
+
2. Separate observations, inferences, and proposals. Test assumptions that
|
|
15
|
+
could change the recommendation.
|
|
16
|
+
3. When viable alternatives exist, present two or three genuinely different
|
|
17
|
+
approaches. Recommend one; for each, give its benefit, cost or risk, when it
|
|
18
|
+
fits, and the smallest useful validation. Do not invent a weak alternative.
|
|
19
|
+
4. Ask only consequential questions, in dependency order. Group independent
|
|
20
|
+
choices into one small round. If an authorized reversible default works,
|
|
21
|
+
state it and proceed.
|
|
22
|
+
5. Record a settled choice once in the existing conversation or task context.
|
|
23
|
+
A discussion decision is knowledge; never fabricate a native permission
|
|
24
|
+
receipt or reopen it without new evidence.
|
|
25
|
+
6. Create durable documentation only when requested or when the decision needs
|
|
26
|
+
a future reader. Brainstorming alone does not require a spec.
|
|
27
|
+
|
|
28
|
+
Say directly when evidence shows a proposal is weak, overcomplicated, or solves
|
|
29
|
+
the wrong problem. Raise a counter-case only when it adds a real constraint.
|
|
30
|
+
|
|
31
|
+
## Guardrails
|
|
32
|
+
|
|
33
|
+
- Do not create a universal spec, plan, approval chain, or second lifecycle.
|
|
34
|
+
- Unknowns that affect an action remain unresolved until evidence or a user
|
|
35
|
+
decision closes them.
|
|
36
|
+
- Use shared operations for tracked state and provenance; never write task
|
|
37
|
+
metadata directly.
|
|
38
|
+
- An in-session counter-case is not fresh-context review.
|
|
39
|
+
|
|
40
|
+
## Common mistakes
|
|
41
|
+
|
|
42
|
+
| Mistake | Correction |
|
|
43
|
+
| --- | --- |
|
|
44
|
+
| Asking what code or docs already answer | Ground first; the user owns choices, not lookups. |
|
|
45
|
+
| Listing every hypothetical objection | Raise only objections that can change the decision. |
|
|
46
|
+
| Asking for agreement without a recommendation | Recommend an option and explain the tradeoff. |
|
|
47
|
+
| Treating a discussion decision as permission | Record it as knowledge; preserve native host authority. |
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
## In Claude Code
|
|
51
|
+
|
|
52
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
53
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
54
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
55
|
+
and `implementer` agents take independent verification, fresh-context
|
|
56
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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
|
+
|
|
13
|
+
## Method
|
|
14
|
+
|
|
15
|
+
1. Inspect task scope, caller authority, candidate identity, existing evidence,
|
|
16
|
+
findings, and worker/writer state with shared `task`, `policy`, `evidence`, and
|
|
17
|
+
`finding` operations.
|
|
18
|
+
2. Reproduce the failure at a stable behavioral boundary. Record observed facts,
|
|
19
|
+
inferences, and unknowns with references; trace the failing value and all
|
|
20
|
+
relevant callers before editing.
|
|
21
|
+
3. State the root-cause hypothesis and the smallest in-scope fix. Write a focused
|
|
22
|
+
regression at the boundary when practical, then run RED and GREEN checks.
|
|
23
|
+
4. Acquire writer authority through `writer` before mutation. Reconcile the
|
|
24
|
+
candidate, evidence, and findings after the change; investigate sibling paths
|
|
25
|
+
and stale conclusions rather than assuming the first patch worked.
|
|
26
|
+
|
|
27
|
+
Respect the user's scope and native authority. For a deterministic failure, make
|
|
28
|
+
one focused reproduction that exercises the affected boundary and add a
|
|
29
|
+
regression check when practical. If no direct reproduction exists, gather the
|
|
30
|
+
available evidence and state what remains uncertain instead of inventing a red
|
|
31
|
+
loop or blocking unrelated work.
|
|
32
|
+
|
|
33
|
+
## Common mistakes
|
|
34
|
+
|
|
35
|
+
| Mistake | Correction |
|
|
36
|
+
| ------------------------------------- | ------------------------------------------------------ |
|
|
37
|
+
| Patching the nearest stack frame | Trace the input, callers, and shared cause. |
|
|
38
|
+
| Reproducing only after editing | Capture the failure before mutation. |
|
|
39
|
+
| Treating one passing command as proof | Verify the affected behavior and record real evidence. |
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
## In Claude Code
|
|
43
|
+
|
|
44
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
45
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
46
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
47
|
+
and `implementer` agents take independent verification, fresh-context
|
|
48
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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
|
+
|
|
12
|
+
## Method
|
|
13
|
+
|
|
14
|
+
1. Code: delete dead helpers, redundant validators, stub references, and
|
|
15
|
+
comments that restate the code. Comments die by default; keep one only
|
|
16
|
+
with proof of an unchangeable constraint, encoded structurally if cheap.
|
|
17
|
+
2. Prose (PR body, spec, docs): cut filler, keep real symbol names and
|
|
18
|
+
before→after numbers. One doc, one purpose.
|
|
19
|
+
3. Keep the diff minimal: deslop removes lines, never moves logic. If a
|
|
20
|
+
cleanup wants behavior change, it becomes its own tasked change.
|
|
21
|
+
|
|
22
|
+
## Completion
|
|
23
|
+
|
|
24
|
+
A smaller diff with identical behavior and green checks. Report lines
|
|
25
|
+
removed, not lines written.
|
|
26
|
+
|
|
27
|
+
Record passing check evidence linked to the `pre-pr-cleanup` requirement id
|
|
28
|
+
from the current policy (`kind: check`, `result: passed`, summary naming what
|
|
29
|
+
was removed). That requirement gates `hosting.pull_request` and close. If the
|
|
30
|
+
change genuinely has nothing to clean, ask for an approved limitation
|
|
31
|
+
decision instead of recording evidence that did not happen.
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
## In Claude Code
|
|
35
|
+
|
|
36
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
37
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
38
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
39
|
+
and `implementer` agents take independent verification, fresh-context
|
|
40
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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
|
+
|
|
12
|
+
## Syntax rules (mermaid v11)
|
|
13
|
+
|
|
14
|
+
- Fence as ` ```mermaid `, no surrounding prose inside the fence.
|
|
15
|
+
- Quote node labels containing punctuation: `A["input (x, y)"]`.
|
|
16
|
+
- One direction per diagram (`TD` or `LR`); keep nodes under twelve.
|
|
17
|
+
- Name actors exactly as the codebase names them (real symbols only).
|
|
18
|
+
|
|
19
|
+
## Verify
|
|
20
|
+
|
|
21
|
+
Re-read the fence before commit: balanced quotes/brackets, every node
|
|
22
|
+
reachable, labels match spec terms. If it cannot be verified by reading,
|
|
23
|
+
delete it.
|
|
24
|
+
|
|
25
|
+
## Completion
|
|
26
|
+
|
|
27
|
+
One diagram that argues a decision, or nothing. Never a diagram suite.
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
## In Claude Code
|
|
31
|
+
|
|
32
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
33
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
34
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
35
|
+
and `implementer` agents take independent verification, fresh-context
|
|
36
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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
|
+
|
|
12
|
+
## Method
|
|
13
|
+
|
|
14
|
+
1. Read the failing checks, not the summary. Quote the failing log lines.
|
|
15
|
+
2. Classify each: flake (rerun once, note it) / stale base (update after
|
|
16
|
+
merge-base check) / real failure (reproduce locally, then fix).
|
|
17
|
+
3. Fix at root cause with a regression test; push one wave.
|
|
18
|
+
4. Re-verify the same checks green on the new head. A fix without a
|
|
19
|
+
green re-run is not a fix.
|
|
20
|
+
|
|
21
|
+
## Completion
|
|
22
|
+
|
|
23
|
+
Green pipeline on the merge head, or an escalated finding with the exact
|
|
24
|
+
failing logs when the fix needs the human.
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
## In Claude Code
|
|
28
|
+
|
|
29
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
30
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
31
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
32
|
+
and `implementer` agents take independent verification, fresh-context
|
|
33
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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 a tracked item
|
|
9
|
+
must continue in another session, host, or agent.
|
|
10
|
+
|
|
11
|
+
## Method
|
|
12
|
+
|
|
13
|
+
1. Inspect the current task, scope, decisions, policy requirements, candidate,
|
|
14
|
+
evidence, findings, progress, and worker states with shared `task` and `state`
|
|
15
|
+
operations.
|
|
16
|
+
2. Export the compact state through `state.export`. Preserve the objective,
|
|
17
|
+
exclusions, accepted decisions and reasons, evidence references, open gaps,
|
|
18
|
+
findings, candidate identity, blockers, and next action. Do not include
|
|
19
|
+
credentials, live writer ownership, or host authority.
|
|
20
|
+
3. Import only through the destination `state.import` operation and its expected
|
|
21
|
+
workspace revision. The destination starts paused or otherwise unauthorised
|
|
22
|
+
until it observes its own host/session and reconciles stale evidence and
|
|
23
|
+
uncertain workers.
|
|
24
|
+
4. Resume or continue through shared `task`, `policy`, `worker`, `writer`, and
|
|
25
|
+
`evidence` operations. Record what changed instead of copying a transcript.
|
|
26
|
+
|
|
27
|
+
A handoff does not require a formal spec or plan unless those are separate
|
|
28
|
+
selected requirements. Never grant destination authority from imported prose,
|
|
29
|
+
create a second lifecycle, or edit task metadata directly.
|
|
30
|
+
|
|
31
|
+
## Common mistakes
|
|
32
|
+
|
|
33
|
+
| Mistake | Correction |
|
|
34
|
+
| --- | --- |
|
|
35
|
+
| Sending the whole transcript | Export compact decisions, gaps, evidence, and next action. |
|
|
36
|
+
| Restoring the old writer or credentials | Re-observe authority in the destination. |
|
|
37
|
+
| Calling a handoff complete without reconciliation | Recheck stale files and uncertain workers first. |
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
## In Claude Code
|
|
41
|
+
|
|
42
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
43
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
44
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
45
|
+
and `implementer` agents take independent verification, fresh-context
|
|
46
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: implement
|
|
3
|
+
description: Use when implementing requested code changes in a repository. Follow its rules and host permissions; use Workit tracking and delegation only when continuity or coordination helps.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Implement within authority
|
|
7
|
+
|
|
8
|
+
Implement within the user request and native host permissions. A task record and
|
|
9
|
+
writer ownership are optional coordination tools. Assignment never expands the
|
|
10
|
+
request, and a timeout is not proof that a worker stopped.
|
|
11
|
+
|
|
12
|
+
## Method
|
|
13
|
+
|
|
14
|
+
1. Inspect the repository, relevant rules, host capabilities, and current work.
|
|
15
|
+
Inspect task state only when this work is already tracked.
|
|
16
|
+
2. If a helper is useful, assign one bounded objective with allowed paths,
|
|
17
|
+
applicable requirements, evidence needed, and a stopping condition. Helpers
|
|
18
|
+
cannot change scope, record binding decisions, close or pause the task, assign
|
|
19
|
+
helpers, or resolve blockers for the lead.
|
|
20
|
+
3. Use writer ownership only when another Workit actor may mutate the same
|
|
21
|
+
checkout; release it when coordination ends. Cancellation remains uncertain
|
|
22
|
+
until process exit or explicit recovery.
|
|
23
|
+
4. Reconcile helper reports and run the checks appropriate to the requested
|
|
24
|
+
outcome. If delegation is unavailable, continue inline when useful.
|
|
25
|
+
5. Before a cross-repo mutation, resolve the actual checkout, branch and remote
|
|
26
|
+
from the request and current context. Ask only if competing plausible targets
|
|
27
|
+
remain unresolved. Branch, commit, direct push, PR-ready, merge and release
|
|
28
|
+
are distinct endpoints; perform only the authorized one under target rules.
|
|
29
|
+
Before saying done, reconcile every named deliverable against that checkout
|
|
30
|
+
and verify the requested result. For a push, observe the destination remote
|
|
31
|
+
ref and confirm it contains the delivered commit; report drift or missing
|
|
32
|
+
items as blockers instead of treating local success as remote delivery.
|
|
33
|
+
|
|
34
|
+
Do not edit Workit metadata directly, create nested helper trees, widen paths, or
|
|
35
|
+
create a second lifecycle. Read-only investigation and bounded reports do not
|
|
36
|
+
grant product-write ownership.
|
|
37
|
+
|
|
38
|
+
Do not request writer ownership for a solo edit. If a concurrent Workit writer
|
|
39
|
+
cannot be fenced, stop only the conflicting managed writes; ordinary writes still
|
|
40
|
+
follow the native host permission and sandbox.
|
|
41
|
+
|
|
42
|
+
## Common mistakes
|
|
43
|
+
|
|
44
|
+
| Mistake | Correction |
|
|
45
|
+
| ---------------------------------------------- | --------------------------------------------------- |
|
|
46
|
+
| "The helper timed out, so the writer is free" | Observe exit or perform explicit recovery. |
|
|
47
|
+
| Letting a helper approve its own exception | Return the decision to the lead/user. |
|
|
48
|
+
| Running a build while another writer is active | Treat builds and tests that mutate state as writes. |
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
## In Claude Code
|
|
52
|
+
|
|
53
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
54
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
55
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
56
|
+
and `implementer` agents take independent verification, fresh-context
|
|
57
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 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
|
+
|
|
12
|
+
## Method
|
|
13
|
+
|
|
14
|
+
1. Fix a legend (`┌─┐ │ └─┘ ░ ≈ [ ] ( )`) and keep sketches 60-80 cols,
|
|
15
|
+
8-20 rows.
|
|
16
|
+
2. Per hypothesis: regions, component reuse vs new (named against the
|
|
17
|
+
existing codebase), empty/loading/populated/error states, nav flow.
|
|
18
|
+
3. Ask at most one clarifying question, then recommend. Flag hi-fi
|
|
19
|
+
escalation when ASCII cannot settle it (density, motion, brand).
|
|
20
|
+
|
|
21
|
+
## Completion
|
|
22
|
+
|
|
23
|
+
The sketch plus the decision lands in the spec dir. Throwaway by design.
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
## In Claude Code
|
|
27
|
+
|
|
28
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
29
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
30
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
31
|
+
and `implementer` agents take independent verification, fresh-context
|
|
32
|
+
review and isolated implementation.
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plan
|
|
3
|
+
description: Use when dependencies, sequencing, coordination, or resumption make durable next actions useful
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Plan useful coordination
|
|
7
|
+
|
|
8
|
+
A plan is useful when work has dependent steps, a handoff, concurrent actors, or
|
|
9
|
+
meaningful unresolved choices. It is never a prerequisite for implementation.
|
|
10
|
+
|
|
11
|
+
## Method
|
|
12
|
+
|
|
13
|
+
1. Establish the requested outcome, constraints, dependencies, and important
|
|
14
|
+
unknowns from the available code, docs, and configuration before asking.
|
|
15
|
+
2. Record only the useful sequence: objective, dependency, bounded outcome,
|
|
16
|
+
evidence needed, and next action. Reuse the project's existing format.
|
|
17
|
+
3. Start a tracked record only when handoff, dependent steps, coordination, or
|
|
18
|
+
durable decisions need continuity. Infer observable facts instead of asking
|
|
19
|
+
the user to fill redundant protocol fields.
|
|
20
|
+
4. Create a spec when a durable behavior contract or interface is requested or
|
|
21
|
+
will help a future reader. Use an ADR for a consequential trade-off and a
|
|
22
|
+
glossary for stable terms. A small fix needs no document.
|
|
23
|
+
5. If the user authorized implementation, proceed through the agreed endpoint
|
|
24
|
+
and applicable checks. Do not ask for a separate plan approval or repeat
|
|
25
|
+
"continue?". Stop for a new consequential choice, host denial, conflict, or
|
|
26
|
+
blocker that cannot be resolved safely.
|
|
27
|
+
6. Update a checkpoint at meaningful boundaries when another session may need
|
|
28
|
+
to resume. Keep settled decisions, changed files, actual checks, blockers,
|
|
29
|
+
and the next action; omit transcript and process trivia.
|
|
30
|
+
|
|
31
|
+
## Shape
|
|
32
|
+
|
|
33
|
+
Plan slices as small end-to-end outcomes with explicit dependencies and checks.
|
|
34
|
+
Keep repo policy and native host authority separate. Preserve the user's branch
|
|
35
|
+
and commit conventions. Do not prescribe one commit per step or create a second
|
|
36
|
+
approval chain unless the user asked for that delivery format.
|
|
37
|
+
|
|
38
|
+
## Common mistakes
|
|
39
|
+
|
|
40
|
+
| Mistake | Correction |
|
|
41
|
+
| --- | --- |
|
|
42
|
+
| Writing a packet for a bounded reversible change | Leave the change undocumented. |
|
|
43
|
+
| Asking what repository state or code can answer | Inspect it first. |
|
|
44
|
+
| Treating the plan as authority | Follow the user's scope and native host permissions. |
|
|
45
|
+
| Copying a transcript into the plan | Keep decisions, evidence, gaps, and next action only. |
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
## In Claude Code
|
|
49
|
+
|
|
50
|
+
Workit operations (`task`, `evidence`, `policy`, `decision`, …) run through
|
|
51
|
+
the `workit` CLI on the Bash tool: `workit <family> <action> --json`
|
|
52
|
+
(`workit --help` lists the verbs). The plugin's `verifier`, `reviewer`
|
|
53
|
+
and `implementer` agents take independent verification, fresh-context
|
|
54
|
+
review and isolated implementation.
|