القائمة
Use when creating docs/todo entries, follow-up work records, or post-validation TODOs that future humans or agents must understand without chat history
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | writing-contextual-todos |
| description | Use when creating docs/todo entries, follow-up work records, or post-validation TODOs that future humans or agents must understand without chat history |
Write TODO docs as handoff artifacts, not reminders. A future reader should understand what happened, why the follow-up matters, what is already proven, and what must be true before the TODO can close.
Use this when asked to record follow-up work after validation, debugging, investigation, implementation, or a boundary discovery.
Do not use it for one-line personal reminders or issue titles that already have full context elsewhere.
docs/todo/<date>-<topic>.md.Use these sections unless the repo has a stronger local template:
Writing Principles: who the doc is for and what “good” means.Context: the story in a few paragraphs, not a transcript.What Was Verified: proven behavior only.Boundary Problems: each gap with why it matters.Follow-up Work: concrete implementation slices.Acceptance Standard: observable pass/fail criteria.Problems Encountered: traps future agents must not repeat.Separate product behavior from operator behavior.
Manual actions can prepare or inspect; they must not be counted as acceptance evidence.
Ask an independent subagent:
Review docs/todo/<file>. Check: can someone without chat context understand the goal, why it matters, what was proven, what remains, source attribution, architecture boundaries, actionability, and brevity? Return Critical / Important / Minor / Verdict. Do not edit files.
| Mistake | Fix |
|---|---|
| Vague TODO like “productize this” | Name the exact missing behavior and acceptance criteria. |
| No source of truth | Record where project/repo/issue identity comes from. |
| Manual actions counted as success | Mark them invalid or operator-only. |
| Narrative dump | Link detailed evidence; keep TODO focused on future work. |
| Skipping reviewer | Review catches context gaps the writer no longer sees. |
Use when the user asks to correct English prompts, broken English, typos, grammar, wording, tone, workplace English, business writing, presentation language, or asks for English practice, quizzes, or help expressing ideas clearly in English.
Use when 用户要求提取、提炼、总结某个日期或时间范围的群聊/聊天记录（EACC 投资群 / eacc-chat），生成群聊日报、核心话题分析或投资价值信息筛选。触发词：提取聊天记录、群聊提炼、群聊总结、某月某日群里聊了什么、chat digest、群聊日报、群聊干货。
评估或对比会议纪要/访谈整理/深度纪要的质量：对照原始转录核查保真度，盘点覆盖度，输出多维度打分与失真清单。适用时机：(1) 用户问"这两份纪要哪份质量更高/写得更好"，(2) AI 生成的纪要发布前验收（有没有幻觉、编造、立场写错），(3) 给纪要挑毛病/做质检/打分。触发语：评估纪要质量、对比纪要、纪要靠谱吗、纪要验收、纪要打分、哪份纪要好。
对会议纪要/活动回顾/访谈整理等将对外发布的文档做敏感信息检查与脱敏，覆盖查塔姆宫规则（Chatham House Rule）合规：人名机构名及变体、职级暗示、玩笑话与人事信号、点评同行、口语化敏感词、外链击穿匿名、身份指纹拼图、第三方未公开信息、编辑残留。适用时机：(1) 纪要将对外发布/进知识库/发群前，(2) 嘉宾或机构方要求脱敏审稿，(3) 用户提到查塔姆规则/讲事不讲人/匿名化/敏感信息检查。输出违规清单+修复建议，或直接执行脱敏。
Use when designing or reviewing lifecycle status fields, finite state machines, async task/order/payment/upload/approval workflows, or when states are overlapping, action-shaped, ownerless, unsafe under retries, concurrency, timeouts, or terminal-state updates.
深度研究与验证技能：当用户提出需要多源信息搜集、逻辑推理和事实验证的复杂问题时使用。 适用场景包括但不限于：投资研究、行业分析、技术对比、政策解读、商业决策支持等需要 "先想清楚怎么查，再去查，查完还要验证"的场景。 触发关键词/短语：为什么A而不是B、分析一下、帮我研究、设计一个SOP流程来回答、 深度分析、请验证、fact check、多角度分析、请先理解问题再回答、不要立即回答。 当用户明确要求"先设计研究流程再回答"或"验证你的结论"时，务必使用此技能。 当用户的问题涉及多个实体的比较（公司、技术、政策等）且答案不是简单事实时，也应触发。