codemini-cli 0.5.0 → 0.5.1

package/skills/superpowers-lite/SKILL.md

@@ -4,9 +4,9 @@ description: Concise workflow skill tuned for 30B-class models: prefer structure
 version: 0.3.0
 ---
 
-Use this skill as the default lightweight operating style for all coding work.
+Use this skill as the default operating style for all coding work, preferring lightweight approaches but invoking specialized skills when needed.
 
-This is the default, not an interrogation mode. Keep help calm and direct. For high-risk decisions only, add a light Grill Me pass: ask 1-3 sharp questions about assumptions, failure modes, or verification before proceeding. Challenge the plan, not the person.
+This is the default, not an interrogation mode. Keep help calm and direct. For decisions that affect multiple systems, involve irreversible changes, or have significant user impact only, add a light Grill Me pass: ask 1-3 sharp questions about assumptions, failure modes, or verification before proceeding. Challenge the plan, not the person.
 
 **Announce when using a skill:** Before following any route below, say "Using [skill name] to [purpose]" in your response. This signals intent and prevents silent skill skipping.
 
@@ -15,6 +15,7 @@ This is the default, not an interrogation mode. Keep help calm and direct. For h
 Before responding to ANY user message, check whether a skill applies. If there is even a small chance a skill is relevant, YOU MUST invoke it. This is not optional.
 
 **Skill check comes BEFORE:**
+
 - Clarifying questions
 - Code exploration
 - Writing code
@@ -24,43 +25,28 @@ Before responding to ANY user message, check whether a skill applies. If there i
 
 If you catch yourself thinking any of the following, STOP — you are about to skip a skill incorrectly:
 
-| Thought | Reality |
-|---|---|
-| "This is too simple for a skill" | Simple tasks derail too. Use the skill. |
-| "I need more context first" | Skills tell you HOW to gather context. Check first. |
-| "The skill is overkill here" | A lightweight pass is cheaper than rework. |
-| "I'll just do this one thing first" | Do the skill check BEFORE anything. |
-| "I already know what to do" | Knowing the concept ≠ following the process. |
+| Thought                             | Reality                                             |
+| ----------------------------------- | --------------------------------------------------- |
+| "This is too simple for a skill"    | Simple tasks derail too. Use the skill.             |
+| "I need more context first"         | Skills tell you HOW to gather context. Check first. |
+| "The skill is overkill here"        | A lightweight pass is cheaper than rework.          |
+| "I'll just do this one thing first" | Do the skill check BEFORE anything.                 |
+| "I already know what to do"         | Knowing the concept ≠ following the process.        |
 
 ## Routing
 
 Evaluate the user's request and YOU MUST follow exactly one route:
 
-1. **Task is clear, small, and obvious path:**
-   - Execute directly
-   - Do NOT invoke brainstorming
-
-2. **Non-trivial implementation that needs codebase exploration, touches multiple areas, or changes shared behavior:**
-   - YOU MUST invoke `writing-plans` skill
-   - Inspect first, then present an implementation plan for approval
-   - Do NOT jump straight into coding
-
-3. **Goal is clear but multiple reasonable approaches exist and the missing piece is user preference or tradeoff choice:**
-   - YOU MUST invoke `brainstorm` skill
-   - Follow brainstorm process — do NOT substitute it with ad-hoc questions
-
-4. **Request is missing a key constraint or success condition:**
-   - Ask exactly one clarifying question
-   - Do NOT give options or write code
-   - Stop and wait for the answer
-
-5. **Request is greenfield and underspecified** ("build a page", "make a site", "generate an app"):
-   - Treat as missing key constraints
-   - Ask one high-value question
-   - Do NOT assume features, scope, or storage model
-   - Stop and wait for the answer
+| Condition                                                                                                          | Action                                                                                                                                        |
+| ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| Task is clear, small, and obvious path                                                                             | Execute directly. Do NOT invoke brainstorming.                                                                                                |
+| Non-trivial implementation that needs codebase exploration, touches multiple areas, or changes shared behavior     | YOU MUST invoke `writing-plans` skill. Inspect first, then present an implementation plan for approval. Do NOT jump straight into coding.     |
+| Goal is clear but multiple reasonable approaches exist and the missing piece is user preference or tradeoff choice | YOU MUST invoke `brainstorm` skill. Follow brainstorm process — do NOT substitute it with ad-hoc questions.                                   |
+| Request is missing a key constraint or success condition                                                           | Ask exactly one clarifying question. Do NOT give options or write code. Stop and wait for the answer.                                         |
+| Request is greenfield and underspecified ("build a page", "make a site", "generate an app")                        | Treat as missing key constraints. Ask one high-value question. Do NOT assume features, scope, or storage model. Stop and wait for the answer. |
 
 **Decision boundary:**
