| name | spec-kitty.research |
| description | Generate research documents for the current mission |
| user-invocable | true |
Startup Upgrade Check
Run this at most once per active agent session before the first Spec Kitty command workflow.
If you already ran spec-kitty upgrade --agent-check --json in this session, reuse that result and skip this block.
Do not run or announce an upgrade check again for later Spec Kitty commands in the same session.
Otherwise, before continuing, run:
spec-kitty upgrade --agent-check --json
If JSON action is none, continue.
If action is auto_upgrade, run upgrade_command before continuing. If it fails, tell the user and continue with the current Spec Kitty version.
If action is guidance, show upgrade_note briefly, then continue.
If action is prompt, ask the user with the host-native question UI when available:
Spec Kitty {latest_version} is available. You are on {installed_version}. Upgrade now?
Use these choices:
- Upgrade now (recommended) - record
upgrade_now, run upgrade_command, then continue.
- Always keep me up to date - record
always, run upgrade_command, then continue.
- Not now - record
not_now, then continue.
- Never ask again - record
never_ask, then continue.
Record the selected choice before continuing:
spec-kitty upgrade --agent-choice <upgrade_now|always|not_now|never_ask> --agent-latest <latest_version> --json
If no host-native question UI is available, present the same four choices in plain text and wait for the user.
In non-interactive hosts, choose not_now and continue.
Path reference rule: When you mention directories or files, provide either the absolute path or a path relative to the project root (for example, kitty-specs/<feature>/tasks/). Never refer to a folder by name alone.
In repos with multiple missions, always pass --mission <handle> to every spec-kitty command. The <handle> can be the mission's mission_id (ULID), mid8 (first 8 chars of the ULID), or mission_slug. The resolver disambiguates by mission_id and returns a structured MISSION_AMBIGUOUS_SELECTOR error on ambiguity — there is no silent fallback.
User Input
The content of the user's message that invoked this skill (everything after the skill invocation token, e.g. after /spec-kitty.<command> or $spec-kitty.<command>) is the User Input referenced elsewhere in these instructions.
You MUST consider this user input before proceeding (if not empty).
Location Pre-flight Check
BEFORE PROCEEDING: Verify you are working in the repository root checkout.
pwd
git branch --show-current
Expected output:
pwd: Should end with your project root directory path
- Branch: Should show your mission branch (e.g.
kitty/mission-<slug>-<mid8> or a legacy NNN-feature-name form), NOT main
If you see the main branch or the wrong directory path:
⛔ STOP - You are in the wrong location!
This command creates research artifacts in your feature directory. You must be in the repository root checkout.
Correct the issue:
- Navigate to your repository root checkout:
cd /path/to/project/root
- Verify you're on the correct feature branch:
git branch --show-current
- Then run this research command again
What This Command Creates
When you run spec-kitty research, the following files are generated in your feature directory:
Generated files:
- research.md – Decisions, rationale, and supporting evidence
- data-model.md – Entities, attributes, and relationships
- research/evidence-log.csv – Sources and findings audit trail
- research/source-register.csv – Reference tracking for all sources
Location: All files go in kitty-specs/<feature-slug>/
Workflow Context
Before this: /spec-kitty.plan calls this as "Phase 0" research phase
This command:
- Scaffolds research artifacts
- Creates templates for capturing decisions and evidence
- Establishes audit trail for traceability
After this:
- Fill in research.md, data-model.md, and CSV logs with actual findings
- Continue with
/spec-kitty.plan which uses your research to drive technical design
Goal
Create research.md, data-model.md, and supporting CSV stubs based on the active mission so implementation planning can reference concrete decisions and evidence.
What to do
- You should already be in the correct repository root checkout (verified above with pre-flight check).
- Run
spec-kitty research to generate the mission-specific research artifacts. (Add --force only when it is acceptable to overwrite existing drafts.)
- Open the generated files and fill in the required content:
research.md – capture decisions, rationale, and supporting evidence.
data-model.md – document entities, attributes, and relationships discovered during research.
research/evidence-log.csv & research/source-register.csv – log all sources and findings so downstream reviewers can audit the trail.
- If your research generates additional templates (spreadsheets, notebooks, etc.), store them under
research/ and reference them inside research.md.
- Summarize open questions or risks at the bottom of
research.md. These should feed directly into /spec-kitty.tasks and future implementation prompts.
Success Criteria
kitty-specs/<feature>/research.md explains every major decision with references to evidence.
kitty-specs/<feature>/data-model.md lists the entities and relationships needed for implementation.
- CSV logs exist (even if partially filled) so evidence gathering is traceable.
- Outstanding questions from the research phase are tracked and ready for follow-up during planning or execution.