编码开发（下游路由 · I11）

> 本 skill 是 tri-intent 的下游执行 skill，依据快照 snapshot.md §三 结构化结论自主管理完整编码工作流。
> 用户心智：把 AI 当执行者，期望拿到可运行、符合项目规范的代码成果物。

强制执行契约（Execution Contract · 最高优先级）

0. 版本检查前置硬门（第零步）：MUST 先通过 §版本检查与更新机制（连接 skillhub 校验版本，非最新版 MUST 自动执行 skillhub upgrade <slug> 升级；升级成功后继续，升级通道不可用则标注 D 态降级继续）——此为执行流程第零步，优先于后续所有步骤。版本检查完成前 NEVER 进入后续步骤。本条目优先级高于所有其他强制前置条目。

1. 强制前置：收到 tri-intent 快照且 下游路由建议 指向本 skill，MUST 先读取快照 §三，再按编码工作流串行推进，NEVER 跳过直接写代码。独立使用时（未经 tri-intent 路由）MUST 先走 §上游依赖检测 判定模式。

2. 双审批门 + 执行前确认 + 任务清单硬性规则：I11 属设计类，MUST 严格串行经过两道落盘审批门 + 执行前确认 + 任务清单执行，禁止直接给最终代码：
   - 门①（需求审批）：先产出 requirements.md（编码需求说明书），向用户结构化复述供审计；通过后方可进入门②。
   - 门②（设计审批）：据已审批的 requirements.md 产出 design.md（技术设计说明书），再交用户审计；通过后方可产出 tasks.md。
   - 门③（执行前确认）：门②通过后产出 tasks.md（原子化编码任务清单+测试清单），进入执行前 MUST 主动询问用户两件事：① 是否需要调用其它 skill 协同（如测试框架、代码审查、安全扫描、文档生成等）；② 是否有需要补充的需求/约束/素材。用户确认无补充 → 进入执行；用户提出补充 → 据反馈更新 tasks.md（涉及设计缺陷则回退门②更新 design.md）后再次确认，通过后方可执行，禁止跳门抢跑。
   - 任务执行：门③确认通过后，按 tasks.md 清单逐项执行（含测试，测试不过回炉 tasks.md），执行完成产出 implements.md（实现清单报告）。复选框状态切换规则（核心机制）：tasks.md 中每个原子任务和测试条目均含「完成状态」复选框字段，默认 `- [ ]`（未完成）；执行完成 → MUST 切换为 `- [x]`；回炉重做 → MUST 重置回 `- [ ]`。复选框状态与「状态明细」字段同步更新，与 §7 执行记录同步回填。
   - 完整链路：requirements.md → 审计① 通过 → design.md → 审计② 通过 → tasks.md → 执行前确认③ 通过 → 执行 → implements.md。任一门未通过则携反馈回炉，不得跳门或抢跑实现。
3. 最小化原则（门禁规则）：进入执行阶段前 MUST 校验变更范围是否最小化——只实现 tasks.md 任务清单范围内的功能，不顺便重构、优化或清理无关代码。若执行中发现需扩大变更范围（如关联缺陷、架构问题），MUST 向用户说明并确认后追加到 tasks.md，NEVER 默默扩大范围。
4. 职责边界：本 skill 负责「读取快照 → 产出编码需求 → 技术设计 → 任务拆解 → 编码执行 → 实现报告」全链路。意图识别（由 tri-intent）、非编码类产出（由 tri-content/tri-plan 等）不属于本 skill。
5. 自检：作答前用一句话声明「本次意图=<L2>，已读取快照，当前阶段=<阶段>」，若与上述规则冲突则停止并纠正。
6. 版权与许可证守卫：生成的代码必须原创、可合规使用；禁止整段复制他人代码而不保留其许可证/署名、禁止仿写闭源商业代码、禁止引入与目标仓库许可证不兼容的依赖。若用户要求复制某私有/闭源代码或绕过许可证，必须拒绝并改走描述性原创实现——本 skill 产出须原创、可合规发布（详见 §代码版权与许可证合规）。

