using-creed

使用 Creed

**输出语言：**使用用户自己的语言回答并撰写产物（与用户的消息保持一致，而不是与仓库的历史保持一致）。

如果你是作为子代理被派来执行特定任务的，请忽略此技能。

何时使用此技能

• 在 Creed 工作区开始会话
• 不确定适用哪项 Creed 技能
• 首次使用／配套技能可能缺失
• 开始创作、测试、调试或发布工作前——先选择合适的技能

快速开始（安装）

必须安装配套技能——仅有 using-creed 并不足够：

npx skills add Gusen1453/creed

检测安装情况

必需技能：explore、grill、issue、write-spec、solid、write-plan、tdd、test-design、debug、review、commit-and-push。

如果工作区技能列表中缺少任何一项：停止并要求用户运行上方的安装命令，然后再开始工作。不要凭记忆编造 Creed 工作流。

已安装但版本过旧？ 仓库只是源文件；安装内容是快照，因此编辑仓库不会产生任何影响，除非重新安装。检测安装是否过旧，并刷新它（仅在用户明确确认后）——参见 references/install-and-update.md。

使用方法

1. 将任务与下方映射中的技能对应起来。
2. 宣布 Using <skill> to …，阅读该技能并遵循其要求。
3. 如果技能包含检查清单，每项都列为一个待办事项。
4. 适用多项技能时，遵循默认流程；两个工作产物之间运行转换关卡（见下文）——绝不自动进入下一项技能，也绝不自动进行审查：

using-creed
  → explore? → grill → [gate] → issue? → write-spec → [gate] → solid? → [gate]
  → write-plan → [gate] → tdd (+ test-design)
  → [gate] → debug? → [gate] → review → [gate] → commit-and-push

explore? = 当任务会修改或引用现有代码（重构／遗留代码／复用）时设置关卡；全新开发时跳过。

issue? = 在 grill 的退出关卡中，其中一个选项会在编写规格说明前，将意图登记为可跟踪的问题；选择该选项后返回同一关卡。没有事项需要搁置时跳过。

solid? = 仅当该切片新增模块／端口／IO 边界时设置关卡；没有新增边界时跳过。跳过后，write-spec → solid 和 solid → write-plan 两个关卡合并为一个 write-spec → write-plan 关卡（审查对象仍为规格说明；仅移除审查边界选项）。

[gate] = 转换关卡——每次交接时提出一个 AskUserQuestion；参见转换关卡。

Transition gates

大多数产出型技能都会以各自的 Transition gate 部分收尾：在交接时提出一个 AskUserQuestion——绝不自动进入下一个技能，也绝不自动进行审查。不同技能的选项并不相同，而且并非每个技能都有此环节。 grill 的 gate 选项是继续／重新打开设计／先提交 issue／其他，并且没有审查选项（因为还没有任何内容可供审查）；issue 特意没有自己的 gate——冷启动时它只会报告，在流水线中则会把控制权交回 grill 的 gate，因此只会提问一次。其余技能遵循以下形式。请查看技能的 Hand-off，不要想当然。

A) Recommended: Proceed → <next skill>
B) Review first — run **review** on the just-finished <object>
   (its rubric in the review skill's `references/`), then return to this gate and re-ask
C) Adjust — go back to <producing skill>, revise the <object>, then re-gate
D) Something else (I will type it)

规则（适用于遵循上述形式的 gate——grill 的 gate 不同，issue 则没有 gate）：

• 选择 B → 使用相应的评分标准对该对象运行 review（它会将该对象与其直接上游对象进行核对；必须包含 claim→case 表格）。修复 Critical + Important 级别的问题，或让用户说明理由并推迟处理。然后返回同一个 gate 并再次提问——用户可以选择 A、要求再审一轮，或进行调整。
• 选择 C → 返回产出该对象的技能，进行修改，然后重新对该对象设置 gate。
• 仅在以下情况下跳过：用户说过“本次会话跳过所有 gate”，或明确豁免某个特定 gate。gate 只是一个简单问题，不是仪式——“太简单了，不值得提问”正是反模式。

有两个自定义 gate：grill → write-spec 目前没有可供审查的内容（spec 尚未编写——没有审查选项：继续／重新打开设计／先提交 issue）；review → commit-and-push 用于把关报告结论（只有在 Critical／Important 问题已修复或已获豁免时才继续——绝不盲目自动发布）。

跳过 solid?（没有新边界）→ write-spec → solid 和 solid → write-plan 两个 gate 合并为一个 write-spec → write-plan gate（审查对象仍是 spec；仅移除审查边界选项）。

