neo-skill 0.1.11

package/bin/skill-creator.js

@@ -0,0 +1,55 @@
+#!/usr/bin/env node
+
+const { spawnSync } = require("child_process");
+const path = require("path");
+
+function main() {
+  const pkgRoot = path.resolve(__dirname, "..");
+  const pySrc = path.join(pkgRoot, "src");
+
+  const env = { ...process.env };
+  env.PYTHONPATH = env.PYTHONPATH ? `${pySrc}${path.delimiter}${env.PYTHONPATH}` : pySrc;
+
+  const baseArgs = ["-m", "skill_creator.cli", ...process.argv.slice(2)];
+
+  const candidates = [];
+  if (env.OMNI_SKILL_PYTHON) {
+    candidates.push({ cmd: env.OMNI_SKILL_PYTHON, extraArgs: [] });
+  }
+  if (process.platform === "win32") {
+    candidates.push({ cmd: "python", extraArgs: [] });
+    candidates.push({ cmd: "python3", extraArgs: [] });
+    candidates.push({ cmd: "py", extraArgs: ["-3"] });
+  } else {
+    candidates.push({ cmd: "python3", extraArgs: [] });
+    candidates.push({ cmd: "python", extraArgs: [] });
+  }
+
+  let lastError = null;
+  for (const c of candidates) {
+    const r = spawnSync(c.cmd, [...c.extraArgs, ...baseArgs], { stdio: "inherit", env });
+    if (r.error) {
+      lastError = r.error;
+      const msg = String(r.error.message || "").toLowerCase();
+      if (msg.includes("enoent")) {
+        continue;
+      }
+      console.error(r.error);
+      process.exit(1);
+    }
+    if (typeof r.status === "number" && r.status === 9009) {
+      continue;
+    }
+    process.exit(r.status == null ? 1 : r.status);
+  }
+
+  console.error(
+    "Python not found. Please install Python 3 and ensure 'python' works, or set OMNI_SKILL_PYTHON to your interpreter path.",
+  );
+  if (lastError) {
+    console.error(lastError);
+  }
+  process.exit(127);
+}
+
+main();

package/package.json

@@ -0,0 +1,25 @@
+{
+  "name": "neo-skill",
+  "version": "0.1.11",
+  "description": "A multi-assistant skill generator (Claude/Windsurf/Cursor/GitHub Skills) driven by a canonical SkillSpec.",
+  "license": "MIT",
+  "bin": {
+    "omni-skill": "bin/omni-skill.js",
+    "skill-creator": "bin/skill-creator.js"
+  },
+  "files": [
+    "bin/**",
+    "src/**",
+    "skills/**",
+    ".shared/**",
+    ".claude/**",
+    ".windsurf/**",
+    ".cursor/**",
+    ".github/skills/**",
+    "README.md"
+  ],
+  "scripts": {},
+  "engines": {
+    "node": ">=16"
+  }
+}

package/skills/review-gate/references/review-gate.md

