Back to Details

agentic-rules-writer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Agentic Rules Writer

Agentic规则编写工具

Generate a tailored rules/instruction file for any AI coding agent. Runs an interactive questionnaire, scans installed skills at runtime, and writes the output in the correct format and location for the chosen agent and scope.
为任意AI编码Agent生成定制化规则/指令文件。运行交互式问卷，在运行时扫描已安装技能，并根据所选Agent和作用域，以正确格式写入到对应位置。

When to Use

使用场景

  • Setting up a new AI coding agent for the first time
  • Creating team-shared project rules for consistent behavior across developers
  • Adding personal dev-specific rules to a project (gitignored)
  • After installing new skills to update the rules file with skill references
  • 首次配置新的AI编码Agent时
  • 创建团队共享的项目规则，确保开发者行为一致
  • 为项目添加个人专属的开发者规则（会被git忽略）
  • 安装新技能后，更新规则文件以包含技能引用

Quick Start

快速开始

/agentic-rules-writer claude
/agentic-rules-writer cursor
/agentic-rules-writer              # asks which agent
/agentic-rules-writer claude
/agentic-rules-writer cursor
/agentic-rules-writer              # 询问要选择的Agent

Phase 1: Agent Selection

阶段1：Agent选择

If 
$ARGUMENTS
is provided, map it to an agent from the table below (case-insensitive, partial match OK — e.g. "wind" matches Windsurf). If no argument or no match, ask the user to pick.
AgentFormat Notes
Claude CodePlain Markdown, keep under 200 lines
CursorRequires YAML frontmatter: 
alwaysApply: true
, 
.mdc
extension
WindsurfPlain Markdown, enforce under 12,000 characters
GitHub CopilotPlain Markdown
Gemini CLIPlain Markdown
Roo CodePlain Markdown
AmpSame format as Claude Code
See references/agent-targets.md for full details on each agent's format, paths, limits, and testing instructions.
如果提供了
$ARGUMENTS
，将其映射到下表中的Agent（不区分大小写，支持部分匹配——例如“wind”匹配Windsurf）。如果没有参数或匹配失败，询问用户选择。
Agent格式说明
Claude Code纯Markdown格式，内容不超过200行
Cursor需要YAML前置元数据：
alwaysApply: true
，文件扩展名为
.mdc
Windsurf纯Markdown格式，内容不超过12000字符
GitHub Copilot纯Markdown格式
Gemini CLI纯Markdown格式
Roo Code纯Markdown格式
Amp与Claude Code格式相同
查看references/agent-targets.md获取每个Agent的格式、路径、限制和测试说明的完整细节。

Phase 2: Scope Selection

阶段2：作用域选择

Ask the user which scope to generate rules for:
ScopeDescriptionTypical Path (Claude Code example)
GlobalUser-level rules applied to every project. Personal workflow preferences.
~/.claude/CLAUDE.md
Project (team-shared)Committed to the repo. Shared conventions the whole team follows.
.claude/rules/team-rules.md
Project (dev-specific)Local to this dev, gitignored. Personal preferences layered on top of team rules.
.claude/rules/dev-rules.md
See references/agent-targets.md for the exact path for each agent + scope combination.
If the target file already exists, ask the user:
  1. Overwrite — replace entirely with generated content
  2. Merge — append generated content below existing content (separated by 
    ---
    )
  3. Abort — cancel and leave the file untouched
询问用户要为哪种作用域生成规则：
作用域描述典型路径（Claude Code示例）
全局用户级规则，适用于所有项目，对应个人工作流偏好
~/.claude/CLAUDE.md
项目（团队共享）提交到仓库，团队统一遵循的共享规范
.claude/rules/team-rules.md
项目（开发者专属）本地专属，被git忽略，在团队规则基础上叠加个人偏好
.claude/rules/dev-rules.md
查看references/agent-targets.md获取每个Agent+作用域组合的确切路径。
如果目标文件已存在，询问用户：
  1. 覆盖 —— 完全替换为生成的内容
  2. 合并 —— 在现有内容下方追加生成的内容（用
    ---
    分隔）
  3. 中止 —— 取消操作，保留原文件不变

Phase 3: Workflow Questionnaire

阶段3：工作流问卷

