ワンクリックでManusで任意のスキルを実行

platform-aware-citation

スター51

フォーク25

更新日2026年5月14日 10:00

Use when writing content that cites sources (URLs, numbers, quotes) across social platforms — each platform has different rules for whether bare URLs should appear at all. Prevents inline URL overflow on platforms where links are unclickable or unwanted (小红书, Instagram-like). Applies whenever a Writer receives research with URLs and must decide per-platform how to surface citations.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

fufankeji

fufankeji/FuFan-VibeCodingCourse

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Platform-Aware Citation

Core Principle

"URL 必须真实" ≠ "URL 必须出现"。这是两层独立决策。第一层：来源是否可信。第二层：此平台是否应该显示 URL。两层都要判断。

Per-Platform Rules

公众号 / Newsletter（长文）

每个事实声明 → 内联 Markdown 链接 [描述](url) + 来源标注
数据数字 → 标注来源平台名称
理由：读者环境支持点击，可信度依赖可追溯来源

小红书 / 竖屏短图文

正文禁止裸 URL（app 内外链不可点击，是视觉噪音）
数据用文字表达："来自 xxx 项目"、"GitHub 上 xxx 个 star"、"HN xxx 分"
结尾可选"相关项目"区域：文字列出项目名，不放链接
理由：小红书 app 内超链接无法点击，裸 URL 只会让读者复制失败后放弃

微博 / Twitter-like（字数受限）

字数允许时：放 至多 1 个最关键 URL（通常是最高热度来源）
字数不允许时：省略 URL，保留数字 + 项目名
禁止超过 1 个 URL（多链接被算法识别为外链垃圾）
理由：字数硬约束优先；单 URL 比多 URL 传播效果更好

决策流程

收到 research.md → 有 URL 需要引用？
  ├── 是 → 当前平台是什么？
  │         ├── 公众号 → 全部内联链接
  │         ├── 小红书 → 正文 0 个 URL，文字替代
  │         └── 微博   → 0 或 1 个，看字数
  └── 否 → 不涉及

Common Mistakes

错误理由	现实
"约束说 URL 必须真实，我就放进去"	"真实"≠"必须出现"，两层独立判断
"字数没限制就多塞 URL"	平台 UX 规则比字数限制更优先
"公众号过了，小红书也应该差不多"	两个平台 URL 规则完全相反
"用户能看懂裸 URL 是什么意思"	不可点击的 URL 是噪音，不是来源
"其他 Writer 放了 URL，我也放"	每个平台独立判断，不参考其他平台输出

このリポジトリの他の Skills

同じリポジトリ

backend-testing

fufankeji/FuFan-VibeCodingCourse

单后端闭环测试执行器（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 在判定"单后端"时调用，也可直接触发。

2026-06-0151

frontend-testing

fufankeji/FuFan-VibeCodingCourse

单前端闭环测试执行器（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 在判定"单前端"时调用，也可直接触发。

2026-06-0151

full-chain-testing

fufankeji/FuFan-VibeCodingCourse

完整功能链路测试执行器（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（局部前后端）。

2026-06-0151

fullstack-slice-testing

fufankeji/FuFan-VibeCodingCourse

局部前后端接缝测试执行器（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（单前端）。

2026-06-0151

test-routing-advisor

fufankeji/FuFan-VibeCodingCourse

测试路由顾问：在某个 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 来保证。

2026-06-0151

testing-system-blueprint

fufankeji/FuFan-VibeCodingCourse

测试体系蓝本（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 承担。

2026-06-0151

name	platform-aware-citation
description	Use when writing content that cites sources (URLs, numbers, quotes) across social platforms — each platform has different rules for whether bare URLs should appear at all. Prevents inline URL overflow on platforms where links are unclickable or unwanted (小红书, Instagram-like). Applies whenever a Writer receives research with URLs and must decide per-platform how to surface citations.

Platform-Aware Citation

Core Principle

"URL 必须真实" ≠ "URL 必须出现"。这是两层独立决策。第一层：来源是否可信。第二层：此平台是否应该显示 URL。两层都要判断。

Per-Platform Rules

公众号 / Newsletter（长文）

每个事实声明 → 内联 Markdown 链接 [描述](url) + 来源标注
数据数字 → 标注来源平台名称
理由：读者环境支持点击，可信度依赖可追溯来源

小红书 / 竖屏短图文

正文禁止裸 URL（app 内外链不可点击，是视觉噪音）
数据用文字表达："来自 xxx 项目"、"GitHub 上 xxx 个 star"、"HN xxx 分"
结尾可选"相关项目"区域：文字列出项目名，不放链接
理由：小红书 app 内超链接无法点击，裸 URL 只会让读者复制失败后放弃

微博 / Twitter-like（字数受限）

字数允许时：放 至多 1 个最关键 URL（通常是最高热度来源）
字数不允许时：省略 URL，保留数字 + 项目名
禁止超过 1 个 URL（多链接被算法识别为外链垃圾）
理由：字数硬约束优先；单 URL 比多 URL 传播效果更好

决策流程

收到 research.md → 有 URL 需要引用？
  ├── 是 → 当前平台是什么？
  │         ├── 公众号 → 全部内联链接
  │         ├── 小红书 → 正文 0 个 URL，文字替代
  │         └── 微博   → 0 或 1 个，看字数
  └── 否 → 不涉及

Common Mistakes

错误理由	现实
"约束说 URL 必须真实，我就放进去"	"真实"≠"必须出现"，两层独立判断
"字数没限制就多塞 URL"	平台 UX 规则比字数限制更优先
"公众号过了，小红书也应该差不多"	两个平台 URL 规则完全相反
"用户能看懂裸 URL 是什么意思"	不可点击的 URL 是噪音，不是来源
"其他 Writer 放了 URL，我也放"	每个平台独立判断，不参考其他平台输出