@@ -0,0 +1,228 @@
+# Review Gate 架构与工程规范
+
+## 目标
+- 建立架构/工程化规范，明确哪些可以自动化（转为 Hard Gate），哪些需要人工 Review
+- 在 PR review 中显式检查架构与设计决策
+- 防止架构在长期演进中"慢慢写歪"
+
+## Non-negotiable
+- Review Gate 不能替代 Hard Gate：能自动化的规则必须先自动化
+- Review 检查点必须具体、可执行，避免模糊的"代码质量"描述
+- 对于重复出现的 Review 问题，应考虑将其转化为 Hard Gate 规则
+
+## 架构/工程化规范（Review Gate 为主）
+
+### 目录组织范式
+- 采用 `type-first` 分层模型
+- 默认层级：
+  - `presentation/`：UI 组件、页面、交互逻辑
+  - `application/`：用例、编排、应用服务
+  - `domain/`：业务逻辑、领域模型、业务规则
+  - `infra/`：基础设施、外部依赖适配器
+  - `shared/`：跨层共享工具、常量
+  - `types/`：公共类型定义
+  - `tests/`：测试相关
+
+**Review 检查点**：
+- 新增目录是否符合现有分层模型？
+- 是否存在职责不清的"杂项"目录？
+
+### 层内职责边界
+两条原则同时成立：
+1. **目录即职责**：一个目录应该只有一个清晰的职责
+2. **依赖反推职责**：通过依赖关系可以反推出职责边界，禁止"为了复用"而跨职责/跨层耦合
+
+**Review 检查点**：
+- 新增的模块/文件是否放在了正确的层级？
+- 是否存在为了复用而跨层导入的情况（应该向下抽取到 shared/domain）？
+- domain/application 是否回依赖了 infra/presentation？
+
+### 命名与一致性
+基本约定：
+- React components：`PascalCase.tsx`
+- hooks：`useXxx.ts`
+- utils/functions：`camelCase.ts` 或 `kebab-case.ts`（保持仓库一致）
+- 常量：`UPPER_SNAKE_CASE` 或 `camelCase`（保持仓库一致）
+- 类型/接口：`PascalCase`
+
+文件名与导出符号一致性：
+- 不强制，但建议文件名与主要导出符号一致
+- 在 Review 中统一建议，避免命名混乱
+
+**Review 检查点**：
+- 新增文件的命名是否符合仓库约定？
+- 文件名与导出符号是否一致（或有合理理由不一致）？
+- 是否存在缩写/拼写不一致的情况？
+
+### 模块 API 设计
+原则：
+- 公共 API 以包级 entrypoints（`package.json#exports`）为准
+- 允许在包根 `index.ts` 聚合导出
+- **禁止**在深层目录层层 `index.ts` 造成循环依赖与耦合扩散
+- 默认倾向 **named exports**；default export 仅在框架强约束处使用（如 Next.js 页面组件）
+
+**Review 检查点**：
+- 新增的 public API 是否通过 `exports` 字段暴露？
+- 是否在深层目录新增了 `index.ts`（可能导致循环依赖）？
+- 是否滥用 default export（应该用 named export）？
+- 导出的 API 是否有清晰的边界和文档？
+
+### 副作用隔离（可测试性）
+核心原则：
+- **domain/application 尽量保持纯**：不直接依赖 network/fs/db/time/random
+- I/O 操作集中在 **infra/adapter**，通过抽象或依赖注入传入
+- 副作用边界清晰，便于测试和替换实现
+
+**Review 检查点**：
+- domain/application 层是否直接调用了 `fetch`/`axios`/`fs`/`Date.now()`/`Math.random()` 等副作用？
+- 是否通过接口/依赖注入的方式隔离了副作用？
+- 关键业务逻辑是否可以在不依赖外部资源的情况下测试？
+
+### 依赖方向与抽象层次
+依赖方向（从上到下）：
+```
+presentation -> application -> domain <- infra
+                                  ^
+                                  |
+                              shared/types
+```
+
+原则：
+- **依赖向下/向内**：presentation 可以依赖 application，application 可以依赖 domain，但反向不行
+- **infra 依赖 domain 的抽象**：infra 实现 domain 定义的接口/抽象
+- **禁止跨层耦合**：不允许为了"方便"而打破依赖方向
+
+**Review 检查点**：
+- 新增依赖是否符合依赖方向？
+- 是否存在跨层的强耦合（应该抽象接口）？
+- 是否存在循环依赖的风险？
+
+### 复杂度与可读性
+虽然有 Hard Gate 限制（单函数 60 行、圈复杂度 15），但 Review 还需关注：
+- **认知复杂度**：代码是否易于理解？
+- **嵌套层级**：是否过度嵌套（建议早返回）？
+- **函数职责**：是否一个函数做了太多事情？
+- **抽象层次一致性**：同一个函数内是否混合了高层业务逻辑和底层实现细节？
+
+**Review 检查点**：
+- 复杂的业务逻辑是否拆分成了多个小函数？
+- 是否存在"上帝函数"（做了太多事情）？
+- 变量/函数命名是否清晰表达了意图？
+
+### 错误处理策略
+Hard Gate 已限制：
+- 统一错误类型（如 `AppError`/`DomainError`）
+- 禁止在非边界层随意 `throw new Error`
+
+Review 需额外关注：
+- **错误边界**：错误是否在合适的边界被捕获和处理？
+- **错误信息质量**：错误信息是否足够帮助定位问题？
+- **优雅降级**：关键路径是否有合理的错误处理和降级策略？
+- **错误传播**：错误是否以合理的方式向上传播（而不是被吞掉）？
+
+**Review 检查点**：
+- 新增的错误处理是否遵循了统一的错误类型？
+- 是否存在空 catch 块（吞掉错误）？
+- 错误信息是否包含足够的上下文？
+
+### 日志与可观测性
+Hard Gate 已限制：
+- 禁止在非边界层直接 `console.*`（仅允许 entry/infra）
+
+Review 需额外关注：
+- **日志级别**：是否使用了合适的日志级别（debug/info/warn/error）？
+- **关键路径日志**：关键业务流程是否有足够的日志便于追踪？
+- **敏感信息**：日志中是否包含了敏感信息（token/密码/个人信息）？
+- **结构化日志**：是否使用结构化日志便于查询和分析？
+
+**Review 检查点**：
+- 新增日志是否在合适的层级（entry/infra）？
+- 日志是否包含足够的上下文信息？
+- 是否泄露了敏感信息？
+
+### 注释与文档
+Hard Gate 已限制：
+- 禁止"解释代码做什么"的注释
+- public API 需要 TSDoc/JSDoc
+
+Review 需额外关注：
+- **关键算法/复杂业务**：是否有块注释或链接到设计文档/issue？
+- **非显而易见的决策**：是否解释了"为什么这样做"而不是"做了什么"？
+- **坑/约束/假设**：是否记录了重要的假设、约束或已知问题？
+- **API 文档完整性**：public API 的文档是否包含了参数说明、返回值、示例、错误情况？
+
+**Review 检查点**：
+- 复杂业务逻辑是否有注释说明"为什么"？
+- public API 的文档是否完整？
+- 是否存在需要删除的过时注释？
+
+### 测试策略
+虽然 Hard Gate 会跑测试，但 Review 需关注：
+- **测试覆盖率**：关键业务逻辑是否有单元测试？
+- **测试质量**：测试是否真正验证了业务逻辑，还是只是为了覆盖率？
+- **测试可维护性**：测试是否易于理解和维护？
+- **集成测试边界**：集成测试是否覆盖了关键路径？
+
+**Review 检查点**：
+- 新增的业务逻辑是否有对应的测试？
+- 测试是否覆盖了边界情况和错误路径？
+- 测试是否依赖了不必要的外部资源（应该 mock）？
+
+### 性能考虑
+Review 需关注明显的性能问题：
+- **明显的性能反模式**：循环中的重复计算、不必要的深拷贝、大数据结构的同步遍历
+- **资源泄漏**：未清理的定时器、未关闭的连接、未取消的订阅
+- **不必要的重渲染**：React 组件是否有不必要的重渲染（缺少 memo/useMemo/useCallback）
+- **阻塞操作**：是否在主线程执行了耗时的同步操作
+
+**Review 检查点**：
+- 是否存在明显的性能问题？
+- 是否有资源泄漏的风险？
+- 大数据处理是否考虑了性能优化？
+
+### 安全考虑
+虽然 Hard Gate 已覆盖部分安全检查，Review 需额外关注：
+- **XSS 风险**：用户输入是否被正确转义？是否使用了 `dangerouslySetInnerHTML`？
+- **SQL/NoSQL 注入**：数据库查询是否使用了参数化查询？
+- **权限检查**：关键操作是否有权限校验？
+- **数据验证**：外部输入是否经过验证？
+
+**Review 检查点**：
+- 用户输入是否经过验证和转义？
+- 是否存在明显的安全风险？
+- 敏感操作是否有权限校验？
+
+## Review Checklist 模板
+
+### 架构层面
+- [ ] 新增代码是否放在了正确的分层？
+- [ ] 是否遵循了依赖方向（向下/向内）？
+- [ ] 是否存在跨层耦合或循环依赖？
+- [ ] 职责划分是否清晰？
+
+### 设计层面
+- [ ] 模块 API 设计是否合理（边界清晰、易用）？
+- [ ] 是否有合理的抽象（不过度设计，也不欠设计）？
+- [ ] 副作用是否被正确隔离？
+- [ ] 关键业务逻辑是否可测试？
+
+### 代码质量
+- [ ] 命名是否清晰表达意图？
+- [ ] 复杂度是否合理（认知复杂度、嵌套层级）？
+- [ ] 错误处理是否完善？
+- [ ] 日志是否合理（层级、内容、敏感信息）？
+
+### 文档与可维护性
+- [ ] 复杂业务逻辑是否有注释说明"为什么"？
+- [ ] public API 是否有完整文档？
+- [ ] 是否有足够的测试覆盖关键路径？
+
+### 性能与安全
+- [ ] 是否存在明显的性能问题或资源泄漏？
+- [ ] 用户输入是否经过验证？
+- [ ] 是否存在明显的安全风险？
+
+## 与 Hard Gate 的协同
+- **优先自动化**：如果某个 Review 检查点可以自动化，应该转化为 Hard Gate 规则
+- **持续演进**：定期回顾 Review 中重复出现的问题，考虑将其自动化
+- **互为补充**：Hard Gate 保证基线，Review Gate 关注设计和架构决策

