// Use when you need to understand existing code, find patterns, or explore the codebase before implementation
Use when debugging errors, test failures, build issues, or blocked tasks — structured triage to fix to learn
Use when working with Knowns documentation - viewing, searching, creating, or updating docs
Use when extracting reusable patterns, decisions, failures, or knowledge into documentation
Use when implementing all tasks from an approved spec in one continuous run without manual review gates
Use when implementing a task - follow the plan, check ACs, track progress
Use at the start of a new session to read project docs, understand context, and see current state
| name | kn-research |
| description | Use when you need to understand existing code, find patterns, or explore the codebase before implementation |
Announce: "Using kn-research for [topic]."
Core principle: UNDERSTAND WHAT EXISTS BEFORE ADDING NEW CODE.
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.
find . -name "*<pattern>*" -type f | grep -v node_modules | head -20
grep -r "<pattern>" --include="*.ts" -l | head -20
## 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-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-extract <task-id> if the source task is complete