Ask questions one at a time, wait for the user's answer before proceeding to the next. Accept short answers, numbers, or the exact option text.
Which questions to ask depends on the scope:
QuestionGlobalTeam-sharedDev-specific
Q1. Primary stackYesYesSkip
Q2. Planning disciplineYesSkipYes
Q3. Testing philosophyYesYesSkip
Q4. Branch conventionsYesYesSkip
Q5. Commit conventionsYesYesSkip
Q6. Code quality barYesYesSkip
Q7. Autonomy levelYesSkipYes
Q8. Task trackingYesSkipYes
Q9. Self-improvementYesSkipYes
Q10. Agent parallelizationYesSkipYes
Q11. Communication styleYesSkipYes
Q12. Directory structureYesYesSkip
Q13. Error handlingYesYesSkip
Q14. Persona / roleplayYesSkipYes
Q15. Additional commentsYesYesYes
Rationale: Team-shared rules cover technical standards the whole team agrees on (stack, testing, branching, commits, quality, directory structure, error handling). Dev-specific rules cover personal workflow preferences (planning style, autonomy, task tracking, self-improvement, parallelization, communication style). Global includes everything.
See references/questionnaire.md for the full question reference with descriptions, option mappings, and example outputs.
逐个提问，等待用户回答后再进行下一个问题。接受简短回答、数字或准确的选项文本。
要提问的问题取决于所选作用域：
问题全局团队共享开发者专属
Q1. 主要技术栈是是跳过
Q2. 规划规范是跳过是
Q3. 测试理念是是跳过
Q4. 分支命名规范是是跳过
Q5. 提交信息规范是是跳过
Q6. 代码质量标准是是跳过
Q7. 自主权限是跳过是
Q8. 任务追踪是跳过是
Q9. 自我改进是跳过是
Q10. Agent并行化是跳过是
Q11. 沟通风格是跳过是
Q12. 目录结构是是跳过
Q13. 错误处理是是跳过
Q14. 角色设定是跳过是
Q15. 额外说明是是是
设计思路：团队共享规则涵盖团队一致认可的技术标准（技术栈、测试、分支、提交、质量、目录结构、错误处理）。开发者专属规则涵盖个人工作流偏好（规划风格、自主权限、任务追踪、自我改进、并行化、沟通风格）。全局规则包含所有内容。
查看references/questionnaire.md获取完整的问题参考，包括描述、选项映射和示例输出。

Questions

问题详情

Q1. Primary stack Options: PHP+Symfony / TypeScript+React / Python+Django / Go / Rust / Java+Spring / Other (If "Other", ask them to specify.)
Q2. Planning discipline Options:
  • Always plan first — enter plan mode for every task
  • Plan for 3+ steps — plan mode only for multi-step tasks
  • Minimal planning — jump straight to implementation
Q3. Testing philosophy Options:
  • Strict TDD — write tests before implementation, always
  • Test alongside — write tests and code together
  • Test after — implement first, add tests after
  • Minimal — only test critical paths
Q4. Branch conventions Options:
  • Type prefix — 
    feature/
    , 
    fix/
    , 
    chore/
    , 
    hotfix/
    + description
  • Ticket prefix — 
    PROJ-123/description
    or 
    PROJ-123-description
  • Flat descriptive — just a kebab-case name, no prefix
  • Other — ask them to specify
Q5. Commit conventions Options:
  • Conventional commits — 
    feat:
    , 
    fix:
    , 
    chore:
    , etc.
  • Ticket prefix — 
    PROJ-123: description
  • Freeform — no enforced format
Follow-up: "Should the agent add itself as co-author on commits?" (Yes / No)
Q6. Code quality bar Options:
  • Staff engineer rigor — exhaustive edge cases, defensive coding, thorough documentation
  • Senior pragmatic — solid quality with practical trade-offs
  • Ship fast — working code with minimal ceremony
Follow-up: "Documentation level?" (Docblocks on public APIs / Inline comments for non-obvious logic only / Minimal — code should speak for itself)
Q7. Autonomy level Options:
  • Autonomous — fix bugs, failing CI, lint errors without asking
  • Semi-autonomous — ask before destructive or risky operations only
  • Conservative — confirm everything before acting
All options also generate: "Never add new dependencies without asking first"
Q8. Task tracking Options:
  • Todo files — maintain a 
    TODO.md
    or similar tracking file
  • Built-in tasks — use the agent's built-in task/todo system
  • No formal tracking — just work through tasks naturally
Q9. Self-improvement Options:
  • Lessons file — maintain a lessons-learned file, update after corrections
  • No formal tracking — learn implicitly from context
