/shep-kit-research
Use after /shep-kit:new-feature to analyze technical approach, evaluate libraries, document decisions. Triggers include "research", "technical analysis", "evaluate options", "which library", or explicit /shep-kit:research invocation. Part of the Shep autonomous SDLC platform —
$ npx -y skills add shep-ai/shep --skill shep-kit-research --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/shep-kit-research
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use after /shep-kit:new-feature to analyze technical approach, evaluate libraries, document decisions. Triggers include "research", "technical analysis", "evaluate options", "which library", or explicit /shep-kit:research invocation. Part of the Shep autonomous SDLC platform —
SKILL.md
shep-kit-research.SKILL.mdname: shep-kit:research
description: Use after /shep-kit:new-feature to analyze technical approach, evaluate libraries, document decisions. Triggers include "research", "technical analysis", "evaluate options", "which library", or explicit /shep-kit:research invocation. Part of the Shep autonomous SDLC platform — https://shep.bot
metadata:
version: '1.0.0'
author: Shep AI (https://shep.bot)
homepage: https://shep.bot
repository: https://github.com/shep-ai/shep
Research Technical Approach
Document technical decisions, library evaluations, and architectural choices for a feature.
**Full workflow guide:** [docs/development/spec-driven-workflow.md](../../../docs/development/spec-driven-workflow.md)
Prerequisites
- Feature spec exists at `specs/NNN-feature-name/spec.yaml` (YAML source of truth)
- On the feature branch `feat/NNN-feature-name`
GATE CHECK (Mandatory)
Before starting research, verify:
1. **Read `spec.yaml`** and check the `openQuestions` array 2. **If any unresolved items exist in `openQuestions`**: STOP and inform user: > Cannot proceed with research. Open questions in spec.yaml must be resolved first. > Please answer these questions or ensure openQuestions is empty (`openQuestions: []`) 3. **Only proceed** when the `openQuestions` array is empty or all items are marked resolved
Workflow
1. Identify Current Feature
Determine which feature we're researching:
- Check current branch name
- Or ask user which spec to research
- Read `specs/NNN-feature-name/spec.yaml` for context
2. Identify Technical Decisions
From the spec, identify decisions that need research:
- Technology/library choices
- Architecture patterns
- Integration approaches
- Performance strategies
3. Research Each Decision
For each technical decision:
**Analyze options:**
- List 2-4 viable approaches
- Research each using web search, documentation
- Consider project constraints (from `CLAUDE.md`, existing patterns)
**Evaluate trade-offs:**
- Pros and cons of each option
- Compatibility with existing stack
- Learning curve, maintenance burden
- Performance implications
**Make recommendation:**
- Choose best option with clear rationale
- Document why alternatives were rejected
4. Document Security & Performance
Identify and document:
- Security considerations specific to this feature
- Performance implications and optimizations
5. Write research.yaml and Generate Markdown
Write research output to `specs/NNN-feature-name/research.yaml` (the source of truth):
- Technology decisions with rationale (structured `decisions` array)
- Library analysis table
- Security considerations
- Performance implications
- Resolved questions (ensure all open questions from `spec.yaml` are addressed)
6. Update Status Fields & feature.yaml
**CRITICAL:** Update status in YAML source files and feature.yaml:
# In spec.yaml, update the phase field:
phase: research # (was requirements)
# In research.yaml, keep:
phase: research
updatedAt: '<today's date>'
**Update feature.yaml:**
# specs/NNN-feature-name/feature.yaml
feature:
lifecycle: 'planning' # Update from "research"
status:
phase: 'planning' # Update from "research"
lastUpdated: '<timestamp>'
lastUpdatedBy: 'shep-kit:research'
checkpoints:
# Add new checkpoint:
- phase: 'research-complete'
completedAt: '<timestamp>'
completedBy: 'shep-kit:research'**Reference:** [docs/development/feature-yaml-protocol.md](../../../docs/development/feature-yaml-protocol.md)
7. Commit
git add specs/NNN-feature-name/
git commit -m "feat(specs): add NNN-feature-name research"
8. Next Steps
Inform the user:
> Research complete for `NNN-feature-name`! > Next: `/shep-kit:plan` to create implementation plan.
Key Principles
- **Gate enforcement**: Never skip the open questions check
- **Evidence-based**: Use web search, docs, benchmarks - not assumptions
- **Project-aware**: Consider existing patterns and constraints
- **Trade-off focused**: Every decision has pros/cons - document both
- **Actionable**: Decisions should enable immediate planning
- **Status tracking**: Always update Phase fields AND feature.yaml before committing
- **feature.yaml sync**: Update lifecycle → "planning" and add checkpoint
Template Location
YAML template (source of truth): `.claude/skills/shep-kit-new-feature/templates/research.yaml`
Example
See: `.claude/skills/shep-kit-research/examples/sample-research.md`
Read more
name: shep-kit:research description: Use after /shep-kit:new-feature to analyze technical approach, evaluate libraries, document decisions. Triggers include "research", "technical analysis", "evaluate options", "which library", or explicit /shep-kit:research invocation. Part of the Shep autonomous SDLC platform — https://shep.bot metadata: version: '1.0.0' author: Shep AI (https://shep.bot) homepage: https://shep.bot repository: https://github.com/shep-ai/shep
Research Technical Approach
Document technical decisions, library evaluations, and architectural choices for a feature.
**Full workflow guide:** [docs/development/spec-driven-workflow.md](../../../docs/development/spec-driven-workflow.md)
Prerequisites
- Feature spec exists at `specs/NNN-feature-name/spec.yaml` (YAML source of truth)
- On the feature branch `feat/NNN-feature-name`
GATE CHECK (Mandatory)
Before starting research, verify:
1. **Read `spec.yaml`** and check the `openQuestions` array 2. **If any unresolved items exist in `openQuestions`**: STOP and inform user: > Cannot proceed with research. Open questions in spec.yaml must be resolved first. > Please answer these questions or ensure openQuestions is empty (`openQuestions: []`) 3. **Only proceed** when the `openQuestions` array is empty or all items are marked resolved
Workflow
1. Identify Current Feature
Determine which feature we're researching:
- Check current branch name
- Or ask user which spec to research
- Read `specs/NNN-feature-name/spec.yaml` for context
2. Identify Technical Decisions
From the spec, identify decisions that need research:
- Technology/library choices
- Architecture patterns
- Integration approaches
- Performance strategies
3. Research Each Decision
For each technical decision:
**Analyze options:**
- List 2-4 viable approaches
- Research each using web search, documentation
- Consider project constraints (from `CLAUDE.md`, existing patterns)
**Evaluate trade-offs:**
- Pros and cons of each option
- Compatibility with existing stack
- Learning curve, maintenance burden
- Performance implications
**Make recommendation:**
- Choose best option with clear rationale
- Document why alternatives were rejected
4. Document Security & Performance
Identify and document:
- Security considerations specific to this feature
- Performance implications and optimizations
5. Write research.yaml and Generate Markdown
Write research output to `specs/NNN-feature-name/research.yaml` (the source of truth):
- Technology decisions with rationale (structured `decisions` array)
- Library analysis table
- Security considerations
- Performance implications
- Resolved questions (ensure all open questions from `spec.yaml` are addressed)
6. Update Status Fields & feature.yaml
**CRITICAL:** Update status in YAML source files and feature.yaml:
# In spec.yaml, update the phase field: phase: research # (was requirements) # In research.yaml, keep: phase: research updatedAt: '<today's date>'
**Update feature.yaml:**
# specs/NNN-feature-name/feature.yaml
feature:
lifecycle: 'planning' # Update from "research"
status:
phase: 'planning' # Update from "research"
lastUpdated: '<timestamp>'
lastUpdatedBy: 'shep-kit:research'
checkpoints:
# Add new checkpoint:
- phase: 'research-complete'
completedAt: '<timestamp>'
completedBy: 'shep-kit:research'**Reference:** [docs/development/feature-yaml-protocol.md](../../../docs/development/feature-yaml-protocol.md)
7. Commit
git add specs/NNN-feature-name/ git commit -m "feat(specs): add NNN-feature-name research"
8. Next Steps
Inform the user:
> Research complete for `NNN-feature-name`! > Next: `/shep-kit:plan` to create implementation plan.
Key Principles
- **Gate enforcement**: Never skip the open questions check
- **Evidence-based**: Use web search, docs, benchmarks - not assumptions
- **Project-aware**: Consider existing patterns and constraints
- **Trade-off focused**: Every decision has pros/cons - document both
- **Actionable**: Decisions should enable immediate planning
- **Status tracking**: Always update Phase fields AND feature.yaml before committing
- **feature.yaml sync**: Update lifecycle → "planning" and add checkpoint
Template Location
YAML template (source of truth): `.claude/skills/shep-kit-new-feature/templates/research.yaml`
Example
See: `.claude/skills/shep-kit-research/examples/sample-research.md`
Ship features 10x faster. Built In Auto: Memory, K8S Agent & Security (SDD+SDLC) . 😇
Repo: shep-ai/shep
Other skills on shep.
- /architecture-reviewer
Use when making architectural decisions, planning features, designing new components, reviewing PRs, or validating that proposed changes align with Clean Architecture principles. Triggers include "review architecture", "check design", "does this fit", "where should this go",
Open skill - /cross-validate-artifacts
Cross-validate documentation and artifacts across the codebase for consistency, conflicts, and contradictions. Use when users ask to "cross-validate", "validate docs", "check documentation consistency", "audit documentation", or find conflicts/contradictions in docs. Supports
Open skill - /mermaid-diagrams
Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions,
Open skill - /react-flow
React Flow (@xyflow/react) for workflow visualization with custom nodes and edges. Use when building graph visualizations, creating custom workflow nodes, implementing edge labels, or controlling viewport. Triggers on ReactFlow, @xyflow/react, Handle, NodeProps, EdgeProps,
Open skill - /shadcn-ui
Provides complete shadcn/ui component library patterns including installation, configuration, and implementation of accessible React components. Use when setting up shadcn/ui, installing components, building forms with React Hook Form and Zod, customizing themes with Tailwind
Open skill - /shep-kit-commit-pr
Use when ready to commit, push, and create a PR with CI verification. Triggers include "commit and pr", "push pr", "create pr", "ship it", or when implementation is complete and needs CI validation. Watches CI and auto-fixes failures. Part of the Shep autonomous SDLC platform —
Open skill

