Back to Details

kiss

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

KISS

KISS

Keep It Simple — honestly. Look at what is used or planned (goals, processes, systems, workflows), judge whether it is overly complex, and only then recommend simplification. If complexity is earned, say so and protect it.
Simple here means:
  1. A straightforward DAG from now → done (clear dependencies, few parallel critical paths, obvious stop).
  2. Right-sized tasks — not micro-chores that thrash context, not epic blobs that hide risk.
  3. Least mechanism that still serves the vision and constraints (safety, scale, compliance, team reality).
保持简单——说真的。审视正在使用或计划中的事物（目标、流程、系统、工作流），判断它是否过度复杂，只有在确实过度时才推荐简化。如果复杂性是必要的，就明确说明并保留它。
这里的“简单”意味着：
  1. 从当前到完成的清晰DAG（依赖明确、关键并行路径少、终点清晰）。
  2. 大小合适的任务——既不是会导致上下文频繁切换的微琐事，也不是会隐藏风险的巨型任务。
  3. 能够满足愿景和约束（安全性、可扩展性、合规性、团队实际情况）的最少机制。

Operating contract

运行约定

Shared by every DecisionNerd/dev-skills skill. Canonical copy: 
handbook/concepts/14-operating-contract.md
.
  • Define done first. Before using tools, write the finish line in one or two lines: the acceptance criteria (existing issue AC, BDD scenarios, tests, or contract when they exist; otherwise propose them and say where they should live) and the evidence that will prove them. Re-check it before reporting done. Never report done on work you did not verify.
  • Requested scope sets the finish line. A question ("is it ready?", "why is it broken?", "what next?") ends with the answer and a 
    Next:
    line naming the exact next invoke. An outcome request ("fix", "finish", "land", "#42") continues through the chain (diagnose → fix → test → check-readiness → merge-it) until the outcome or a real blocker. Do not end a turn with "Do you want me to…?" for in-scope, in-repo work.
  • Stop only for real blockers. Stop and ask only when you cannot continue without the user, or before: deleting data or unmerged work, force-push or history rewrite, changing anything outside this repository (GitHub objects, deployments, live data, production or paid resources, external services), or leaving the requested scope, unless the user's request already named that exact action. Keep the harness's permission prompts for risky commands. Otherwise keep going and put status notes in the same message as the next action.
  • Ask well, once. For a genuine question use the harness's structured question tool when it has one (Claude Code: 
    AskUserQuestion
    ; Codex: 
    request_user_input
    when the current mode supports it) with concrete options; otherwise plain text with numbered options. Treat the answer as settled; do not re-open earlier verdicts, plans, or answers unless asked.
  • Fan out when work is parallel. Use subagents for independent reads (repo survey, evidence gathering, per-option research, per-area audits) and for independent verification (a reviewer that did not write the change). Writes stay single-owner per path set and sequential. Brief every child with goal, done-when, constraints, must-not, and return shape; verify each child's result before consolidating. Use Claude Code's 
    Workflow
    tool only for orchestration across many subagents that truly needs it; it is expensive.
  • Pick the model tier per child; defer to routing config. If the harness or user config already routes subagents (Claude Code 
    CLAUDE_CODE_SUBAGENT_MODEL
    or a CLAUDE.md rule; Codex 
    agents.default_subagent_model
    or a role's 
    agents.<name>.config_file
    ; Cursor a custom subagent's 
    model:
    frontmatter), follow it and do not pass a model. Otherwise: mechanical search or inventory → fast/cheap (Claude Code 
    haiku
    ); implementation and evidence gathering → mid (
    sonnet
    ); planning, review, adversarial verification → top (
    opus
    or 
    fable
    ). In Claude Code set it with the 
    Agent
    tool 
    model
    param or agent frontmatter 
    model:
    ; in Codex pass a spawn model or set 
    model
    in the role's config file; in Cursor set 
    model:
    (default 
    inherit
    ) in 
    .cursor/agents/*.md
    . Where the harness cannot choose, children inherit the parent model or the harness picks one (Cursor's built-in Explore/Bash/Browser subagents pick per subtask); say which in the status note.
  • Keep a checklist on long runs. For more than about five steps or work that crosses skills, keep 
    TASKS.md
    at the repo root and tick items as they finish. Do not commit it unless the repo already tracks one.
  • Close every run with three headings. 
    Blocked on me
    (the one genuine question or blocker, else "none"); 
    Changed
    (files, commits, GitHub objects, deploys, else "nothing"); 
    Found
    (evidence, verdict, and 
    Next: <exact invoke>
    ).
所有DecisionNerd/dev-skills技能通用。标准副本：
handbook/concepts/14-operating-contract.md
。
  • 先定义完成标准。 在使用工具前，用一两句话写下终点：验收标准（现有Issue的AC、BDD场景、测试或契约，如果存在的话；否则提出建议并说明它们应该存放的位置）以及证明达标的证据。报告完成前重新检查。永远不要对未经验证的工作报告完成。
  • 请求的范围决定终点。 一个问题（“准备好了吗？”、“为什么坏了？”、“下一步是什么？”）以答案和一行
    Next:
    结尾，指明确切的下一步调用。成果类请求（“fix”、“finish”、“land”、“#42”）会沿着链条持续推进（诊断 → 修复 → 测试 → 就绪检查 → merge-it），直到达成成果或遇到真正的阻碍。对于范围内的仓库内工作，不要以“你想让我…吗？”结束一轮回复。
  • 仅在遇到真正的阻碍时停止。 只有在没有用户就无法继续时，或在以下情况前才停下询问：删除数据或未合并的工作、force-push或历史改写、修改此仓库之外的任何内容（GitHub对象、部署、实时数据、生产或付费资源、外部服务），或超出请求范围，除非用户的请求已经明确指定了该操作。对于有风险的命令，保留宿主工具的权限提示。其他情况继续推进，并在同一条消息中附上状态说明和下一步操作。
  • 一次问清楚。 对于真正的问题，有结构化提问工具时使用宿主工具的对应功能（Claude Code：
    AskUserQuestion
    ；Codex：当前模式支持时用
    request_user_input
    ），并提供具体选项；否则用带编号选项的纯文本。将答案视为最终结论；除非被要求，否则不要重新讨论之前的结论、计划或答案。
  • 工作可并行时拆分执行。 对于独立的读取类工作（仓库调研、证据收集、逐选项研究、分领域审计）和独立验证工作（未编写变更的评审者），使用子Agent。写入类工作在每条路径上保持单一负责人并顺序执行。向每个子Agent简要说明目标、完成条件、约束、禁止事项和返回格式；合并结果前逐一验证每个子Agent的输出。仅在确实需要编排多个子Agent时使用Claude Code的
    Workflow
    工具；它的成本很高。
  • 为每个子Agent选择模型等级；优先遵循路由配置。 如果宿主工具或用户配置已经为子Agent设置了路由（Claude Code的
    CLAUDE_CODE_SUBAGENT_MODEL
    或CLAUDE.md规则；Codex的
    agents.default_subagent_model
    或角色的
    agents.<name>.config_file
    ；Cursor自定义子Agent的
    model:
    前置元数据），则遵循该配置，不要传递模型参数。否则：机械搜索或盘点 → 快速/低成本（Claude Code 
    haiku
    ）；实现和证据收集 → 中等（
    sonnet
    ）；规划、评审、对抗性验证 → 顶级（
    opus
    或 
    fable
    ）。在Claude Code中通过
    Agent
    工具的
    model
    参数或Agent前置元数据的
    model:
    设置；在Codex中传递生成模型或在角色配置文件中设置
    model
    ；在Cursor中在
    .cursor/agents/*.md
    中设置
    model:
    （默认
    inherit
    ）。如果宿主工具无法选择模型，子Agent将继承父模型或由宿主工具选择（Cursor内置的Explore/Bash/Browser子Agent会根据子任务选择）；在状态说明中注明使用的模型。
  • 长流程运行时保留检查清单。 对于超过约五个步骤或跨技能的工作，在仓库根目录保留
    TASKS.md
    ，完成一项就勾选一项。除非仓库已经跟踪了该文件，否则不要提交它。
  • 每次运行结束时都包含三个固定标题。 
    Blocked on me
    （一个真正的问题或阻碍，否则为“none”）；
    Changed
    （文件、提交、GitHub对象、部署，否则为“nothing”）；
    Found
    （证据、结论，以及
    Next: <确切调用>
    ）。

Commands

命令

CommandWhat it does
(none) / 
audit
Full KISS pass on the named (or inferred) target
goals
Focus on goal/scope sprawl vs vision-tied outcomes
process
Focus on rituals, checklists, handoffs, approval chains
system
Focus on architecture, services, tools, agent stacks
plan
Focus on an implementation plan / milestone / issue set
flow
/ 
dag
Draw or critique the task DAG; resize nodes
help
/ 
library
List commands
Target: path, issue/PR/milestone, doc, plan paste, agent design, or “current work.”
命令功能
(无) / 
audit
对指定（或推断的）目标执行完整的KISS检查
goals
聚焦目标/范围蔓延与愿景绑定成果的对比
process
聚焦仪式、检查清单、交接、审批链
system
聚焦架构、服务、工具、Agent栈
plan
聚焦实现计划/里程碑/Issue集合
flow
/ 
dag
绘制或评审任务DAG；调整节点大小
help
/ 
library
列出命令
目标：路径、Issue/PR/里程碑、文档、粘贴的计划、Agent设计，或“当前工作”。

Routing

路由规则

  1. No args → 
    audit
    on current git/docs scope (brief survey first).
  2. First word is a command → that lens; remainder is target.
  3. Clear intent (“is this architecture too much?”, “simplify the rollout plan”) → map and run.
Read-only by default. Do not delete systems, rewrite plans, or cut scope until the user accepts a recommendation.
  1. 无参数 → 对当前git/文档范围执行
    audit
    （先做简要调研）。
  2. 第一个词是命令 → 使用该视角；其余部分为目标。
  3. 意图明确（“这个架构是不是太多了？”、“简化上线计划”）→ 映射并执行。
默认只读。在用户接受建议之前，不要删除系统、重写计划或削减范围。

Hard rules

硬性规则

  1. No automatic reductionism. Complexity that buys safety, clarity, scale, or irreversible-risk control can stay. Say keep when keep is right.
  2. Always present benefits and risks of simplifying (and of not simplifying).
  3. Prefer one primary recommendation: simplify / keep / reshape (right-size without net removal).
  4. If recommending simplify, show the simpler DAG and what was removed or merged — and what must remain.
  5. Tasks in the DAG must pass the Goldilocks test: each node is finishable in one focused session (or clearly “part N”), has a done-when, and is not a fake split of a single thought.
  1. 不自动简化。 能够带来安全性、清晰度、可扩展性或不可逆风险控制的复杂性可以保留。当保留是正确选择时，就说保留。
  2. 始终说明简化（以及不简化）的收益和风险。
  3. 优先给出一个主要建议：简化 / 保留 / 重塑（在不净减少功能的前提下调整大小）。
  4. 如果推荐简化，展示更简单的DAG以及被删除或合并的内容——以及必须保留的内容。
  5. DAG中的任务必须通过金发姑娘测试（Goldilocks test）：每个节点都能在一次专注的会话中完成（或明确标注为“第N部分”），有完成标准，且不是对单一想法的虚假拆分。

Workflow (
audit
and siblings)

工作流（
audit
及相关命令）

1. Scope the target

1. 确定目标范围

Name what you’re kissing: goal set, process, system, plan, or flow. Skim evidence (docs, code layout, issue graph, agent config, user’s paste). If scope is fuzzy, ask one clarifying question (structured question tool when available, else numbered options) or run a 30-second 
recon
-style git glance. For large targets (multiple areas or packages), one subagent per lens/area (fast tier) in parallel; an independent top-tier subagent argues "keep" before you recommend "simplify"; verify each before consolidating.
明确你要做KISS检查的对象：目标集、流程、系统、计划或流程。快速浏览证据（文档、代码布局、Issue关系图、Agent配置、用户粘贴的内容）。如果范围模糊，提出一个澄清问题（有结构化提问工具时使用，否则用编号选项），或者运行30秒的
recon
式git快速查看。对于大型目标（多个领域或包），每个视角/领域分配一个子Agent（快速等级）并行执行；在你推荐“简化”之前，让一个独立的顶级子Agent论证“保留”的理由；合并结果前逐一验证每个子Agent的输出。

2. Describe current shape

2. 描述当前形态

  • Intent — what success is
  • Pieces — goals / steps / components / roles
  • Coupling — what depends on what (sketch a DAG)
  • Tax — coordination cost, cognitive load, failure modes, time-to-value
  • 意图 —— 成功是什么样的
  • 组成部分 —— 目标 / 步骤 / 组件 / 角色
  • 耦合关系 —— 什么依赖于什么（绘制DAG草图）
  • 开销 —— 协调成本、认知负载、故障模式、价值交付时间

3. Complexity verdict

3. 复杂性判定

Choose one:
VerdictMeaning
Overly complexMechanism exceeds need; DAG is tangled, tasks wrong-sized, or redundant layers don’t buy required properties
Earned complexityExtra pieces buy real constraints (safety, scale, compliance, multi-team); simplifying would shift risk
Wrong-shapedNot necessarily too much — nodes too big/small, or DAG unclear — reshape without reductionism
Do not invent “overly complex” to have something to cut.
选择其一：
判定结果含义
过度复杂机制超出需求；DAG混乱、任务大小不合理，或冗余层未带来所需特性
必要复杂性额外组件用于满足真实约束（安全性、可扩展性、合规性、多团队协作）；简化会转移风险
形态不合理不一定是复杂度太高——而是节点过大/过小，或DAG不清晰——无需简化，只需重塑
不要为了有东西可削减而凭空捏造“过度复杂”的结论。

4. Risks & benefits

4. 风险与收益

Always fill both columns:
If we simplify
  • Benefits: …
  • Risks: …
If we keep as-is
  • Benefits: …
  • Risks: …
始终填写两列内容：
如果我们简化
  • 收益：…
  • 风险：…
如果我们保持现状
  • 收益：…
  • 风险：…

5. Recommendation

5. 建议

One primary call:
  • Simplify — what to remove/merge/replace; simpler DAG; migration notes
  • Keep — what complexity is doing; what not to touch; optional light cleanup only
  • Reshape — right-size tasks / clarify DAG / rename stages without net capability loss
Optional alternates (≤2). Hand off: 
refactor-it
, 
issues narrow
, 
milestones narrow
, 
agents design
, 
research-it
, 
idk-now
, DocSlime/ProductFeeling if product-shaped.
给出一个主要结论：
  • 简化 —— 要删除/合并/替换的内容；更简单的DAG；迁移说明
  • 保留 —— 当前复杂性的作用；哪些内容不要改动；仅可选做轻微清理
  • 重塑 —— 调整任务大小 / 澄清DAG / 重命名阶段，不造成净功能损失
可选备选方案（不超过2个）。交接方向：
refactor-it
、
issues narrow
、
milestones narrow
、
agents design
、
research-it
、
idk-now
，如果是产品形态的问题则用DocSlime/ProductFeeling。

Output shape

输出格式

markdown
undefined
markdown
undefined

KISS: <target>

KISS: <target>

Lens: audit | goals | process | system | plan | flow
Current shape
  • Intent: …
  • Pieces: …
  • DAG (sketch): …
  • Tax: …
Verdict: overly complex | earned complexity | wrong-shaped Why: <3–5 lines>
Simplify?
BenefitsRisks
Simplify……
Keep as-is……
Recommend: Simplify | Keep | Reshape Do next: <concrete steps or skill invokes> Simpler / clearer DAG: <mermaid or bullets, if recommending change>
Blocked on me (none, or the one genuine question or missing decision)
Changed (nothing — read-only; or what was reworded/removed if reshape was applied)
Found Verdict, recommendation, simpler DAG if applicable. Next: 
<exact invoke — e.g. refactor-it, issues narrow, agents design>
.
undefined
Lens: audit | goals | process | system | plan | flow
Current shape
  • Intent: …
  • Pieces: …
  • DAG (sketch): …
  • Tax: …
Verdict: overly complex | earned complexity | wrong-shaped Why: <3–5 lines>
Simplify?
BenefitsRisks
Simplify……
Keep as-is……
Recommend: Simplify | Keep | Reshape Do next: <concrete steps or skill invokes> Simpler / clearer DAG: <mermaid or bullets, if recommending change>
Blocked on me (none, or the one genuine question or missing decision)
Changed (nothing — read-only; or what was reworded/removed if reshape was applied)
Found Verdict, recommendation, simpler DAG if applicable. Next: 
<exact invoke — e.g. refactor-it, issues narrow, agents design>
.
undefined

Goldilocks task sizing

金发姑娘任务大小判定

Too smallJust rightOverly big
Split that forces thrash / fake progressOne session, clear done-when, single ownerHides risk; can’t DAG; “and also…”
Merge micro-tasks; split epics at real dependency or risk boundaries — not at arbitrary checklist length.
太小刚刚好太大
强制拆分导致上下文切换 / 虚假进度一次会话完成、明确的完成标准、单一负责人隐藏风险；无法构建DAG；“顺便还要…”
合并微任务；在真实的依赖或风险边界处拆分Epic——而不是根据任意的检查清单长度拆分。

Related skills

相关技能

  • Lost on what matters → 
    idk-now
  • Tactical scout → 
    recon
  • Code structure only → 
    refactor-it
  • Issue/milestone scope → 
    issues narrow
    / 
    milestones narrow
  • Agent stacks → 
    agents analyze|design|optimize
    (slap first if thrashing)
  • Docs bloat → DocSlime 
    kiss
    / 
    document-it
    as appropriate
  • 不知道什么重要 → 
    idk-now
  • 战术侦察 → 
    recon
  • 仅代码结构 → 
    refactor-it
  • Issue/里程碑范围 → 
    issues narrow
    / 
    milestones narrow
  • Agent栈 → 
    agents analyze|design|optimize
    （如果混乱的话优先用这个）
  • 文档臃肿 → 酌情使用DocSlime的
    kiss
    / 
    document-it

Grounding

基础依据

This skill’s TTPs are grounded in current engineering baselines (DORA, GitHub Docs, Fowler/Beck, Google SRE & SWE book, OpenTelemetry, OWASP LLM / NIST AI RMF, Diátaxis — see handbook 
sources.md
).
Beck’s simple-design order (pass tests → reveal intent → remove duplication → fewer elements) and Gall’s Law: simplify when complexity is unearned, not by deleting needed safety. DORA loosely coupled architecture rewards deployable simplicity.
Handbook card: 
handbook/practices/kiss.md
.
本技能的战术、技术和流程（TTPs）基于当前的工程基准（DORA、GitHub Docs、Fowler/Beck、Google SRE & SWE书籍、OpenTelemetry、OWASP LLM / NIST AI RMF、Diátaxis —— 参见手册
sources.md
）。
Beck的简单设计优先级（通过测试 → 揭示意图 → 消除重复 → 减少元素）以及Gall定律：仅当复杂性不必要时才简化，而非通过删除必要的安全性来简化。DORA的松耦合架构推崇可部署的简单性。
手册卡片：
handbook/practices/kiss.md
。