一键导入
vault-research
Use when a vault note, idea, project, or topic needs external sources, competitor research, discussion evidence, or market signals
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when a vault note, idea, project, or topic needs external sources, competitor research, discussion evidence, or market signals
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run a marketing/positioning pass on an open source repo's README and public-facing docs so a developer landing on it for the first time immediately understands what it is, why it exists, and how to use it. Use this whenever the user wants to improve a repo's README, write launch copy for an OSS project, sharpen positioning ("does this README explain what the project does"), prep a repo for a Show HN / Hacker News / Product Hunt / Twitter launch, or asks for an "OSS marketing pass," "README audit," or similar. This is about clarity and conversion (visitor → user → star), not contribution mechanics — for CONTRIBUTING.md, issue templates, CODEOWNERS, or governance docs, that's a different concern.
Audit and prepare a GitHub repo for open source release, with a focus on developer experience (DevEx) — the things that determine whether a stranger can go from "found this repo" to "opened a PR" without friction. Use this whenever the user wants to open-source a repo, make a private repo public, do a "pre-launch checklist" or "OSS readiness audit," improve their README/CONTRIBUTING/issue templates, or asks something like "is this repo ready for people to use/contribute to." Also trigger for narrower asks that are really pieces of this — "write a CONTRIBUTING.md," "set up issue templates," "add a CODEOWNERS file" — since those are almost always better done as part of the full readiness pass rather than in isolation.
Design, build, or review command-line interfaces using the Command Line Interface Guidelines from clig.dev. Use this skill whenever the user is creating a new CLI, adding commands/subcommands/flags, designing help text, choosing stdout/stderr/exit-code behavior, adding JSON or plain output modes, improving error messages, making destructive operations safer, or asking whether a CLI feels good, scriptable, discoverable, or Unix-friendly.
Collapse semantically overlapping notes, ideas, and project docs into clearer canonical surfaces while preserving distinct claims, decisions, examples, and source provenance.
Maintain canonical concept pages and surface recurring themes
Hygiene pass over active notes, ideas, and projects
| name | vault-research |
| description | Use when a vault note, idea, project, or topic needs external sources, competitor research, discussion evidence, or market signals |
Research a target note, idea, project, or topic. Preserve external sources as
traceable source records by default; write summaries only when the user asks for
synthesis, assessment, or a concise research brief. Any source used in a summary
keeps a complete immutable copy in raw/processed/YYYY-MM-DD/.
Notes tagged external are treated as clipped/imported external sources and are
eligible for synthesis while preserving the complete source record.
Portent reference: ../references/portent-knowledge-base-spec.md.
Research briefs are type: Note by default. External changes, meetings,
incidents, product launches, or decisions that happened are type: Event. Every
synthesized Note or Event should set belongs_to to its primary Project,
Responsibility, Operation, or Topic when that context is clear.
Target can be:
voice-notes-app or voice-notes-app.md)notes/car-search/prd.md)Optional flags:
--mode report|apply (default: report)--output sources|summary|both (default: sources)Resolve target in this order:
external tag.Note or Event and identify the primary
belongs_to relationship when clear.sources: create or update source records onlysummary: write a concise synthesized research block with citationsboth: preserve source records and write a concise synthesisapply mode, archive every external source used for synthesis to
raw/processed/YYYY-MM-DD/ before writing the synthesis.projects/active/<project>/research/ideas/<state>/<idea>/research/notes/<topic>/high|medium|low) for key claims.Default to --output sources for untagged material. Notes tagged external may
use summary or both during processing because the tag explicitly marks them
as external clipped sources.
sources for collecting, categorizing, moving, linking, or preserving
external records without interpretation.summary when the user wants an answer or brief and does not need
separate working source notes.both when the user wants synthesis and the sources should remain useful
as organized research material.Never summarize user-authored ideas, project drafts, plans, or notes as part of research unless the user explicitly asks for that specific note to be summarized. Link external findings to those owned notes instead.
external as the source-origin signal for synthesis eligibility.raw/processed/YYYY-MM-DD/ for
every synthesized claim or source summary.external, --output summary, --output both, or
an explicit user request for synthesis.apply mode, do not write a summary until complete source records have
been archived.Return:
raw/processed/YYYY-MM-DD/