@zhiman_innies/innies-codex 0.122.36 → 0.122.37

package/assets/superpowers/skills/brainstorming/SKILL.md

@@ -7,16 +7,28 @@ description: "Use this before explicit creative design or implementation work -
 
 Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
 
-Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+Start by understanding the current project context, then either proceed with stated assumptions or ask one blocking question if missing information would materially change the design. Once you understand what you're building, present the design and get user approval.
 
 <HARD-GATE>
 Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+
+This is an implementation gate, not a permission to stall. If enough context exists, present a concrete design immediately and ask for approval once.
 </HARD-GATE>
 
 ## Anti-Pattern: "This Is Too Simple To Need A Design"
 
 Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
 
+## Execution Bias: Avoid Clarification Loops
+
+Do not turn brainstorming into a clarification loop.
+
+If the user explicitly delegates the design, proceed with stated assumptions. Examples include "需要", "继续", "你帮我重新设计吧", "直接帮我设计", "你帮我全自动实施", "go ahead", and "make reasonable assumptions".
+
+Treat short confirmations such as "需要" as permission to continue from prior context, not as a reason to restart the workflow. When the conversation already contains enough purpose, domain, actors, constraints, or success criteria to make a defensible design, state assumptions briefly and present the concrete design in the same response.
+
+Ask at most one blocking question when missing information would materially change the architecture, make implementation unsafe, or waste significant work. Do not ask serial background questions merely because more detail would be nice to have.
+
 ## Applicability Boundary
 
 Use brainstorming when the user explicitly asks to design, build, create, implement, modify, or optimize something. Examples include "我要设计 / 我准备做 / 应该怎么设计 / 应该如何设计", "I want to design / let's build", "How should I design X", "help me build a workflow platform", or "optimize this architecture".
@@ -29,16 +41,16 @@ Positive Chinese design examples include "我准备做一个 RAG 检索系统，
 
 ## Checklist
 
-You MUST create a task for each of these items and complete them in order:
+Create tasks for the relevant items and complete them in order. Skip non-applicable items; do not manufacture questions or documents just to satisfy the checklist.
 
-1. **Explore project context** — check files, docs, recent commits
+1. **Explore project context** — check files, docs, recent commits when working in an existing project
 2. **Offer visual companion** (if topic will involve visual questions) — this is its own message, not combined with a clarifying question. See the Visual Companion section below.
-3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-4. **Propose 2-3 approaches** — with trade-offs and your recommendation
-5. **Present design** — in sections scaled to their complexity, get user approval after each section
-6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
-7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
-8. **User reviews written spec** — ask user to review the spec file before proceeding
+3. **Assess context sufficiency** — proceed with stated assumptions, or ask at most one blocking question
+4. **Propose approaches** — lead with your recommendation; include alternatives only when they clarify a real trade-off
+5. **Present design** — scaled to complexity, then get user approval once
+6. **Write design doc** — only when the user requests a durable spec or the repo workflow requires it
+7. **Spec self-review** — if a spec was written, check for placeholders, contradictions, ambiguity, scope (see below)
+8. **User reviews written spec** — only if a spec was written
 9. **Transition to implementation** — invoke writing-plans skill to create implementation plan
 
 ## Process Flow
