ccjk 14.1.10 → 14.2.0

package/dist/templates/skills/ts-best-practices.md

@@ -0,0 +1,354 @@
+---
+name: ts-best-practices
+description: TypeScript 5.3+ best practices and patterns for type-safe development
+description_zh: TypeScript 5.3+ 最佳实践和类型安全开发模式
+version: 1.0.0
+category: programming
+triggers: ['/ts-best-practices', '/typescript', '/ts-patterns']
+use_when:
+  - Writing TypeScript code with strict typing
+  - Implementing generic constraints and utility types
+  - Optimizing TypeScript performance and maintainability
+  - Code review for TypeScript projects
+use_when_zh:
+  - 编写严格类型的 TypeScript 代码
+  - 实现泛型约束和工具类型
+  - 优化 TypeScript 性能和可维护性
+  - TypeScript 项目代码审查
+auto_activate: true
+priority: 8
+agents: [typescript-expert, code-reviewer]
+tags: [typescript, types, generics, patterns, best-practices]
+---
+
+# TypeScript Best Practices | TypeScript 最佳实践
+
+## Context | 上下文
+
+Use this skill when working with TypeScript 5.3+ projects that require strict typing, performance optimization, and maintainable code architecture. Essential for enterprise-grade TypeScript development.
+
+在使用 TypeScript 5.3+ 项目时使用此技能，需要严格类型、性能优化和可维护的代码架构。对于企业级 TypeScript 开发至关重要。
+
+## Best Practices | 最佳实践
+
+### 1. Strict Type Configuration | 严格类型配置
+
+```typescript
+// tsconfig.json - Recommended strict settings
+{
+  "compilerOptions": {
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "exactOptionalPropertyTypes": true,
+    "noImplicitReturns": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUncheckedSideEffectImports": true
+  }
+}
+```
+
+### 2. Generic Constraints | 泛型约束
+
+```typescript
+// ✅ Good: Proper generic constraints
+interface Repository<T extends { id: string }> {
+  findById(id: string): Promise<T | null>;
+  save(entity: T): Promise<T>;
+}
+
+// ✅ Good: Conditional types with constraints
+type ApiResponse<T> = T extends string
+  ? { message: T }
+  : { data: T };
+
+// ❌ Bad: Unconstrained generics
+interface BadRepository<T> {
+  findById(id: string): Promise<T | null>; // T could be anything
+}
+```
+
+### 3. Utility Types Usage | 工具类型使用
+
+```typescript
+// ✅ Good: Leverage built-in utility types
+interface User {
+  id: string;
+  name: string;
+  email: string;
+  password: string;
+}
+
+type PublicUser = Omit<User, 'password'>;
+type UserUpdate = Partial<Pick<User, 'name' | 'email'>>;
+type CreateUser = Omit<User, 'id'>;
+
+// ✅ Good: Custom utility types
+type NonNullable<T> = T extends null | undefined ? never : T;
+type DeepReadonly<T> = {
+  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];
+};
+```
+
+### 4. Type Guards and Assertions | 类型守卫和断言
+
+```typescript
+// ✅ Good: Type guards
+function isString(value: unknown): value is string {
+  return typeof value === 'string';
+}
+
+function isUser(obj: unknown): obj is User {
+  return typeof obj === 'object' &&
+         obj !== null &&
+         'id' in obj &&
+         'name' in obj;
+}
+
+// ✅ Good: Assertion functions
+function assertIsNumber(value: unknown): asserts value is number {
+  if (typeof value !== 'number') {
+    throw new Error('Expected number');
+  }
+}
+```
+
+## Common Patterns | 常用模式
+
+### 1. Builder Pattern with Types | 带类型的建造者模式
+
+```typescript
+class QueryBuilder<T> {
+  private conditions: Array<(item: T) => boolean> = [];
+
+  where<K extends keyof T>(
+    key: K,
+    value: T[K]
+  ): QueryBuilder<T> {
+    this.conditions.push(item => item[key] === value);
+    return this;
+  }
+
+  build(): (items: T[]) => T[] {
+    return items => items.filter(item =>
+      this.conditions.every(condition => condition(item))
+    );
+  }
+}
+
+// Usage
+const userFilter = new QueryBuilder<User>()
+  .where('status', 'active')
+  .where('role', 'admin')
+  .build();
+```
+
+### 2. Event System with Type Safety | 类型安全的事件系统
+
+```typescript
+interface EventMap {
+  'user:created': { user: User };
+  'user:updated': { user: User; changes: Partial<User> };
+  'user:deleted': { userId: string };
+}
+
+class TypedEventEmitter<T extends Record<string, any>> {
+  private listeners: {
+    [K in keyof T]?: Array<(data: T[K]) => void>;
+  } = {};
+
+  on<K extends keyof T>(
+    event: K,
+    listener: (data: T[K]) => void
+  ): void {
+    if (!this.listeners[event]) {
+      this.listeners[event] = [];
+    }
+    this.listeners[event]!.push(listener);
+  }
+
+  emit<K extends keyof T>(event: K, data: T[K]): void {
+    this.listeners[event]?.forEach(listener => listener(data));
+  }
+}
+
+// Usage with full type safety
+const emitter = new TypedEventEmitter<EventMap>();
+emitter.on('user:created', ({ user }) => {
+  console.log(`User ${user.name} created`); // ✅ Type-safe
+});
+```
+
+### 3. Branded Types for Domain Safety | 领域安全的品牌类型
+
+```typescript
+// ✅ Good: Branded types prevent mixing different IDs
+type UserId = string & { readonly brand: unique symbol };
+type ProductId = string & { readonly brand: unique symbol };
+
+function createUserId(id: string): UserId {
+  return id as UserId;
+}
+
+function createProductId(id: string): ProductId {
+  return id as ProductId;
+}
+
+function getUser(id: UserId): Promise<User> {
+  // Implementation
+}
+
+// This prevents accidental ID mixing
+const userId = createUserId('user-123');
+const productId = createProductId('product-456');
+
+getUser(userId); // ✅ Works
+getUser(productId); // ❌ Type error - prevents bugs
+```
+
+## Anti-Patterns | 反模式
+
+### 1. Avoid `any` and Type Assertions | 避免 `any` 和类型断言
+
+```typescript
+// ❌ Bad: Using any
+function processData(data: any): any {
+  return data.someProperty;
+}
+
+// ❌ Bad: Unsafe type assertions
+const user = data as User; // Could fail at runtime
+
+// ✅ Good: Proper typing with validation
+function processData<T extends { someProperty: unknown }>(
+  data: T
+): T['someProperty'] {
+  return data.someProperty;
+}
+
+// ✅ Good: Safe type assertions with validation
+function isUser(data: unknown): data is User {
+  return typeof data === 'object' &&
+         data !== null &&
+         'id' in data;
+}
+
+const user = isUser(data) ? data : null;
+```
+
+### 2. Avoid Overly Complex Types | 避免过于复杂的类型
+
+```typescript
+// ❌ Bad: Overly complex type that's hard to understand
+type ComplexType<T> = T extends infer U
+  ? U extends Record<string, any>
+    ? { [K in keyof U]: U[K] extends Function
+        ? ReturnType<U[K]> extends Promise<infer R>
+          ? R extends object
+            ? ComplexType<R>
+            : never
+          : never
+        : never }
+    : never
+  : never;
+
+// ✅ Good: Break down complex types into smaller, named pieces
+type AsyncReturnType<T> = T extends (...args: any[]) => Promise<infer R>
+  ? R
+  : never;
+
+type FunctionProperties<T> = {
+  [K in keyof T]: T[K] extends Function ? T[K] : never;
+};
+
+type ExtractAsyncReturns<T> = {
+  [K in keyof FunctionProperties<T>]: AsyncReturnType<T[K]>;
+};
+```
+
+### 3. Avoid Mutation of Readonly Types | 避免修改只读类型
+
+```typescript
+// ❌ Bad: Mutating readonly arrays
+function badSort(items: readonly number[]): readonly number[] {
+  return items.sort(); // Mutates the original array!
+}
+
+// ✅ Good: Create new arrays for readonly inputs
+function goodSort(items: readonly number[]): readonly number[] {
+  return [...items].sort();
+}
+
+// ✅ Good: Use proper readonly patterns
+interface ReadonlyConfig {
+  readonly apiUrl: string;
+  readonly timeout: number;
+  readonly features: readonly string[];
+}
+```
+
+## Performance Tips | 性能提示
+
+### 1. Use Type-Only Imports | 使用仅类型导入
+
+```typescript
+// ✅ Good: Type-only imports don't affect bundle size
+import type { User, ApiResponse } from './types';
+import { validateUser } from './validators';
+
+// ❌ Bad: Importing types as values
+import { User, ApiResponse, validateUser } from './module';
+```
+
+### 2. Optimize Conditional Types | 优化条件类型
+
+```typescript
+// ✅ Good: Efficient conditional type
+type IsArray<T> = T extends readonly any[] ? true : false;
+
+// ❌ Bad: Inefficient nested conditionals
+type BadIsArray<T> = T extends any[]
+  ? true
+  : T extends readonly any[]
+    ? true
+    : false;
+```
+
+### 3. Use Template Literal Types Wisely | 明智使用模板字面量类型
+
+```typescript
+// ✅ Good: Reasonable template literal usage
+type EventName = `on${Capitalize<string>}`;
+type HttpMethod = 'GET' | 'POST' | 'PUT' | 'DELETE';
+type ApiEndpoint = `/${string}`;
+
+// ❌ Bad: Overly complex template literals that slow compilation
+type BadComplexTemplate<T extends Record<string, any>> = {
+  [K in keyof T as `get${Capitalize<string & K>}From${Capitalize<string>}With${Capitalize<string>}`]: T[K];
+};
+```
+
+## Code Quality Checklist | 代码质量检查清单
+
+- [ ] All functions have explicit return types
+- [ ] Generic constraints are properly defined
+- [ ] No usage of `any` or unsafe type assertions
+- [ ] Proper error handling with typed errors
+- [ ] Type guards are used for runtime validation
+- [ ] Utility types are leveraged appropriately
+- [ ] Complex types are broken down into smaller pieces
+- [ ] Type-only imports are used where possible
+- [ ] Branded types are used for domain safety
+- [ ] Performance implications of types are considered
+
+## 代码质量检查清单
+
+- [ ] 所有函数都有明确的返回类型
+- [ ] 泛型约束定义正确
+- [ ] 不使用 `any` 或不安全的类型断言
+- [ ] 使用类型化错误进行适当的错误处理
+- [ ] 使用类型守卫进行运行时验证
+- [ ] 适当利用工具类型
+- [ ] 复杂类型被分解为更小的部分
+- [ ] 在可能的地方使用仅类型导入
+- [ ] 使用品牌类型确保领域安全
+- [ ] 考虑类型的性能影响

