超能力方法论（tri-superpower · 横向型方法论参考 skill）
> 本 skill 是横向型方法论知识包（原型 skill-archetypes §B）：由用户显式调用或下游 skill 引用激活，不由 tri-intent 依 L2 直接路由。
> 唯一对照基准：家族方法论对照基准档（tri-code-analyzer 深度穿透分析报告，内部归档，2026-09-17）。本包每条方法论规则 MUST 标注基准档 § 锚点；NEVER 引入基准档未记载的能力断言（一致性红线，用户任务硬约束）。
> 用户心智：把 AI 当「方法论检索器与应用器」——问一条规则，拿到规则原文 + 基准档锚点 + 应用方式；给一个任务，按 7 步工作流给出流程指导。
强制执行契约（Execution Contract · 最高优先级）
> 本节定义 skill「被激活后必须做什么」，优先级高于 Agent 的通用默认行为。用户命中触发语或下游 skill 引用本包规则即视为激活本工作流，不得仅将其当作参考文档。
- 版本检查前置硬门（第零步）：MUST 先通过 §版本检查与更新机制（运行
scripts/check_update.py，按tri-forge/references/version-check-spec.md四态判定处置；非最新版自动升级，升级通道不可用则降级继续）——此为执行流程第零步，优先于后续所有步骤。版本检查完成前 NEVER 进入后续步骤。本条目优先级高于所有其他强制前置条目。 - 教训预载：版本检查后 MUST 优先读取
.tribro/superpower/lessons.md（历史执行沉淀的经验教训）；目录或文件不存在时静默跳过——NEVER 报错、NEVER 阻断、NEVER 追问。 - 一致性红线（本 skill 第一性规则）：输出的每一条 superpowers 方法论规则 MUST 与对照基准档一致并标注基准档 § 锚点；基准档未记载的行为细节 MUST 显式标注「基准档未展开，细节以原项目为准」（置信度标注降为推断）；NEVER 编造方法论未记载的功能或规则。
- 结论置信标注：本 skill 产出的每一个结论性表达 MUST 附三要素：① 置信度（高/中/低）；② 依据类型六选一（
事实 known/计算 computed/推断 inferred/常识 common/框架 iframe/猜测 guess）；③ 可验证来源。guess类标低置信并提示人工验证。 - 自检：作答前用一句话声明「本次操作=<方法检索/流程指导/对照校准>，触发源=<用户显式/下游引用>，已读取<方法论索引/教训=<N 条/无文件>>」，若与上述规则冲突则停止并纠正。
- MUST/NEVER 大写：契约与关键规则一律大写祈使；描述性文字不受限。
触发时机
激活分支（由用户显式调用 / 下游 skill 委派激活，不由 tri-intent 依 L2 直接路由）：
| 触发分支 | 典型信号 | 模式 |
|---|---|---|
| 用户显式调用 | 「用 superpowers 的方法论」「按 superpowers 流程做 X」「给我 superpowers 的 SDD/brainstorming/writing-skills 规则」 | 模式 A/B |
| 下游 skill 引用 | tri-coding/tri-review/tri-fix 等需要方法论规则佐证（如审查裁决依据、计划格式规范） | 模式 C |
| 方法检索 | 「本包里怎么说 YY」「superpowers 对 ZZ 的规则是什么」 | 模式 A |
不由本 skill 处理（命中以下信号 MUST 指向对应 skill，NEVER 在本工作流内代办）：
| 信号 | 归属 |
|---|---|
| 意图识别与路由 | tri-intent |
| 生成业务代码 | tri-coding |
| 执行代码审查 | tri-review（本包仅提供 receiving-review 等方法论佐证） |
| 锻造/补全 skill | tri-forge |
| 用户要把某工作流/方法论沉淀为 skill（通用对象） | tri-god |
输入契约
| 字段 | 用途 | 默认值 |
|---|---|---|
mode |
方法检索 / 流程指导 / 对照校准 | 由触发信号推断 |
target |
任务描述、问题、或待检索的规则名/skill 名 | 必填（缺失时从对话上下文提取；仍缺失则列 14 skills 地图供用户选择） |
context |
当前项目/语言栈/约束（用于规则的情境化应用建议） | 可选 |
职责边界
- 本 skill 负责：superpowers 方法论规则的检索（模式 A）、按 7 步工作流的流程指导（模式 B）、为下游 skill 提供规则佐证与裁决依据（模式 C）；全部输出锚定对照基准档。
- 不负责：意图识别（tri-intent）、业务代码生成（tri-coding）、审查执行（tri-review）、skill 锻造（tri-forge）、一般方法论蒸馏（tri-god）。
- 关键边界：本包是「规则知识 + 应用指导」，不是「原方法论插件本身」——它不安装 hooks、不注入 additionalContext、不携带任何原项目脚本；宿主平台适配属于原项目能力（对照基准档 §6.3 剔除清单）。
- 不触发场景（Not-Trigger）：本 skill 不接手「意图识别」（转 tri-intent）；不接手「业务代码生成」（属 tri-coding）；不接手「审查执行」（属 tri-review）；不接手「skill 锻造」（属 tri-forge）；不接手「一般方法论蒸馏」造 skill（属 tri-god，本 skill 只做规则检索与工作流指导）。
tri-superpower 方法论（可扩展）
> 核心内容为「一张地图 + 三大规则 + 七篇规则集」。地图常驻本文件；规则集按需加载 references/（含增补篇 methodology-deltas：对照基准档未逐条展开的行为经济学细节，锚定增补基准档 §4.2）。
14 skills 地图（对照基准档 §1.3/§2.1，置信度：高；依据：事实 known）
| 分组 | skills（原项目行数） | 一句话定位 |
|---|---|---|
| 工作流链 9 | brainstorming(197) / worktrees(168) / writing-plans(172) / SDD(457) / TDD(247) / systematic-debugging(211) / verification(121) / finishing(226) | 从想法到收尾的完整开发流程：先澄清意图→隔离工作区→写计划→执行（单代理或子代理）→测试驱动→调试→验收自查→收尾 |
| 审查协作 3 | dispatching(168) / requesting-review(96) / receiving-review(206) | 子代理派发纪律、审查请求包、审查意见接收与回应 |
| 元技能 2 | writing-skills(487) / using-superpowers(引导) | 「如何写 skill」的元方法论 + 引导注入正文（1% 规则载体） |
7 步基础工作流（对照基准档 §5.1，置信度：高；依据：事实 known）
brainstorming（澄清意图，一次一问）
→ worktrees（git worktree 隔离实现）
→ writing-plans（精确到任务粒度的计划文档）
→ SDD 或 executing-plans（子代理驱动 或 单代理批处理执行）
→ TDD（红绿循环，先测试后实现）
→ code-review（双阶段：spec 合规 + quality 质量）
→ finishing（收尾清理、文档同步、工作区合并）
三大核心规则（全包的决策内核，对照基准档 §2.1/§2.2，置信度：高；依据：事实 known）
- 1% 规则：只要有超过 1% 的可能性某个 skill/规则适用，MUST 先读取它再行动（对照基准档 §2.1）——对抗「代理偷懒跳过流程」。
- Cannot-verify 显式上报：无法验证某条验收标准时 MUST 显式上报「Cannot-verify」，NEVER 装作通过（对照基准档 §2.2 双裁决机制）——对抗「静默假通过」。
- rulings-not-stalls 裁决而非停摆：审查者发现问题给出裁决让执行者继续走，而非停下等待（对照基准档 §2.2 引入）——对抗「流程卡死」。
补充：用户显式指令优先于方法论规则（对照基准档 §2.1）——保留人工否决权。
设计哲学四条（对照基准档 §3.3，置信度：高；依据：事实 known）
可组合（composable）· 渐进披露（progressive disclosure）· 过程导向（process over outcome）· 确定性工具优先（把确定性步骤从 LLM 手里拿走，交给脚本）。
知识装配顺序（约束 25 · Prompt Layering）
| 层 | 载体 | 加载时机 |
|---|---|---|
| ① 常驻层 | 本文件（SKILL.md：地图/规则/流程） | 每次激活 |
| ② 方法论层 | references/ 七篇（按 mode/target 命中加载） | 模式判定后按需 |
| ③ 用户指定层 | 用户点名某 skill 细节时加载对应篇 | 显式要求 |
| ④ 外部覆盖层 | 无——本包自包含；外部资料仅为补充参照，NEVER 覆盖本包结论（以对照基准档为准） | — |
装配去重：同名规则只取 references/ 一处（本文件地图仅留指针）；grep 检索模式：grep -l "<关键词>" references/*.md——关键词索引：brainstorming/worktree/plan→methodology-workflow.md；SDD/subagent/ledger/熔断→sdd-subagent-development.md；TDD/debugging/verification→tdd-and-debugging.md；executing/review/YAGNI→plans-and-reviews.md；writing-skills/rationalization/SDO→writing-skills-guide.md；harness/版本联动/验收测试→harness-adaptation.md；模型选择/上下文经济学/形式匹配/微型测试/三路径棘轮/门控五步→methodology-deltas.md（增补篇，与主篇冲突时以增补篇为准）。
处理流程（三模式）
激活（用户显式 / 下游引用）
│
▼
第零步 版本检查 → 教训预载 → 自检句声明
│
▼
模式判定
├── A 方法检索：定位地图行 → 加载对应 references 篇 → 输出规则原文摘要 + 基准档 § 锚 + 应用建议
├── B 流程指导：按 7 步工作流定位当前环节 → 给该环节规则清单 + 反模式警示 + 下一步动作
└── C 对照校准：下游 skill 引用规则时 → 给出规则原文 + 裁决依据（SATISFIED/NOT/Cannot-verify 语义）+ 基准档锚
│
▼
输出（每条结论附置信标注三要素）→ 教训追加写入 .tribro/superpower/lessons.md
- 模式 A 输出格式：规则名 / 规则内容（压缩自对照基准档）/ 基准档 § 锚 / 置信三要素 / 一句应用建议。
- 模式 B 输出格式：当前环节定位 → 该环节 MUST 规则（≤5 条）→ Red Flags 反模式 → 下一环节。
- 模式 C 输出格式：被引规则原文 + 基准档锚 + 对当前争议的裁决建议（引用 rulings-not-stalls 或 Cannot-verify 语义时 MUST 注明出处环节）。
交付产物机制
| 产物 | 载体 | 内容 |
|---|---|---|
| 方法卡片 | 对话输出 | 单条规则：内容+锚+置信+应用建议（模式 A/C） |
| 流程指导 | 对话输出 | 环节规则清单+反模式+下一步（模式 B） |
| 教训记录 | .tribro/superpower/lessons.md |
本次执行的情境化教训（追加式，空泛内容禁写入） |
> 本 skill 为知识包，无独立文件交付物；对话输出即产物。若用户要求把某次规则应用固化为文档，落盘至用户指定路径（不落 .tribro/superpower/ 以外的包内路径）。
质量标准
| 维度 | 标准 | 验证方式 |
|---|---|---|
| 一致性 | 每条规则可回溯对照基准档 § 锚点；无基准档外能力断言 | 抽查任一输出，锚点可在对照基准档 grep 到 |
| 置信标注 | 结论性表达 100% 附三要素；guess ≤10% | grep 输出「置信度」 |
| 规则可检索 | references/ 每篇含关键词索引；地图行均有指针 | 按装配顺序表 grep 关键词命中 |
| 规模合规 | SKILL.md ≤500 行；references/ 单篇无膨胀（纯规则，无脚本内联） | wc -l |
| 版本一致 | SKILL==CHANGELOG==_meta==tests==README 版本号 | grep 版本串 |
落盘规则
- 本包自身：
.tribro/skills/tri-superpower/（tri-forge 生成物指定落盘位置，门③已执行）。 - 教训文件：
.tribro/superpower/lessons.md（启动读取；结束 MUST 追加写入；目录或文件不存在时创建；写入失败 MUST 提示用户但不阻断交付）。 - 本 skill 的链路审计文档：
.tribro/forge/I21_20260917_064900_wbsess/（forge-requirements.md / forge-compliance-report.md）。 - NEVER 生成
LICENSE或.gitignore——许可证仅由 frontmatterlicense: MIT声明。
版本检查与更新机制（强制技术约束 · 硬红线）
> 家族级强制技术约束，优先级与「强制执行契约」同级。skill 任一执行入口启动后的第零步，先于核心执行阶段。
> 细则唯一真源：tri-forge/references/version-check-spec.md（家族规范源，由 tri-forge 维护）。可执行实现：本包 scripts/check_update.py（与 tri-forge 同源，按 --slug 自适应）。
> 铁律：版本比较、升级执行、回退、四态判定 MUST 由脚本完成；prompt 层 ONLY「调用脚本 + 解析 JSON + 按 state 处置」，NEVER 在 prompt 内联推断版本或拼接升级命令。
执行方式（MUST）
- 启动后、核心执行前运行：
python scripts/check_update.py --slug tri-superpower --json - 解析
state字段：A/B/C/D→ 一律放行（据 warnings/notes 标注口径）；BLOCK→ 绝对禁止执行，按block_code输出结构化恢复指引。 - 退出码语义：
<20放行，>=20阻断；脚本自身异常时兜底降级放行，NEVER 因版本门自身故障阻断 skill 启动。 - 节流：24h 内仅校验一次；
--force强制重查；--dry-run只判定不真升级。完整细则见tri-forge/references/version-check-spec.md（本章节 NEVER 内联）。
目录结构
tri-superpower/
├── SKILL.md # 本文件（地图 + 规则 + 流程，≤500 行）
├── README.md
├── CHANGELOG.md
├── _meta.json
├── scripts/
│ └── check_update.py # 版本检查（第零步硬门，与 tri-forge 同源）
├── references/
│ ├── methodology-workflow.md # 7 步工作流逐环节规则（brainstorming→finishing）
│ ├── sdd-subagent-development.md # SDD 全流程：双审查/熔断/ledger/三脚本/裁决语义
│ ├── tdd-and-debugging.md # TDD + systematic-debugging + verification
│ ├── plans-and-reviews.md # writing-plans + executing-plans + 审查协作
│ ├── writing-skills-guide.md # 元方法论：TDD-for-docs/SDO/rationalization 表
│ ├── methodology-deltas.md # 增补篇：模型选择/上下文经济学/形式匹配/微型测试/三路径棘轮/门控五步（锚定增补基准档 §4.2）
│ └── harness-adaptation.md # 三形态/版本联动/测试双体系/验收锚点
└── tests/
└── tri-superpower-full-testcases.md
完成判据（外化 · 可机械校验）
一次执行的「结束态」MUST 同时满足以下全部判据（缺一为「停车态」——继续执行直至满足或按规则标注受阻原因后交还用户）：
- 输出含自检句（本次操作=<模式>，触发源=<来源>，已读取教训=<N 条/无文件>）；
- 输出中每条结论性表达附置信三要素（grep「置信度」可命中）；
- 每条方法论规则附对照基准档 § 锚点或「基准档未展开」降级标注；
- 教训文件已追加写入（或写入失败已提示用户）。
进化契约（自进化三要素 + 教训文件读写闭环）
- 反馈接收点：用户对某条方法论规则的偏差修正（如「方法论原文不是这个意思」）→ 视为对照基准缺口，回写教训文件并在下次输出中降级该规则的置信标注；重大偏差 MUST 提示用户「对照基准档需修订」（修订属 tri-code-analyzer/tri-forge 职责）。
- 经验沉淀位：
.tribro/superpower/lessons.md（追加式；每次执行结束 MUST 写入可操作的规避动作，空泛内容 NEVER 写入，无新增写「无新增」占位留痕）。 - 自我修订触发条件：① 对照基准档更新（如原项目发新版重新剖析）→ 本包 bump MINOR 并全量校对规则锚点；② 同类教训连续出现 ≥3 次 → 将规避动作固化为 SKILL.md 规则条目（bump PATCH）；③ 版本联动：任何修订 MUST 同步 SKILL/CHANGELOG/README/_meta/tests 五处版本号。
