تشغيل أي مهارة في Manus بنقرة واحدة

platform-aware-citation

النجوم٥١

التفرعات٢٥

آخر تحديث١٤ مايو ٢٠٢٦ في ١٠:٠٠

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 عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

المحررونالفنون والتصميم والترفيه والرياضة والإعلام·SOC 27-3041

مستكشف الملفات

2 ملفات

SKILL.md

readonly

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，我也放"	每个平台独立判断，不参考其他平台输出

المزيد من هذا المستودع

نفس المستودع

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，我也放"	每个平台独立判断，不参考其他平台输出