package/package.json

@@ -1,8 +1,7 @@
 {
   "name": "ccjk",
   "type": "module",
-  "version": "14.1.10",
-  "packageManager": "pnpm@10.17.1",
+  "version": "14.2.0",
   "description": "Production-ready AI dev environment for Claude Code, Codex, and modern coding workflows with 30-second onboarding, persistent memory, Agent Teams, remote control, and capability discovery.",
   "author": {
     "name": "CCJK Team",
@@ -81,46 +80,6 @@
   "engines": {
     "node": ">=20"
   },
-  "scripts": {
-    "dev": "tsx ./src/cli.ts",
-    "build": "pnpm build:release:deps && pnpm build:root",
-    "build:root": "unbuild",
-    "build:release:deps": "pnpm --filter @ccjk/wire build && pnpm --filter @ccjk/evolution build",
-    "start": "node bin/ccjk.mjs",
-    "typecheck": "pnpm build:release:deps && pnpm typecheck:root",
-    "typecheck:root": "tsc --noEmit",
-    "release:verify": "node scripts/release-verify.mjs",
-    "release:verify:full": "node scripts/release-verify.mjs --with-tests",
-    "prepublishOnly": "node scripts/validate-prepublish.mjs && pnpm contract:check && pnpm build",
-    "lint": "eslint",
-    "lint:fix": "eslint --fix",
-    "test": "vitest",
-    "test:ui": "vitest --ui",
-    "test:coverage": "vitest run --coverage",
-    "test:run": "vitest run",
-    "test:release": "vitest run src/commands/menu/index.test.ts src/commands/menu/main-menu.test.ts src/utils/tool-update-scheduler.test.ts tests/commands/api-config-selector.test.ts tests/commands/init.silent.test.ts tests/commands/onboarding-wizard.test.ts tests/commands/research.test.ts tests/utils/banner.test.ts tests/utils/code-type-resolver.test.ts tests/utils/memory-feature.test.ts",
-    "test:watch": "vitest watch",
-    "test:e2e": "NODE_ENV=test vitest --config vitest.e2e.config.ts",
-    "test:e2e:run": "NODE_ENV=test vitest run --config vitest.e2e.config.ts",
-    "test:e2e:ui": "NODE_ENV=test vitest --config vitest.e2e.config.ts --ui",
-    "test:e2e:coverage": "NODE_ENV=test vitest run --config vitest.e2e.config.ts --coverage",
-    "test:e2e:debug": "NODE_ENV=test CCJK_E2E_DEBUG=true vitest --config vitest.e2e.config.ts",
-    "test:integration": "NODE_ENV=test vitest --config vitest.integration.config.ts",
-    "test:integration:run": "NODE_ENV=test vitest run --config vitest.integration.config.ts",
-    "test:integration:ui": "NODE_ENV=test vitest --config vitest.integration.config.ts --ui",
-    "test:integration:coverage": "NODE_ENV=test vitest run --config vitest.integration.config.ts --coverage",
-    "prepare": "husky",
-    "format": "prettier --write src/**/*.ts",
-    "prepublish:fix": "node scripts/fix-package-catalog.mjs",
-    "cleanup": "node scripts/cleanup.js",
-    "cleanup:auto": "node scripts/cleanup.js --auto",
-    "cleanup:dry": "node scripts/cleanup.js --dry-run",
-    "clean": "rm -rf dist coverage .turbo *.tsbuildinfo",
-    "benchmark:compression": "tsx scripts/benchmark-compression.ts",
-    "i18n:check": "tsx scripts/check-i18n.ts",
-    "i18n:report": "tsx scripts/check-i18n.ts --report",
-    "contract:check": "node scripts/check-remote-contract.mjs"
-  },
   "dependencies": {
     "better-sqlite3": "^12.9.0",
     "fdir": "^6.5.0",
@@ -183,5 +142,43 @@
     "unbuild": "^3.6.1",
     "uuid": "^11.1.0",
     "vitest": "^3.2.4"
+  },
+  "scripts": {
+    "dev": "tsx ./src/cli.ts",
+    "build": "pnpm build:release:deps && pnpm build:root",
+    "build:root": "unbuild",
+    "build:release:deps": "pnpm --filter @ccjk/wire build && pnpm --filter @ccjk/evolution build",
+    "start": "node bin/ccjk.mjs",
+    "typecheck": "pnpm build:release:deps && pnpm typecheck:root",
+    "typecheck:root": "tsc --noEmit",
+    "release:verify": "node scripts/release-verify.mjs",
+    "release:verify:full": "node scripts/release-verify.mjs --with-tests",
+    "lint": "eslint",
+    "lint:fix": "eslint --fix",
+    "test": "vitest",
+    "test:ui": "vitest --ui",
+    "test:coverage": "vitest run --coverage",
+    "test:run": "vitest run",
+    "test:release": "vitest run src/commands/menu/index.test.ts src/commands/menu/main-menu.test.ts src/utils/tool-update-scheduler.test.ts tests/commands/api-config-selector.test.ts tests/commands/init.silent.test.ts tests/commands/onboarding-wizard.test.ts tests/commands/research.test.ts tests/utils/banner.test.ts tests/utils/code-type-resolver.test.ts tests/utils/memory-feature.test.ts",
+    "test:watch": "vitest watch",
+    "test:e2e": "NODE_ENV=test vitest --config vitest.e2e.config.ts",
+    "test:e2e:run": "NODE_ENV=test vitest run --config vitest.e2e.config.ts",
+    "test:e2e:ui": "NODE_ENV=test vitest --config vitest.e2e.config.ts --ui",
+    "test:e2e:coverage": "NODE_ENV=test vitest run --config vitest.e2e.config.ts --coverage",
+    "test:e2e:debug": "NODE_ENV=test CCJK_E2E_DEBUG=true vitest --config vitest.e2e.config.ts",
+    "test:integration": "NODE_ENV=test vitest --config vitest.integration.config.ts",
+    "test:integration:run": "NODE_ENV=test vitest run --config vitest.integration.config.ts",
+    "test:integration:ui": "NODE_ENV=test vitest --config vitest.integration.config.ts --ui",
+    "test:integration:coverage": "NODE_ENV=test vitest run --config vitest.integration.config.ts --coverage",
+    "format": "prettier --write src/**/*.ts",
+    "prepublish:fix": "node scripts/fix-package-catalog.mjs",
+    "cleanup": "node scripts/cleanup.js",
+    "cleanup:auto": "node scripts/cleanup.js --auto",
+    "cleanup:dry": "node scripts/cleanup.js --dry-run",
+    "clean": "rm -rf dist coverage .turbo *.tsbuildinfo",
+    "benchmark:compression": "tsx scripts/benchmark-compression.ts",
+    "i18n:check": "tsx scripts/check-i18n.ts",
+    "i18n:report": "tsx scripts/check-i18n.ts --report",
+    "contract:check": "node scripts/check-remote-contract.mjs"
   }
-}
+}