+
 - Use `brainstorm` when one focused user answer will determine the direction.
 - Use `writing-plans` when the task is implementation-shaped but needs a plan before coding.
 - If both could apply, prefer `brainstorm` first when the core uncertainty is user intent; prefer `writing-plans` first when the core uncertainty is codebase impact.

package/skills/writing-plans/SKILL.md

@@ -1,67 +1,67 @@
----
-name: writing-plans
-description: Use when you have a clear goal or approved design for a non-trivial task, before touching code. Creates a step-by-step implementation plan with exact file paths, code, and verification steps.
-version: 0.1.0
----
-
-Use this skill when the task is implementation-shaped but large enough that jumping straight into coding is risky.
-
-**Announce:** When entering writing-plans, say "Using writing-plans to create an implementation plan."
-
-## When to Use
-
-- Task touches 3+ files or multiple areas of the codebase
-- Task changes shared behavior, APIs, or data flow
-- Task has interdependent steps where order matters
-- You need user sign-off before starting work
-
-## When NOT to Use
-
-- Single-file fix with a clear solution → just do it
-- Task is a direct extension of an existing pattern → just do it
-- User explicitly says to skip planning → respect that
-
-## Plan Format
-
-Write the plan as a markdown checklist. Each step is one action (2-5 minutes of work).
-
-```markdown
-# [Task Name] Plan
-
-**Goal:** [one sentence]
-**Files:** [list files that will be created or modified]
-
-### Phase 1: [Phase name]
-
-- [ ] **Step N: [action verb + what]**
-  - File: `exact/path/to/file.ext`
-  - What: [specific change]
-  - Verify: [how to confirm it works]
-
-### Phase 2: [Phase name]
-
-- [ ] ...
-```
-
-## Rules
-
-1. **Exact file paths always.** No "the relevant file" or "in the component directory".
-2. **Show code in steps that change code.** No "add appropriate error handling" without showing the code.
-3. **No placeholders.** No "TBD", "TODO", "implement later", "similar to step N". If a step needs code, write the code.
-4. **Every step is verifiable.** Include a test command, expected output, or visual check.
-5. **YAGNI.** Only plan what was asked for. Do not add "nice to have" steps.
-6. **DRY.** If two steps share logic, plan the shared piece first.
-
-## Self-Review
-
-After writing the plan, check:
-- Can you point to a step for every requirement? If not, add the missing step.
-- Any placeholders or vague descriptions? Replace with specifics.
-- Do types and function names match across steps? Fix inconsistencies.
-- Is the order correct? Steps that depend on earlier work must come after.
-
-## Exit
-
-After the user approves the plan → proceed to implement step by step.
-After each step → verify before moving to the next.
-If a step reveals the plan is wrong → stop, explain, and update the plan before continuing.
+---
+name: writing-plans
+description: Use when you have a clear goal or approved design for a non-trivial task, before touching code. Creates a step-by-step implementation plan with exact file paths, code, and verification steps.
+version: 0.1.0
+---
+
+Use this skill when the task is implementation-shaped but large enough that jumping straight into coding is risky.
+
+**Announce:** When entering writing-plans, say "Using writing-plans to create an implementation plan."
+
+## When to Use
+
+- Task touches 3+ files or multiple areas of the codebase
+- Task changes shared behavior, APIs, or data flow
+- Task has interdependent steps where order matters
+- You need user sign-off before starting work
+
+## When NOT to Use
+
+- Single-file fix with a clear solution → just do it
+- Task is a direct extension of an existing pattern → just do it
+- User explicitly says to skip planning → respect that
+
+## Plan Format
+
+Write the plan as a markdown checklist. Each step is one action (2-5 minutes of work).
+
+```markdown
+# [Task Name] Plan
+
+**Goal:** [one sentence]
+**Files:** [list files that will be created or modified]
+
+### Phase 1: [Phase name]
+
+- [ ] **Step N: [action verb + what]**
+  - File: `exact/path/to/file.ext`
+  - What: [specific change]
+  - Verify: [how to confirm it works]
+
+### Phase 2: [Phase name]
+
+- [ ] ...
+```
+
+## Rules
+
+1. **Exact file paths always.** No "the relevant file" or "in the component directory".
+2. **Show code in steps that change code.** No "add appropriate error handling" without showing the code.
+3. **No placeholders.** No "TBD", "TODO", "implement later", "similar to step N". If a step needs code, write the code.
+4. **Every step is verifiable.** Include a test command, expected output, or visual check.
+5. **YAGNI.** Only plan what was asked for. Do not add "nice to have" steps.
+6. **DRY.** If two steps share logic, plan the shared piece first.
+
+## Self-Review
+
+After writing the plan, check:
+- Can you point to a step for every requirement? If not, add the missing step.
+- Any placeholders or vague descriptions? Replace with specifics.
+- Do types and function names match across steps? Fix inconsistencies.
+- Is the order correct? Steps that depend on earlier work must come after.
+
+## Exit
+
+After the user approves the plan → proceed to implement step by step.
+After each step → verify before moving to the next.
+If a step reveals the plan is wrong → stop, explain, and update the plan before continuing.

