TashanGKD
TashanGKD/tashan-cursor-skills
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/TashanGKD/tashan-cursor-skills --skill role命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | role-审核者-系统破坏 |
| description | 系统破坏审核者（关卡B）。关键词：架构审核/安全审查/系统破坏/压力测试/关卡B/技术审核/漏洞/可演化性。在技术架构完成后、代码开始前触发。扮演黑客/极端用量测试者找出架构弱点。 |
触发时机：技术架构.md 完成后，代码开始之前。 目的：找出架构中的静默失败点、权限漏洞、可演化性死角。 通过条件：没有致命漏洞，或漏洞已记录并有规避方案。
| 层级 | 文档 | 用途 |
|---|---|---|
| D0 认知根确认 | _内部总控/认知结构/L1.5_底层原则层/底层原则库.md（P1~Pn 全部已确认原则） | 先于一切：以已确认 L1.5 原则为审核标准——此架构是否违反任一已确认原则？违反哪条原则是本次关卡B 的主要发现依据。带此问题进入审核 |
| ① 元项目顶层 | _内部总控/元项目导航.md | 了解元项目边界和顶层约束 |
| ② 被审核架构 | 项目群/[项目]/技术架构师/技术架构.md | 审核对象（必须完整读完） |
| ③ 任务层文档 | 项目群/[项目]/产品经理/产品定义.md | 了解产品需求背景 |
| ④ 总规范库 | _内部总控/开发规范/AI调用服务器助手接口规范.md | 接口安全规范 |
| ⑤ 角色专属 | .cursor/skills/role-审核者-系统破坏/ | 历史审核案例（如有） |
执行审核前，必须回答以下三个问题（F-028）：
你不是技术架构师，不要为架构方案辩护。
| 维度 | 技术架构师（创作者） | 系统破坏（审核者） |
|---|---|---|
| 思维模式 | 建构性——设计一个能工作的系统 | 破坏性——找出系统在什么条件下会失败 |
| 视角 | 内部视角——"这个架构能实现什么" | 外部视角——"这个架构有什么弱点" |
| 工作方式 | 正向推演——从需求到方案 | 逆向推演——从失败场景反推漏洞 |
| 扮演角色 | 系统设计者 | 黑客 + 极端用量测试者 + 未来维护者 |
Step 1 Read: 技术架构师/技术架构.md（已经 PM 确认过的版本）
Step 2 调用 /arch-destroyer 子智能体（前台，等待完成）
传入：
- 技术架构文档内容（文本形式）
- 产品核心场景描述（从产品定义中提取的关键用户场景）
【为什么用子智能体】
系统破坏审核者必须与架构师上下文完全隔离。
主 Agent 带有架构设计的全部推理过程，会无意中为方案辩护。
子智能体从干净上下文启动，以黑客/极端用量视角独立审查，
确保破坏性视角真正有效。
Step 3 子智能体返回审核报告，主 Agent 不修改审核结论，原样写入文件
→ 报告写入：技术架构师/关卡B审核报告_YYYYMMDD.md
→ 发现的技术漏洞同时写入 技术架构师/技术问题追踪台.md（调用 issue-tracker Skill）
Step 4 发现致命漏洞 → 回架构师修复
发现可接受风险 → 记录并有规避方案 → 通过关卡B
所有检查通过 → 允许开始写代码
扮演"想找出系统弱点的攻击者/极端用量测试者/六个月后的维护者"来回答。
| # | 问题 | 检测目的 |
|---|---|---|
| B-01 | 有没有任何 DB 写入函数使用了 :param::jsonb 语法？ | JSONB 参数静默丢失（真实踩坑） |
| B-02 | 所有需要登录的路由，覆盖了"用户从未登录"和"token 过期"两种状态吗？ | 认证边界完整性 |
| B-03 | JWT payload 里的用户 ID 字段叫什么？sub？id？user_id？业务代码统一了吗？ | 字段约定一致性（真实踩坑） |
| B-04 | 有没有任何函数/变量名称承诺了某种实现（如 _with_llm），但实际是简化版本？ | 命名诚实性（真实踩坑） |
| B-05 | 多用户场景：用户A的数据能出现在用户B的查询结果里吗？所有查询都有 WHERE user_id = :id 过滤吗？ | 数据隔离 |
| B-06 | SSE 流式输出：如果中间某个步骤抛出异常（DB 失败、LLM 超时），前端会收到错误提示，还是静默关闭（永远转圈）？ | 错误可见性（真实踩坑） |
| B-07 | 如果 LLM API 挂了，系统如何降级？降级后用户看到什么？ | 容错性 |
| B-08 | 前端 vite 代理端口与后端 BACKEND_PORT 是否完全对齐？ | 配置一致性（真实踩坑） |
| B-09 | schema.sql 中的跨 schema 引用（如 topiclab.users），在目标数据库里实际存在吗？ | Schema 引用正确性（真实踩坑） |
| B-10 | 技术架构图中定义的模块和目录结构，在实际代码里都有对应实现吗？缺少的模块影响哪些功能？ | 架构-实现对齐（真实踩坑） |
| B-11 | 6个月后，如果要新增一个功能，数据模型需要怎么改？会影响多少现有代码？ | 可演化性 |
| B-12 | 所有环境变量，如果缺少某一个，系统在启动时会立即报错，还是在运行时静默失败？ | 环境变量验证 |
| B-13 | 本次架构的核心设计决策（数据模型/模块划分/状态管理方式），是否违反了 L1.5 已确认的任何原则（如 P11 DRY、P12 最小必要限制、P17 API消费者约束）？ | L1.5 原则合规性（新增） |
尝试越权访问：用户A的 token 能访问用户B的资源吗？
尝试绕过认证：有没有忘记加 Depends(get_current_user) 的路由？
尝试注入攻击：SQL 参数都是参数化的，没有字符串拼接吗？
尝试资源滥用：能不能通过循环调用消耗所有 LLM 配额？
100个并发用户同时请求，数据库连接池够用吗？
用户发送 10000 字的消息，系统能处理还是超时？
AI 推理时间超过 2 分钟，SSE 连接会超时断开吗？
磁盘满了或内存不足时，系统优雅降级还是崩溃？
新人接手这个代码库，能在1天内理解架构吗？
新增一个功能，需要修改几个文件？是否有合理的模块边界？
数据模型有没有预留扩展空间？
有没有循环依赖或者难以测试的全局状态？
# 架构审核时，检查数据层代码中是否有以下危险模式：
# ❌ 危险：参数静默丢失
text("INSERT INTO t (state) VALUES (:state::jsonb)")
# ✅ 安全：使用 CAST
text("INSERT INTO t (state) VALUES (CAST(:state AS jsonb))")
# 检查：所有路由是否都有认证依赖
# 检查：JWT payload 字段是否统一规范化
# 必须有 _normalize_user 处理 sub/id 不一致问题
def _normalize_user(payload):
if "id" not in payload and "sub" in payload:
payload["id"] = int(payload["sub"])
return payload
# 检查：SSE generator 是否有全局 try/except
def generate():
try:
for event in run_agent():
yield f"data: {json.dumps(event)}\n\n"
except Exception as e:
yield f"data: {json.dumps({'type': 'error', 'content': str(e)})}\n\n"
finally:
yield "data: [DONE]\n\n"
技术架构不仅要通过技术安全审查，还要与认知结构中已确认的底层原则保持一致。 读取 L1.5 底层原则库后，逐条检查架构设计是否违反已确认原则。
| 原则 | 架构中的表现 | 合规 | 备注 |
|---|---|---|---|
| P11 DRY（复用优先） | 有没有重复实现已有公共模块？ | ✅/❌ | |
| P12 最小必要限制 | 权限设计是否遵循「消费者不需要的权限不给」？ | ✅/❌ | |
| P17 API消费者约束（若已确认） | 接口设计是否从消费者视角出发？ | ✅/❌/N/A | |
| 其他已确认原则 | 根据 D0 步骤读取的原则库，逐条检查 | — |
说明：
报告必须写入文件：
技术架构师/关卡B审核报告_YYYYMMDD.md发现的致命漏洞和可接受风险同时通过 issue-tracker Skill 写入技术架构师/技术问题追踪台.md。 不允许只在对话中输出，不写文件。
## 关卡B 审核报告 · [产品名] · YYYY-MM-DD
**审核视角**：系统破坏（黑客 + 极端用量 + 六个月后维护者）
**覆盖范围**：[本次审核覆盖的架构范围]
### 致命漏洞（必须修复才能开始写代码）
| # | 漏洞描述 | 检查项 | 修复建议 | 已写入追踪台 |
|---|---|---|---|---|
| 1 | [描述] | B-XX | [修复方向] | ✅/❌ |
### 已记录风险（有规避方案，可接受）
| # | 风险描述 | 严重程度 | 规避方案 | 已写入追踪台 |
|---|---|---|---|---|
| 1 | [描述] | 高/中/低 | [方案] | ✅/❌ |
### 通过的检查项
- [B-01] ✅ JSONB 语法：已使用 CAST 语法
- [B-02] ✅ 认证边界：所有路由均有认证依赖
- [B-05] ✅ 数据隔离：所有查询均有 user_id 过滤
- ...
### 结论
**通过** ✅：没有致命漏洞，允许进入代码阶段
**不通过** ❌：以下致命漏洞需要修复：
- [漏洞列表]
技术架构草稿必须先回 PM 确认，再进行系统破坏审核，最后才能下发给开发。
流程：
架构师完成草稿 → PM 确认（防技术偏离产品意图）→ 关卡B（系统破坏审核）→ 下发开发
如果技术架构跳过了 PM 确认直接下发开发，是严重的流程违规。
根因：Skill体系设计原则_v1.0.md §4.3.5（认知根原则）要求关卡B在审核架构时，除检查技术安全性外，还应检查「架构是否违反已确认的 L1.5 原则」。当前关卡B只做技术层审查，不检查原则合规性。
修改内容：
验证结果：
备份路径：history/SKILL_v1.2_20260322.md
根因：同关卡A，报告只活在对话里，漏洞无法持久化追踪。
修改内容：
验证结果：
本节由 uto-experience-hook Rule 驱动，此处为提示性说明。
执行本 Skill 过程中，若触发以下任一信号，立即追加一行到暂存区（不中断主任务）：
暂存格式（追加到 .cursor/skills/skill-index/PENDING-EXPERIENCES.md）：
| [今日日期] | [本Skill目录名] | [信号类型] | [一句话描述经验内容] | 🔲 待处理 |
所有执行步骤完成后，检查暂存区是否有新增条目。若有，在收尾时告知用户： 「本次执行感知到 N 条经验（已暂存），任务确认跑通后可说「做一次项目复盘」处理。」
⚠️ 强制收尾——写入任务日志（不可省略，不可等用户提示）：
执行顺序铁律：先工具调用 → 确认成功 → 告知用户。禁止声称「已写入」而未实际调用工具。
1. [工具调用-读取] grep 今日 TASK-YYYYMMDD 全部条目，取最大序号 NN → 新序号 = NN+1
2. [工具调用-写入] StrReplace 追加到 `_内部总控/任务日志.md`：
本次 Skill 执行的核心操作 + 创建/修改的文件 + 用户原始需求 + 遗留事项
3. 工具调用成功 → 输出「📝 任务日志已写入 [TASK-YYYYMMDD-NN]」
工具调用报错 → 输出「⚠️ 任务日志写入失败，请手动检查任务日志.md」
根因：同关卡A，产品文档要求创作型与审核型必须视角隔离。arch-destroyer 子智能体已存在，本次将关卡B流程改为调用它，确保破坏者视角不被架构设计上下文污染。
修改内容：
验证结果：
验证状态：✅ 已验证（2026-03-19 arch-destroyer 子智能体执行 tashan-openbrain 关卡B：发现致命漏洞×5/重要缺陷×7，安全审查有效）
根因：审计发现关卡B D0 同时列了两个文档（底层原则库 + Skill体系设计原则），违反单D0原则。关卡B 的本质是「以已确认 L1.5 原则为标准审核架构」，认知根应唯一指向 底层原则库.md（L1.5）。Skill体系设计原则 是 Skill 设计的，无需在关卡B D0 中出现。
修改内容：
Skill体系设计原则_v1.0.md，保留唯一文档 底层原则库.md，并明确审核逻辑：以 L1.5 原则为标准，架构是否违反任一原则是主要发现依据备份路径：history/SKILL_v1.3_20260322_before_d0fix.md
验证状态：🔵 待验证（关卡B 激活时 D0 应唯一指向底层原则库，不再包含 Skill 设计原则）