メニュー
Use when gathering evidence before a decision, summarizing repo or external facts, checking whether context supports a proposed path, or preparing a brief before specs, plans, brainstorming, or implementation.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | research-brief |
| description | Use when gathering evidence before a decision, summarizing repo or external facts, checking whether context supports a proposed path, or preparing a brief before specs, plans, brainstorming, or implementation. |
Gather evidence before deciding.
Before researching, identify the exact target: artifact, URL, repo, product, paper, package, model, organization, or source.
Use provided context first: links, screenshots, attached files, browser or page context, repo paths, issue numbers, and named artifacts.
If multiple plausible targets would change the research path, stop and ask for the source. Do not choose by search ranking, source richness, name similarity, or an "I assume..." caveat.
Research is not approval to follow the latest request.
If the request is biased, stale, or asks you to skip relevant sources, inspect the evidence anyway.
Do not edit implementation files. Do not create a durable brief unless asked.
Start with the smallest sources that can answer the question:
Prefer live evidence over summaries, handoffs, or the user's framing.
Keep the brief short:
Question: ...
Evidence: ...
Conflict: ...
Unknowns: ...
Decision needed: ...
Recommendation: ...
Omit sections that do not apply.
Stop and surface the decision when evidence reveals:
Ask only after checking discoverable evidence.
If the brief will guide later work, link to evidence instead of copying volatile repo inventory.
If the next step is collaborative direction-setting, route to grill-context.
If the next step is durable requirements, route to write-spec.
Use when coordinating Freeflow Pi/cmux pane delegation, orchestrator/planning-parent/execution-parent workflows, task packets, child results, context locality, capability reroutes, multi-agent execution, work packages, worktrees, routing fresh-reviewer/subagent requests, or when the user asks to spawn/manage visible pane agents.
Use when shaping, reviewing, implementing, or diagnosing work where module/interface/seam/state/role-boundary choices affect complexity, locality, testability, future change, or repeated edge-case churn. Use for architecture direction, state machines, event systems, tool interfaces, prompt/result serialization, delegation/context boundaries, role ownership, failure contracts, growing scope, shallow modules, bad seams, broad refactors, and review loops that keep finding new edge cases.
Use for pre-work thinking before consequential work, including codebase exploration, brainstorming, planning direction, shaping ideas/features/specs, conceptual/design/routing/interface/state/context-boundary questions, workflow/tool-surface questions, "should we" / "how should we" / "what do you think" prompts, vague requests, and work that needs evidence before spec, plan, build, review, verification, or durable memory.
Use when implementing an approved plan, executing planned slices, resuming planned work, handling planned verification failures, adjudicating review findings during execution, or encountering scope/source conflicts while carrying out a plan.
Use when context is low, scope is ambiguous, implementation/review/verification reveals unknowns, the user asks a question or suggests a path that could be misread as correction/permission, or the agent may be about to make a user-owned decision.
Use when asked to review whether a spec, plan, decision note, discovery checkpoint, handoff, or other durable artifact is fit to guide future work; also use when adjudicating artifact-review findings or repeated review loops.