/shep-kit-new-feature
Use when starting any new feature, functionality, or enhancement. Triggers include "new feature", "start developing", "add functionality", "implement X", or explicit /shep-kit:new-feature invocation. Creates spec branch and scaffolds specification directory. Part of the Shep
$ npx -y skills add shep-ai/shep --skill shep-kit-new-feature --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-new-feature
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when starting any new feature, functionality, or enhancement. Triggers include "new feature", "start developing", "add functionality", "implement X", or explicit /shep-kit:new-feature invocation. Creates spec branch and scaffolds specification directory. Part of the Shep
SKILL.md
shep-kit-new-feature.SKILL.mdname: shep-kit:new-feature
description: Use when starting any new feature, functionality, or enhancement. Triggers include "new feature", "start developing", "add functionality", "implement X", or explicit /shep-kit:new-feature invocation. Creates spec branch and scaffolds specification directory. 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
Create New Feature Specification
Start spec-driven development by creating a feature branch and specification directory.
**Full workflow guide:** [docs/development/spec-driven-workflow.md](../../../docs/development/spec-driven-workflow.md)
Phase Lifecycle
Requirements → Research → Planning → Implementation → Complete
↓ ↓ ↓ ↓ ↓
spec.yaml research.yaml plan.yaml tasks.yaml all files
↓ ↓ ↓ ↓ ↓
spec.md research.md plan.md tasks.md (auto-generated)**CRITICAL:** Each phase MUST update the `Phase` status field before proceeding.
**IMPORTANT:** Edit YAML files, not Markdown.
Workflow
1. Gather Minimal Input
Ask the user for:
- **Feature name** (kebab-case, e.g., `user-authentication`)
- **One-liner description** (brief summary)
2. Create Branch
# Determine next number
NEXT_NUM=$(ls -d specs/[0-9][0-9][0-9]-* 2>/dev/null | wc -l | xargs printf "%03d" $(($ + 1)))
# If no specs exist, use 001
[ -z "$NEXT_NUM" ] && NEXT_NUM="001"
# Create branch from main
git checkout main && git pull
git checkout -b "feat/${NEXT_NUM}-${FEATURE_NAME}"3. Run Init Script
Execute the scaffolding script:
.claude/skills/shep-kit-new-feature/scripts/init-feature.sh <NNN> <feature-name>
This creates `specs/NNN-feature-name/` with all template files using a **YAML-first** approach:
- **YAML source files**: `spec.yaml`, `research.yaml`, `plan.yaml`, `tasks.yaml` (source of truth)
- **Markdown files**: `spec.md`, `research.md`, `plan.md`, `tasks.md` (auto-generated from YAML)
- **Status tracking**: `feature.yaml` (implementation status, unchanged)
4. Analyze Context
Before filling the spec, analyze:
- **Existing specs**: Read `specs/*/spec.yaml` (or `specs/*/spec.md`) to understand feature landscape and discover dependencies
- **Codebase**: Identify affected areas, patterns, existing implementations
- **Cross-reference**: Infer dependencies, impact areas, size estimate
5. Propose Spec Content
Fill the template placeholders with inferred values:
- Problem statement (from user description + context)
- Success criteria (inferred from scope)
- Affected areas with impact levels (from codebase analysis)
- Dependencies on other features (from existing specs)
- Size estimate with reasoning (S/M/L/XL)
- Open questions (gaps identified during analysis)
Present the proposed spec to the user for review.
6. User Confirms/Adjusts
Allow the user to:
- Approve the proposed spec
- Modify any inferred values
- Add missing context or requirements
7. Write Spec & Update feature.yaml
# Write confirmed content to spec.yaml (the source of truth)
# feature.yaml already created by init script with initial state:
# - lifecycle: "research"
# - phase: "research"
# - checkpoint: "feature-created"
# See: docs/development/feature-yaml-protocol.md for details
# Stage and commit (both YAML source and generated Markdown)
git add specs/NNN-feature-name/
git commit -m "feat(specs): add NNN-feature-name specification"
**IMPORTANT:** Always edit `spec.yaml`. Never hand-edit Markdown spec files.
**feature.yaml Status**: Already initialized by init script. No manual updates needed at this stage.
8. Next Steps
Inform the user:
> Spec created on `feat/NNN-feature-name`! > Next: `/shep-kit:research` to analyze technical approach.
Open Questions Policy
**CRITICAL:** Open questions in `spec.yaml` (the `openQuestions` array) MUST be resolved before `/shep-kit:research`.
- If questions are identified, add them to the `openQuestions` array in `spec.yaml`
- User must confirm answers or mark the array empty (`openQuestions: []`)
- Research phase will REFUSE to proceed if unresolved open questions exist in `spec.yaml`
Key Principles
- **Branch first**: All spec work happens on the feature branch
- **Infer, don't interrogate**: Analyze codebase to propose smart defaults
- **Dependencies from specs**: Scan existing `specs/*/spec.yaml` for relationships
- **User confirms**: Always get approval before writing files
- **Open questions block progress**: Never proceed with unresolved questions
Template Location
Templates are in: `.claude/skills/shep-kit-new-feature/templates/`
YAML Templates (Source of Truth)
- `spec.yaml` - Feature specification
- `research.yaml` - Technical decisions
- `plan.yaml` - Implementation strategy
- `tasks.yaml` - Task breakdown
Other Templates
- `data-model.md` - Domain models
- `feature.yaml` - Status tracking
feature.yaml Protocol
All shep-kit skills update `feature.yaml` as work progresses.
**Reference:** [docs/development/feature-yaml-protocol.md](../../../docs/development/feature-yaml-protocol.md)
**This skill's responsibility:**
- Create initial `feature.yaml` with:
- `lifecycle: "research"`
- `phase: "research"`
- Checkpoint: "feature-created"
Example
See: `.claude/skills/shep-kit-new-feature/examples/001-sample-feature/`
Read more
name: shep-kit:new-feature description: Use when starting any new feature, functionality, or enhancement. Triggers include "new feature", "start developing", "add functionality", "implement X", or explicit /shep-kit:new-feature invocation. Creates spec branch and scaffolds specification directory. 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
Create New Feature Specification
Start spec-driven development by creating a feature branch and specification directory.
**Full workflow guide:** [docs/development/spec-driven-workflow.md](../../../docs/development/spec-driven-workflow.md)
Phase Lifecycle
Requirements → Research → Planning → Implementation → Complete
↓ ↓ ↓ ↓ ↓
spec.yaml research.yaml plan.yaml tasks.yaml all files
↓ ↓ ↓ ↓ ↓
spec.md research.md plan.md tasks.md (auto-generated)**CRITICAL:** Each phase MUST update the `Phase` status field before proceeding.
**IMPORTANT:** Edit YAML files, not Markdown.
Workflow
1. Gather Minimal Input
Ask the user for:
- **Feature name** (kebab-case, e.g., `user-authentication`)
- **One-liner description** (brief summary)
2. Create Branch
# Determine next number
NEXT_NUM=$(ls -d specs/[0-9][0-9][0-9]-* 2>/dev/null | wc -l | xargs printf "%03d" $(($ + 1)))
# If no specs exist, use 001
[ -z "$NEXT_NUM" ] && NEXT_NUM="001"
# Create branch from main
git checkout main && git pull
git checkout -b "feat/${NEXT_NUM}-${FEATURE_NAME}"3. Run Init Script
Execute the scaffolding script:
.claude/skills/shep-kit-new-feature/scripts/init-feature.sh <NNN> <feature-name>
This creates `specs/NNN-feature-name/` with all template files using a **YAML-first** approach:
- **YAML source files**: `spec.yaml`, `research.yaml`, `plan.yaml`, `tasks.yaml` (source of truth)
- **Markdown files**: `spec.md`, `research.md`, `plan.md`, `tasks.md` (auto-generated from YAML)
- **Status tracking**: `feature.yaml` (implementation status, unchanged)
4. Analyze Context
Before filling the spec, analyze:
- **Existing specs**: Read `specs/*/spec.yaml` (or `specs/*/spec.md`) to understand feature landscape and discover dependencies
- **Codebase**: Identify affected areas, patterns, existing implementations
- **Cross-reference**: Infer dependencies, impact areas, size estimate
5. Propose Spec Content
Fill the template placeholders with inferred values:
- Problem statement (from user description + context)
- Success criteria (inferred from scope)
- Affected areas with impact levels (from codebase analysis)
- Dependencies on other features (from existing specs)
- Size estimate with reasoning (S/M/L/XL)
- Open questions (gaps identified during analysis)
Present the proposed spec to the user for review.
6. User Confirms/Adjusts
Allow the user to:
- Approve the proposed spec
- Modify any inferred values
- Add missing context or requirements
7. Write Spec & Update feature.yaml
# Write confirmed content to spec.yaml (the source of truth) # feature.yaml already created by init script with initial state: # - lifecycle: "research" # - phase: "research" # - checkpoint: "feature-created" # See: docs/development/feature-yaml-protocol.md for details # Stage and commit (both YAML source and generated Markdown) git add specs/NNN-feature-name/ git commit -m "feat(specs): add NNN-feature-name specification"
**IMPORTANT:** Always edit `spec.yaml`. Never hand-edit Markdown spec files.
**feature.yaml Status**: Already initialized by init script. No manual updates needed at this stage.
8. Next Steps
Inform the user:
> Spec created on `feat/NNN-feature-name`! > Next: `/shep-kit:research` to analyze technical approach.
Open Questions Policy
**CRITICAL:** Open questions in `spec.yaml` (the `openQuestions` array) MUST be resolved before `/shep-kit:research`.
- If questions are identified, add them to the `openQuestions` array in `spec.yaml`
- User must confirm answers or mark the array empty (`openQuestions: []`)
- Research phase will REFUSE to proceed if unresolved open questions exist in `spec.yaml`
Key Principles
- **Branch first**: All spec work happens on the feature branch
- **Infer, don't interrogate**: Analyze codebase to propose smart defaults
- **Dependencies from specs**: Scan existing `specs/*/spec.yaml` for relationships
- **User confirms**: Always get approval before writing files
- **Open questions block progress**: Never proceed with unresolved questions
Template Location
Templates are in: `.claude/skills/shep-kit-new-feature/templates/`
YAML Templates (Source of Truth)
- `spec.yaml` - Feature specification
- `research.yaml` - Technical decisions
- `plan.yaml` - Implementation strategy
- `tasks.yaml` - Task breakdown
Other Templates
- `data-model.md` - Domain models
- `feature.yaml` - Status tracking
feature.yaml Protocol
All shep-kit skills update `feature.yaml` as work progresses.
**Reference:** [docs/development/feature-yaml-protocol.md](../../../docs/development/feature-yaml-protocol.md)
**This skill's responsibility:**
- Create initial `feature.yaml` with:
- `lifecycle: "research"`
- `phase: "research"`
- Checkpoint: "feature-created"
Example
See: `.claude/skills/shep-kit-new-feature/examples/001-sample-feature/`
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

