Loading ToolBench
The project board that doesn't take your coding agent's word for it. Runs your check before a card moves; lets git overrule the board.
Shipward has well-structured tool definitions with clear, domain-specific descriptions (avg 180 chars, within baseline 194). All 7 tools have input schemas with proper JSON Schema format and type definitions. However, parameter descriptions are sparse, many lack actionable guidance on format/constraints. Tool names are verb-based but domain-specific (standup, recall, log, start, note, done, sync) rather than following standard verb_noun patterns (get_standup, search_memory). Error handling is minimal; no recovery guidance or categorization. Output schemas are not documented. Composition is strong, tools chain well via card IDs, but descriptions could better explain prerequisites and when to call each tool.
Hand back a card: status becomes review/shipped and the note is filed. Runs the check before the move — if it fails, the card stays where it was and the check output is the reply. The check is a script you write; Shipward runs it, git is the witness.
Add a card to the backlog. Use this the moment work is discovered or promised — a bug seen in passing, a follow-up, a TODO — so that nothing lives only in the conversation. Infer type, priority and effort from the description yourself and pass them; put the context a future session would need in `note`.
Write to a card's memory WITHOUT moving it. Use it the moment you decide something, reproduce something, or get bitten — a decision taken mid-task, a finding that belongs on a card you are not working, the reason you did NOT do the obvious thing. Every other tool attaches a note to a transition, so anything learned between transitions had nowhere to go; this is where it goes. The entry is appended and dated, never rewritten.
Search everything Claude Code has previously written down about this repo — decisions, reproduced bugs, gotchas, tradeoffs, open questions. Call this BEFORE editing an unfamiliar file: a finding is filed under the card that found it, not under the code it concerns, so the warning you need is never on the card you are working. Read-only. Every result carries the card and date it came from; judge it, do not simply believe it.
Parameter descriptions lack actionable constraints. 'project' appears in 5 tools with identical description 'Project id or name. Defaults to the active project.' but no guidance on format, length, or valid values. 'kind' enum in recall/note lacks explanation of what each value means (e.g., what distinguishes 'finding' from 'evidence'?).
No output schema documentation. Tools return structured data (card state, branch name, search results) but responses are not formally specified. LLMs cannot plan downstream calls or extract fields reliably without knowing return structure.
Error handling is absent. No guidance on retryability, user-fixable vs fatal errors, or recovery steps. If 'done' fails a check, the description says 'check output is the reply' but does not explain what the LLM should do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Read the tracker and report the state of the active project: what Claude is working on, what is waiting for review, the top of the backlog, and what shipped in the last week. Read-only — call this at the start of a session before doing anything else.
Take a card: status becomes claude/working and a branch is named if it has none. Returns the branch to check out and the card note. Call this BEFORE writing any code — work that is not on a card is work the next session cannot see.
Reconcile the board against git: move cards whose commits landed, clear the claude flag from cards whose branches were deleted, and report what changed. Idempotent — call it as often as you like. Runs at session start and after every done; you rarely need to call it by hand.
Tool naming deviates from verb_noun convention. 'standup', 'recall', 'log', 'note', 'done', 'sync' are domain-specific but not self-documenting. Standard names like 'get_standup', 'search_memory', 'create_card', 'update_card_status' would improve clarity for LLMs unfamiliar with Shipward.
'recall' tool accepts 'limit' parameter (default 10, capped 50) but description does not explain token/size tradeoff or when results are clipped. 'Entries share a fixed size budget' is vague, LLMs need explicit guidance on expected result size.