package/skills/review-gate/skillspec.json

@@ -0,0 +1,131 @@
+{
+  "version": 1,
+  "name": "review-gate",
+  "description": "为 TypeScript/JavaScript（React/Vue/Node）项目建立架构与工程化 Review 规范：明确分层职责边界、模块 API 设计、副作用隔离、复杂度与可读性、错误处理策略等，提供可执行的 PR Review Checklist，防止架构在长期演进中"慢慢写歪"。",
+  "assistants": ["claude", "windsurf", "cursor", "github-skills"],
+  "questions": [
+    "你的仓库采用什么分层模型（type-first / feature-first / 其他），现有层级命名是什么？",
+    "是否已有明确的架构/工程规范文档，或仅依靠口头约定？",
+    "PR Review 流程是什么（必须至少 1 人 approve / 需要架构师 review / 其他）？",
+    "哪些架构检查点是团队反复强调但容易被忽略的（跨层依赖/副作用隔离/命名一致性/其他）？",
+    "是否需要生成 PR Review Checklist 模板，以及是否要集成到 PR 模板中？",
+    "团队是否有特定的代码风格偏好（例如：early return / 禁止 default export / 统一错误类型）？"
+  ],
+  "triggers": [
+    "我想建立 PR Review 架构规范检查点",
+    "帮我生成 PR Review Checklist 模板",
+    "如何在 Review 中检查分层职责边界",
+    "如何防止架构在演进中写歪",
+    "设置工程化规范和代码审查标准",
+    "软评审代码"
+  ],
+  "freedom_level": "medium",
+  "workflow": {
+    "type": "sequential",
+    "steps": [
+      {
+        "id": "understand",
+        "title": "理解现有架构与分层模型",
+        "kind": "action",
+        "commands": [],
+        "notes": "识别仓库的分层模型（type-first / feature-first / 其他），梳理现有层级命名（presentation/application/domain/infra/shared/types/tests 或其他）。输出当前架构概览。"
+      },
+      {
+        "id": "review-points",
+        "title": "识别关键 Review 检查点（基于团队痛点）",
+        "kind": "action",
+        "commands": [],
+        "notes": "基于团队反馈和常见问题，识别最重要的 Review 检查点。参考 `references/review-gate.md` 中的完整检查点清单，优先级排序。"
+      },
+      {
+        "id": "checklist",
+        "title": "生成 PR Review Checklist 模板",
+        "kind": "action",
+        "commands": [],
+        "notes": "基于识别的检查点，生成具体的、可执行的 PR Review Checklist。包括架构层面、设计层面、代码质量、文档与可维护性、性能与安全等维度。模板见 `references/review-gate.md`。"
+      },
+      {
+        "id": "layer-boundary",
+        "title": "审查分层边界与依赖方向",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查当前 PR 的变更是否符合分层模型，是否存在跨层耦合或违反依赖方向的情况。重点关注 domain/application 是否回依赖了 infra/presentation。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "api-design",
+        "title": "审查模块 API 设计与边界",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查新增或修改的 public API 是否设计合理：是否通过 exports 暴露、是否有清晰边界、是否滥用 default export、是否在深层目录新增 index.ts 导致循环依赖风险。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "side-effects",
+        "title": "审查副作用隔离与可测试性",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查 domain/application 层是否保持纯净（不直接依赖 network/fs/db/time/random），I/O 操作是否集中在 infra/adapter 并通过抽象注入。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "complexity-readability",
+        "title": "审查复杂度与可读性",
+        "kind": "action",
+        "commands": [],
+        "notes": "除了 Hard Gate 限制的指标（单函数 60 行、圈复杂度 15），还需关注认知复杂度、嵌套层级、函数职责、抽象层次一致性。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "error-handling",
+        "title": "审查错误处理策略",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查错误处理是否遵循统一的错误类型、错误边界是否合理、错误信息是否足够、是否存在空 catch 块（吞掉错误）。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "logging",
+        "title": "审查日志与可观测性",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查日志是否在合适的层级（entry/infra）、日志级别是否合适、是否包含足够上下文、是否泄露敏感信息。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "documentation",
+        "title": "审查注释与文档质量",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查复杂业务逻辑是否有注释说明"为什么"、public API 文档是否完整、是否存在需要删除的过时注释。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "tests",
+        "title": "审查测试策略与覆盖",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查关键业务逻辑是否有对应测试、测试是否覆盖边界情况和错误路径、测试是否依赖了不必要的外部资源。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "performance-security",
+        "title": "审查性能与安全考虑",
+        "kind": "action",
+        "commands": [],
+        "notes": "检查是否存在明显的性能问题（循环中重复计算、资源泄漏、不必要的重渲染）和安全风险（XSS、注入、权限检查、数据验证）。详见 `references/review-gate.md`。"
+      },
+      {
+        "id": "output",
+        "title": "输出 Review 结果与改进建议",
+        "kind": "action",
+        "commands": [],
+        "notes": "汇总 Review 结果，明确列出：符合规范的部分、需要改进的部分（按优先级）、可以转化为 Hard Gate 的重复问题。提供具体的改进建议和参考文档链接。"
+      },
+      {
+        "id": "integrate",
+        "title": "（可选）集成到 PR 模板",
+        "kind": "action",
+        "commands": [],
+        "notes": "如果团队需要，可以将生成的 Review Checklist 集成到 `.github/pull_request_template.md` 或其他 PR 模板中，确保每次 PR 都经过规范检查。"
+      }
+    ]
+  },
+  "references": [
+    "references/review-gate.md"
+  ],
+  "scripts": [],
+  "assets": []
+}

