capyai 0.5.3 → 0.5.4

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.
Files changed (2) hide show
  1. package/package.json +1 -1
  2. package/skills/capy/SKILL.md +2 -2
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "capyai",
3
- "version": "0.5.3",
3
+ "version": "0.5.4",
4
4
  "type": "module",
5
5
  "description": "Unofficial Capy.ai CLI for agent orchestration with quality gates",
6
6
  "bin": {
package/skills/capy/SKILL.md CHANGED
@@ -97,7 +97,7 @@ These are the mistakes agents make. Do not make them.
97
97
 
98
98
  ## Workflow: Start new work
99
99
 
100
- 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).
100
+ Default to `capy captain`. It plans, orchestrates, and can spawn multiple tasks. Only use `capy build` for small single-task work where Captain is overkill.
101
101
 
102
102
  ```bash
103
103
  # 1. Start a Captain thread (the default for almost everything)
@@ -274,7 +274,7 @@ Captain prompts should include:
274
274
 
275
275
  Do NOT tell Captain which files to touch, which commands to run, or how to implement. It has the codebase. It figures that out.
276
276
 
277
- **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.
277
+ **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.
278
278
 
279
279
  ## Triggers
280
280