触发时机

• tri-intent 产出的快照中 下游路由建议 指向本 skill
• 意图编码范围：I11 编码开发

上游依赖检测（独立使用时）

> 本 skill 可独立安装。激活时 MUST 检测上游 tri-intent skill 是否可用，据检测结果选择执行模式：

模式 B 提示语：
> 本 skill 依赖 tri-intent 进行意图识别与输入校验。当前未检测到 tri-intent。
> 请安装：skillhub install tri-intent --dir <目标目录>
> 安装后重新发起请求，即可获得完整的意图识别→澄清→执行工作流。

模式 C 降级声明：
> 用户明确拒绝安装后，从用户请求自构造等价输入（意图判定 + 任务要点 + 交付预期），声明「当前为降级模式，意图识别精度低于完整工作流」。

输入契约

读取 .tribro/snapshots/<命名>.md 的 §三 结构化结论区：

> 若快照 澄清门状态 = 待澄清，不应激活本 skill——先由 tri-intent 的 clarify-gate 完成澄清。

> 模式 C 降级模式输入：当用户拒绝安装 tri-intent 时（见 §上游依赖检测 模式 C），从用户原始请求自构造等价输入——意图判定（默认 I11）+ 任务要点（从请求提取功能点）+ 交付预期（从请求推断代码成果物），声明降级模式后按工作流推进。

职责边界

• 本 skill 负责：依据快照结论，自主管理编码全链路（需求→设计→任务→执行→实现报告），产出可运行代码及配套链路文档
• 不负责：意图识别（由 tri-intent）、调试修复（由 tri-fix）、非编码类文本产物（由 tri-content）、规划方案不写代码（由 tri-plan）、多媒体产物（由 tri-mm）、代码审查（由 tri-review）
• 与 tri-frontend-design 的边界：I11 前端设计方向子类（界面设计方向/风格锚点/配色字体结构方案/动效设计与评审/多变体探索，快照 L3_子意图 = frontend-design）由 tri-frontend-design 承接，本 skill 负责产出可运行代码实现；若快照 下游路由建议 已覆写为 tri-frontend-design，本 skill NEVER 激活。设计先行场景由 tri-frontend-design 交付 CSS 令牌/动效基线规格，本 skill 依令牌落地代码，两者按交付对象衔接不竞争。
• 关键边界：本 skill 既「出方案」也「动手写代码」——出方案归 design.md/tasks.md，动手归执行阶段；tri-plan 只出方案不写代码；tri-fix 专注调试修复
• 不触发场景（Not-Trigger）：本 skill 不接手「单点 bug 的调试修复」（转 tri-fix）；不接手「只审查不改码的代码审查」（属 tri-review）；不接手「规划方案不写实现」（属 tri-plan，仅产出规划文档本身）；不接手「识别用户意图」（由 tri-intent / 自身快照驱动）。

技术栈加载方法论（核心能力 · 可扩展）

> 编码类技术栈种类繁多且持续增长，本 skill 通过 registry 驱动的动态加载机制 匹配项目技术栈，无需修改 SKILL.md 即可扩展。这是 tri-coding 的主要设计特点：registry 驱动、可零改动扩展技术栈。

加载时机

在产出 design.md 的「氛围校准」步骤中执行技术栈匹配与加载——此时已读取快照、已通过需求审批（门①），正处于技术设计阶段，是确定技术栈规范的最佳时机。

加载流程

design.md · 氛围校准
    │
    ▼
读取 tech-skills/registry.md（注册清单）
    │
    ▼
扫描项目特征文件（package.json / tsconfig.json / go.mod / *.ets / ...）
    │
    ▼
按注册表「触发规则」逐条匹配
    │
    ├── 始终加载 general.md（基底）
    ├── 命中的技术栈 skill（可叠加多个，如 TypeScript + React + Tailwind）
    └── 全部未命中 → 仅用 general.md 兜底
    │
    ▼
将已加载技术栈 skill 的编码规范注入 design.md 的「技术选型」与「编码规范」环节
    │
    ▼