package/src/core/chat-runtime.js

@@ -22,7 +22,7 @@ import {
   estimateMessagesTokens,
   parseCompactArgs
 } from './context-compact.js';
-import { buildSystemPromptWithReplyLanguage } from './reply-language.js';
+import { buildSystemPromptWithReplyLanguage, getReplyLanguage, getReplyLanguageName } from './reply-language.js';
 import { buildSystemPromptWithSoul } from './soul.js';
 import { getProjectPlansDir, getProjectSpecsDir, getProjectWorkspaceDir, getSessionsDir } from './paths.js';
 import { buildProjectContextSnippet, initializeProjectIndex } from './project-index.js';
@@ -341,6 +341,104 @@ const PROJECT_REQUIREMENTS_SECTION_MARKERS = [
   { key: 'questions', marker: 'REQUIREMENTS_OPEN_QUESTIONS', labels: ['10', 'open questions', 'unknowns', '待确认问题', '待确认', '问题'] },
   { key: 'evidence', marker: 'REQUIREMENTS_EVIDENCE_INDEX', labels: ['11', 'evidence', 'source evidence', 'source evidence index', '源码证据索引', '证据索引', '源码证据'] }
 ];
+const PROJECT_REQUIREMENTS_SHELL_COPY = {
+  en: {
+    html_lang: 'en',
+    title: 'Project Requirements Report',
+    meta_workspace: 'Workspace',
+    meta_date: 'Date',
+    meta_generated: 'Generated',
+    nav_label: 'Report sections',
+    nav_summary: 'Summary',
+    nav_architecture: 'Architecture',
+    nav_interfaces: 'Interfaces',
+    nav_requirements: 'Requirements',
+    nav_flows: 'Flows',
+    nav_domain: 'Domain Model',
+    nav_security: 'Security',
+    nav_errors: 'Errors',
+    nav_nonfunctional: 'Non-functional',
+    nav_questions: 'Open Questions',
+    nav_evidence: 'Evidence',
+    search_placeholder: 'Search APIs, modules, evidence...',
+    expand_all: 'Expand all',
+    collapse_all: 'Collapse all',
+    questions_only: 'Questions only',
+    show_all_sections: 'Show all sections',
+    no_results: 'No matching content found.',
+    heading_summary: 'Executive Summary',
+    heading_architecture: 'System Architecture',
+    heading_interfaces: 'Interface Inventory',
+    heading_requirements: 'Requirement Cards',
+    heading_flows: 'Core Flows',
+    heading_domain: 'Domain Model And Data Ownership',
+    heading_security: 'Permissions, Security, And Compliance',
+    heading_errors: 'Error Handling And Edge Cases',
+    heading_nonfunctional: 'Non-functional Requirements',
+    heading_questions: 'Open Questions',
+    heading_evidence: 'Source Evidence Index',
+    pending_summary: 'Pending summary.',
+    pending_architecture: 'Pending architecture map.',
+    pending_interfaces: 'Pending interface inventory.',
+    pending_requirements: 'Pending requirement cards.',
+    pending_flows: 'Pending flow diagrams.',
+    pending_domain: 'Pending domain model and data ownership.',
+    pending_security: 'Pending permissions, security, and compliance notes.',
+    pending_errors: 'Pending error handling and edge cases.',
+    pending_nonfunctional: 'Pending non-functional requirements.',
+    pending_questions: 'Pending open questions.',
+    pending_evidence: 'Pending evidence index.',
+    back_to_top: 'Back to top'
+  },
+  zh: {
+    html_lang: 'zh-CN',
+    title: '项目需求报告',
+    meta_workspace: '工作区',
+    meta_date: '日期',
+    meta_generated: '生成时间',
+    nav_label: '报告章节',
+    nav_summary: '摘要',
+    nav_architecture: '系统架构',
+    nav_interfaces: '接口清单',
+    nav_requirements: '需求卡片',
+    nav_flows: '核心流程',
+    nav_domain: '领域模型',
+    nav_security: '权限与安全',
+    nav_errors: '异常与边界',
+    nav_nonfunctional: '非功能需求',
+    nav_questions: '开放问题',
+    nav_evidence: '证据索引',
+    search_placeholder: '搜索 API、模块、证据...',
+    expand_all: '全部展开',
+    collapse_all: '全部收起',
+    questions_only: '仅看问题',
+    show_all_sections: '显示全部章节',
+    no_results: '未找到匹配内容。',
+    heading_summary: '执行摘要',
+    heading_architecture: '系统架构',
+    heading_interfaces: '接口清单',
+    heading_requirements: '需求卡片',
+    heading_flows: '核心流程',
+    heading_domain: '领域模型与数据归属',
+    heading_security: '权限、安全与合规',
+    heading_errors: '异常处理与边界情况',
+    heading_nonfunctional: '非功能需求',
+    heading_questions: '开放问题',
+    heading_evidence: '源码证据索引',
+    pending_summary: '等待填写摘要。',
+    pending_architecture: '等待填写架构图。',
+    pending_interfaces: '等待填写接口清单。',
+    pending_requirements: '等待填写需求卡片。',
+    pending_flows: '等待填写流程图。',
+    pending_domain: '等待填写领域模型与数据归属。',
+    pending_security: '等待填写权限、安全与合规说明。',
+    pending_errors: '等待填写异常处理与边界情况。',
+    pending_nonfunctional: '等待填写非功能需求。',
+    pending_questions: '等待填写开放问题。',
+    pending_evidence: '等待填写证据索引。',
+    back_to_top: '返回顶部'
+  }
+};
 const PLAN_MEMORY_MARKERS = {
   findings: ['<!-- plan-findings-start -->', '<!-- plan-findings-end -->'],
   progress: ['<!-- plan-progress-start -->', '<!-- plan-progress-end -->']
@@ -2150,6 +2248,11 @@ function buildRuntimeStateSnapshot({ currentSession, config, model, executionMod
       value: currentSession?.planState?.status === 'pending_reflect_skill',
       enumerable: false,
       writable: false
+    },
+    replyLanguage: {
+      value: getReplyLanguage(config),
+      enumerable: false,
+      writable: false
     }
   });
   return snapshot;
