菜单
Systematic feature planning workflow - use when starting complex features requiring structured approach
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Go concurrency mastery — goroutines, channels, context, sync primitives, patterns, performance.
Go microservices — gRPC, REST, cloud-native patterns, service discovery, circuit breakers, observability, health checks, graceful shutdown.
Effective Go patterns — idiomatic code, testing, benchmarks, project layout. Always use Go 1.21+ patterns.
Compose Multiplatform Architecture Framework - strict Screen/View/Component layering, use cases, repositories, and feature slice patterns
Decompose navigation and components - use for KMP component architecture, navigation, lifecycle, and state management
Procedural KMP feature generation workflow — step-by-step creation of feature slices with typed errors, compose-arch compliance, and build verification. Use when scaffolding a new feature module in a KMP/Compose Multiplatform project.
| name | systematic-planning |
| description | Systematic feature planning workflow - use when starting complex features requiring structured approach |
Transform complex feature requests into structured, executable plans.
Define what we're building and why:
## Feature: [Name]
### Problem Statement
[What problem does this solve?]
### Success Criteria
- [ ] [Measurable outcome 1]
- [ ] [Measurable outcome 2]
### Scope
**In Scope**: [what's included]
**Out of Scope**: [what's NOT included]
### Constraints
- [Technical constraints]
- [Business constraints]
How we'll build it:
## Technical Design
### Approach
[High-level approach in 2-3 sentences]
### Components
1. [Component 1] - [responsibility]
2. [Component 2] - [responsibility]
### Data Model
[Tables/entities needed]
### API Design
[Endpoints with methods]
### Dependencies
[External services/libraries needed]
Numbered steps for execution:
## Implementation Tasks
### S001: [First task]
- Files: [files to create/modify]
- Acceptance: [how to verify]
### S002: [Second task]
- Files: [files to create/modify]
- Acceptance: [how to verify]
[Continue with S003, S004, etc.]
Save planning documents to: .work-state/plans/[feature-name].md (ensure directory: mkdir -p .work-state/plans)
Backward compatibility: Previously plans were saved to
.claude/plans/. Check there if continuing work from an older session.
User: "Add user notification preferences"
Response:
# Feature: User Notification Preferences
## Phase 1: Business Spec
### Problem
Users cannot control which notifications they receive, leading to notification fatigue.
### Success Criteria
- [ ] Users can toggle email notifications
- [ ] Users can toggle in-app notifications
- [ ] Preferences persist across sessions
### Scope
**In**: Email, in-app notification toggles
**Out**: SMS, push notifications (future phase)
## Phase 2: Technical Design
### Approach
Add notification_preferences table linked to users, expose via REST API, update notification service to check preferences.
### Components
1. NotificationPreference entity
2. PreferenceService
3. PreferenceController
4. UI Settings panel
### API
GET/PUT /api/v1/users/{id}/notification-preferences
## Phase 3: Tasks
### S001: Database migration
- Files: V026__notification_preferences.sql
- Acceptance: Table exists with correct schema
### S002: Backend implementation
- Files: NotificationPreference.kt, PreferenceService.kt, PreferenceController.kt
- Acceptance: API returns/updates preferences
### S003: Frontend UI
- Files: settings/notifications.tsx
- Acceptance: User can toggle preferences