smithery/SDiamante13

story-planner

Break an application or feature into thin vertical user-story slices with clear acceptance criteria and user-observable value. Use when planning a backlog, decomposing a feature, writing implementation-ready stories, or turning requirements into deliverable slices.

Installation

$ npx skills add smithery/SDiamante13 --skill story-planner

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/SDiamante13.

npx skills add smithery/SDiamante13

Browse all from smithery/SDiamante13

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,655 B
  • docs SUMMARY.md 95 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Story Planning Assistant

I'll help break your application into thin vertical slices—user stories that deliver end-to-end value with clear acceptance criteria.

Arguments: $ARGUMENTS - Feature area or planning context

Core Philosophy

Thin Vertical Slices:

  • Each story provides complete user-observable value
  • End-to-end functionality from user interaction to outcome
  • No crashes or incomplete-implementation errors
  • Cohesively complete—smallest possible change enabling user function

WHAT Not HOW:

  • Focus on user capabilities and outcomes
  • Remove ALL implementation details from stories
  • Express business outcomes, not code behavior
  • Example: "User sends message to conversation" NOT "SessionHandle<Ready>.send_message() stores MessageSent event"

Process

1. Context Discovery

First, I'll gather planning context:

Document Review:

  • Requirements documents (functional needs)
  • Event models or workflow diagrams (business processes)
  • Architecture decisions (technical constraints)
  • Style guides (UX patterns)

Pattern Analysis:

  • Existing user stories or issues
  • Natural feature boundaries
  • User workflows and interactions
  • Integration points

2. Story Extraction

I'll derive stories from your requirements:

Vertical Slice Identification:

  • Break features into implementable increments
  • Each slice delivers observable user value
  • Align with natural workflow boundaries
  • Consider integration points and user access

Story Format:

Title: [User-focused capability]
Description: WHAT this enables and WHY it matters

Acceptance Criteria (Gherkin):
Scenario: [User-focused scenario name]
  Given [initial user context]
  When [user action or event]
  Then [observable user outcome]

Integration: [How user accesses this feature]
Manual Testing: [Step-by-step verification instructions]

3. Acceptance Criteria Writing

I'll create clear Gherkin scenarios:

Given/When/Then Format:

  • Given: Initial user context (not technical state)
  • When: User action or business event
  • Then: Observable user outcome (not code behavior)

Examples:

✅ Good (User Experience):

Scenario: Developer sends message
  Given developer has started session
  When they send a message
  Then response appears in conversation history

❌ Bad (Implementation Details):

Scenario: Message storage
  Given SessionHandle<Ready> state
  When send_message() called
  Then MessageSent event stored in database

4. Quality Checks

Before finalizing each story:

  • ✓ Thin vertical slice providing observable user value?
  • ✓ Proper Gherkin Given/When/Then format?
  • ✓ Focus on user experience (WHAT/WHY not HOW)?
  • ✓ No implementation details in description or criteria?
  • ✓ Clear integration point and user access method?
  • ✓ Cohesively complete (no crashes or incomplete errors)?
  • ✓ Manual testing steps for user verification?

5. Prioritization

I'll help prioritize stories:

Priority Factors:

  • Business risk vs. value
  • User impact and urgency
  • Technical dependencies
  • Design dependencies

Output: Recommended priority order with rationale

Story Quality Principles

Integration Requirements:

  • Every story MUST specify how user accesses feature
  • Features must be accessible through main application entry point
  • Not just through tests—real user access path

Manual Testing:

  • Step-by-step user verification instructions
  • Observable outcomes user can confirm
  • No technical test commands or internal state checks

Documentation References: When applicable, link stories to:

  • Requirements they satisfy
  • Workflows they implement
  • Architecture decisions constraining them
  • Design patterns they follow

What I Won't Do

  • Include implementation details in stories
  • Write technical specifications instead of user stories
  • Create stories without clear user value
  • Add acceptance criteria about internal code behavior
  • Plan stories without understanding user workflows

Example Session

/story-planner user authentication

I'll analyze your authentication requirements and break them into thin vertical slices:

Story 1: User registers account
- Focus on registration flow user experience
- Acceptance criteria for successful registration
- Integration: accessible from main app login screen

Story 2: User logs in with credentials
- Focus on login flow user experience
- Acceptance criteria for successful login
- Integration: accessible from main app entry point

Story 3: User resets forgotten password
- Focus on password reset user experience
- Acceptance criteria for reset flow
- Integration: accessible from login screen

Each story is cohesively complete and provides end-to-end user value.

Safety Guarantees

I will:

  • Keep stories focused on user outcomes
  • Remove technical implementation details
  • Ensure each story provides complete user value
  • Write clear, testable acceptance criteria
  • Specify integration points for user access

I won't:

  • Include code structure or technical approach
  • Create stories without user-observable value
  • Write acceptance criteria about internal implementation
  • Add HOW when story should focus on WHAT/WHY

Let me help you break your application into well-defined, user-focused stories that deliver value incrementally.