package/skills/skill-creator/references/output-patterns.md

@@ -0,0 +1,82 @@
+# Output Patterns
+
+Use these patterns when skills need to produce consistent, high-quality output.
+
+## Template Pattern
+
+Provide templates for output format. Match the level of strictness to your needs.
+
+**For strict requirements (like API responses or data formats):**
+
+```markdown
+## Report structure
+
+ALWAYS use this exact template structure:
+
+# [Analysis Title]
+
+## Executive summary
+[One-paragraph overview of key findings]
+
+## Key findings
+- Finding 1 with supporting data
+- Finding 2 with supporting data
+- Finding 3 with supporting data
+
+## Recommendations
+1. Specific actionable recommendation
+2. Specific actionable recommendation
+```
+
+**For flexible guidance (when adaptation is useful):**
+
+```markdown
+## Report structure
+
+Here is a sensible default format, but use your best judgment:
+
+# [Analysis Title]
+
+## Executive summary
+[Overview]
+
+## Key findings
+[Adapt sections based on what you discover]
+
+## Recommendations
+[Tailor to the specific context]
+
+Adjust sections as needed for the specific analysis type.
+```
+
+## Examples Pattern
+
+For skills where output quality depends on seeing examples, provide input/output pairs:
+
+```markdown
+## Commit message format
+
+Generate commit messages following these examples:
+
+**Example 1:**
+Input: Added user authentication with JWT tokens
+Output:
+```
+feat(auth): implement JWT-based authentication
+
+Add login endpoint and token validation middleware
+```
+
+**Example 2:**
+Input: Fixed bug where dates displayed incorrectly in reports
+Output:
+```
+fix(reports): correct date formatting in timezone conversion
+
+Use UTC timestamps consistently across report generation
+```
+
+Follow this style: type(scope): brief description, then detailed explanation.
+```
+
+Examples help Claude understand the desired style and level of detail more clearly than descriptions alone.

