capyai 0.5.3 → 0.5.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "capyai",
-  "version": "0.5.3",
+  "version": "0.5.5",
   "type": "module",
   "description": "Unofficial Capy.ai CLI for agent orchestration with quality gates",
   "bin": {

package/skills/capy/SKILL.md

@@ -83,7 +83,7 @@ These are the mistakes agents make. Do not make them.
 
 1. **Never message a task with idle jams.** If the last jam has `status: "idle"` and zero credits, the task is finished. It cannot receive messages. Sending `capy msg` will appear to succeed but nothing happens. If you need to change something, use `capy retry` to start a new attempt.
 
-2. **Never create a new Captain thread for work that already has a diff.** If a task produced code changes, that work exists. Create a PR for the existing task with `capy pr <id>`. Starting a new Captain thread throws away the existing work and burns credits.
+2. **Always check for existing work before starting a new Captain thread.** Run `capy triage --brief --json` or `capy list --json` first. If a task or thread already exists for the same work (in any state: `in_progress`, `needs_review`, `backlog`, `stuck`), resume it instead of creating a new thread. Use `capy retry <id> --fix="..."` to resume stuck/failed tasks, `capy wait <id>` for in-progress ones, `capy pr <id>` for ones needing a PR. Only start a new Captain thread when no related work exists. Creating duplicate threads throws away existing progress and burns credits.
 
 3. **Never call `capy review` on a task with no PR.** It will fail with `error.code: "no_pr"`. Always create the PR first with `capy pr <id> --json`, then review.
 
@@ -97,9 +97,13 @@ These are the mistakes agents make. Do not make them.
 
 ## Workflow: Start new work
 
-Default to `capy captain`. It has codebase context and plans its own approach. Only use `capy build` for small isolated tasks (one-file fix, config tweak).
+Before creating a new Captain thread, check if related work already exists. If it does, resume it (see Decision tree). Only start new work when nothing related is in flight.
 
 ```bash
+# 0. Check for existing related work first
+capy triage --brief --json
+# If something related exists → use retry/wait/pr on that task instead of starting new
+
 # 1. Start a Captain thread (the default for almost everything)
 RESULT=$(capy captain "We need feature X implemented. Make sure tests pass and CI is green." --json)
 THREAD_ID=$(echo "$RESULT" | jq -r '.id')
@@ -274,7 +278,7 @@ Captain prompts should include:
 
 Do NOT tell Captain which files to touch, which commands to run, or how to implement. It has the codebase. It figures that out.
 
-**Build** is the exception, not the rule. Use it only for small isolated tasks where Captain is overkill. Build has no codebase context, so be specific: name the files, the commands, the acceptance criteria.
+**Build** is the exception, not the rule. It has codebase context too, but it works on a single task and can't orchestrate like Captain does. Use it for small one-off work where Captain is overkill.
 
 ## Triggers