@slycode/slycode 0.2.21 → 0.2.23

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slycode/slycode",
-  "version": "0.2.21",
+  "version": "0.2.23",
   "description": "AI-powered development workspace with kanban, terminal bridge, and skill management",
   "bin": {
     "slycode": "bin/slycode.js",

package/templates/changelog.json

@@ -0,0 +1,242 @@
+[
+  {
+    "version": "0.2.23",
+    "date": "2026-04-09",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "Show current git branch in the web dashboard and messaging responses"
+      },
+      {
+        "type": "feature",
+        "description": "Changelog modal in the dashboard — view version history and what shipped in each release"
+      },
+      {
+        "type": "bugfix",
+        "description": "Preserve card fields when merging cards via drag-and-drop"
+      },
+      {
+        "type": "bugfix",
+        "description": "Fix automation run notifications not being delivered via messaging"
+      },
+      {
+        "type": "improvement",
+        "description": "Clarify voice shortcut formatting in the tutorial template"
+      }
+    ]
+  },
+  {
+    "version": "0.2.22",
+    "date": "2026-04-03",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "Cross-card prompt execution: send prompts from one card session to another via the kanban CLI"
+      },
+      {
+        "type": "bugfix",
+        "description": "Fix double-submit when messaging delivered the same prompt twice in quick succession"
+      }
+    ]
+  },
+  {
+    "version": "0.2.21",
+    "date": "2026-03-30",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "Per-card provider model selection across web UI, bridge, and messaging — pick which model variant a session uses"
+      }
+    ]
+  },
+  {
+    "version": "0.2.20",
+    "date": "2026-03-29",
+    "changes": [
+      {
+        "type": "improvement",
+        "description": "Documentation refresh and feature guide updates"
+      }
+    ]
+  },
+  {
+    "version": "0.2.19",
+    "date": "2026-03-25",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "Shift+Enter inserts newlines in terminal input instead of submitting"
+      },
+      {
+        "type": "bugfix",
+        "description": "Fix session detection when working directory is a symlink"
+      },
+      {
+        "type": "improvement",
+        "description": "Cleaner PTY environment variables when spawning provider CLIs"
+      }
+    ]
+  },
+  {
+    "version": "0.2.18",
+    "date": "2026-03-25",
+    "changes": [
+      {
+        "type": "improvement",
+        "description": "MCP store pipeline updates: managed MCP servers in the canonical store"
+      }
+    ]
+  },
+  {
+    "version": "0.2.17",
+    "date": "2026-03-23",
+    "changes": [
+      {
+        "type": "improvement",
+        "description": "MCP feature spec groundwork and minor UI tweaks"
+      }
+    ]
+  },
+  {
+    "version": "0.2.16",
+    "date": "2026-03-22",
+    "changes": [
+      {
+        "type": "bugfix",
+        "description": "Terminal submit fix: Enter key now reliably submits prompts to the active provider"
+      }
+    ]
+  },
+  {
+    "version": "0.2.15",
+    "date": "2026-03-22",
+    "changes": [
+      {
+        "type": "improvement",
+        "description": "Replaced node-telegram-bot-api with raw Telegram API — smaller dependency footprint, fewer security audit issues"
+      },
+      {
+        "type": "bugfix",
+        "description": "Fix paste timing issues in the terminal so multi-line pastes land cleanly"
+      }
+    ]
+  },
+  {
+    "version": "0.2.14",
+    "date": "2026-03-22",
+    "changes": [
+      {
+        "type": "bugfix",
+        "description": "macOS launchd fix: services now spawn with the correct PATH"
+      },
+      {
+        "type": "bugfix",
+        "description": "PTY PATH fix: provider CLIs find the right binaries in inherited environments"
+      },
+      {
+        "type": "feature",
+        "description": "Spawn error toast: surface CLI spawn failures directly in the UI"
+      }
+    ]
+  },
+  {
+    "version": "0.2.13",
+    "date": "2026-03-22",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "sly-kanban archive --undo: restore archived cards from the CLI"
+      },
+      {
+        "type": "bugfix",
+        "description": "Fix createdAt timestamp on newly created cards"
+      }
+    ]
+  },
+  {
+    "version": "0.2.12",
+    "date": "2026-03-21",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "AWS Transcribe S3-based STT pipeline as an additional voice transcription backend"
+      },
+      {
+        "type": "bugfix",
+        "description": "Fix stale entries in the project registry after deletion"
+      }
+    ]
+  },
+  {
+    "version": "0.2.9",
+    "date": "2026-03-20",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "systemd-aware service lifecycle management on Linux"
+      },
+      {
+        "type": "feature",
+        "description": "slycode env wrapper for consistent service environment variables"
+      },
+      {
+        "type": "feature",
+        "description": "slycode restart command for clean service restarts"
+      }
+    ]
+  },
+  {
+    "version": "0.2.6",
+    "date": "2026-03-19",
+    "changes": [
+      {
+        "type": "improvement",
+        "description": "Store UI now shows all skills regardless of manifest filtering — better visibility for store contents"
+      }
+    ]
+  },
+  {
+    "version": "0.2.5",
+    "date": "2026-03-19",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "AWS Transcribe Streaming as a voice transcription backend option"
+      }
+    ]
+  },
+  {
+    "version": "0.2.4",
+    "date": "2026-03-18",
+    "changes": [
+      {
+        "type": "improvement",
+        "description": "Automation diagnostic logging for easier troubleshooting of scheduled runs"
+      }
+    ]
+  },
+  {
+    "version": "0.2.2",
+    "date": "2026-03-16",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "Quick-access cards in messaging: see active and recent cards immediately after switching projects"
+      }
+    ]
+  },
+  {
+    "version": "0.2.1",
+    "date": "2026-03-15",
+    "changes": [
+      {
+        "type": "feature",
+        "description": "Store manifest filtering in build pipeline — only manifest-approved skills ship in the package"
+      },
+      {
+        "type": "bugfix",
+        "description": "Instruction file check now validates correctly during session creation"
+      }
+    ]
+  }
+]