执行阶段编码时遵循已加载技术栈 skill 的规范条目

触发规则示例

可扩展性

> 新增技术栈 skill 无需修改本 SKILL.md：
1. 在 tech-skills/ 目录创建 <tech-id>.md（遵循 general.md 格式）
2. 在 tech-skills/registry.md 注册表追加一行（tech_id / 名称 / 分类 / 触发规则 / 文件名）
3. 完成——下次氛围校准时自动匹配加载

与工作流的集成点

版本检查与更新机制（强制技术约束 · 硬红线）

> 家族级强制技术约束，优先级与「强制执行契约」同级。skill 任一执行入口启动后的第零步，先于核心执行阶段。
> 细则唯一真源：tri-forge/references/version-check-spec.md。可执行实现（single source of truth for logic）：本 skill 自带 scripts/check_update.py（与 tri-intent 同源一致，按 --slug 自动适配）。
> 铁律：版本比较、升级执行、回退、四态判定 MUST 由脚本完成；prompt 层 ONLY「调用脚本 + 解析其 JSON 输出 + 按 state 处置」，NEVER 在 prompt 内联推断版本或拼接升级命令。修订规则只改真源一处，脚本与真源保持同步。

执行方式（MUST）

1. 任一执行入口启动后、核心执行前，运行脚本并取 JSON：
   bash python scripts/check_update.py --slug tri-coding --json
   - 节流：结果持久化缓存（默认 1440 分钟 / 24h 仅校验一次），--force 强制重查，--dry-run 只判定不真升级。
   - 脚本自动定位 skill 目录（默认脚本上级目录），--slug 显式指定自身 slug（如上）。
2. 解析 JSON 的 state 字段，按态处置：
   - A 校验通过 / B 离线降级 / C 通道降级 / D 升级降级 → 一律放行，进入后续阶段；并据 warnings / notes / actions 在交付物或日志标注对应口径（如「版本校验未完成（离线）」「版本陈旧·自动升级失败」）。
   - BLOCK → 绝对禁止执行，按 block_code（P2/P3/P4）输出结构化恢复指引（手动命令见 actions 字段）。
3. 退出码语义（供 shell 编排）：0=A 放行；10=B；11=C；12=D；20=阻断。判定规则：<20 放行，>=20 阻断。脚本自身异常时兜底降级放行（退出码 11），NEVER 因版本门自身故障导致 skill 无法启动。

执行要点

1. 端点取自配置：API 主机 MUST 读自 ~/.skillhub/metadata.json，NEVER 硬编码域名。营销官网 skillhub.cn 与 API 主机 api.skillhub.cn 是两个站点——官网对任意路径都返回 200 + HTML 兜底页，绝不可作校验端点。读不到配置即判通道不可用。
2. 校验请求：GET {api_host}/api/v1/skills/{slug}，超时 ≤ 5s，失败重试 1 次，会话内仅校验一次。
3. 最新版取值：latestVersion.version，缺失时回退 skill.tags.latest。平台不提供 min_compatible / deprecated / checksum_sha256 / signature，NEVER 依赖这些字段。
4. 响应有效性（三条件同时成立）：HTTP 200 且 Content-Type 含 application/json 且 能解析出版本字段。仅看状态码会被 SPA 兜底页击穿。
5. 版本比较：按 SemVer 逐段整数比较，NEVER 字符串比较。
6. 四态判定：
   - A 校验通过（响应有效且 current >= latest）→ 放行。
   - B 离线降级（网络不可达）→ 标注「版本校验未完成（离线）」后以当前版本继续。
   - C 通道降级（可达但响应无效 / 404 / 405 / 读不到配置）→ 标注「版本校验未完成（通道不可用）」+ 输出通道异常告警后继续。
   - D 升级降级（陈旧且已真实尝试自动升级但未完成）→ 标注「版本陈旧·自动升级失败」+ 输出手动升级指引后继续。
   - 四态 NEVER 用于绕过「已检出陈旧却不尝试升级」——MUST 先真实执行一次自动升级，失败方可落 D 态。