技能图谱（场景）

情况	技能
重构 / 修改现有代码——任务名称涉及要修改或引用的方法 / 类 / 表	explore → grill → write-spec → …
新功能 / 行为变更 / 架构 / “grill me” / 头脑风暴——编写任何代码之前	grill
记录 / 提交某项内容以便日后跟进——“记一下这个 bug”、“提个 issue”、“这个先放着”、bug 报告或功能请求	issue
已批准的设计 → 持久化产品规格（场景、范围、决策日志）	write-spec
规格完成后：锁定包 / 端口 / 依赖关系；或存在模拟堆积 / 耦合异味	solid
已批准的规格（必要时包含 solid）→ 将多步骤工作拆解为 TDD 任务	write-plan
编写生产代码（功能 / bug 修复 / 重构）	tdd
编写或审查测试：是否值得测试？单元测试还是集成测试？断言 / 模拟什么？	test-design
Bug、测试 / CI 失败、意外行为，或即将声称“已修复”	debug
完成一个任务切片 / 打开或更新 PR 之前	review
阶段交接——由用户决定接下来做什么	产出技能的 Hand-off 部分（选项各不相同；issue 没有此部分）
将规格 / 计划 / 结构决策本身作为对象审查（而不是代码）	review（转到 references/{spec,plan,solid}.md）
用户要求提交 / 推送 / 打开 PR（PR 需要测试计划）	commit-and-push

常见搭配：

• explore → grill — explore 收集仓库事实（锚点、断言检查、冲突）；随后 grill 只询问需要判断的问题。
• grill → write-spec — grill 对齐决策；write-spec 固化内容 / 原因，便于指导和交接。
• write-spec 与 write-plan 的区别 — spec = 产品场景和权衡；plan = 文件、顺序、RED→GREEN。
• write-spec → solid? → write-plan — 当边界是新的，solid 是一道关卡；并非每次都必须执行。
• tdd + test-design — tdd 是节奏（先写测试，观察失败）；test-design 决定输入什么、断言什么以及模拟什么。实现时两者都要用。
• debug → tdd — 修复 bug：先用证据查明根因，再编写失败的回归测试。
• grill & solid — grill 期间，只在选项中指出边界异味；在内容 / 原因确定之前，不要将主技能切换为 solid。

最简任务提示词模板（供人使用）

三个区块；Agent 会探索其余内容，只针对仓库无法回答的问题进行 grill：

Task: <one-line intent, name the method/class to change>
Hard constraints: <numbers, policies, red lines — only you know these>
Explore hints (optional): <class/method names to reference; the agent reads them itself — no need to describe>
Acceptance (optional): <one line of demo language: how we'll know it works>

Let the agent explore the repo for the rest; grill it only on judgment calls. Run /grill

硬约束栏规则：

• 软约束措辞（“尽量不要” / 偏好式表述）= 优先级，而非禁令。如果与仓库实际情况冲突（例如，重新运行的幂等性），explore 会在事实清单中标出冲突，grill 会将其转化为权衡问题供你决定。
• 不要写 SQL、字段名、方法签名或组装细节——这些都是仓库可以回答的事实；写下来可能与代码矛盾。

示例（之前 → 之后）——同一任务：约 600 个字符 → 约 150 个字符。删去的内容都可以由仓库回答（SQL、字段名、方法签名、组装细节）；保留的内容都只能由人决定（并发、重试策略、红线）：

Before: 6-step flow + 3 SQL snippets + thread-pool/retry/Redis details + "the response format needs to be
List<ImageEmbeddingUpdateRequest.ContentItem> batchContentList" (a guess about the code)

After: Refactor RagRecoverPushJob#imageRecover to re-push dp_research_report_structure_info
(data_source in ('2','3'), id 111~2000) to the vector DB.
Hard constraints: descending pagination, 1000 per batch; 40-concurrency thread pool; on push failure retry
once, then enqueue to Redis for retry; try not to update dp_research_report_image_search.
Explore hints: SecAnnouncementThreadPoolManager, PushImageChunkService#buildReportChunkDto/#sendListToRag.
Let the agent explore the repo for the rest; grill it only on judgment calls. Run /grill

检查清单

• 已安装配套的 Creed 技能（否则 → Quick Start）
• 已确定相关的 Creed 技能（或明确标记为 N/A）
• 已阅读 / 遵循技能要求；已宣布
• 已在每个 [gate] 运行转换关卡——用户选择了该技能的某个选项（继续 / 审查 / 调整，或 grill 的重新打开 / 提交问题），或明确放弃