AgentSkillsCN

Feature Planner

功能规划师

SKILL.md

Feature Planner

Goal: Break down a feature description into phases and actionable tasks with dependencies and estimates; optionally create GitHub issues.

Description

Breaks down feature requests into actionable tasks with dependencies, estimates, and GitHub issue creation.

Usage

  • •"Break down the [feature] into tasks"
  • •"Create a plan for [feature]"
  • •"What tasks are needed for [feature]"
  • •"Plan the implementation of [feature]"

When to Use

Use this skill when you need to:

  • •Transform a high-level feature request into concrete tasks
  • •Identify dependencies between tasks
  • •Estimate complexity and effort
  • •Create a structured implementation plan
  • •Generate GitHub issues for tracking

When run by pipeline you receive only the feature description (no prior spec); still produce phases and tasks from that single description.

Pipeline Contract (sdlc-full.lobster)

Inputs (from pipeline or user; current sdlc-full passes only description):

  • •description (string): The feature description. The pipeline does not pass a prior spec from another step; use this as the sole feature input.
  • •create_github_issues (boolean, optional): If true and gh is available, create GitHub issues. Wrapper passes --create-issues when requested.

Output: Produce the full markdown plan (see Output Format below). When invoked by pipeline, also output a JSON object with keys: breakdown (array of { title, phase, depends_on, estimate }) and github_issues (array of issue URLs, or [] if none created or gh unavailable). This allows a future wrapper or pipeline to parse the result.

Implementation

Execute in order. Do not run the Lobster tool or any pipeline. Use read_file to inspect workspace when relevant (e.g. existing services, package structure). Use bash only when creating issues (gh CLI).

Step 1: Analyze Feature Request

  • •Parse the feature from the user message or the single description provided; do not expect a prior spec from another step.
  • •Identify affected components: scan workspace with list_dir/read_file for src/, services/, packages/, or similar; infer frontend/backend/database from structure.
  • •Determine scope and boundaries; list assumptions and constraints in one short paragraph.

Step 2: Break Into Phases

  • •Phase 1: Planning – Specs, design docs, API contracts (estimate hours).
  • •Phase 2: Implementation – Core functionality, integrations (estimate hours).
  • •Phase 3: Testing – Unit tests, integration tests, E2E tests (estimate hours).
  • •Phase 4: Deployment – Config changes, migrations, rollout (estimate hours).

Step 3: Generate Task List

For each phase:

  • •Create specific, actionable tasks (each < 4 hour chunks).
  • •For each task: title, phase, depends_on (list of task titles or "none"), estimate (S/M/L or hours).
  • •Add one-line acceptance criteria per task where helpful.
  • •If pipeline expects structured output: build a list breakdown of objects { title, phase, depends_on, estimate } and a list github_issues of URLs (or empty array).

Step 4: Create GitHub Issues (Optional)

  • •Only if create_github_issues is true and user/pipeline requested it. Check for gh with which gh or run gh auth status; if not available, skip and set github_issues = [] and say so in one line (e.g. "GitHub issues skipped: gh not available or not authenticated").
  • •For each task (or top-level tasks only to avoid clutter): run gh issue create --title "..." --body "..." --label "feature" (add labels like backend/frontend from task phase/component).
  • •Collect issue URLs from command output and set github_issues to that list. When by pipeline, after the markdown plan output a JSON block with breakdown and github_issues.

Output Format

markdown
# Feature: [Feature Name]

## Overview
[Brief description of what this feature accomplishes]

## Affected Components
- Component 1 (changes required)
- Component 2 (new functionality)

## Implementation Plan

### Phase 1: Planning (Estimated: X hours)
- [ ] Task 1: Write API spec for endpoint (depends on: none)
- [ ] Task 2: Design database schema (depends on: Task 1)
- [ ] Task 3: Create feature spec document (depends on: Task 1, Task 2)

### Phase 2: Implementation (Estimated: Y hours)
- [ ] Task 4: Implement backend endpoint (depends on: Task 3)
- [ ] Task 5: Add frontend UI components (depends on: Task 3)
- [ ] Task 6: Integrate with existing auth flow (depends on: Task 4)

### Phase 3: Testing (Estimated: Z hours)
- [ ] Task 7: Write unit tests (depends on: Task 4, Task 5)
- [ ] Task 8: Add integration tests (depends on: Task 6)
- [ ] Task 9: Manual E2E testing (depends on: Task 7, Task 8)

### Phase 4: Deployment (Estimated: A hours)
- [ ] Task 10: Create database migration (depends on: Task 9)
- [ ] Task 11: Update deployment config (depends on: Task 9)
- [ ] Task 12: Deploy to staging (depends on: Task 10, Task 11)
- [ ] Task 13: Deploy to production (depends on: Task 12)

## GitHub Issues
[Links to created issues if applicable]

## Risks & Considerations
- Risk 1: [Description and mitigation]
- Risk 2: [Description and mitigation]

## Total Estimated Time: X hours

Example Usage

User: "Break down the authentication refactor into tasks"

Feature Planner: [Analyzes current auth system, identifies components]

Output:

code
# Feature: Authentication Refactor

## Overview
Migrate from session-based auth to JWT tokens for better scalability and mobile support.

## Affected Components
- auth_service (major changes)
- api_gateway (middleware update)
- frontend (token storage)
- database (new refresh_tokens table)

## Implementation Plan

### Phase 1: Planning (Estimated: 8 hours)
- [ ] Design JWT token structure and claims
- [ ] Plan refresh token rotation strategy
- [ ] Document new auth flow diagrams
- [ ] Review security implications

### Phase 2: Implementation (Estimated: 16 hours)
- [ ] Add JWT library to auth_service
- [ ] Implement token generation/validation
- [ ] Create refresh token endpoint
- [ ] Update API Gateway middleware
- [ ] Migrate frontend to use tokens
- [ ] Create database migration for refresh_tokens

[... continued ...]

Notes

  • •Always ask clarifying questions if feature scope is unclear
  • •Default to breaking tasks into < 4 hour chunks
  • •Flag tasks that might need external dependencies or approvals
  • •Consider backwards compatibility when planning changes