Construction blueprint

Skill BackToCimaCoppi/Praxis/skills/construction-blueprint

给「AI 驱动开发」立规矩的 Claude Code skill 方法论库：七层文档治理 · 对抗评审 · 任务总控三驾马车，外加老代码考古、施工蓝图等共 16 个 skill —— 让 AI 写代码又快又不失控。

Install

npx -y skills add BackToCimaCoppi/Praxis --skill construction-blueprint

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

施工蓝图 skill（用户级通用）。在写代码之前，把一次任务的施工面做成"代码镜像 + 施工指南"：逐文件变更清单、关键实现点、施工切片、验收映射。目的是限制施工范围，并让对抗评审发生在图纸上而不是已成型的代码上。一次性消耗品，施工完成即归档。

SKILL.md

7.0 KB, as published. Nobody here has run it

施工蓝图

本 skill 是任务级详细设计的施工层，用户级通用，可跨项目使用。

它解决的问题：直接从设计跳到代码，评审只能发生在代码写完之后——错误已扩散进几十个文件，大 diff 评审有疲劳和沉没成本，范围蔓延和漏改反而最难看出来。施工蓝图把评审前移：

作用 = 代码镜像 + 施工指南：开工前把"动哪些文件、按什么顺序、关键处长什么样"钉死，让对抗评审打在图纸上。蓝图评审拦"方向错"，代码后检查拦"手抖错"，两道闸缺一不可。

与轻量设计方案（lightweight-design skill）的海拔分工：

轻量设计方案 ── 决策海拔 ── 人看的，用户审核拍板
      ↓
施工蓝图 ────── 代码海拔 ── AI 看的，开工前对抗评审（本 skill）
      ↓
   施工 → 回补七层文档

关键性质：一次性消耗品。 L5/L6 禁止代码镜像是因为它们是长期真值、代码一改就腐烂；蓝图施工完即归档，来不及腐烂，所以文件清单、方法签名、伪代码在本层全部合法。

1. 输入与何时用

输入（按优先级）：

轻量设计方案（首选——已拍板的决策是蓝图的裁判标准）
七层正式文档（任务直接基于现存设计施工时）
需求 + 用户当轮聊天确认（必须在蓝图里显式登记为"真值来源"）

用：中大任务施工前必经；凡是写了轻量设计方案的任务，默认接一份蓝图。

可跳过：

小改动（计划模式足够）
纯文档任务
轻量设计方案本身已足够简单、变更面只有一两个文件时（此时计划模式即蓝图）

2. 粒度铁律（防"代码写两遍"反模式）

蓝图写得太细 = 把代码写两遍，又慢又没增益。粒度卡死在：

内容	粒度
变更清单（主体）	文件级：一文件一行，新增/修改/删除 + 一句"改成什么样"
关键实现点	仅歧义点/风险点下沉到逻辑级（允许方法签名、伪代码）
纯透传 / CRUD / 标准操作	只列文件，不展开

判定句：蓝图字数接近预估代码量 → 写过头了，砍。

3. 文档模板

# 施工蓝图：{任务名}

> 上游输入：{轻量设计方案路径 / 七层文档 / 用户决策}
> 状态：待评审 / 已评审通过 / 施工中 / 已归档

## 1. 任务边界
   改什么 + 明确不改什么（负面清单，限制范围的主力）

## 2. 变更清单 ★代码镜像主体
   逐文件三分类（含 DB migration、配置、脚本）：
   ### 新增
   - `path/to/NewFile`：一句意图
   ### 修改
   - `path/to/File`：改哪部分、改成什么样（一句）
   ### 删除
   - `path/to/OldFile`：为什么退出

## 3. 关键实现点（仅少数点，逻辑级）
   对有歧义/有风险的点写到逻辑级；允许签名与伪代码

## 4. 施工切片
   | 切片 | 内容 | 前置 | 完成判定 |
   每片独立可编译/可验证；判定写得可执行，不写"完成即完成"

## 5. 历史资产退出（重构/替换类任务必写）
   旧表 / 旧代码 / 旧格式 / 旧接口语义：删什么、何时删、是否留兼容层

## 6. 红线自检
   项目分层方向 / 域边界 / 工程红线 逐条打勾（清单由项目补丁注入）

## 7. 验收映射 ★对抗评审主靶面
   | 轻量设计决策点 | 落在哪条变更条目 |
   有决策无落点 = 漏；有落点无决策 = 越权加戏

## 8. 验证与回归
   编译 / 测试 / 接口脚本是否同步 / 是否需手工验证（逐项判断，不留空白）

## 9. 风险与回滚
   最坏情况怎么退（一段话）

## 10. 可开工性结论
   只许三种：可以 / 基本可以但差非阻塞补充 / 不可以＋阻塞清单

4. 对抗评审协议（开工前的那道闸）

评审输入：蓝图 + 轻量设计方案 + 相关契约文档（接口/数据库层）。

三个靶面（恰好是代码评审最容易漏的）：

靶面	评审问题
范围越界	变更清单里有没有不在任务边界内的文件？有没有动了不该动的域/模块？
遗漏	该改的调用点列全了吗？接口改了，所有消费方都在清单里吗？
方案性错误	关键实现点与已拍板决策一致吗？分层/事务边界/批量查询等是否违反项目规范？

裁判标准：第 7 节验收映射表逐条核对——评审不是泛泛"看看方案好不好"，而是拿轻量设计当裁判逐条对。

强度分档（具体升级条件由项目补丁声明）：

常规任务：单评审（一个独立视角过三个靶面）
高风险 / 命中项目死亡线：adversarial-review 多方对抗评审

评审结论处理：评审发现的问题改在蓝图上，改完可再评一轮；评审通过后蓝图冻结，进入施工。

5. 施工纪律

施工只能按蓝图执行——蓝图就是施工范围的合同
施工中发现必须偏离 → 先回改蓝图（小偏离：更新变更清单并说明原因）再继续写代码
偏离触及已拍板决策 → 退回轻量设计层重新拍板，不允许蓝图或代码里悄悄改
禁止"代码里偷偷扩张"：完工后实际 diff 与变更清单的差异，就是验收时要解释的清单

6. 生命周期

起草 → 对抗评审 → 冻结开工 → 施工（偏离须回改）→ 完工归档

蓝图是任务资产，不是正式真值：不得混入七层正式文档目录冒充 L3/L4/L6
回补七层按轻量设计方案的"回补清单"执行；蓝图本身归档即终结
与七层文档冲突时听七层裁决链（经轻量设计层裁决过的除外），蓝图无裁决权

7. 项目补丁挂载点

挂载项	内容
存放路径	与轻量设计方案同任务目录
红线自检清单	项目工程红线 / 分层方向 / 域边界规则（注入模板第 6 节）
死亡线升级	命中项目死亡线区域 → 评审升档规则
验证基建	项目的编译/测试/检查脚本命令

8. 质量自检清单

负面清单写硬了（明确不改什么）？
变更清单覆盖了代码、DB、配置、脚本全部施工面？
只有歧义点/风险点下沉到逻辑级，没把代码写两遍？
重构类任务写了历史资产退出（不留双轨）？
验收映射双向核对过（无漏、无越权）？
红线自检逐条打了勾？
每个施工切片有可执行的完成判定？
可开工性结论明确（不暧昧）？
新 agent 只读蓝图就能开工，而不是继续大量追问？