7. 更新通道（自动执行）：检出陈旧 MUST 自动执行 skillhub upgrade <slug> → skillhub verify <slug>，升级前备份、签名明确不一致则回滚。CLI 不在 PATH 时回退 python ~/.skillhub/skills_store_cli.py upgrade <slug>；CLI 缺失或升级失败 → 落 D 态降级继续，NEVER 阻断。以 junction 指向源码树的 source: local skill 跳过自动更新，改为提示维护者手动同步。命令细则、CLI 定位顺序与已知陷阱见真源。
8. 阻断条件 P1–P4 与四处版本同步点见真源；发布前 MUST 通过 python tri-forge/scripts/sync_registry.py --check。

编码工作流（设计类链路）

> 执行顺序固定：§版本检查与更新机制（第零步）→ 上游依赖检测 → 读取快照 §三 → 核心执行。版本检查未通过前 NEVER 进入以下任一执行步骤。

tri-intent 快照 §三
        │
        ▼
  requirements.md（编码需求说明书）
        │
     门①·需求审计 ──不通过──→ 携反馈更新 requirements.md → 再门①
        │通过
        ▼
    design.md（技术设计说明书）
        │
     门②·设计审计 ──不通过──→ 携反馈更新 design.md → 再门②
        │通过                       （涉及需求变更则回退门①）
        ▼
    tasks.md（原子化编码任务+测试清单）
        │
     门③·执行前确认 ──有补充──→ 更新 tasks.md（设计缺陷回退门②）→ 再门③
        │无补充
        ▼
    执行（按 tasks.md 逐项编码+测试）
        │              测试不过 ──→ 回炉 tasks.md → 再执行
        ▼
    implements.md（编码实现清单报告）

阶段速查表

> 各阶段产出物的详细内容见对应模板文件；门的通过/不通过规则与复选框切换机制见 §强制执行契约。

执行阶段补充规则（阶段 7）

> 契约 §2 已定义复选框切换与回炉规则，此处只补充编码执行策略。

搜索优先原则（通用）：改动前用 search 定位相关文件与既有模式，复用胜过新造，只改必要处，不擅自重构无关代码。

> 技术栈规范约束力：氛围校准阶段匹配加载的技术栈 skill（如 typescript/react/arkts 等）的编码规范条目，在执行阶段具有约束力。

交付产物机制

一、文件命名规范

沿用 tri-intent 快照命名：<问题类型>_<日期>_<时间>_<会话ID>

• 示例：I11_20250211_143022_6a5c037d

二、存放目录

.tribro/                    # 若不存在则先创建
├── snapshots/              tri-intent 产出（已存在）
│   └── <命名>.md
└── coding/                 tri-coding 链路文档
    └── <命名>/
        ├── requirements.md   # 编码需求说明书（门①载体）
        ├── design.md         # 技术设计说明书（门②载体）
        ├── tasks.md          # 原子化编码任务+测试清单（门③载体+执行蓝图）
        └── implements.md     # 编码实现清单报告（最终交付物）

三、产物清单

质量标准

> 每条标准都可被独立验证。交付前逐行核对，任一不达标则回到对应阶段。

工具结果治理（执行阶段）

> 蒸馏自 strix agents/factory.py + tools/output_store.py（Apache-2.0），去产品化改写。
> 解决的问题：编码执行阶段的工具输出（编译日志、测试输出、抓取内容、搜索结果）常常远超有用信息量——全量进上下文会挤爆窗口，粗暴截断又会丢掉关键行号与报错原文。

> 与 tri-cache 的分工：单次工具输出的限幅与溢出治理归本节；跨轮次的上下文压缩与 token 预算归 tri-cache 的 CONTEXT_COMPACT 模式。

落盘规则