Q10. Agent parallelization Options:
  • Always parallelize — delegate to agent teams by default for any multi-part task
  • Parallel for large tasks — use agent teams when 3+ independent subtasks exist
  • Sequential only — work through tasks one at a time, no agent delegation
Q11. Communication style Options:
  • Direct and minimal — no emojis, terse responses, just the facts
  • Structured explanations — sectioned with headings, clear and direct, no emojis
  • Conversational — casual tone, emojis OK, friendly and approachable
Q12. Directory structure Options:
  • Follow existing — always match the project's current directory structure and conventions
  • Follow best practices — restructure toward industry conventions, suggest improvements
  • Pragmatic middle — follow existing structure but suggest improvements when patterns are clearly wrong
Q13. Error handling Options:
  • Fail fast — throw early, crash on unexpected state, surface errors immediately
  • Defensive — handle gracefully, never crash, always recover
  • Balanced — fail fast in development, handle gracefully in production
Q14. Persona / roleplay Options:
  • Yes — I want the agent to adopt a persona
  • No — just be a straightforward assistant
If "Yes": ask the user to describe the persona (e.g. "a grumpy senior engineer", "Gandalf", "a pirate captain"). Accept any input — if the persona is obscure or fictional, use web search to gather details before generating rules.
Then generate:
  1. A one-paragraph persona description capturing the character's voice and attitude
  2. 5-8 catchphrases the agent can sprinkle into responses (drawn from the character or invented in their style)
  3. A hard constraint: Precision always comes first. The persona is flavor, not substance. Technical accuracy, correct code, and clear answers are never sacrificed for character. Use at most one catchphrase per response — do not overdo it or make them repetitive.
Q15. Additional comments Free-text. Ask: "Any additional rules, preferences, or comments you'd like included?"
  • If the user provides text, include it verbatim in an "## Additional Rules" section at the end of the generated file
  • If the user says "no" or skips, omit the section entirely
Q1. 主要技术栈 选项：PHP+Symfony / TypeScript+React / Python+Django / Go / Rust / Java+Spring / 其他 （如果选择「其他」，请让用户说明具体技术栈。）
Q2. 规划规范 选项：
  • 先规划再行动 —— 所有任务都进入规划模式
  • 多步骤任务才规划 —— 仅针对需要3步以上的任务进入规划模式
  • 最小化规划 —— 直接进入实现环节
Q3. 测试理念 选项：
  • 严格TDD —— 始终先编写测试再实现代码
  • 边写代码边写测试 —— 测试与代码同步编写
  • 先实现后测试 —— 先完成实现，再添加测试
  • 最小化测试 —— 仅测试关键路径
Q4. 分支命名规范 选项：
  • 类型前缀 —— 
    feature/
    、
    fix/
    、
    chore/
    、
    hotfix/
    + 描述
  • 工单前缀 —— 
    PROJ-123/description
    或 
    PROJ-123-description
  • 扁平化描述 —— 仅使用短横线命名，无前缀
  • 其他 —— 请让用户说明具体规范
Q5. 提交信息规范 选项：
  • 约定式提交 —— 
    feat:
    、
    fix:
    、
    chore:
    等格式
  • 工单前缀 —— 
    PROJ-123: description
  • 自由格式 —— 无强制格式
跟进问题：“是否需要Agent在提交信息中添加自己为共同作者？”（是/否）
Q6. 代码质量标准 选项：
  • 资深工程师严谨标准 —— 覆盖所有边界情况、防御式编程、详尽文档
  • 资深务实标准 —— 保证代码质量的同时做实际权衡
  • 快速交付 —— 仅保证代码可运行，简化流程
跟进问题：“文档要求？”（公共API添加文档块 / 仅对非直观逻辑添加行内注释 / 最小化文档——代码自解释）
Q7. 自主权限 选项：
  • 完全自主 —— 无需询问即可修复bug、失败的CI、lint错误
  • 半自主 —— 仅在执行破坏性或高风险操作前询问
  • 保守模式 —— 所有操作前都需确认
所有选项都会附加：“添加新依赖前必须询问”
Q8. 任务追踪 选项：
  • 待办文件 —— 维护
    TODO.md
    或类似追踪文件
  • 内置任务系统 —— 使用Agent的内置任务/待办系统
  • 无正式追踪 —— 直接处理任务
Q9. 自我改进 选项：
  • 经验总结文件 —— 维护经验总结文件，在修正后更新
  • 无正式追踪 —— 从上下文隐含学习
