菜单
Create detailed design documents for specific features before implementation. Use when planning a significant feature, migration, or architectural change that needs options analysis and implementation phases. Edit sections in place as design evolves.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run the GitHub issue triage tool for Redux repos. This skill should be used when triaging GitHub issues, generating triage reports, or understanding triage output for redux-toolkit, react-redux, reselect, redux, or immer repositories.
Create architecture review documents to understand and document existing codebases. Use when onboarding to an unfamiliar codebase, conducting architecture audits, or creating reference documentation for team members.
Document coding conventions, patterns, and guidelines for an existing codebase. Use when onboarding to a new project to understand its coding style, or when creating style documentation for team reference.
Design patterns for data-dense dashboard UIs with dark themes. Use when building tables, charts, status panels, and data visualization components. Focuses on readability, information density, and consistent design systems.
Create detailed development plans with task lists and progress tracking for major projects. Use for multi-phase work requiring detailed task breakdown, progress tracking, and living documentation of decisions and learnings.
Manage tasks via dex CLI. Use when breaking down complex work, tracking implementation items, or persisting context across sessions.
| name | feature-design |
| description | Create detailed design documents for specific features before implementation. Use when planning a significant feature, migration, or architectural change that needs options analysis and implementation phases. Edit sections in place as design evolves. |
Create detailed design documents for features, migrations, or architectural changes that require upfront planning.
Don't use for:
project-overview skill)development-plan skill)Feature designs typically live alongside the development plan:
dev-plans/
└── {project}/
├── features/
│ ├── 2025-12-29-user-auth-redesign.md
│ └── 2025-12-15-api-migration.md
└── current-focus.md
Naming: YYYY-MM-DD-feature-name.md
# Design: [Feature Name]
**Status:** [Draft / In Review / Approved / Superseded]
**Created:** [Date]
**Updated:** [Date if modified]
---
Status notes:
One paragraph (3-5 sentences) describing:
## Executive Summary
[Concise description of the feature, the problem it solves, and the high-level approach. Reader should understand the "what" and "why" after this paragraph.]
Describe what exists today and why it's insufficient.
## Current State
### How It Works Today
[Describe the current implementation, data flow, or architecture]
### Problems
- [Problem 1 - be specific about the pain point]
- [Problem 2]
- [Problem 3]
### Why Change Now?
[What triggered this work? New requirements, tech debt, performance issues?]
Include when helpful:
Evaluate different approaches. Required when multiple viable options exist.
## Options Analysis
### Option A: [Name]
**Description:** [How this approach works]
**Pros:**
- [Advantage 1]
- [Advantage 2]
**Cons:**
- [Disadvantage 1]
- [Disadvantage 2]
**Effort:** [Rough estimate - hours/days/weeks]
### Option B: [Name]
[Same structure]
### Option C: [Name]
[Same structure]
### Comparison
| Criteria | Option A | Option B | Option C |
|----------|----------|----------|----------|
| Complexity | Low | Medium | High |
| Risk | Medium | Low | Low |
| Future flexibility | Limited | Good | Best |
| Effort | 2 days | 1 week | 2 weeks |
Guidelines:
State your recommendation clearly with rationale.
## Recommended Approach
**Recommendation:** Option B - [Name]
### Rationale
[2-3 paragraphs explaining why this option is best. Reference the comparison criteria. Acknowledge what you're giving up by not choosing alternatives.]
### Key Trade-offs Accepted
- [Trade-off 1 - what you're accepting by choosing this approach]
- [Trade-off 2]
The meat of the document. Structure depends on what you're designing.
## Technical Design
### Architecture Overview
[High-level description of the design. Include a diagram if helpful.]
### Data Flow
[Describe how data moves through the system]
[ASCII diagram or mermaid flowchart]
### Interface Definitions
[Key interfaces, types, or contracts]
```typescript
interface FooService {
doThing(input: Input): Promise<Output>;
}
Responsibility: [What it does]
Location: path/to/file.ts
[Implementation details]
[Same structure]
[How this connects to existing systems]
**Include what's relevant:**
- Directory structure for new code
- Database schema changes
- API endpoints
- State management approach
- Error handling strategy
### Implementation Phases
Break down the work into phases with rough estimates.
```markdown
## Implementation Phases
### Phase 1: [Name] ([Estimate])
**Goal:** [What this phase accomplishes]
**Tasks:**
- [ ] [Task 1]
- [ ] [Task 2]
- [ ] [Task 3]
**Deliverable:** [What's working at the end of this phase]
### Phase 2: [Name] ([Estimate])
**Goal:** [Goal]
**Tasks:**
- [ ] [Tasks]
**Deliverable:** [Deliverable]
### Phase 3: [Name] ([Estimate])
[Same structure]
Guidelines:
Capture unresolved decisions or unknowns.
## Open Questions
### Technical
- [ ] [Question 1] - [Context or options being considered]
- [ ] [Question 2]
### Product/Requirements
- [ ] [Question about requirements or scope]
### Dependencies
- [ ] [External dependency or blocker]
Update: Check off questions as they're answered. Add the answer inline or in relevant sections.
Edit in place as the design evolves. Don't preserve outdated information in the main sections.
When to add an Addendum:
## Addendum: [Title] ([Date])
[Content explaining the update, what changed, why]
Always include:
Include when relevant:
Rarely needed: