agentic-coding-starter-kit/.claude/commands/create-feature.md

description

description
Create a new feature with requirements and implementation plan

Create Feature

This command creates a new feature specification folder with requirements and implementation plan documents.

Instructions

Given the above conversation:

1. Create feature folder

   • Store the requirements and implementation plan in /specs
   • Create a new subfolder for this feature using kebab-case (e.g., add-auth)

2. Create requirements.md

   • Document what the feature does and why
   • Include acceptance criteria
   • Reference any related features or dependencies

3. Create implementation-plan.md

   • Split the implementation into phases
   • Create actionable tasks for each phase
   • Each task should have a checkbox: [ ] Task description
   • Tasks should be specific enough for an agent to implement independently
   • Include dependencies between tasks where relevant
   • Mark complex tasks with [complex] suffix (these will get their own GitHub issue when published)

4. Create action-required.md

   • Extract all manual steps that require human action
   • Include tasks like: account creation, API key setup, environment variables, third-party service configuration, DNS settings, etc.
   • Each task has a checkbox and brief context (one-liner explaining why it's needed)
   • Keep these tasks in the implementation plan as well (for full context)
   • If no manual steps exist, create the file with a "None required" note

5. Exclude testing tasks

   • Do NOT include unit or e2e testing tasks
   • UNLESS the user explicitly asks for testing to be included

If no conversation exists:

Ask the user what the requirements are first, then create the spec subfolder with:

• requirements.md
• implementation-plan.md
• action-required.md

Implementation Plan Format

Use this structure for implementation-plan.md:

# Implementation Plan: {Feature Name}

## Overview

Brief summary of what will be built.

## Phase 1: {Phase Name}

{Brief description of this phase's goal}

### Tasks

- [ ] Task 1 description
- [ ] Task 2 description (depends on Task 1)
- [ ] Task 3 description [complex]
  - [ ] Sub-task 3a
  - [ ] Sub-task 3b

## Phase 2: {Phase Name}

{Brief description}

### Tasks

- [ ] Task 4 description (depends on Phase 1)
- [ ] Task 5 description
      ...

Note: Tasks marked with [complex] or containing nested sub-tasks will be created as separate GitHub issues when published (linked to their parent phase issue).

action-required.md Format

Use this structure for action-required.md:

# Action Required: {Feature Name}

Manual steps that must be completed by a human. These cannot be automated.

## Before Implementation

- [ ] **{Action}** - {Brief reason why this is needed}

## During Implementation

- [ ] **{Action}** - {Brief reason}

## After Implementation

- [ ] **{Action}** - {Brief reason}

---

> **Note:** These tasks are also listed in context within `implementation-plan.md`

When No Manual Steps Exist

If the feature has no manual steps, create the file with:

# Action Required: {Feature Name}

No manual steps required for this feature.

All tasks can be implemented automatically.

Next Steps

After creating the feature, inform the user:

Feature specification created at specs/{feature-name}/

Next steps:

1. Review action-required.md for tasks you need to complete manually
2. Review the requirements and implementation plan
3. Run /publish-to-github to create GitHub issues and project
4. Use /continue-feature to start implementing

Notes

• Keep tasks atomic - each should be implementable in a single session
• Tasks should produce working, testable code when complete
• Use clear, descriptive task names that explain what will be done
• Note dependencies explicitly when tasks must be done in order
• Common manual tasks: account creation, API key generation, environment variables, OAuth app configuration, DNS/domain setup, billing setup, third-party service registration

When to Use [complex]

Mark a task with [complex] when it:

• Has multiple sub-tasks that need individual tracking
• Requires significant architectural decisions or discussion
• Spans multiple files or systems
• Would benefit from its own GitHub issue for comments/review

Most tasks should NOT be marked complex - reserve this for genuinely substantial work items.