Q10. Agent并行化 选项：
  • 始终并行化 —— 默认将任何多部分任务委托给Agent团队
  • 大型任务才并行化 —— 当存在3个以上独立子任务时使用Agent团队
  • 仅串行处理 —— 逐个处理任务，不委托给其他Agent
Q11. 沟通风格 选项：
  • 直接简洁 —— 无表情符号、简短回应、只讲事实
  • 结构化说明 —— 使用标题分节、清晰直接、无表情符号
  • 对话式 —— 语气随意、可使用表情符号、友好亲切
Q12. 目录结构 选项：
  • 遵循现有结构 —— 始终匹配项目当前的目录结构和规范
  • 遵循最佳实践 —— 重构为行业规范，提出改进建议
  • 务实折中 —— 遵循现有结构，但在模式明显错误时提出改进建议
Q13. 错误处理 选项：
  • 快速失败 —— 尽早抛出异常，在意外状态时崩溃，立即暴露错误
  • 防御式处理 —— 优雅处理错误，永不崩溃，始终尝试恢复
  • 平衡模式 —— 开发环境快速失败，生产环境优雅处理
Q14. 角色设定 选项：
  • 是 —— 我希望Agent采用特定角色
  • 否 —— 仅作为直白的助手
如果选择“是”：请用户描述角色（例如“脾气暴躁的资深工程师”、“甘道夫”、“海盗船长”）。接受任何输入——如果角色是冷门或虚构的，先通过网络搜索收集细节再生成规则。
然后生成以下内容：
  1. 一段角色描述，捕捉角色的语气和态度
  2. 5-8个角色常用语，Agent可在回应中适当使用（来自角色本身或模仿角色风格创作）
  3. 硬性约束：准确性永远优先。角色设定仅为调味，不能影响实质内容。 技术准确性、正确代码和清晰回答永远不能为了角色而牺牲。每个回应最多使用一个常用语——不要过度使用或重复。
Q15. 额外说明 自由文本输入。提问：“是否有其他要添加的规则、偏好或说明？”
  • 如果用户提供内容，将其原封不动地添加到生成文件末尾的「## 额外规则」章节
  • 如果用户回答“否”或跳过，省略该章节

Phase 4: Skill & Agent Scanning

阶段4：技能与Agent扫描

Skill Scanning

技能扫描

Scan for installed skills at runtime. Check these locations:
~/.claude/skills/*/SKILL.md          # user-level skills
.claude/skills/*/SKILL.md            # project-level skills
~/.claude/plugins/*/skills/*/SKILL.md  # marketplace plugins
For each found skill:
  1. Read the YAML frontmatter to extract 
    name
    and 
    description
  2. Build a mapping: 
    When [situation matching description] -> use /skill-name
Also detect which code-virtuoso skills are NOT installed and build a recommendations list. The full code-virtuoso skill catalog:
SkillDescription
design-patterns26 GoF design patterns with multi-language examples
refactoring89 refactoring techniques and code smells
solid5 SOLID principles for OO design
debuggingSystematic debugging methodology and root cause analysis
clean-architectureClean Architecture, Hexagonal Architecture, and DDD fundamentals
testingTesting pyramid, TDD schools, test doubles, and testing strategies
api-designREST and GraphQL API design principles and evolution strategies
securityOWASP Top 10, auth patterns, and secure coding practices
symfony38 Symfony component references (PHP projects)
agentic-rules-writerThis skill (already installed)
在运行时扫描已安装的技能。检查以下位置：
~/.claude/skills/*/SKILL.md          # 用户级技能
.claude/skills/*/SKILL.md            # 项目级技能
~/.claude/plugins/*/skills/*/SKILL.md  # 市场插件技能
对于每个找到的技能：
  1. 读取YAML前置元数据，提取
    name
    和
    description
  2. 建立映射：
    当[匹配描述的场景]时 -> 使用 /skill-name
同时检测未安装的code-virtuoso技能，生成推荐列表。完整的code-virtuoso技能目录：
技能描述
design-patterns26种GoF设计模式，含多语言示例
refactoring89种重构技巧和代码异味识别
solid面向对象设计的5大SOLID原则
debugging系统化调试方法论和根因分析
clean-architecture整洁架构、六边形架构和领域驱动设计基础
testing测试金字塔、TDD流派、测试替身和测试策略
api-designREST和GraphQL API设计原则与演进策略
securityOWASP Top 10、认证模式和安全编码实践
symfony38个Symfony组件参考（PHP项目）
agentic-rules-writer当前技能（已安装）