• 快照由 tri-intent 已落盘于 .tribro/snapshots/
• 本 skill 链路文档落盘于 .tribro/coding/<命名>/
• 链路文档可覆盖更新（以最新一轮为准），审计记录留痕于各文档审计章节
• 最终代码成果物就地落盘于用户工作区项目目录（实际交付物，非 .tribro/）
• 产物归档：.tribro/ 不存在时 MUST 先创建；每轮执行 MUST 在 .tribro/coding/<命名>/ 落 delivery-manifest.md，记录本次交付/修改的文件路径清单与说明，保证产物可追溯

代码版权与许可证合规（硬红线）

> 原则：本 skill 生成的代码必须原创、可合规使用与发布。版权与许可证问题零容忍——任何疑似侵权或许可证冲突的代码，在解决前不得提交、发布或交付。

五条硬红线（提交/发布/交付前全过才可出）：

• 原创不照搬：只写描述性原创实现，NEVER 把训练数据/网络片段整段照搬；复用开源须完整保留其 LICENSE 与版权声明，不剥离头部。
• 许可证兼容：遵循目标仓库现有许可证，NEVER 引入与其不兼容的依赖（如向 GPL 项目引入不兼容许可代码造成"传染"）。
• 依赖已授权：只用可商用、来源可信的公共包并记录版本与来源，NEVER 使用未授权/来源不明/私有付费包，NEVER 绕过付费或私有限制。
• 披露到位：平台/雇主/开源社区要求披露 AI 生成代码时，提交前按其最新政策标注。
• LICENSE 已声明：代码落盘时按目标仓库许可证写入 LICENSE 声明或头部注释。

> 违规拒绝规则：用户要求复制私有/闭源代码或绕过许可证时，MUST 拒绝并改走描述性原创实现（对应契约 §6）。
> 📌 提交/发布前速查：配套一页式 代码合规自查小卡片.html（skill 根目录）。
> 📖 详见 references/license-compliance.md——含四类风险与预防、生成期源头杜绝、6 步硬性自检清单、平台/仓库条款速查、商用授权与原创存证、侵权应急处置。

目录结构

tri-coding/
├── SKILL.md              # 主入口：编码工作流定义 + 双审批门 + 执行前确认 + 技术栈加载方法论
├── README.md             # skill 说明与快速上手
│   ├── arkts.md  cpp.md  css.md  django.md  electron.md        # 技术栈子 skill（扁平存放，无层级子目录）
│   ├── fastapi.md  flask.md  flutter.md  git.md  gitflow.md  golang.md
│   ├── h5.md  java.md  nextjs.md  python.md  react.md  react-native.md
│   └── swiftui.md  tailwind.md  taro.md  typescript.md  uniapp.md  vuejs.md  wechat.md
├── CHANGELOG.md          # 版本变更记录
├── 代码合规自查小卡片.html   # 提交/发布前一页式合规速查卡（配合 §代码版权与许可证合规 使用）
├── references/           # 静态参考资料（非流程逻辑）
│   └── license-compliance.md   # 代码版权与许可证合规完整参考
├── templates/            # 链路文档模板
│   ├── requirements.md   # 编码需求说明书模板
│   ├── design.md         # 技术设计说明书模板
│   ├── tasks.md          # 编码任务清单+测试清单模板
│   └── implements.md     # 编码实现清单报告模板
├── tech-skills/          # 技术栈子 skill（registry 驱动，可扩展；general 基底 + 24 个技术栈，完整清单见 registry.md）
│   ├── registry.md       # 技术栈注册清单（唯一扩展入口，含互斥规则与分类匹配顺序）
│   ├── general.md        # 通用编程基底（始终加载）
│   ├── README.md         # 如何添加新技术栈
│   ├── arkts.md  cpp.md  css.md  django.md  electron.md        # 技术栈子 skill（扁平存放，无层级子目录）
│   ├── fastapi.md  flask.md  flutter.md  git.md  gitflow.md  golang.md
│   ├── h5.md  java.md  nextjs.md  python.md  react.md  react-native.md
│   └── swiftui.md  tailwind.md  taro.md  typescript.md  uniapp.md  vuejs.md  wechat.md
└── tests/                # 测试用例
    └── tri-coding-full-testcases.md   # 全场景全能力测试用例（审计版）