菜单
Use when implementing/building/coding the Daily AI Intelligence pipeline — Phase A thin daily-briefing tickets, source adapters, ranking, validation. Do NOT use to run, poll, or generate a daily brief — use the daily-ai-intelligence skill for that.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | daily-ai-intelligence-implementer |
| description | Use when implementing/building/coding the Daily AI Intelligence pipeline — Phase A thin daily-briefing tickets, source adapters, ranking, validation. Do NOT use to run, poll, or generate a daily brief — use the daily-ai-intelligence skill for that. |
You are implementing the Daily AI Intelligence pipeline as an audited, ticket-driven workflow.
Your job is not to finish vaguely. Your job is to advance the implementation state machine.
docs/daily-ai-intelligence/phase-status.yamldocs/daily-ai-intelligence/implementation-backlog.mddocs/daily-ai-intelligence/acceptance-gates.mddocs/daily-ai-intelligence/startup-audit-policy.mddocs/daily-ai-intelligence/copilot-execution-rules.mddocs/daily-ai-intelligence/phase-a-spec.mdEvery session begins with startup audit.
Do not trust done, verified, or audit_pass blindly.
If a completed ticket fails audit, mark it reopened and fix the earliest reopened ticket first.
Before implementation, create or update the current ticket's acceptance contract.
The contract must say how the feature will be proven complete.
Write or update tests and fixtures before implementation whenever the ticket changes behavior.
After implementation, write a proof pack proving what passed.
Stop only when the current ticket's deterministic checks pass, phase-status.yaml is updated, and the next pending/reopened ticket is identified.
Implement only Phase A until all A01-A12 tickets pass audit.
See verification-policy.md in this skill directory for the full verification
policy — the preferred deterministic verification layers and the assertions
every test must make.
Use this when phase-status.yaml shows Phase F is active.
Add one source class at a time, disabled by default, with source registry policy, offline fixtures, retention policy, and side-by-side report comparison.
Run the daily AI technical-intelligence briefing workflow. Polls governed registry sources (GitHub releases, RSS/Atom, Hacker News, Reddit, Bluesky, X, papers, video/audio, manual items), normalizes and deduplicates events, ranks with topic memory and explicit feedback, generates a validated daily Markdown brief, and optionally exports to Obsidian, builds hot-topic dossiers, records feedback, runs weekly trend synthesis, or compares ranked output across registries. Use when the user asks for a "daily AI brief", "AI tooling watch", "coding-agent update scan", "MCP/Copilot/Claude Code daily brief", "weekly AI tooling trend memo", "hot-topic dossier from a daily brief", a "weekly AI tooling synthesis", or to "rank/validate/export today's AI intelligence". Do NOT use for academic literature reviews, PDF download/conversion, citation-graph expansion, or paper-only synthesis (use the `research-pipeline` skill instead).
End-to-end reproducible academic-paper research using the research-pipeline CLI and MCP server. Plans queries, searches arXiv/Google Scholar/Semantic Scholar/OpenAlex/DBLP/HuggingFace, screens with BM25, downloads and converts PDFs to Markdown, extracts evidence, summarizes, validates, and writes a human-readable, evidence-cited research report. Iterates up to 4 rounds to close academic and engineering gaps, and resumes on top of any prior same-topic report. Use when the user asks to "research", "find papers", "survey the literature", "do a literature review", "analyze arXiv papers", "build a research report", "screen papers", "summarize papers", "expand citations", "fill research gaps", or "resume a prior research report". Do NOT use for general web search, simple PDF-to-Markdown conversion (use `research-pipeline convert-file` directly), or requirements analysis (use the req-analysis skill).
Convert a research synthesis report into an implementation-neutral product blueprint for product concept, users, workflow, product experience direction, logical architecture, MVP, evaluation, handoff, and next-stage routing. Use when the user has a research report and asks to "Create a blueprint from this research report", "Design the product based on this research", "Turn this research into a product design", "What should we build?", "Generate a product blueprint", "Convert the research to an MVP plan", "Define the product experience direction", "Define how users should experience the product", "Define user trust/control/review expectations", "What should we build next?", "Which design stages should we run next?", or "Recommend the next stages after the blueprint"; or after research-pipeline handover. Aliases: "product-blueprint", "research-blueprint", "research-to-product". Do NOT use for more research, tech stack, detailed UI/UX design or wireframes, user-story requirements, or single-paper explanation.