codemini-cli 0.1.15 → 0.1.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codemini-cli",
-  "version": "0.1.15",
+  "version": "0.1.16",
   "description": "Coding CLI optimized for small-model workflows and Windows PowerShell",
   "keywords": [
     "cli",

package/skills/brainstorm/SKILL.md

@@ -4,35 +4,54 @@ description: Lightweight brainstorming skill for 30B-class models. Use when a fe
 version: 0.1.0
 ---
 
-Use this skill before adding new behavior, new features, or meaningful workflow changes.
+Use this skill only after the controller has decided the task needs clarification or option comparison before coding.
 
 Primary purpose:
-- stop premature coding when the request is still fuzzy
-- narrow the decision to a small number of approaches
-- leave with one chosen direction
+- ask one high-value question when a key constraint is missing
+- compare 2-3 short options when the goal is clear but the approach is not
+- stop at a clear decision point
 
 Rules:
 
 1. Ask one question at a time.
 Do not dump a long questionnaire. Pick the most important uncertainty and resolve it first.
 
+1a. If a key uncertainty remains, stop after one question.
+Do not ask multiple numbered questions in the same reply. Do not continue into options, decisions, code, or file edits until that question is answered.
+
 2. Stay concrete.
-Focus on purpose, constraints, success criteria, and what should be intentionally left out.
+Focus only on the uncertainty that blocks execution.
 
-3. Offer 2-3 approaches.
-Keep each option short. Lead with the recommended option and say why.
+3. Offer 2-3 approaches only when the key constraint is already clear.
+Keep each option short and focused on the main tradeoff.
 
 4. Keep the design small.
-Write only enough design for the current scope. Do not inflate a simple task into a full spec process unless needed.
+Do not expand a simple task into a long design discussion.
 
 5. Confirm before implementation.
-Summarize the chosen direction in a few bullets or a short paragraph, then move to execution only after alignment.
+If options were given, wait for the user to choose unless the user explicitly asks for a recommendation.
 
 6. No code before convergence.
 Do not write implementation code, pseudo-code, or file edits while the direction is still being chosen.
 
+7. Do not decide for the user when the request is still under-specified.
+If the user has not provided enough information to choose confidently, ask the next best question and wait.
+
+8. Do not inspect the repo unless existing project context is directly relevant.
+For greenfield brainstorming, stay in conversation mode first.
+
 Output format:
 
+Mode A: key constraint missing
+
+Question:
+- ask:
+- why this matters:
+
+Wait for the user's answer.
+
+Mode B: goal is clear but approach choice remains
+
 Option 1:
 - idea:
 - pros:
@@ -57,9 +76,7 @@ After decision:
 
 Suggested flow:
 - Restate the task briefly
-- Ask the next best question when a key uncertainty blocks implementation
-- Propose options with tradeoffs
-- Confirm the chosen approach
+- Choose one mode only: Question or Options
 - Stop at a clear decision point
 
 Avoid:

package/skills/superpowers-lite/SKILL.md

@@ -12,6 +12,27 @@ Primary behavior:
 - keep edits local
 - verify before claiming success
 
+Routing:
+
+1. If the task is clear, small, and the implementation path is obvious:
+- execute directly
+- do not force brainstorming
+
+2. If the goal is clear but there are multiple reasonable implementation paths:
+- use `brainstorm`
+- give 2-3 short options
+- do not choose for the user unless the user explicitly asks for a recommendation
+
+3. If the request is still missing a key constraint or success condition:
+- ask exactly one clarifying question
+- do not give options yet
+- do not write code yet
+
+4. If the request is greenfield and underspecified, such as "build a page", "make a site", "generate an app", or similar:
+- treat it as missing key constraints by default
+- ask one high-value question before coding
+- do not assume features, storage model, or scope unless the user already gave them
+
 Core rules:
 
 1. Search first.
@@ -28,7 +49,10 @@ When a task can be split cleanly, use sub-agents for bounded subtasks so the mai
 - a concrete expected output
 
 4. Do not code against unclear requirements.
-If the requested behavior, scope, or acceptance is unclear, do not jump into implementation. Ask the next best question or use `brainstorm` to compare a few small options and converge first.
+If the requested behavior, scope, or acceptance is unclear, do not jump into implementation. First decide which of these applies:
+- missing key constraint -> ask one question
+- multiple valid approaches -> use `brainstorm`
+- clear enough to build -> proceed
 
 5. Read and write with intent.
 Use `read_file` only when shell output is not enough. Use `write_file` for edits. Avoid unnecessary tool calls and avoid rereading the same file without a reason.
@@ -39,7 +63,7 @@ Run the relevant test, check, or command before saying work is fixed or complete
 Default workflow:
 - Search with `rg`
 - Inspect local context
-- If the request is unclear, pause for clarification or brainstorm
+- If the request is unclear, first decide: ask one question, brainstorm, or proceed
 - Plan the next smallest step
 - Delegate if the work is independent
 - Edit

package/src/cli.js

@@ -4,7 +4,7 @@ import { handleConfig } from './commands/config.js';
 import { handleDoctor } from './commands/doctor.js';
 import { handleSkill } from './commands/skill.js';
 
-const VERSION = '0.1.15';
+const VERSION = '0.1.16';
 
 function printHelp() {
   console.log(`codemini ${VERSION}

package/src/core/chat-runtime.js

@@ -572,14 +572,19 @@ function selectAutoSkillNames(text = '') {
   const explicitBrainstorm =
     /(brainstorm|头脑风暴|方案|思路|设计一下|设计方案|怎么做|如何做|approach|options?)/i.test(input);
   const ambiguitySignals =
-    /(not sure|unsure|unclear|help me think|let'?s think|should we|which (?:approach|option|way)|best way|trade-?off|vs\b|versus|or should|要不要|不确定|不明确|先别写|先不要写|先讨论|先想一下|哪个方案|怎么设计|如何设计|取舍|还是)/i.test(
+    /(not sure|unsure|unclear|help me think|let'?s think|should we|which (?:approach|option|way)|best way|trade-?off|vs\b|versus|or should|maybe|roughly|just something simple|要不要|不确定|不明确|先别写|先不要写|先讨论|先想一下|哪个方案|怎么设计|如何设计|取舍|还是|大概|先做个|做一个简单的|先来个)/i.test(
       input
     );
   const featureRequest =
-    /\b(add|build|create|implement|support|introduce|design|refactor|change|update)\b/i.test(input) ||
-    /(新增|增加|实现|支持|设计|重构|改造|调整)/i.test(input);
+    /\b(add|build|create|generate|make|implement|support|introduce|design|refactor|change|update)\b/i.test(input) ||
+    /(新增|增加|实现|支持|设计|重构|改造|调整|生成|做一个|做个|创建)/i.test(input);
+  const greenfieldBuildRequest =
+    (/\b(build|create|generate|make)\b/i.test(input) || /(生成|做一个|做个|创建)/i.test(input)) &&
+    /(\b(project|app|site|website|page|dashboard|tool|component|landing page|html page)\b|项目|应用|网页|页面|网站|工具|组件|看板)/i.test(
+      input
+    );
 
-  if (explicitBrainstorm || (ambiguitySignals && featureRequest)) {
+  if (explicitBrainstorm || (ambiguitySignals && featureRequest) || greenfieldBuildRequest) {
     selected.push('brainstorm');
   }
   return selected;
@@ -2537,6 +2542,10 @@ export async function createChatRuntime({
         custom.name === 'brainstorm'
           ? [
               renderCommandPrompt(custom, []),
+              'Explicit brainstorm mode:',
+              '- Ask exactly one clarifying question first if any important uncertainty remains.',
+              '- Do not inspect the repo or generate code unless the user explicitly asks for that.',
+              '- Do not choose an option on the first reply unless the request is already specific enough or the user explicitly asks you to recommend one.',
               parsedInput.args.length > 0 ? `Current question:\n${parsedInput.args.join(' ')}` : ''
             ]
               .filter(Boolean)