@@ -3288,15 +3391,17 @@ function renderProjectRequirementsSectionContract(ignoredSections = []) {
   return lines.join('\n');
 }
 
-function buildProjectRequirementsSteps(renderedSkillPrompt, args = []) {
+function buildProjectRequirementsSteps(renderedSkillPrompt, args = [], config = {}) {
   const options = parseProjectRequirementsOptions(args);
   const userArgs = options.raw;
   const requestedFocus = userArgs ? `User request/focus: ${userArgs}` : 'User request/focus: full workspace requirements report.';
+  const replyLanguageName = getReplyLanguageName(config);
   const reportDate = formatLocalDate();
   const reportPath = `docs/requirements/${reportDate}-project-requirements.html`;
   const companionPath = `docs/requirements/${reportDate}-project-requirements.md`;
   const reportContract = [
     requestedFocus,
+    `Reply language: write generated report prose, UI labels inserted into the report, review notes, and final user-facing status in ${replyLanguageName} unless the user explicitly requested a different language. Do not translate REQUIREMENTS_* marker names or source code identifiers.`,
     `Primary report path: ${reportPath}`,
     `Optional companion Markdown path: ${companionPath}`,
     'A pre-created HTML shell already exists at the primary report path.',
@@ -3531,7 +3636,8 @@ async function createProjectRequirementsShell({
   planFile,
   goal,
   steps,
-  depth = 'standard'
+  depth = 'standard',
+  config = {}
 }) {
   const workspaceRoot = process.cwd();
   const absoluteReportPath = path.resolve(workspaceRoot, reportPath);
@@ -3539,8 +3645,9 @@ async function createProjectRequirementsShell({
   await fs.mkdir(path.dirname(absoluteReportPath), { recursive: true });
   const template = await fs.readFile(PROJECT_REQUIREMENTS_TEMPLATE, 'utf8');
   const now = new Date().toISOString();
+  const shellCopy = PROJECT_REQUIREMENTS_SHELL_COPY[getReplyLanguage(config)] || PROJECT_REQUIREMENTS_SHELL_COPY.zh;
   const html = replaceTemplateVariables(template, {
-    title: 'Project Requirements Report',
+    ...shellCopy,
     workspace_name: path.basename(workspaceRoot) || workspaceRoot,
     date: formatLocalDate(),
     generated_at: now
@@ -3617,7 +3724,7 @@ async function runProjectRequirementsPipeline({
   const reportPath = `docs/requirements/${reportDate}-project-requirements.html`;
   const companionPath = `docs/requirements/${reportDate}-project-requirements.md`;
   const manifestPath = `docs/requirements/${reportDate}-project-requirements.manifest.json`;
-  const steps = buildProjectRequirementsSteps(renderedSkillPrompt, parsedInput.args);
+  const steps = buildProjectRequirementsSteps(renderedSkillPrompt, parsedInput.args, config);
   const planFile = await writeMarkdownInProjectDir(
     'plans',
     'project-requirements-pipeline',
@@ -3632,7 +3739,8 @@ async function runProjectRequirementsPipeline({
     planFile,
     goal,
     steps,
-    depth: options.depth
+    depth: options.depth,
+    config
   });
   const planState = {
     status: 'approved',

package/src/core/fff-adapter.js

@@ -111,7 +111,7 @@ class FffMcpClient {
       capabilities: {},
       clientInfo: {
         name: 'codemini-cli',
-        version: '0.5.0'
+        version: '0.5.1'
       }
     });
     this.sendNotification('notifications/initialized', {});

package/src/core/reply-language.js

@@ -6,8 +6,17 @@ export function normalizeReplyLanguage(value) {
   return 'zh';
 }
 
+export function getReplyLanguage(config = {}) {
+  if (typeof config === 'string') return normalizeReplyLanguage(config);
+  return normalizeReplyLanguage(config?.ui?.reply_language);
+}
+
+export function getReplyLanguageName(config = {}) {
+  return getReplyLanguage(config) === 'en' ? 'English' : 'Simplified Chinese';
+}
+
 export function buildSystemPromptWithReplyLanguage(baseSystemPrompt, config = {}) {
-  const replyLanguage = normalizeReplyLanguage(config?.ui?.reply_language);
+  const replyLanguage = getReplyLanguage(config);
   const directive =
     replyLanguage === 'en'
       ? [