@slycode/slycode 0.2.22 → 0.2.24

package/templates/updates/actions/challenge.md

@@ -0,0 +1,119 @@
+---
+name: challenge
+version: 1.0.0
+label: "Challenge"
+description: "Send design to another AI provider for adversarial review and synthesis"
+group: "Card Actions"
+placement: both
+scope: global
+classes:
+  design: 50
+---
+
+{{cardContext}}
+
+---
+
+## Your Task — Challenge Design
+
+You are initiating a **cross-agent design challenge** for card `{{card.id}}`. The goal is to send the current design work to a different AI provider for adversarial review, then synthesize their feedback to strengthen the design.
+
+---
+
+### Phase 1 — Gather Context
+
+1. **Read the full card details** (notes, problems, checklist):
+   ```bash
+   sly-kanban show {{card.id}}
+   ```
+
+2. **Read the design document** (if linked):
+   {{#if card.design_ref}}
+   Read `{{card.design_ref}}`
+   {{/if}}
+
+3. **Read the feature spec** (if linked):
+   {{#if card.feature_ref}}
+   Read `{{card.feature_ref}}`
+   {{/if}}
+
+4. **Read all card notes** — these contain cross-agent communication and prior context.
+
+---
+
+### Phase 2 — Determine Target Provider
+
+You need to send the challenge to a **different** provider than yourself.
+
+- If you are **Claude** → send to `codex`
+- If you are **Codex** → send to `claude`
+- If you are **Gemini** → try `claude` first; if that fails (no session / error), try `codex`
+
+To determine who you are: check your model identity. Claude models start with "claude-", Codex models are OpenAI (e.g., o3, o4-mini, codex-mini), Gemini models start with "gemini-".
+
+---
+
+### Phase 3 — Prepare and Send
+
+Before sending the prompt, you may optionally add a note to the card summarising key context that the other agent should know:
+
+```bash
+sly-kanban notes {{card.id}} add "Challenge context: <brief summary of design state, key decisions, open questions>" --agent "<your-provider-name>"
+```
+
+Now construct a detailed prompt for the other agent. The prompt must include:
+
+1. **The full design document content** (paste it inline — the other agent may not have access to the file)
+2. **The feature spec content** if one exists (paste inline)
+3. **Key notes from the card** that provide relevant context
+4. **Clear instructions** asking the other agent to:
+   - Review the design from as many perspectives as seem necessary (technical feasibility, user experience, edge cases, security, performance, simplicity, maintainability, etc.)
+   - State what it **agrees with** and why
+   - State what it **disagrees with** or sees as risky, with specific reasoning
+   - Suggest concrete improvements or alternatives where it sees weakness
+   - Call out any assumptions that seem unvalidated
+   - Use `sly-kanban respond <response-id> "..."` to send back a structured response
+
+**Send the prompt:**
+
+```bash
+sly-kanban prompt {{card.id}} "<your constructed prompt>" --provider <target-provider> --wait --timeout 180
+```
+
+Use `--timeout 180` (3 minutes) to allow thorough analysis. Do **not** use `--fresh` — send to the existing session.
+
+If the prompt times out, that's OK — the response will arrive asynchronously. Tell the user you're waiting and check back. The response will eventually come through.
+
+---
+
+### Phase 4 — Synthesize Feedback
+
+When the response arrives, **do not blindly adopt the suggestions**. Instead:
+
+1. **Categorise each point** as:
+   - **Agree** — valid concern, should be addressed
+   - **Disagree** — you believe the current design is correct, explain why
+   - **Needs discussion** — legitimate tension, the user should decide
+
+2. **For agreed points**: Propose specific changes to the design document.
+
+3. **For disagreed points**: Explain your reasoning for why the current approach is sound.
+
+4. **For ambiguous points**: Present both perspectives clearly and ask the user what they'd like to do.
+
+5. **Update the design doc** with an "## External Review" section capturing:
+   - Who reviewed (which provider)
+   - Key agreements and changes made
+   - Key disagreements and your reasoning
+   - Open questions surfaced to the user
+
+6. **Add a summary note** to the card:
+   ```bash
+   sly-kanban notes {{card.id}} add "Challenge review complete: <N> points agreed, <N> disagreed, <N> need user input. Design doc updated with External Review section." --agent "<your-provider-name>"
+   ```
+
+7. **Present the synthesis to the user** with clear recommendations and any decisions that need their input.
+
+---
+
+**Start now** — begin Phase 1.

package/templates/updates/actions/checkpoint.md

@@ -7,9 +7,9 @@ group: "Utilities"
 placement: both
 scope: global
 classes:
-  design: 60
+  design: 70
   implementation: 30
-  project-terminal: 50
+  project-terminal: 60
 ---
 
 /checkpoint

package/templates/updates/actions/context.md

@@ -8,11 +8,11 @@ placement: both
 scope: global
 classes:
   backlog: 20
-  design: 90
+  design: 100
   done: 30
   implementation: 60
-  project-terminal: 60
-  testing: 60
+  project-terminal: 10
+  testing: 70
 ---
 
 {{cardContext}}

package/templates/updates/actions/create-card.md

@@ -7,7 +7,7 @@ group: "Project"
 placement: startup
 scope: global
 classes:
-  project-terminal: 40
+  project-terminal: 50
 ---
 
 {{projectContext}}

package/templates/updates/actions/deep-design.md

@@ -1,6 +1,6 @@
 ---
 name: deep-design
-version: 1.0.0
+version: 1.1.0
 label: "Deep Design"
 description: "Thorough design with parallel analysis agents for creative, risk, and quality perspectives"
 group: "Card Actions"
@@ -21,6 +21,8 @@ classes:
 
 We're starting a **deep design** session for card `{{card.id}}`. This is the thorough version — after creating the initial design doc, we'll run parallel analysis agents to stress-test the design from multiple angles before iterating.
 
+**Your role is to investigate and advise.** You must NOT unilaterally cut scope, drop requirements, or decide what to build. All scope and direction decisions belong to the user. Present findings, options, and trade-offs — then ask.
+
 ---
 
 ### Phase 1 — Initial Design Doc
@@ -48,6 +50,7 @@ Now launch sub-agents to analyse the design from different perspectives. Each ag
 - Read the card details
 - If the card has Areas, use `/context-priming` with those areas for codebase awareness
 - Return a focused brief (aim for 5-15 bullet points, not essays)
+- **Advise only** — do not recommend cutting scope or dropping requirements. Flag risks and trade-offs, but respect the stated scope as given
 
 Here are the 6 available perspectives:
 
@@ -64,7 +67,7 @@ Here are the 6 available perspectives:
 > You are a codebase archaeologist. Read the design doc and card details, then search the existing codebase for related patterns, reusable components, utilities, or conventions. Use `/context-priming` with the card's Areas and explore the code. Report: What existing code can be reused? What patterns should this design follow for consistency? Are there similar features we can learn from? Is there anything we'd be duplicating unnecessarily?
 
 #### 5. Simplification Advocate
-> You are a complexity skeptic. Read the design doc and card details, then challenge every piece of complexity. For each requirement or design decision, ask: Is this truly needed? Could it be simpler? Could we defer this part? Is there a 20% effort solution that delivers 80% of the value? Your job is to push back on over-engineering and scope creep. Propose concrete simplifications with clear trade-offs.
+> You are a complexity skeptic. Read the design doc and card details, then look for ways the *implementation* could be simpler while still meeting the stated requirements. For each design decision, ask: Could the implementation be simpler? Is there a less complex way to achieve this requirement? Are we over-engineering the solution? Propose concrete simplifications with clear trade-offs. **Important:** Do NOT recommend cutting requirements or reducing scope — the requirements are the user's decision. Focus on simpler ways to achieve what's been asked for.
 
 #### 6. Edge Case Hunter
 > You are a boundary condition specialist. Read the design doc and card details, then enumerate edge cases, boundary conditions, and scenarios the design should handle. Think about: empty/null/missing data, concurrent access, very large inputs, rapid repeated actions, permission boundaries, network failures, interrupted operations, first-use vs power-user flows. Rate each edge case by likelihood and severity.
@@ -81,7 +84,7 @@ Once the agents return, **synthesize** their findings:
    - 🟡 **Should consider** — meaningful improvement or risk worth discussing
    - 🟢 **Nice to know** — interesting perspective, may inform decisions later
 3. Update the design doc with a new **"Analysis Notes"** section capturing the key findings.
-4. Recommend which items should be folded into the design requirements vs deferred.
+4. Present options and suggestions — do NOT unilaterally fold findings into requirements or cut scope. The user decides what to act on.
 
 ---
 
@@ -93,6 +96,13 @@ Now begin the normal design iteration:
 - Update the design doc as decisions are made
 - Focus on goals, constraints, and acceptance criteria
 
+**IMPORTANT — Surface everything in your message.** Do not assume the user has read the design document. Every time you respond, list in your conversation message:
+- Any **outstanding questions** that need answers
+- Any **options or trade-offs** that need a decision
+- Any **suggestions** you want feedback on
+
+Questions written into the doc but not surfaced in your message are effectively invisible.
+
 **When design is complete — assess complexity:**
 
 Look at the scope of work:

package/templates/updates/actions/design-requirements.md

@@ -1,6 +1,6 @@
 ---
 name: design-requirements
-version: 1.0.0
+version: 1.1.0
 label: "Design Doc"
 description: "Create a requirements document through iterative discovery"
 group: "Card Actions"
@@ -21,6 +21,8 @@ classes:
 
 We're starting a **requirements discovery** session for card `{{card.id}}`. The goal is to create a design document that captures WHAT we're building and WHY - not HOW (unless architectural decisions are essential to the requirements).
 
+**Your role is to investigate and advise.** You must NOT unilaterally cut scope, drop requirements, or decide what to build. All scope and direction decisions belong to the user. Present findings, options, and trade-offs — then ask.
+
 > Card details are provided above. Run `sly-kanban show {{card.id}}` only if you need additional detail.
 
 **Workflow:**
@@ -68,6 +70,14 @@ When in doubt, lean toward creating the feature spec — it's better to over-doc
 - Keep the document updated after each decision
 - Focus on goals, constraints, and acceptance criteria
 - Flag when you think the requirements are complete
+- Do NOT unilaterally cut scope or drop requirements — the user decides what's in and out
+
+**IMPORTANT — Surface everything in your message.** Do not assume the user has read the design document. Every time you respond, list in your conversation message:
+- Any **outstanding questions** that need answers
+- Any **options or trade-offs** that need a decision
+- Any **suggestions** you want feedback on
+
+Questions written into the doc but not surfaced in your message are effectively invisible.
 
 ---
 

package/templates/updates/actions/explore.md

@@ -8,7 +8,7 @@ placement: startup
 scope: global
 classes:
   global-terminal: 10
-  project-terminal: 30
+  project-terminal: 40
 ---
 
 {{projectContext}}

package/templates/updates/actions/implement.md

@@ -7,7 +7,7 @@ group: "Card Actions"
 placement: both
 scope: global
 classes:
-  design: 70
+  design: 80
   implementation: 10
 ---
 

package/templates/updates/actions/onboard.md

@@ -1,6 +1,6 @@
 ---
 name: onboard
-version: 1.0.0
+version: 1.1.0
 label: "Onboard"
 description: "Analyze and improve a backlog item, then move to design"
 group: "Card Actions"
@@ -23,7 +23,7 @@ Onboard this backlog item. Analyze it, improve it, and move it to design.
 **Do this:**
 1. Analyze the card - understand the intent from title and description
 2. Improve the title - make it clear, concise, action-oriented
-3. Rewrite the description - structure logically, capture the essential gist
+3. Rewrite the description - structure logically, capture the essential gist. **Do not add new solutions or implementation suggestions** — that belongs in the design phase. However, preserve any solution ideas already present in the original description.
 4. Set appropriate areas (run `sly-kanban areas` to see options)
 4.5 Potentially use context-priming to understand that area better
 5. Set correct type and priority
@@ -34,5 +34,3 @@ Onboard this backlog item. Analyze it, improve it, and move it to design.
 - What you understood the intent to be
 - What changes you made and why
 - Ask for confirmation - if I disagree, I'll tell you what to adjust
-# test change
-# user edit

package/templates/updates/actions/show-card.md

@@ -8,10 +8,10 @@ placement: both
 scope: global
 classes:
   backlog: 30
-  design: 80
+  design: 90
   done: 40
   implementation: 70
-  testing: 70
+  testing: 80
 ---
 
 Show the full details of this card:

package/templates/updates/actions/summarize.md

@@ -7,11 +7,11 @@ group: "Session"
 placement: startup
 scope: global
 classes:
-  design: 50
+  design: 60
   done: 20
   implementation: 50
-  project-terminal: 20
-  testing: 50
+  project-terminal: 30
+  testing: 60
 ---
 
 {{cardContext}}

package/templates/updates/actions/test-review.md

@@ -7,7 +7,7 @@ group: "Card Actions"
 placement: both
 scope: global
 classes:
-  testing: 90
+  testing: 100
 ---
 
 {{cardContext}}

package/templates/updates/skills/kanban/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: kanban
-version: 1.4.0
-updated: 2026-03-11
-description: "Manage kanban cards via CLI with commands for search, create, update, move, reorder, problem tracking, cross-agent notes, and scheduled automations"
+version: 1.5.0
+updated: 2026-04-03
+description: "Manage kanban cards via CLI with commands for search, create, update, move, reorder, problem tracking, cross-agent notes, scheduled automations, and cross-card prompt execution"
 provider: claude
 ---
 
@@ -26,8 +26,22 @@ Manage kanban cards via CLI: `sly-kanban <command>`
 | `problem` | Track issues on cards |
 | `notes` | Manage cross-agent notes |
 | `automation` | Configure and manage scheduled automations |
+| `prompt` | Send a prompt to another card's session (cross-card) |
+| `respond` | Reply to a cross-card prompt (--wait callback) |
 | `areas` | List available areas |
 
+## Card Identification
+
+All commands accept either a **card ID** or an **exact card title** (case-insensitive, non-archived cards only):
+
+```bash
+sly-kanban show card-1234567890      # By ID
+sly-kanban show "Test Card"          # By exact title
+sly-kanban prompt "Test Card" "do X" # Title works for prompt too
+```
+
+If a title doesn't match, use the card ID instead.
+
 ## Quick Reference
 
 ```bash
@@ -269,6 +283,66 @@ sly-kanban automation list --tag "deploy"
 - One-shot automations auto-disable after firing, config preserved
 - "Report via messaging" toggle appends instructions for the agent to send results
 
+## Cross-Card Prompt Execution
+
+Send prompts to other cards' sessions for orchestration, multi-provider review, and automation chains.
+
+**IMPORTANT:** Only use `sly-kanban prompt` when **explicitly instructed** to do so — either by a user, a card description, or an automation instruction. Never fire prompts at other cards on your own initiative (e.g., during testing, exploration, or as a "helpful" side-effect). Cross-card prompts start real sessions that consume resources and are hard to track if unexpected.
+
+### Fire-and-Forget (async)
+
+```bash
+sly-kanban prompt <card-id> "Your prompt text"
+sly-kanban prompt <card-id> "Your prompt" --provider codex
+sly-kanban prompt <card-id> "Your prompt" --provider codex --model o3
+sly-kanban prompt <card-id> "Your prompt" --fresh   # Stop existing session, start clean
+```
+
+Delivers the prompt and returns immediately. Session handling:
+- **Running session** → submits prompt to it directly
+- **Stopped session** → **resumes** it (preserves conversation context), then delivers the prompt
+- **No session** → creates a fresh one
+
+Use `--fresh` only when you explicitly want to discard the existing session and start clean. Without it, stopped sessions are always resumed to preserve context.
+
+**Card context is auto-injected.** Every prompt is automatically prepended with the target card's ID, title, stage, type, priority, and description. The called AI always knows its own card details without needing to look them up. Your prompt text follows after a `---` separator.
+
+### Wait-for-Response (sync)
+
+```bash
+sly-kanban prompt <card-id> "Analyze this design" --wait --timeout 120
+```
+
+Sends the prompt with an embedded callback instruction. The called card must run `sly-kanban respond` to return data. The CLI blocks until the response arrives or the timeout is reached.
+
+**Timeout outcomes:**
+- Response received → data printed to stdout (exit 0)
+- Timeout + session still active → message indicating work is ongoing (exit 1)
+- Timeout + session idle → terminal snapshot showing what blocked it (exit 1)
+
+Late responses are automatically injected into the calling session's terminal even after timeout.
+
+### Responding to a Prompt
+
+When your session receives a prompt with a callback instruction like:
+
+> When you have completed this task, you MUST run: `sly-kanban respond <response-id> "<your response>"`
+
+Run the respond command:
+
+```bash
+sly-kanban respond <response-id> "Your response data here"
+```
+
+### Session Guards
+
+The submit endpoint enforces three checks:
+1. **Call-locked** — another `--wait` prompt is active on the target session → rejected (409)
+2. **Active/busy** — the target session is mid-generation → rejected (409)
+3. **Idle/ready** — proceeds with submission
+
+Use `--force` to bypass all guards.
+
 ## Error Handling
 
 The CLI provides clear error messages: