메뉴
Use when generating a Weibo post (微博) — ultra-short punchy Chinese microblog updates of ≤280 characters with 1–2 hashtags and a direct hook. Triggers on 微博, Weibo post, Chinese microblog, or short social update requests where brevity and immediacy are required.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
单后端闭环测试执行器（stack-agnostic / project-agnostic）。当一个后端 feature 收尾、需要补 superpowers/spec-kit 开发期 TDD 与契约测试覆盖不了的后端结构性测试缺口时使用：先读项目栈 （package.json / pyproject.toml / go.mod / pom.xml 等）按栈实例化对应工具，再针对实际命中的缺口 RED→GREEN 补测并固化为回归。覆盖四类后端结构性缺口——真库数据层/迁移/事务/约束、鉴权与越权 （BOLA/BFLA）、并发/竞态/限频原子性、韧性/故障注入（重试/超时/降级）。触发词：单后端测试 / 后端缺口补测 / backend testing / 真库测试 / 越权测试 / 并发测试 / 韧性测试 / 后端集成测试 / 后端回归补测。遵循 testing-system-blueprint 蓝本（风险分级 / 可追溯 / 发布门 / 三层节奏），受自愈护栏约束（只写 tests/、断言 不可弱化、禁伪造修复、有界重试、产 PR 人审）。被 test-routing-advisor 在判定"单后端"时调用，也可直接触发。
单前端闭环测试执行器（stack-agnostic / project-agnostic）。当一个前端 feature 收尾、需要补 superpowers/spec-kit 开发期覆盖不了的前端结构性测试缺口时使用：先读项目栈（package.json 或 等价清单）按栈实例化对应成熟工具，再针对实际命中的层 RED→GREEN 补测并固化为回归。与 backend-testing 的根本区别——后端缺口无现成工具需自建（"施工队"），前端成熟工具齐全，本 skill 不重新发明工具，只做 三件事：装 + 配 + 把项目的视觉/交互契约翻译成这些工具能跑的断言/规则（"装配工 + 监理"）。覆盖五层 前端结构性缺口——编译期 lint 门、L0/L1 单测（含 getComputedStyle 断言 token/深色/涨跌色）、a11y + 跨浏览器/响应式、前后端契约 mock、视觉回归。触发词：单前端测试 / 前端缺口补测 / frontend testing / 视觉回归 / a11y 测试 / 跨浏览器测试 / 响应式测试 / token 断言 / 前后端契约 mock / 前端回归补测。 常见地基为零：很多前端 [FE] 任务出参验证只写"手测"、测试运行器/RTL/Playwright 可能完全没装—— 本 skill 第一动作是"识栈→若无测试运行器先立地基"，不假设 L0/L1 已就绪。遵循 testing-system-blueprint 蓝本（风险分级 / 可追溯 / 发布门 / 三层节奏），受自愈护栏约束（只写测试不改产品码、断言不可弱化、禁伪造 修复、有界重试、产 PR 人审）。被 test-routing-advisor 在判定"单前端"时调用，也可直接触发。
完整功能链路测试执行器（stack-agnostic / project-agnostic）。当多个 feature 已陆续收尾、 某条**跨多 feature 的端到端旅程（A→B→C）首次贯通**、需要为这条关键旅程织一张端到端安全网时使用： 与前三格根本不同——本格的被测对象**不是给定的，要先从系统结构里【挖掘】出来**。先从三源 （静态代码图 + 运行时 trace + spec 契约）挖出一份**跨多 feature 的通路清单（path inventory）**， 挑 P0 关键旅程，再端到端验证、固化成安全网。覆盖跨多 feature 且含非 UI 跳步（定时任务 / 异步 / 跨通道）的 完整链路；单 feature 内单切片归"局部前后端"第三格，不在这里。两个最独特点：① 被测对象要先被挖掘出来； ② 它是**安全网层**——少而精只盖 P0；**若 bug 首次在这层被发现，说明下层（单后端/单前端/局部前后端）漏测了， 应回补下层**。六步闭环：挖通路+选 P0 → 全系统编排+只 stub 外部边界 → 条件命中 → 两层落地 → RED→GREEN（禁 sleep， fake clock/手动触发定时任务/poll-retry 等最终态）→ 归档+拆栈+PR 人审。触发词：完整功能链路 / 端到端旅程 / 跨 feature 测试 / 通路挖掘 / path inventory / 关键旅程 / 安全网 / journey 测试 / full chain testing / e2e journey / 链路贯通测试。天然要最多代码才能跑、是最后才能执行的一格；代码未落地时只能"挖候选通路 + 写 RED E2E"不能跑。遵循 testing-system-blueprint 蓝本（风险分级 / 可追溯 / 发布门 / 三层节奏），受自愈护栏约束 （只写测试不改产品码、断言不可弱化、禁伪造修复、有界重试、产 PR 人审，发现真 bug 回交 superpowers TDD）。 被 test-routing-advisor 判定"完整功能链路"时调用，也可直接触发。兄弟：backend-testing（单后端）/ frontend-testing（单前端）/ fullstack-slice-testing（局部前后端）。
局部前后端接缝测试执行器（stack-agnostic / project-agnostic）。当一个 feature 的前后端两侧都收尾、 需要把"单前端阶段拿来 mock 的那份假设"与"单后端的真实行为"做一次对账时使用：在**单 feature 内**， 让消费者侧（前端/调用方）↔ 提供者侧（后端/被调方）的**单条切片**以真实形态对接、停止 mock，验证接缝。 它是 backend-testing / frontend-testing 的对账——单前端 mock 撒的谎（字段/类型/状态码/错误体/鉴权/时序） 在这里穿帮。**仅限单 feature 内单切片，不跨 feature**（跨多 feature 旅程属"完整功能链路"第四格）。覆盖四个 能力缺口——环境编排（让两侧+依赖以真实形态可复现一键起来）、契约真实性（消费者 mock↔提供者规格比对）、 接缝粘合（凭证透传/序列化往返/错误映射/头部跨域）、真实时序（条件命中：仅切片含流式/实时/异步才测）。 与前两格的根本区别——新难点是"起真栈（环境编排）"而非写断言：前两格能把另一侧 mock 掉，这格不能， 必须真把两侧拉活。先读两侧栈清单按栈实例化编排/契约工具，再 RED→GREEN 补接缝断言并固化为回归。 触发词：局部前后端测试 / 前后端接缝测试 / 切片对账 / 真前后端对接 / 起真栈集成 / 契约漂移验证 / 消费者契约对账 / fullstack slice testing / seam testing / contract drift / 前后端集成补测。 遵循 testing-system-blueprint 蓝本（风险分级 / 可追溯 / 发布门 / 三层节奏），受自愈护栏约束（只写测试不改 产品码、断言不可弱化、禁伪造修复、有界重试、产 PR 人审）。被 test-routing-advisor 判定"局部前后端"时调用， 也可直接触发。兄弟：backend-testing（单后端）/ frontend-testing（单前端）。
测试路由顾问：在某个 feature 的所有 task 完成（全绿）、进入收尾阶段时，先通篇扫描该 feature 的所有 task/文件，把它们归入一个「开放可增减」的场景类别集合（单后端 / 单前端 / 局部前后端 / 完整功能链路 / 可增类…），判定本 feature 整体属于哪一类，再把每个测试缺口 「路由到对应类别的执行器 skill」去闭环补测。它是 stack-agnostic 的检测器 / 路由器： 本 skill 只做「判类 + 标缺口 + 路由」，不写死任何单栈工具为答案——具体工具由被路由到的 类别 skill 按栈（读 package.json / pyproject / go.mod 等判栈后）实例化。当前路由去向： 单后端 → `backend-testing` skill；单前端 → `frontend-testing` skill；局部前后端 → `fullstack-slice-testing` skill；完整功能链路 → `full-chain-testing` skill（gstack `/qa` 折叠进它的 UI 可走段，非依赖）。判类、缺口标注、 三层节奏、可追溯、发布门等方法标准统一遵循 `testing-system-blueprint` skill。判类信号来自 任务范围标签、依赖图、跨模块契约声明、验收标准 AC，因此与具体项目无关。它的杀手锏：从依赖图 推导出「完成本 feature 后某条完整功能链路（A→B→C）首次贯通」并主动提示「这条链路现在可以 端到端测了」——这是人最容易忘的事。 当某个 feature 正在收尾、用户说出类似「这个 feature 该测什么 / 收尾测试 / 测试路由 / feature 完成后测什么 / 该用什么测试 / run test routing / what should I test now / which testing tool should I use / what tests does this feature need」时务必使用。 它只做建议与路由——绝不编写、运行或强制任何测试；测试是否真的写了、过了、断言有没有被弱化， 靠确定性的 CI 闸和护栏化自愈 agent 来保证。
测试体系蓝本（testing blueprint / test strategy）——一份 stack-agnostic、project-agnostic 的"测试作为体系"方法骨架。当需要确定测试策略、做风险分级（P0–P3）、建立需求↔测试可追溯、 规划三层测试节奏、设计闭环补测、定义发布 go/no-go 门（release gate）时遵循本蓝本。 触发词：测试体系蓝本、测试策略、测试策略蓝本、风险分级、可追溯、需求追溯、发布门、 闭环补测、testing blueprint、test strategy、test pyramid、release gate。 它被 test-routing-advisor（路由器）和各类别测试 skill（如 backend-testing）共同遵循。 本蓝本只给"方法与标准"，不写死任何语言/框架/工具，不执行测试也不强制门禁—— 能力是通用原语，工具由调用方读项目栈后实例化；门禁的强制由 CI/hook/pre-commit 承担。
| name | style-weibo |
| description | Use when generating a Weibo post (微博) — ultra-short punchy Chinese microblog updates of ≤280 characters with 1–2 hashtags and a direct hook. Triggers on 微博, Weibo post, Chinese microblog, or short social update requests where brevity and immediacy are required. |
Option A — Single punch:
[核心观点]。[一句支撑]。#话题#
Option B — Short list (2–3 items max):
[引子]：
· [点1]
· [点2]
#话题#
#AI #Claude4 — more dilutes reach| Excuse | Reality |
|---|---|
| 把公众号摘要搬过来 | 超字数，读者看不完，系统截断 |
| 无 hashtag | 发现率接近零，算法无法归类 |
| 铺垫太长 | 微博读者1秒判断，开头即结论 |
| 超过2个话题标签 | 显得 spam，降低互动率 |