菜单
Exploratory design discussion — generate and pressure-test architectural options for .NET problems before committing to a plan. Use when scope is unclear or multiple approaches exist.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Full-project health audit — spawns 5 specialists (dotnet-reviewer, security-analyzer, testing-reviewer, performance-profiler, deployment-validator) in parallel. Use for onboarding or pre-release.
Analyze project/namespace boundaries, detect circular refs and layering violations via dotnet-depends and solution graph. Use before major refactors or to validate Clean Architecture.
Senior-engineer challenge mode — aggressively question the current approach, hunt for N+1 queries, captive deps, missing auth, sync-over-async, leaks. Use before finalizing significant changes.
Capture a solved problem as institutional knowledge. Writes `.claude/solutions/{category}/{slug}.md` with symptoms, root cause, fix, category, tags. Use after notable fixes.
Generate or update documentation — XML doc comments, README, architecture docs, OpenAPI descriptions. Uses code as source of truth; no hallucinated features.
Extract durable lessons from a just-finished fix — propose CLAUDE.md rule, Iron Law addition, or Solution doc. Use after resolving a surprising/repeatable bug.
| name | brainstorm |
| description | Exploratory design discussion — generate and pressure-test architectural options for .NET problems before committing to a plan. Use when scope is unclear or multiple approaches exist. |
| argument-hint | <topic or problem> |
| effort | medium |
Interactive design exploration. Produces options, not a plan. Use
before /dotnet:plan when the problem space is ambiguous.
Use /dotnet:plan once you've picked a direction.
/dotnet:plan "implement option N"Each option is:
### Option N: <name>
**Approach**: one-paragraph description referencing actual .NET
primitives (not vague architecture words)
**Implementation sketch**:
```csharp
// 5-15 lines showing the key call sites
Pros:
Cons:
Iron Law considerations: any that are relevant
Complexity: S / M / L
## Example Topics
- "Authentication: cookie vs JWT vs both?"
- "Background work: Hangfire vs Quartz vs hosted BackgroundService?"
- "Real-time: SignalR vs SSE vs polling?"
- "Multi-tenancy: schema-per-tenant vs row-level vs separate DBs?"
- "Migration strategy: big-bang vs strangler vs parallel run?"
## Iron Laws
Options that would violate Iron Laws are flagged, not silently
discarded — sometimes the violation is an explicit trade-off the user
accepts. But the flag must be visible.
## Output
Inline Markdown; no file written. If the user says "let's do option
3", hand off to `/dotnet:plan`.
## Integration
/dotnet:brainstorm → pick direction → /dotnet:plan → /dotnet:work
## References
- `${CLAUDE_SKILL_DIR}/references/design-heuristics.md` — when to
prefer simple vs configurable, YAGNI vs future-proofing
- `${CLAUDE_SKILL_DIR}/references/tradeoff-matrix.md` — common .NET
trade-offs (performance vs maintainability, etc.)
- `${CLAUDE_SKILL_DIR}/references/stack-choices.md` — common
library/pattern decisions with opinionated defaults
## Anti-patterns
- Single option disguised as "brainstorm" — defeats the purpose
- 10 options with no recommendation — decision fatigue
- Pure abstractions without concrete .NET primitives — users cannot
evaluate
- Brainstorming trivial problems where the answer is obvious