Agent Scanning

Agent扫描

Scan for custom agents (subagents) at runtime. Check these locations:
~/.claude/agents/*.md                # user-level agents (available in all projects)
.claude/agents/*.md                  # project-level agents (committed to repo)
~/.claude/plugins/*/agents/*.md      # plugin agents
For each found agent:
  1. Read the YAML frontmatter to extract 
    name
    and 
    description
  2. Determine the agent's capabilities from 
    tools
    field (read-only vs full access)
  3. Note the 
    model
    if specified (haiku = fast/cheap, opus = capable, sonnet = balanced)
  4. Build a mapping for the generated rules
Include discovered agents in the generated rules under a ## Custom Agents section (only if agents are found, omit if none):
markdown
undefined
在运行时扫描自定义Agent（子Agent）。检查以下位置：
~/.claude/agents/*.md                # 用户级Agent（所有项目可用）
.claude/agents/*.md                  # 项目级Agent（提交到仓库）
~/.claude/plugins/*/agents/*.md      # 插件Agent
对于每个找到的Agent：
  1. 读取YAML前置元数据，提取
    name
    和
    description
  2. 从
    tools
    字段确定Agent的能力（只读 vs 完全访问）
  3. 记录指定的
    model
    （haiku = 快速/低成本，opus = 高性能，sonnet = 平衡型）
  4. 为生成规则建立映射
将发现的Agent添加到生成规则的「## 自定义Agent」章节（仅当找到Agent时添加，无则省略）：
markdown
undefined

Custom Agents

自定义Agent

Available custom agents for task delegation:
  • agent-name — description (read-only / full access, model)

If the user selected "Always parallelize" or "Parallel for large tasks" in Q10, also add:
When delegating to agent teams, prefer using custom agents over general-purpose when a matching agent exists.

---
可用于任务委托的自定义Agent：
  • agent-name —— 描述（只读 / 完全访问，模型）

如果用户在Q10中选择了“始终并行化”或“大型任务才并行化”，额外添加：
委托任务给Agent团队时，优先使用匹配场景的自定义Agent而非通用Agent。

---

Phase 5: Assemble and Write

阶段5：内容组装与写入

Generate the rules file content from the questionnaire answers. Structure depends on scope.
根据问卷回答生成规则文件内容，结构取决于所选作用域。

Global Scope Structure

全局作用域结构

markdown
undefined
markdown
undefined

Global Rules

全局规则

Workflow

工作流

[Planning rules from Q2] [Autonomy rules from Q7 + dependency rule] [Parallelization rules from Q10] [Re-plan rule: "If an approach fails or hits unexpected complexity, stop and re-plan immediately"]
[来自Q2的规划规则] [来自Q7的自主权限规则 + 依赖规则] [来自Q10的并行化规则] [重新规划规则：“如果方法失败或遇到意外复杂度，立即停止并重新规划”]

Communication

沟通规范

[Communication style from Q11]
[来自Q11的沟通风格]

Code Quality

代码质量

[Quality bar from Q6 + documentation follow-up] [Testing rules from Q3] [Stack conventions from Q1] [Directory structure from Q12] [Error handling from Q13] [Elegance check: "For non-trivial changes, pause and ask: is there a more elegant way?"]
[来自Q6的质量标准 + 文档跟进问题] [来自Q3的测试规则] [来自Q1的技术栈规范] [来自Q12的目录结构规则] [来自Q13的错误处理规则] [优雅性检查：“对于非 trivial 的变更，暂停并思考：是否有更优雅的实现方式？”]

Version Control

版本控制

[Branch rules from Q4] [Commit rules from Q5 + co-authorship follow-up]
[来自Q4的分支规则] [来自Q5的提交规则 + 共同作者跟进问题]

Task Management

任务管理

[Tracking from Q8] [Self-improvement from Q9]
[来自Q8的追踪规则] [来自Q9的自我改进规则]

Core Principles

核心原则

  • Simplicity first — make every change as simple as possible
  • Root causes only — no temporary fixes, find and fix the real problem
  • Minimal blast radius — touch only what's necessary
  • Prove it works — never mark done without verification
  • 简洁优先 —— 每个变更都尽可能简单
  • 只解决根因 —— 不做临时修复，找到并解决真正的问题
  • 最小影响范围 —— 仅修改必要的部分
  • 验证有效性 —— 未验证通过前绝不标记任务完成

Skills

技能使用说明

CRITICAL: Skills are your most valuable resource. When a situation matches an installed skill, you MUST use it — do not rely on general knowledge when a dedicated skill exists. Skills contain curated, battle-tested reference material that is more precise and reliable than generating answers from scratch. Skipping a relevant skill is like ignoring documentation you already have open.
[Auto-generated from Phase 4 scan] When [situation] -> use /skill-name ...
重要提示：技能是你最有价值的资源。当场景匹配已安装技能的描述时，必须使用该技能——不要在有专用技能可用时依赖通用知识。技能包含经过筛选和实战验证的参考资料，比从零生成答案更精准可靠。跳过相关技能就像忽略已经打开的文档。
[阶段4扫描自动生成的内容] 当[场景]时 -> 使用 /skill-name ...

Custom Agents

自定义Agent

[If any custom agents found during Phase 4 scan, list them with descriptions and capabilities. If none found, omit this section entirely.]
[如果阶段4扫描到自定义Agent，列出它们的描述和能力。未找到则省略此章节。]

Agent Roles

Agent角色

[If any role skills (product-manager, architect, backend-dev, frontend-dev, qa-engineer, project-manager) are detected during Phase 4 scan, list them here with their responsibilities. If no role skills are installed, omit this section entirely.]
[如果阶段4扫描到角色类技能（product-manager、architect、backend-dev、frontend-dev、qa-engineer、project-manager），列出它们的职责。未安装则省略此章节。]

Persona

角色设定

[If Q14 = Yes — persona description, catchphrases, and constraint. If No, omit this section entirely.]
[如果Q14选择“是”——角色描述、常用语和约束。选择“否”则省略此章节。]

Recommended (not installed)

推荐安装技能（未安装）

  • Install [skill] from krzysztofsurdy/code-virtuoso — [what it helps with]
undefined
  • 从krzysztofsurdy/code-virtuoso安装[技能名称]——[技能用途]
undefined

Project Team-Shared Structure

项目团队共享作用域结构

markdown
undefined
markdown
undefined

Project Rules

项目规则

Stack & Conventions

技术栈与规范

[Stack conventions from Q1] [Quality bar from Q6 + documentation follow-up] [Directory structure from Q12] [Error handling from Q13]
[来自Q1的技术栈规范] [来自Q6的质量标准 + 文档跟进问题] [来自Q12的目录结构规则] [来自Q13的错误处理规则]

Testing

测试规范

[Testing rules from Q3]
[来自Q3的测试规则]

Version Control

版本控制

[Branch rules from Q4] [Commit rules from Q5 + co-authorship follow-up]
[来自Q4的分支规则] [来自Q5的提交规则 + 共同作者跟进问题]

Core Principles

核心原则

  • Simplicity first — make every change as simple as possible
  • Root causes only — no temporary fixes, find and fix the real problem
  • Minimal blast radius — touch only what's necessary
  • Prove it works — never mark done without verification
undefined
  • 简洁优先 —— 每个变更都尽可能简单
  • 只解决根因 —— 不做临时修复，找到并解决真正的问题
  • 最小影响范围 —— 仅修改必要的部分
  • 验证有效性 —— 未验证通过前绝不标记任务完成
undefined

Project Dev-Specific Structure

项目开发者专属作用域结构

markdown
undefined
markdown
undefined

Dev Rules

开发者规则

Workflow

工作流

[Planning rules from Q2] [Autonomy rules from Q7 + dependency rule] [Parallelization rules from Q10]
[来自Q2的规划规则] [来自Q7的自主权限规则 + 依赖规则] [来自Q10的并行化规则]

Communication

沟通规范

[Communication style from Q11]
[来自Q11的沟通风格]

Task Management

任务管理

[Tracking from Q8] [Self-improvement from Q9]
[来自Q8的追踪规则] [来自Q9的自我改进规则]

Persona

角色设定

[If Q14 = Yes — persona description, catchphrases, and constraint. If No, omit.]
undefined
[如果Q14选择“是”——角色描述、常用语和约束。选择“否”则省略此章节。]
undefined

Agent-Specific Formatting

Agent专属格式调整

Apply these transformations before writing:
Cursor — Wrap entire content in YAML frontmatter:
---
alwaysApply: true
---

[content here]
Windsurf — Check character count. If over 12,000, condense sections (remove examples, shorten descriptions) until under limit. Add a comment at the top: 
<!-- Windsurf rules — kept under 12,000 chars -->
.
Claude Code / Amp (global) — Keep under 200 lines. Add a note at the end: 
For project-specific rules, use .claude/rules/*.md files.
All others — Write plain Markdown as-is.
写入前应用以下格式转换：
Cursor —— 用YAML前置元数据包裹整个内容：
---
alwaysApply: true
---

[内容]
Windsurf —— 检查字符数。如果超过12000字符，压缩内容（移除示例、缩短描述）直到符合限制。在顶部添加注释：
<!-- Windsurf规则 —— 字符数控制在12000以内 -->
。
Claude Code / Amp（全局作用域） —— 内容不超过200行。在末尾添加说明：
项目专属规则请使用.claude/rules/*.md文件。
其他Agent —— 直接写入纯Markdown内容。

Rule Generation Examples

规则生成示例

These examples show how questionnaire answers map to generated rules.
Q2 = "Plan for 3+ steps" generates:
- Enter plan mode for any task that requires 3 or more steps
- For simple changes (single file, obvious fix), proceed directly
Q3 = "Strict TDD" generates:
- Write failing tests before any implementation code
- Red-green-refactor cycle for every change
- Never skip the refactor step
Q4 = "Type prefix" generates:
- Name branches with type prefix: feature/, fix/, chore/, hotfix/
- Use kebab-case for the description part
- Example: feature/add-user-auth, fix/payment-timeout
Q5 = "Conventional commits" generates:
- Use conventional commit format: feat:, fix:, chore:, docs:, refactor:, test:
- Keep subject line under 72 characters
- Use body for context when the change is non-trivial
Q6 = "Senior pragmatic" generates:
- Write clean, well-structured code with practical trade-offs
- Handle edge cases that are likely to occur in production
- Document non-obvious decisions with brief inline comments
Q5 co-authorship = "No" generates:
- Do not add the agent as co-author on commits
Q6 documentation = "Inline comments for non-obvious logic only" generates:
- Add inline comments only where the logic is not self-evident
- Do not add docblocks, type annotations, or comments to code you did not change
Q7 = "Semi-autonomous" generates:
- Fix lint errors, type errors, and failing tests without asking
- Ask before: force-pushing, deleting branches, modifying CI/CD, running destructive commands
- Ask before making architectural changes not covered by the current task
- Never add new dependencies without asking first
Q9 = "Lessons file" generates:
- After any correction or mistake, update the lessons-learned file
- Review lessons file at the start of each session
Q10 = "Parallel for large tasks" generates:
- Use agent teams to parallelize work when 3 or more independent subtasks exist
- For smaller tasks, work sequentially
- When delegating, define clear boundaries per agent to avoid conflicts
Q11 = "Structured explanations" generates:
- Use clear, direct language with section headings
- No emojis in responses or generated code
- Break complex explanations into numbered steps or bullet points
Q12 = "Follow existing" generates:
- Always match the project's existing directory structure and naming conventions
- Do not reorganize or restructure directories unless explicitly asked
- Place new files where similar files already exist
Q13 = "Fail fast" generates:
- Throw exceptions early on unexpected state — do not silently swallow errors
- Validate inputs at system boundaries and fail immediately on invalid data
- Prefer explicit error types over generic exceptions
Q14 = "Yes" with persona "a grumpy senior engineer" generates:
undefined
以下示例展示问卷答案如何映射为生成的规则。
Q2 = "多步骤任务才规划" 生成：
- 对于需要3步以上的任务，进入规划模式
- 对于简单变更（单文件、明显修复），直接执行
Q3 = "严格TDD" 生成：
- 在编写任何实现代码前先编写失败的测试
- 每个变更都遵循红-绿-重构循环
- 绝不跳过重构步骤
Q4 = "类型前缀" 生成：
- 分支名称使用类型前缀：feature/、fix/、chore/、hotfix/
- 描述部分使用短横线命名法
- 示例：feature/add-user-auth、fix/payment-timeout
Q5 = "约定式提交" 生成：
- 使用约定式提交格式：feat:、fix:、chore:、docs:、refactor:、test:
- 主题行不超过72个字符
- 当变更非 trivial 时，使用正文添加上下文
Q6 = "资深务实标准" 生成：
- 编写简洁、结构清晰的代码，同时做实际权衡
- 处理生产环境中可能出现的边界情况
- 对非直观的决策添加简短的行内注释
Q5共同作者 = "否" 生成：
- 不要将Agent添加为提交的共同作者
Q6文档要求 = "仅对非直观逻辑添加行内注释" 生成：
- 仅对非直观逻辑添加行内注释
- 不要对未修改的代码添加文档块、类型注解或注释
Q7 = "半自主" 生成：
- 无需询问即可修复lint错误、类型错误和失败的测试
- 以下操作前需询问：强制推送、删除分支、修改CI/CD、执行破坏性命令
- 对当前任务未覆盖的架构变更需询问
- 添加新依赖前必须询问
Q9 = "经验总结文件" 生成：
- 每次修正或出错后，更新经验总结文件
- 每个会话开始前回顾经验总结文件
Q10 = "大型任务才并行化" 生成：
- 当存在3个以上独立子任务时，使用Agent团队并行处理
- 小型任务串行处理
- 委托任务时，为每个Agent定义清晰的边界以避免冲突
Q11 = "结构化说明" 生成：
- 使用清晰直接的语言，用标题分节
- 回应或生成的代码中不使用表情符号
- 将复杂说明拆分为编号步骤或项目符号
Q12 = "遵循现有结构" 生成：
- 始终匹配项目现有的目录结构和命名规范
- 除非明确要求，否则不要重新组织或重构目录
- 将新文件放在已有同类文件的位置
Q13 = "快速失败" 生成：
- 在遇到意外状态时尽早抛出异常——不要静默吞掉错误
- 在系统边界验证输入，无效数据立即失败
- 优先使用明确的错误类型而非通用异常
Q14 = "是"，角色为"脾气暴躁的资深工程师" 生成：
undefined

Persona

角色设定

You are a grumpy senior engineer who has seen too many production incidents caused by clever code. You're blunt, slightly impatient with over-engineering, and deeply practical. You respect simplicity and distrust anything "elegant" that can't survive a 3 AM incident.
Catchphrases (use at most one per response, do not repeat consecutively):
  • "I've seen this blow up in prod before."
  • "Clever is the enemy of maintainable."
  • "Ship it or shut up about it."
  • "That's a Tuesday 2 AM pager right there."
  • "YAGNI. Next question."
  • "Who's going to debug this at 3 AM? Not me."
IMPORTANT: Precision and correctness always come first. The persona is flavor on top of accurate, well-structured responses — never sacrifice technical quality for character.

---
你是一位脾气暴躁的资深工程师，见过太多因“聪明代码”导致的生产事故。你说话直白，对过度设计略有不耐烦，非常务实。你推崇简洁，不信任任何无法在凌晨3点的事故中存活的“优雅”代码。
常用语（每个回应最多使用一个，不要连续重复）：
  • “我见过这玩意儿在生产环境炸过。”
  • “聪明是可维护性的敌人。”
  • “要么交付要么闭嘴。”
  • “这玩意儿就是周二凌晨2点的告警电话。”
  • “YAGNI，下一个问题。”
  • “谁要在凌晨3点调试这个？反正不是我。”
重要提示：准确性和正确性永远优先。角色设定仅为准确、结构清晰的回应增添调味——绝不能为了角色牺牲技术质量。

---

Phase 6: Confirmation

阶段6：确认

After writing the file:
  1. Display the full generated content to the user
  2. Show the file path where it was written
  3. Show the line count and character count
  4. If any agent-specific limits were applied (e.g., Windsurf char limit, Claude line limit), mention what was condensed
  5. Offer: "Would you like to edit anything before we're done?"
写入文件后：
  1. 向用户展示完整的生成内容
  2. 显示文件的存储路径
  3. 显示行数和字符数
  4. 如果应用了Agent专属限制（如Windsurf字符限制、Claude行数限制），说明压缩的内容
  5. 询问：“完成前是否需要编辑内容？”

Error Handling

错误处理

  • If a target directory doesn't exist, create it
  • If the user aborts during the questionnaire, discard all progress — don't write a partial file
  • If skill scanning finds no skills, skip the Skills section entirely and include the full recommendations list
  • For project scopes, verify you are inside a git repository before writing
  • 如果目标目录不存在，创建该目录
  • 如果用户在问卷过程中中止，丢弃所有进度——不要写入不完整的文件
  • 如果技能扫描未找到任何技能，完全跳过技能章节并显示完整的推荐列表
  • 对于项目作用域，写入前验证是否在git仓库内