package/skills/skill-creator/references/pre-delivery-checklist.md

@@ -0,0 +1,70 @@
+# Pre-Delivery Checklist
+
+Verify these items before delivering a skill.
+
+## Spec Quality
+
+- [ ] **name** is kebab-case (lowercase, hyphens only)
+- [ ] **description** clearly states when to use (>20 chars)
+- [ ] **questions** are ≤10 and prioritized
+- [ ] **triggers** include ≥5 example phrases
+- [ ] **freedom_level** matches task type (low=deterministic, high=heuristic)
+
+## Workflow Quality
+
+- [ ] All steps have unique `id` (kebab-case)
+- [ ] All steps have descriptive `title`
+- [ ] Gate steps (`kind: gate`) have clear pass/fail criteria
+- [ ] Step `notes` are concise (<200 chars) and use index-style references
+- [ ] Commands are copy-pastable and use `<placeholders>` consistently
+
+## Resource Organization
+
+- [ ] `references/` contains only static rules/guidelines
+- [ ] `scripts/` contains only deterministic, executable code
+- [ ] `assets/` contains only structured data (CSV/JSON)
+- [ ] No duplicate content across resources
+- [ ] `.shared/` used for cross-skill reusable content
+
+## Generated Outputs
+
+Run validation:
+```bash
+python3 .shared/skill-creator/scripts/validate.py skills/<skill>/skillspec.json
+```
+
+- [ ] Windsurf workflow generated at `.windsurf/workflows/<name>.md`
+- [ ] Claude SKILL.md has strict frontmatter (name + description only)
+- [ ] No banned files in skill bundles (README.md, CHANGELOG.md, etc.)
+- [ ] Resources copied correctly for Claude/GitHub targets
+
+## Trigger Coverage
+
+- [ ] Covers main action verb ("create", "review", "fix", etc.)
+- [ ] Covers Chinese equivalents if applicable
+- [ ] Covers common variations/synonyms
+- [ ] Covers context keywords (technology, domain)
+- [ ] Test: would a new user's phrasing match at least one trigger?
+
+## Common Issues to Avoid
+
+| Issue | Check |
+|-------|-------|
+| Notes too long | Move details to `references/` |
+| Hardcoded paths | Use `<placeholders>` |
+| Missing gates | Add validation after risky steps |
+| Unclear output | Specify exact format in step notes |
+| Duplicate triggers | Consolidate similar phrases |
+
+## Final Sign-off
+
+```markdown
+## Delivery Confirmation
+
+- Skill: <name>
+- Version: 1
+- Primary target: windsurf
+- Backward compat: claude, cursor, github
+- Validation: ✓ passed
+- Package: dist/<name>.skill (if Claude target)
+```

