Skill: work-plan

Inline

Plan the implementation of a feature. Use when the user wants to plan, architect, define an approach, or before coding a complex feature.

Configuration

Property	Value
Context	inline
Pre-approved tools	None declared: the project's permission settings apply
Trigger	manual only — run /work-plan

Detailed description

Plan an Implementation

Objective

Define an action plan BEFORE coding. The plan must be validated before implementation.

Instructions

1. Understand the request

Questions to clarify:

• What is the business objective?
• What are the acceptance criteria?
• Are there any technical constraints?
• What is the priority/deadline?

2. Analyze the existing code

# Search for similar code
grep -rn "similar_pattern" --include="*.ts" | head -20

# Identify dependencies
cat package.json | grep -A 20 '"dependencies"'

3. Define the architecture

Decisions to make:

• Where to place the new code?
• Which patterns to use?
• Which interfaces to create?
• How to handle errors?

4. List the tasks

Break down into atomic tasks of 1-2h max.

Plan template

## Plan: [Feature name]

### Objective
[Description in 1-2 sentences]

### Files to create
| File | Description |
|---------|-------------|
| `src/xxx.ts` | [Role] |

### Files to modify
| File | Modifications |
|---------|---------------|
| `src/yyy.ts` | [Changes] |

### Tests to write
- [ ] Nominal case test
- [ ] Edge cases test
- [ ] Error test

### Implementation steps
1. [ ] [Task 1]
2. [ ] [Task 2]
3. [ ] [Task 3]

### Identified risks
| Risk | Mitigation |
|--------|------------|
| [Risk 1] | [Solution] |

### Dependencies
- [ ] [Prerequisite 1]

Rules

• NEVER code without a validated plan
• One plan = one feature
• Estimate complexity, not time
• Identify risks BEFORE

Manual invocation only

This skill carries disable-model-invocation: true, so Claude cannot load it — not when keywords match, and not from inside the same-named command either. Start it yourself with /work-plan.

Context inline

Inline means the skill runs in the conversation (the default, no context key):

• Sees the full history
• Its work is visible as it happens
• Right for almost every skill

---

Practical examples

1. Implementation planning example

Implementation planning example

Context

Add a real-time notification system to an application.

Product plan

Objective

Allow users to receive real-time notifications (new messages, mentions, system alerts).

Acceptance criteria

• Real-time push notifications
• Unread counter badge
• Notification history
• Mark as read/unread
• User preferences

Technical plan

Chosen architecture

┌─────────────┐     WebSocket      ┌─────────────┐
│   Client    │◄──────────────────►│   Server    │
│  (React)    │                    │  (Node.js)  │
└─────────────┘                    └──────┬──────┘
                                          │
                                   ┌──────▼──────┐
                                   │   Redis     │
                                   │  (Pub/Sub)  │
                                   └──────┬──────┘
                                          │
                                   ┌──────▼──────┐
                                   │ PostgreSQL  │
                                   │  (storage)  │
                                   └─────────────┘

Files to create

File	Description
src/services/websocket.ts	WebSocket client
src/hooks/useNotifications.ts	React hook
src/components/NotificationBell.tsx	UI component
src/components/NotificationList.tsx	Dropdown list
server/ws/notification-handler.ts	Server handler
prisma/migrations/xxx_notifications.sql	DB schema

Files to modify

File	Changes
src/app/layout.tsx	Add notifications provider
src/components/Header.tsx	Add NotificationBell
server/index.ts	Initialize WebSocket server

Implementation steps

1. Backend (day 1-2)

   • Create notifications table in Prisma
   • Implement WebSocket server with Socket.io
   • Configure Redis Pub/Sub
   • Create REST endpoints for history

2. Frontend (day 3-4)

   • Create useNotifications hook
   • Implement NotificationBell with badge
   • Create NotificationList with infinite scroll
   • Add animations (Framer Motion)

3. Integration (day 5)

   • Connect frontend/backend
   • E2E tests
   • Documentation

Identified risks

Risk	Probability	Impact	Mitigation
WebSocket disconnections	Medium	High	Auto-reconnect + offline queue
Redis overload	Low	High	Rate limiting + TTL
List performance	Medium	Medium	Virtualization + pagination

Dependencies to add

npm install socket.io socket.io-client ioredis

Plan validation

• Architecture validated with the team
• Estimates reviewed
• Risks accepted
• Ready for implementation

---

See also

• Back to skills
• Architecture