package/templates/kanban-seed.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 1,
   "cards": [],
-  "lastUpdated": "2026-03-28T22:34:01.687Z"
+  "lastUpdated": "2026-04-09T10:45:26.785Z"
 }

package/templates/store/actions/checkpoint.md

@@ -9,7 +9,7 @@ scope: global
 classes:
   design: 60
   implementation: 30
-  project-terminal: 50
+  project-terminal: 60
 ---
 
 /checkpoint

package/templates/store/actions/context.md

@@ -11,7 +11,7 @@ classes:
   design: 90
   done: 30
   implementation: 60
-  project-terminal: 60
+  project-terminal: 10
   testing: 60
 ---
 

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

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

package/templates/store/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/store/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/store/actions/explore.md

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

package/templates/store/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/store/actions/summarize.md

@@ -10,7 +10,7 @@ classes:
   design: 50
   done: 20
   implementation: 50
-  project-terminal: 20
+  project-terminal: 30
   testing: 50
 ---
 

package/templates/store/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:

package/templates/tutorial-project/documentation/kanban.json

@@ -31,7 +31,7 @@
         "updated_at": "{{TIMESTAMP}}",
         "id": "card-tutorial-2",
         "title": "If You Don't Like Tutorials",
-        "description": "If you want the fast version, here are the core points.\n\n- Move cards through stages by dragging them across lanes.\n- Open a card, go to Terminal, and run the stage action buttons; the AI handles the workflow for you.\n  - Base Kanban and messaging skills are included to teach your agent how to interact with SlyCode.\n  - It can move cards between lanes as part of your workflow.\n  - It can attach planning docs to cards (design docs, feature specs, and chore plans when used).\n  - It can add/edit notes and keep a running context trail.\n  - It can create and update testing checklists directly on the card.\n- Sly Actions are lane-aware meta-prompts built on top of your CLI skills/agents, and they can reuse those same skills/agents. You can customize them from the top-right menu (three-line icon).\n- Cards and workflows can be automated from the top-right clock icon.\n- Archived cards are visible via the top-right archive/box icon.\n- Card terminal (Terminal tab) [runs in project workspace].\n- Project terminal (bottom-right) [runs in project workspace].\n- Global terminal (Dashboard) [runs in SlyCode workspace].\n- Skills are managed from Dashboard/Toolkit: stored centrally, then deployed to projects for Claude or .agents (Codex/Gemini).\n- Voice input works after OpenAI API key setup; default hotkey is Ctrl + .\n- Telegram can be linked for updates.\n  - Create your own Telegram bot with @BotFather, then use that token in config.\n  - Add bot token and chat ID in your environment/config.\n  - Start messaging service and send a test message.\n  - For voice in Telegram, add your OpenAI key (STT) and ElevenLabs key (TTS) in `.env`.\n  - Enable report-via-messaging on automations when you want async summaries.\n  - You can also ask the agent to message you in any workflow at any time.\n\nIf this is enough context, jump straight to the companion card, or add one of your own projects from the dashboard and start working on your real code.",
+        "description": "If you want the fast version, here are the core points.\n\n- Move cards through stages by dragging them across lanes.\n- Open a card, go to Terminal, and run the stage action buttons; the AI handles the workflow for you.\n  - Base Kanban and messaging skills are included to teach your agent how to interact with SlyCode.\n  - It can move cards between lanes as part of your workflow.\n  - It can attach planning docs to cards (design docs, feature specs, and chore plans when used).\n  - It can add/edit notes and keep a running context trail.\n  - It can create and update testing checklists directly on the card.\n- Sly Actions are lane-aware meta-prompts built on top of your CLI skills/agents, and they can reuse those same skills/agents. You can customize them from the top-right menu (three-line icon).\n- Cards and workflows can be automated from the top-right clock icon.\n- Archived cards are visible via the top-right archive/box icon.\n- Card terminal (Terminal tab) [runs in project workspace].\n- Project terminal (bottom-right) [runs in project workspace].\n- Global terminal (Dashboard) [runs in SlyCode workspace].\n- Skills are managed from Dashboard/Toolkit: stored centrally, then deployed to projects for Claude or .agents (Codex/Gemini).\n- Voice input works after OpenAI API key setup; default hotkey is [Ctrl+.]\n- Telegram can be linked for updates.\n  - Create your own Telegram bot with @BotFather, then use that token in config.\n  - Add bot token and chat ID in your environment/config.\n  - Start messaging service and send a test message.\n  - For voice in Telegram, add your OpenAI key (STT) and ElevenLabs key (TTS) in `.env`.\n  - Enable report-via-messaging on automations when you want async summaries.\n  - You can also ask the agent to message you in any workflow at any time.\n\nIf this is enough context, jump straight to the companion card, or add one of your own projects from the dashboard and start working on your real code.",
         "type": "chore",
         "priority": "low",
         "order": 20

package/templates/updates/actions/checkpoint.md

@@ -9,7 +9,7 @@ scope: global
 classes:
   design: 60
   implementation: 30
-  project-terminal: 50
+  project-terminal: 60
 ---
 
 /checkpoint

package/templates/updates/actions/context.md

@@ -11,7 +11,7 @@ classes:
   design: 90
   done: 30
   implementation: 60
-  project-terminal: 60
+  project-terminal: 10
   testing: 60
 ---
 

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.
 
 ---