@@ -48,10 +60,13 @@ digraph brainstorming {
     "Explore project context" [shape=box];
     "Visual questions ahead?" [shape=diamond];
     "Offer Visual Companion\n(own message, no other content)" [shape=box];
-    "Ask clarifying questions" [shape=box];
-    "Propose 2-3 approaches" [shape=box];
-    "Present design sections" [shape=box];
+    "Enough context?" [shape=diamond];
+    "Ask one blocking question" [shape=box];
+    "State assumptions" [shape=box];
+    "Propose recommended approach" [shape=box];
+    "Present design" [shape=box];
     "User approves design?" [shape=diamond];
+    "Spec required?" [shape=diamond];
     "Write design doc" [shape=box];
     "Spec self-review\n(fix inline)" [shape=box];
     "User reviews spec?" [shape=diamond];
@@ -59,13 +74,18 @@ digraph brainstorming {
 
     "Explore project context" -> "Visual questions ahead?";
     "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
-    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
-    "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
-    "Ask clarifying questions" -> "Propose 2-3 approaches";
-    "Propose 2-3 approaches" -> "Present design sections";
-    "Present design sections" -> "User approves design?";
-    "User approves design?" -> "Present design sections" [label="no, revise"];
-    "User approves design?" -> "Write design doc" [label="yes"];
+    "Visual questions ahead?" -> "Enough context?" [label="no"];
+    "Offer Visual Companion\n(own message, no other content)" -> "Enough context?";
+    "Enough context?" -> "State assumptions" [label="yes"];
+    "Enough context?" -> "Ask one blocking question" [label="no"];
+    "Ask one blocking question" -> "State assumptions";
+    "State assumptions" -> "Propose recommended approach";
+    "Propose recommended approach" -> "Present design";
+    "Present design" -> "User approves design?";
+    "User approves design?" -> "Present design" [label="no, revise"];
+    "User approves design?" -> "Spec required?" [label="yes"];
+    "Spec required?" -> "Write design doc" [label="yes"];
+    "Spec required?" -> "Invoke writing-plans skill" [label="no"];
     "Write design doc" -> "Spec self-review\n(fix inline)";
     "Spec self-review\n(fix inline)" -> "User reviews spec?";
     "User reviews spec?" -> "Write design doc" [label="changes requested"];
@@ -82,14 +102,14 @@ digraph brainstorming {
 - Check out the current project state first (files, docs, recent commits)
 - Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
 - If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
-- For appropriately-scoped projects, ask questions one at a time to refine the idea
+- For appropriately-scoped projects, proceed once enough context is available
 - Prefer multiple choice questions when possible, but open-ended is fine too
-- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Ask at most one blocking question per turn; if the user has delegated the design, prefer stated assumptions over another question
 - Focus on understanding: purpose, constraints, success criteria
 
 **Exploring approaches:**
 
-- Propose 2-3 different approaches with trade-offs
+- Propose 2-3 different approaches with trade-offs when the choice is meaningful
 - Present options conversationally with your recommendation and reasoning
 - Lead with your recommended option and explain why
 
@@ -97,7 +117,7 @@ digraph brainstorming {
 
 - Once you believe you understand what you're building, present the design
 - Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
-- Ask after each section whether it looks right so far
+- Ask for approval once after the design, not after every small section
 - Cover: architecture, components, data flow, error handling, testing
 - Be ready to go back and clarify if something doesn't make sense
 
@@ -118,13 +138,13 @@ digraph brainstorming {
 
 **Documentation:**
 
-- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
+- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` only when the user requests a durable spec or the repo workflow requires it
   - (User preferences for spec location override this default)
 - Use elements-of-style:writing-clearly-and-concisely skill if available
 - Commit the design document to git
 
 **Spec Self-Review:**
-After writing the spec document, look at it with fresh eyes:
+If writing the spec document, look at it with fresh eyes:
 
 1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
 2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
@@ -134,7 +154,7 @@ After writing the spec document, look at it with fresh eyes:
 Fix any issues inline. No need to re-review — just fix and move on.
 
 **User Review Gate:**
-After the spec review loop passes, ask the user to review the written spec before proceeding:
+If a written spec is required, after the spec review loop passes, ask the user to review the written spec before proceeding:
 
 > "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
 
@@ -147,7 +167,8 @@ Wait for the user's response. If they request changes, make them and re-run the
 
 ## Key Principles
 
-- **One question at a time** - Don't overwhelm with multiple questions
+- **Execution bias** - If enough context exists, present a concrete design instead of asking another question
+- **One blocking question at a time** - Don't overwhelm with multiple questions
 - **Multiple choice preferred** - Easier to answer than open-ended when possible
 - **YAGNI ruthlessly** - Remove unnecessary features from all designs
 - **Explore alternatives** - Always propose 2-3 approaches before settling

package/assets/superpowers/skills/using-superpowers/SKILL.md

@@ -100,6 +100,8 @@ Only load brainstorming for explicit design/build/modify requests. Examples incl
 
 Concept explanation prompts are not brainstorming by default. If the user asks "what is / how does X work / 机制 / 原理 / 是什么 / 有什么区别", answer directly unless they also explicitly ask to design, build, implement, adapt, or modify something.
 
+When brainstorming is active, proceed once enough context is available. Do not let brainstorming become a serial interrogation loop. If the user has delegated the work or confirmed continuation, use stated assumptions and present a concrete design instead of asking non-blocking background questions.
+
 ## Skill Priority
 
 When multiple skills could apply, use this order:

package/bin/innies-config.js

@@ -16,6 +16,7 @@ const DEFAULT_CATALOG_FILENAME = "catalog.json";
 const DEFAULT_CONFIG_FILENAME = "config.toml";
 const DEFAULT_STATE_FILENAME = "innies-state.json";
 const DEFAULT_SUPERPOWERS_DIRNAME = "superpowers";
+const INSTALL_SUPERPOWERS_ENV = "INNIES_INSTALL_SUPERPOWERS";
 const SUPERPOWERS_MARKER_FILENAME = ".innies-superpowers.marker";
 const ZHIMAN_35B_PROVIDER_HEADER = "[model_providers.zhiman_35b]";
 const ZHIMAN_35B_RESPONSES_BASE_URL = "http://101.237.37.116:7380/v1";
@@ -52,7 +53,11 @@ export function ensureInniesHomeDefaults(homeDir) {
   const state = loadInniesState(homeDir);
   const catalogPath = path.join(homeDir, DEFAULT_CATALOG_FILENAME);
   ensureInniesCatalog(catalogPath);
-  ensureInniesSuperpowers(homeDir);
+  if (shouldInstallInniesSuperpowers()) {
+    ensureInniesSuperpowers(homeDir);
+  } else {
+    removeManagedInniesSuperpowers(homeDir);
+  }
   const nextState = ensureInniesConfig(
     path.join(homeDir, DEFAULT_CONFIG_FILENAME),
     catalogPath,
@@ -69,6 +74,11 @@ function defaultSuperpowersAssetPath() {
   return path.join(__dirname, "..", "assets", DEFAULT_SUPERPOWERS_DIRNAME);
 }
 
+function shouldInstallInniesSuperpowers() {
+  const value = process.env[INSTALL_SUPERPOWERS_ENV]?.trim().toLowerCase();
+  return value === "1" || value === "true" || value === "yes";
+}
+
 function loadDefaultCatalog() {
   return JSON.parse(fs.readFileSync(defaultCatalogAssetPath(), "utf8"));
 }
@@ -100,6 +110,16 @@ function ensureInniesSuperpowers(homeDir) {
   fs.writeFileSync(markerPath, `${fingerprint}\n`);
 }
 
+function removeManagedInniesSuperpowers(homeDir) {
+  const destDir = path.join(homeDir, DEFAULT_SUPERPOWERS_DIRNAME);
+  const markerPath = path.join(destDir, SUPERPOWERS_MARKER_FILENAME);
+  if (!fs.existsSync(markerPath)) {
+    return;
+  }
+
+  fs.rmSync(destDir, { recursive: true, force: true });
+}
+
 function readTextFile(filePath) {
   try {
     return fs.readFileSync(filePath, "utf8");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zhiman_innies/innies-codex",
-  "version": "0.122.36",
+  "version": "0.122.37",
   "license": "Apache-2.0",
   "bin": {
     "innies": "bin/innies.js"
@@ -23,7 +23,7 @@
     "postinstall": "node bin/innies-init.js"
   },
   "optionalDependencies": {
-    "@zhiman_innies/innies-codex-darwin-x64": "0.122.36-darwin-x64",
-    "@zhiman_innies/innies-codex-darwin-arm64": "0.122.36-darwin-arm64"
+    "@zhiman_innies/innies-codex-darwin-x64": "0.122.37-darwin-x64",
+    "@zhiman_innies/innies-codex-darwin-arm64": "0.122.37-darwin-arm64"
   }
 }