/ca-task
The sanctioned task-board mutator — add a queued task, start one (flips to in-progress and stamps the date, minting a dotted ID on pick-up), or mark an in-progress task done. The only blessed write to open-tasks.md.
$ npx -y skills add arbiterForge/codeArbiter --skill ca-task --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/ca-task
Context preview
The summary Claude sees to decide when to auto-load this skill.
The sanctioned task-board mutator — add a queued task, start one (flips to in-progress and stamps the date, minting a dotted ID on pick-up), or mark an in-progress task done. The only blessed write to open-tasks.md.
SKILL.md
ca-task.SKILL.mdname: ca-task
description: The sanctioned task-board mutator — add a queued task, start one (flips to in-progress and stamps the date, minting a dotted ID on pick-up), or mark an in-progress task done. The only blessed write to open-tasks.md.
argument-hint: "add \"<desc>\" | start <id|\"title\"> | done <id|\"title\">"
$ca-task — task-board writer
The one blessed way to mutate `<project-root>/.codearbiter/open-tasks.md` (resolves D-1). Hand-editing the board is no longer the only path; this command keeps every entry schema-conformant and every transition dated. The board LOGIC lives in the pure `_taskboardlib` transforms; this command runs the thin writer `${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py`.
Verbs
Always put `--` before user text (a desc or title) so a value beginning with `-` is not parsed as a flag. Interpreter fallback, same shape as the hooks: `python3 … || python …`.
- **add** — append a queued task. ID-less by default; pass `--id <group>.<type>` to mint
a dotted ID now, `--from <origin>` for a harvest back-ref, `--boundaries a,b` for the security/trust boundaries it touches. The description must be nonblank and single-line; origin and boundary values must also stay on one line.
- `python3 "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" add [--id group.type] [--from origin] [--boundaries a,b] -- "<desc>" || python "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" add ... -- "<desc>"`
- **start** — flip a task to in-progress and **stamp the started date** (so it can never
be a dateless `[~]`). On an ID-less item, pass `--as <group>.<type>` to mint its dotted ID at pick-up. `--date YYYY-MM-DD` overrides today.
- `python3 "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" start [--as group.type] [--date YYYY-MM-DD] -- "<id|title>"`
- **done** — flip an in-progress task to done and stamp the done date (`--date`
overrides today). A queued task must be `start`ed first.
- `python3 "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" done [--date YYYY-MM-DD] -- "<id|title>"`
A missing target, an already-matching state, an out-of-order transition, a malformed add field or `--date`, or an invalid `GROUP.TYPE` namespace is reported and writes nothing (exit 1). A queued `done` identifies the task as queued and tells the caller to `start` it first. **Targeting by title is best-effort:** prefer the dotted ID, and note that if two ID-less items share a title, `start`/`done` act on the first — give one an ID (`$ca-task start --as <group>.<type> -- "<title>"`) to disambiguate.
When NOT to use
- Promoting workflow follow-ups in bulk → that is the harvest
(`${CLAUDE_PLUGIN_ROOT}/includes/harvest.md`), which calls this writer for you.
- Reading the board / counts → `$ca-status` (read-only).
- Archiving long-settled done items → deferred (D-2); done items stay in-place for now.
- Filing a separate `chore(board)` PR just to flip a task state → task-board transitions
(`[x]` done-flip, `[~]` start-flip, new `[ ]` add) ride the **work commit** via commit-gate, co-located atomically with the code that completes, starts, or spawns the task (ADR-0008). A lagging board-only PR is the anti-pattern this design eliminates.
Hard gate
- MUST write the board only through `taskwrite.py` (the pure transforms), never a
free-hand Edit that can malform the schema.
- `start` MUST stamp a started date — never leave a dateless `[~]`.
- `done` MUST target an in-progress task — a queued task must go through `start` first.
- MUST NOT delete a task to "complete" it — mark it `done` so the record survives.
Read more
name: ca-task description: The sanctioned task-board mutator — add a queued task, start one (flips to in-progress and stamps the date, minting a dotted ID on pick-up), or mark an in-progress task done. The only blessed write to open-tasks.md. argument-hint: "add \"<desc>\" | start <id|\"title\"> | done <id|\"title\">"
$ca-task — task-board writer
The one blessed way to mutate `<project-root>/.codearbiter/open-tasks.md` (resolves D-1). Hand-editing the board is no longer the only path; this command keeps every entry schema-conformant and every transition dated. The board LOGIC lives in the pure `_taskboardlib` transforms; this command runs the thin writer `${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py`.
Verbs
Always put `--` before user text (a desc or title) so a value beginning with `-` is not parsed as a flag. Interpreter fallback, same shape as the hooks: `python3 … || python …`.
- **add** — append a queued task. ID-less by default; pass `--id <group>.<type>` to mint
a dotted ID now, `--from <origin>` for a harvest back-ref, `--boundaries a,b` for the security/trust boundaries it touches. The description must be nonblank and single-line; origin and boundary values must also stay on one line.
- `python3 "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" add [--id group.type] [--from origin] [--boundaries a,b] -- "<desc>" || python "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" add ... -- "<desc>"`
- **start** — flip a task to in-progress and **stamp the started date** (so it can never
be a dateless `[~]`). On an ID-less item, pass `--as <group>.<type>` to mint its dotted ID at pick-up. `--date YYYY-MM-DD` overrides today.
- `python3 "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" start [--as group.type] [--date YYYY-MM-DD] -- "<id|title>"`
- **done** — flip an in-progress task to done and stamp the done date (`--date`
overrides today). A queued task must be `start`ed first.
- `python3 "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" done [--date YYYY-MM-DD] -- "<id|title>"`
A missing target, an already-matching state, an out-of-order transition, a malformed add field or `--date`, or an invalid `GROUP.TYPE` namespace is reported and writes nothing (exit 1). A queued `done` identifies the task as queued and tells the caller to `start` it first. **Targeting by title is best-effort:** prefer the dotted ID, and note that if two ID-less items share a title, `start`/`done` act on the first — give one an ID (`$ca-task start --as <group>.<type> -- "<title>"`) to disambiguate.
When NOT to use
- Promoting workflow follow-ups in bulk → that is the harvest
(`${CLAUDE_PLUGIN_ROOT}/includes/harvest.md`), which calls this writer for you.
- Reading the board / counts → `$ca-status` (read-only).
- Archiving long-settled done items → deferred (D-2); done items stay in-place for now.
- Filing a separate `chore(board)` PR just to flip a task state → task-board transitions
(`[x]` done-flip, `[~]` start-flip, new `[ ]` add) ride the **work commit** via commit-gate, co-located atomically with the code that completes, starts, or spawns the task (ADR-0008). A lagging board-only PR is the anti-pattern this design eliminates.
Hard gate
- MUST write the board only through `taskwrite.py` (the pure transforms), never a
free-hand Edit that can malform the schema.
- `start` MUST stamp a started date — never leave a dateless `[~]`.
- `done` MUST target an in-progress task — a queued task must go through `start` first.
- MUST NOT delete a task to "complete" it — mark it `done` so the record survives.
When you can't trust yourself with your code base, trust Arbiter.
Repo: arbiterForge/codeArbiter
Other skills on codearbiter.
- /brainstorming
The Socratic spec-refinement front of /feature, and the planning front of /sprint. Routed to BEFORE any code — it takes a one-line idea and drives it to an approved, concrete spec with testable acceptance criteria. Four gated phases — frame, refine, write, approve. No
Open skill - /commit-gate
The only path to a commit. Routed to when the user invokes /commit or otherwise instructs codeArbiter to persist staged changes. Nine gated phases — permission, branch, classification, verification (test/lint/secrets), behavioral proof, diff review, selective stage, message,
Open skill - /context-check
Optional manual drift audit — report stale provenance-tracked docs (via _provenancelib drift detection across .codearbiter/.provenance/), then per stale doc offer re-scout / re-baseline / defer. Not the daily loop; commit-gate auto-heal owns routine maintenance.
Open skill - /context-creation
The brownfield back-fill. Routed to by /create-context, and by startup when .codearbiter/CONTEXT.md lacks the <!--INITIALIZED--> body marker but source code exists. Six gated phases — pre-flight, scout dispatch, synthesis, gap interview, write, lock. Reads the existing codebase
Open skill - /crypto-compliance
The banned-primitive gate. Routed to when changed code hashes, signs, encrypts, derives keys, generates security-relevant randomness, configures TLS, or imports a crypto library. Rejects broken primitives, disabled TLS verification, and home-rolled crypto; the approved-primitive
Open skill - /debug
Investigate-then-decide root-cause analysis for a defect whose cause is unknown (distinct from /fix, which assumes a known bug). Five gated phases: capture, hypothesize, gather, decide, hand off. Investigation only, no code changes; exits to /fix, /adr, or a no-action close.
Open skill