package/skills/skill-creator/references/requirement-collection.md

@@ -0,0 +1,80 @@
+# Requirement Collection Protocol
+
+Guide for collecting skill requirements through conversational Q&A (max 10 questions).
+
+## Priority Order
+
+Ask questions in this priority order (skip if already known):
+
+1. **Goal** - What is the one-sentence objective? (verb-based, repeatable task)
+2. **Triggers** - What phrases/keywords will users say? (at least 5)
+3. **Output** - What form should the output take? (code/report/checklist/patch)
+4. **Constraints** - What are the hard limits? (no network/must test/read-only)
+5. **Tools** - What tools are allowed? (shell/git/python/file ops)
+6. **Inputs** - What inputs are needed? (repo/config/logs/diff)
+7. **Workflow** - What are the key steps? Where are the gates?
+8. **Edge Cases** - What failures are expected? How to handle?
+9. **Resources** - What goes to references/scripts/assets/.shared?
+
+## Question Templates
+
+### Goal Question
+```
+这个 skill 的一句话目标是什么（动词开头，面向可重复任务）？
+What is the one-sentence goal of this skill (verb-based, for repeatable tasks)?
+```
+
+### Trigger Question
+```
+用户会用哪些触发语句/关键词来表述这个需求（至少 5 条）？
+What trigger phrases/keywords will users say? (at least 5 examples)
+```
+
+### Output Question
+```
+期望输出是什么形态？
+- 报告 (report/analysis)
+- 代码 (code generation)
+- 补丁 (patch/diff)
+- 命令 (shell commands)
+- 文件树 (directory structure)
+- 清单 (checklist)
+- 其他
+```
+
+## Inference Rules
+
+Before asking, try to infer from context:
+
+| If user says... | Infer... |
+|-----------------|----------|
+| "review", "audit", "check" | Output = checklist, Workflow = gated |
+| "generate", "create", "build" | Output = code/files, Freedom = low-medium |
+| "fix", "debug", "repair" | Output = patch, Tools = git/diff |
+| "explain", "document" | Output = report, Freedom = high |
+| "convert", "migrate" | Output = transformed code, Tools = file ops |
+
+## Stop Conditions
+
+Stop collecting when:
+- All 9 priority items are known
+- 10 questions reached
+- User explicitly says "够了" / "that's enough"
+
+## Output Format
+
+After collection, summarize in this format:
+
+```markdown
+## Skill Requirements Summary
+
+- **Goal**: [one sentence]
+- **Triggers**: [list of 5+]
+- **Output**: [form]
+- **Constraints**: [hard limits]
+- **Tools**: [allowed tools]
+- **Inputs**: [required inputs]
+- **Workflow**: [key steps]
+- **Edge Cases**: [failure handling]
+- **Resources**: [distribution plan]
+```