package/templates/common/karpathy-baseline.md

@@ -0,0 +1,83 @@
+# Coding Discipline Baseline
+
+> Default behavior for all coding tasks in this project, unless the user
+> explicitly says otherwise. Inspired by Andrej Karpathy's observations on
+> common LLM coding failure modes.
+
+These rules apply to **every** task. Style guides (Linus / Carmack / DHH …)
+layer on top — they change voice, not discipline.
+
+---
+
+## 1. Think before coding
+
+Surface ambiguity. Don't pick silently.
+
+- If the request has two reasonable interpretations, present both and ask.
+- If a constraint is unclear (target file, scope, behavior), ask before coding.
+- If you'd push back on a senior engineer ("this seems unnecessary"), do.
+- Prefer clarifying questions before edits over rework after.
+
+## 2. Simplicity first
+
+Minimum code that meets the stated request. Nothing speculative.
+
+- No unrequested features, options, flags, or config knobs.
+- No abstractions for single-use code. No interfaces with one implementation.
+- No error handling for impossible scenarios.
+- If 200 lines could be 50, rewrite.
+
+Litmus test: a senior engineer reviewing the diff should not think "why all this?"
+
+## 3. Surgical changes
+
+Touch only what the task requires.
+
+- Don't reformat or "improve" code adjacent to your edit.
+- Don't refactor working code unless that *is* the task.
+- Match existing style/naming/imports — don't introduce a new convention.
+- For orphans created by your own change (now-unused imports, variables, helpers): remove them. For pre-existing dead code: leave it, mention it.
+
+Litmus test: every changed line should trace directly to the user's request.
+
+## 4. Goal-driven execution
+
+Convert tasks into verifiable goals. Loop until the goal is met — don't ask
+the user to re-run something you can verify yourself.
+
+| Vague request | Verifiable goal |
+|---|---|
+| "Add validation" | Write a failing test for invalid input, then make it pass |
+| "Fix the bug" | Write a reproducing test, then make it pass |
+| "Refactor X" | Confirm the same tests pass before and after |
+| "Make it work" | Define what "work" means with a command + expected output |
+
+For multi-step tasks, share a brief plan with verification per step before
+starting. Strong goals enable independent looping. Weak goals ("make it
+nice") force back-and-forth.
+
+---
+
+## Project-specific rules
+
+These extend the baseline; they don't replace it.
+
+- **Verification commands:** `pnpm typecheck`, `pnpm lint`, `pnpm test:run`,
+  `pnpm test:release` (curated subset). For Codex/Claude integration paths,
+  smoke test with `echo '<option>' | node dist/cli.mjs`.
+- **Generated rule files:** `CLAUDE.md`, `clavue.md`, `AGENTS.md` are
+  rewritten by Clavue `/init`. Put durable guidance in
+  `docs/CLAUDE-NOTES.md`.
+- **Anti-aggression:** ccjk complements Claude Code; do not auto-run things
+  in Claude's runtime. Skills run only on explicit invocation. Don't add
+  background hooks that fire on every tool call.
+- **Workspace ownership:** ccjk config lives at `~/.ccjk/`, separate from
+  `~/.claude/` and `~/.codex/`. Don't mix them.
+
+---
+
+## When to skip this baseline
+
+- Trivial fixes (typo, one-liner): use judgment, don't over-process.
+- The user explicitly says "just do it" / "no questions": skip clarification, but keep simplicity + surgical edits.
+- Emergencies (build broken, prod down): goal is restore-first, then write the regression test.

package/templates/common/output-styles/zh-CN/carmack-mode.md

@@ -365,3 +365,17 @@ profiler.report();
 - [ ] 数据结构是否合适？
 - [ ] 是否有内存泄漏？
 - [ ] 是否可以缓存结果？
+
+
+---
+
+## Discipline Baseline
+
+这一节统一约束所有人物风格，不影响上面的语气与口味。完整版见 `~/.claude/CLAUDE.md` 的 "Coding Discipline Baseline" 章节。
+
+1. **Think before coding** — 含糊请求先问，不静默选择。
+2. **Simplicity first** — 最小代码满足需求，没要求的抽象/标志/错误处理一律删。
+3. **Surgical changes** — 只改任务相关的行；不"顺手优化"邻近代码。
+4. **Goal-driven** — 把任务转成可验证目标（写失败测试 → 跑通 → 完）；自己 loop，别让用户帮你跑命令验证。
+
+如果上面的人物风格与这 4 条冲突，**这 4 条优先**。

package/templates/common/output-styles/zh-CN/dhh-mode.md

@@ -249,3 +249,17 @@ const result = data.map(item => item.value * 2);
 - **快速反馈** - 尽早给用户看
 - **持续改进** - 小步快跑
 - **享受编程** - 代码应该是愉悦的
+
+
+---
+
+## Discipline Baseline
+
+这一节统一约束所有人物风格，不影响上面的语气与口味。完整版见 `~/.claude/CLAUDE.md` 的 "Coding Discipline Baseline" 章节。
+
+1. **Think before coding** — 含糊请求先问，不静默选择。
+2. **Simplicity first** — 最小代码满足需求，没要求的抽象/标志/错误处理一律删。
+3. **Surgical changes** — 只改任务相关的行；不"顺手优化"邻近代码。
+4. **Goal-driven** — 把任务转成可验证目标（写失败测试 → 跑通 → 完）；自己 loop，别让用户帮你跑命令验证。
+
+如果上面的人物风格与这 4 条冲突，**这 4 条优先**。

package/templates/common/output-styles/zh-CN/evan-you-mode.md

@@ -523,3 +523,17 @@ const handlers = {
 - 实际的使用示例
 - 常见问题解答
 - TypeScript 类型定义
+
+
+---
+
+## Discipline Baseline
+
+这一节统一约束所有人物风格，不影响上面的语气与口味。完整版见 `~/.claude/CLAUDE.md` 的 "Coding Discipline Baseline" 章节。
+
+1. **Think before coding** — 含糊请求先问，不静默选择。
+2. **Simplicity first** — 最小代码满足需求，没要求的抽象/标志/错误处理一律删。
+3. **Surgical changes** — 只改任务相关的行；不"顺手优化"邻近代码。
+4. **Goal-driven** — 把任务转成可验证目标（写失败测试 → 跑通 → 完）；自己 loop，别让用户帮你跑命令验证。
+
+如果上面的人物风格与这 4 条冲突，**这 4 条优先**。

package/templates/common/output-styles/zh-CN/jobs-mode.md

@@ -353,3 +353,17 @@ const launchPlan = {
 3. 这符合我们的愿景吗？
 
 如果答案不是三个 YES，就不要做。
+
+
+---
+
+## Discipline Baseline
+
+这一节统一约束所有人物风格，不影响上面的语气与口味。完整版见 `~/.claude/CLAUDE.md` 的 "Coding Discipline Baseline" 章节。
+
+1. **Think before coding** — 含糊请求先问，不静默选择。
+2. **Simplicity first** — 最小代码满足需求，没要求的抽象/标志/错误处理一律删。
+3. **Surgical changes** — 只改任务相关的行；不"顺手优化"邻近代码。
+4. **Goal-driven** — 把任务转成可验证目标（写失败测试 → 跑通 → 完）；自己 loop，别让用户帮你跑命令验证。
+
+如果上面的人物风格与这 4 条冲突，**这 4 条优先**。

package/templates/common/output-styles/zh-CN/linus-mode.md

@@ -119,3 +119,17 @@ KISS - Keep It Simple, Stupid.
 - 用 `rg` 快速搜索
 - 批量操作提高效率
 - 不做多余的事
+
+
+---
+
+## Discipline Baseline
+
+这一节统一约束所有人物风格，不影响上面的语气与口味。完整版见 `~/.claude/CLAUDE.md` 的 "Coding Discipline Baseline" 章节。
+
+1. **Think before coding** — 含糊请求先问，不静默选择。
+2. **Simplicity first** — 最小代码满足需求，没要求的抽象/标志/错误处理一律删。
+3. **Surgical changes** — 只改任务相关的行；不"顺手优化"邻近代码。
+4. **Goal-driven** — 把任务转成可验证目标（写失败测试 → 跑通 → 完）；自己 loop，别让用户帮你跑命令验证。
+
+如果上面的人物风格与这 4 条冲突，**这 4 条优先**。

package/templates/common/output-styles/zh-CN/uncle-bob-mode.md

@@ -205,3 +205,17 @@ class ShoppingCart {
 - [ ] 是否有重复代码？
 - [ ] 是否有足够的测试？
 - [ ] 是否遵循项目规范？
+
+
+---
+
+## Discipline Baseline
+
+这一节统一约束所有人物风格，不影响上面的语气与口味。完整版见 `~/.claude/CLAUDE.md` 的 "Coding Discipline Baseline" 章节。
+
+1. **Think before coding** — 含糊请求先问，不静默选择。
+2. **Simplicity first** — 最小代码满足需求，没要求的抽象/标志/错误处理一律删。
+3. **Surgical changes** — 只改任务相关的行；不"顺手优化"邻近代码。
+4. **Goal-driven** — 把任务转成可验证目标（写失败测试 → 跑通 → 完）；自己 loop，别让用户帮你跑命令验证。
+
+如果上面的人物风格与这 4 条冲突，**这 4 条优先**。

package/templates/common/workflow/linearMethod/zh-CN/linear-method.md

@@ -9,6 +9,8 @@ argument-hint: [--validate] [--prioritize] [--focus-mode]
 #   - /linear-method --focus-mode       # 专注构建模式
 ---
 
+> **基于 Discipline Baseline**：本 workflow 在 4 条全局原则（Think / Simplicity / Surgical / Goal-driven）之上提供更具体的流程编排。当本文档与 baseline 冲突，**baseline 优先**。
+
 # Linear Quality Method
 
 基于 Linear 团队的产品开发哲学，通过严格的问题验证、优先级排序和专注构建，打造高质量软件产品。

package/templates/common/workflow/refactoringMaster/zh-CN/refactoring-master.md

@@ -8,6 +8,8 @@ argument-hint: [--pattern <pattern-name>] [--scope <file|module|system>] [--safe
 #   - /refactoring-master --safe-mode               # 安全模式（每步运行测试）
 ---
 
+> **基于 Discipline Baseline**：本 workflow 在 4 条全局原则（Think / Simplicity / Surgical / Goal-driven）之上提供更具体的流程编排。当本文档与 baseline 冲突，**baseline 优先**。
+
 # Refactoring Master Mode
 
 基于 Martin Fowler 的《重构：改善既有代码的设计》（第 2 版），系统化地改善代码质量。

package/templates/common/workflow/sixStep/zh-CN/workflow.md

@@ -8,6 +8,8 @@ argument-hint: <任务描述> [--skip-research] [--quick] [--focus <阶段>]
 #   - /workflow 优化性能 --focus optimize     # 聚焦优化阶段
 ---
 
+> **基于 Discipline Baseline**：本 workflow 在 4 条全局原则（Think / Simplicity / Surgical / Goal-driven）之上提供更具体的流程编排。当本文档与 baseline 冲突，**baseline 优先**。
+
 # Workflow - 专业开发助手
 
 > **核心理念**: 研究驱动，质量把关，持续优化