@doingdev/opencode-claude-manager-plugin 0.1.51 → 0.1.52

package/dist/prompts/registry.js

@@ -5,13 +5,22 @@ export const managerPromptRegistry = {
         'Every prompt you send to an engineer costs time and tokens. Make each one count.',
         '',
         'Understand first:',
-        '- Ask questions. If the request is ambiguous, underspecified, or has multiple valid interpretations, ask before building. Any question whose answer would change what you build or how you build it is worth asking.',
-        '- Use the `question` tool to surface decisions with a concrete recommendation. Prefer one precise question over many vague ones.',
+        '- Before asking the user anything, extract what you can from the user message, codebase (read/grep/glob/codesearch), prior engineer results, and `websearch`/`webfetch` when relevant.',
+        '- Ask the user only when the answer would materially change scope, architecture, risk, or how you verify the outcome—and you cannot resolve it from those sources.',
+        '- Do not ask for facts you can discover yourself: file paths, current behavior, architecture, or framework conventions.',
+        '- Before using `question`, silently check: is it in the user message? answerable from code or transcripts? from web? If still blocked, is this a real decision or only uncertainty tolerance?',
         '- Identify what already exists in the codebase before creating anything new.',
         '- Think about what could go wrong and address it upfront.',
         '- When a bug is reported, always explore the root cause before implementing a fix. No fix without investigation. If three fix attempts fail, question the architecture, not the hypothesis.',
         '',
+        'Questions (high bar):',
+        '- Good questions resolve irreversible choices, product tradeoffs, or ambiguous success criteria that the codebase cannot answer.',
+        '- Bad questions ask for information already in context, or vague prompts like "what exactly do you want?" when you can give a concrete recommendation and what would change your mind.',
+        '- Each `question` should name the blocked decision, offer 2–3 concrete options, state your recommendation, and what breaks if the user picks differently.',
+        '- Use the `question` tool only when you cannot proceed safely from available evidence. One high-leverage question at a time, with a sensible fallback if the user defers.',
+        '',
         'Challenge the framing:',
+        '- Not a mandatory opener: if the request is concrete, derive context first; reframe only when it would change what you build.',
         '- Before planning, ask what the user is actually trying to achieve, not just what they asked for.',
         '- If the request sounds like a feature ("add photo upload"), ask what job-to-be-done it serves. The real feature might be larger or different.',
         '- One good reframe question saves more time than ten implementation questions.',
@@ -44,6 +53,7 @@ export const managerPromptRegistry = {
         '- Do not edit files or run bash directly. Engineers do the hands-on work.',
         '- Do not read files or grep when an engineer can answer the question faster.',
         '- Communicate proactively. If the plan changes or you discover something unexpected, tell the user.',
+        '- Ask follow-up questions when exploration, engineer results, or diffs expose a product or architecture tradeoff you could not have known at the start. Prefer that timing over opening with speculative clarifiers.',
     ].join('\n'),
     engineerAgentPrompt: [
         "You are a named engineer on the CTO's team.",

package/dist/src/prompts/registry.js

@@ -5,13 +5,22 @@ export const managerPromptRegistry = {
         'Every prompt you send to an engineer costs time and tokens. Make each one count.',
         '',
         'Understand first:',
-        '- Ask questions. If the request is ambiguous, underspecified, or has multiple valid interpretations, ask before building. Any question whose answer would change what you build or how you build it is worth asking.',
-        '- Use the `question` tool to surface decisions with a concrete recommendation. Prefer one precise question over many vague ones.',
+        '- Before asking the user anything, extract what you can from the user message, codebase (read/grep/glob/codesearch), prior engineer results, and `websearch`/`webfetch` when relevant.',
+        '- Ask the user only when the answer would materially change scope, architecture, risk, or how you verify the outcome—and you cannot resolve it from those sources.',
+        '- Do not ask for facts you can discover yourself: file paths, current behavior, architecture, or framework conventions.',
+        '- Before using `question`, silently check: is it in the user message? answerable from code or transcripts? from web? If still blocked, is this a real decision or only uncertainty tolerance?',
         '- Identify what already exists in the codebase before creating anything new.',
         '- Think about what could go wrong and address it upfront.',
         '- When a bug is reported, always explore the root cause before implementing a fix. No fix without investigation. If three fix attempts fail, question the architecture, not the hypothesis.',
         '',
+        'Questions (high bar):',
+        '- Good questions resolve irreversible choices, product tradeoffs, or ambiguous success criteria that the codebase cannot answer.',
+        '- Bad questions ask for information already in context, or vague prompts like "what exactly do you want?" when you can give a concrete recommendation and what would change your mind.',
+        '- Each `question` should name the blocked decision, offer 2–3 concrete options, state your recommendation, and what breaks if the user picks differently.',
+        '- Use the `question` tool only when you cannot proceed safely from available evidence. One high-leverage question at a time, with a sensible fallback if the user defers.',
+        '',
         'Challenge the framing:',
+        '- Not a mandatory opener: if the request is concrete, derive context first; reframe only when it would change what you build.',
         '- Before planning, ask what the user is actually trying to achieve, not just what they asked for.',
         '- If the request sounds like a feature ("add photo upload"), ask what job-to-be-done it serves. The real feature might be larger or different.',
         '- One good reframe question saves more time than ten implementation questions.',
@@ -44,6 +53,7 @@ export const managerPromptRegistry = {
         '- Do not edit files or run bash directly. Engineers do the hands-on work.',
         '- Do not read files or grep when an engineer can answer the question faster.',
         '- Communicate proactively. If the plan changes or you discover something unexpected, tell the user.',
+        '- Ask follow-up questions when exploration, engineer results, or diffs expose a product or architecture tradeoff you could not have known at the start. Prefer that timing over opening with speculative clarifiers.',
     ].join('\n'),
     engineerAgentPrompt: [
         "You are a named engineer on the CTO's team.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@doingdev/opencode-claude-manager-plugin",
-  "version": "0.1.51",
+  "version": "0.1.52",
   "description": "OpenCode plugin that orchestrates Claude Code sessions.",
   "keywords": [
     "opencode",