メニュー
Use when you need to understand existing code, find patterns, search project knowledge, use web research for external/current facts, or explore a large codebase before implementation
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when orchestrating a full Knowns spec or task wave through planning, implementation, review, integration, and verification, optionally using sub-agents when scopes are parallel-safe.
Use when committing code changes with proper conventional commit format and verification
Use when working with Knowns documentation - viewing, searching, creating, or updating docs
Use when extracting reusable patterns, decisions, failures, or knowledge into documentation
Use only when the user explicitly wants the legacy no-review-gates pipeline for an approved spec; prefer kn-flow for normal spec orchestration
Use when implementing a task - follow the plan, check ACs, track progress
| name | kn-research |
| description | Use when you need to understand existing code, find patterns, search project knowledge, use web research for external/current facts, or explore a large codebase before implementation |
Announce: "Using kn-research for [topic]."
Core principle: UNDERSTAND WHAT EXISTS BEFORE ADDING NEW CODE.
Use the narrowest search surface that can answer the question, then widen deliberately.
search first for project context: docs, tasks, memories, and decisions.retrieve when the next consumer needs a cited context pack, not for every lookup.code.find, code.symbols, code.references, code.definition) for code structure before raw file reads.If the research surface is too large for one pass, split it into independent tracks before reading everything.
Use sub-agents when all are true:
Good delegated research tracks:
Avoid delegating overlapping broad asks like "research the whole repo." While workers run, continue non-overlapping local research. Inspect worker findings before relying on them. If sub-agent tools are unavailable or not allowed, execute the same split sequentially in the main context.
mcp_knowns_search({ "action": "search", "query": "<topic>", "type": "doc" })
mcp_knowns_search({ "action": "search", "query": "<topic>", "type": "memory" })
mcp_knowns_docs({ "action": "get", "path": "<path>", "smart": true })
Unified search returns docs and memory entries. If relevant memories appear, include them in findings and note whether they're still current.
Use search for discovery-first research. Only use retrieve when the next consumer needs assembled context with citations rather than raw hits:
mcp_knowns_search({ "action": "retrieve", "query": "<topic>" })
If MCP is unavailable, fall back to CLI: knowns retrieve "<topic>" --json
If Step 1 found a spec or doc relevant to the topic, use structural resolve to discover related tasks, dependencies, and implementation status before searching tasks by keyword. This gives a complete picture of what already exists.
// Found specs/ai-permission-model in Step 1 → find all tasks implementing it
mcp_knowns_search({ "action": "resolve", "ref": "@doc/specs/<found-path>{implements}", "direction": "inbound", "entityTypes": "task" })
// Found a doc that others depend on → find what depends on it
mcp_knowns_search({ "action": "resolve", "ref": "@doc/<found-path>{depends}", "direction": "inbound", "depth": 2 })
Skip this step only if Step 1 returned no relevant docs or specs.
mcp_knowns_search({ "action": "search", "query": "<keywords>", "type": "task" })
mcp_knowns_tasks({ "action": "get", "taskId": "<id>" })
If Step 2 already found related tasks via structural resolve, focus keyword search on gaps — tasks that might be related but not formally linked.
Use MCP code tools as the primary code research path:
mcp_knowns_code({ "action": "find", "query": "<symbol/topic>", "limit": 20 })
mcp_knowns_code({ "action": "symbols", "path": "<file>" })
mcp_knowns_code({ "action": "references", "query": "<symbol>", "path": "<file>" })
Only fall back to raw shell search when MCP/code tools are unavailable, or when MCP/code search returns no useful entry point after narrowing the query. Prefer rg over slower shell search tools:
rg --files | rg "<pattern>"
rg -n "<pattern>" --glob '!node_modules/**'
After an rg fallback finds likely files or symbols, return to MCP code tools (symbols, definition, references, diagnostics) before drawing conclusions.
Use external MCP providers first when local repo context is not enough because the topic depends on current or external information.
Examples:
Rules:
## Research: [Topic]
### Existing Implementations
- `src/path/file.ts`: Does X
### Patterns Found
- Pattern 1: Used for...
### Related Docs
- @doc/path1 - Covers X
### Recommendations
1. Reuse X from Y
2. Follow pattern Z
All built-in skills in scope must end with the same user-facing information order: kn-init, kn-spec, kn-flow, kn-plan, kn-research, kn-implement, kn-verify, kn-doc, kn-template, kn-extract, and kn-commit.
Required order for the final user-facing response:
Keep this concise for CLI use. Research-specific content may extend the key-details section, but must not replace or reorder the shared structure.
Out of scope: explaining, syncing, or generating .claude/skills/*. Runtime auto-sync already handles platform copies, so this skill source only defines the built-in output contract.
For kn-research, the key details should cover:
If the research surface becomes too large for one response or one task:
@doc/<path>If the research uncovers a broad follow-up topic that should be tracked independently:
@task-<id> from the current contextOnly suggest a next command when the findings clearly lead somewhere:
/kn-plan <task-id>/kn-flow @doc/<spec-path>/kn-extract <task-id> if the source task is complete