菜单
Use after brainstorming to apply vanilla-rails patterns to a feature, producing structured handoff for implementation planning. Invoke with /shape.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when writing Rails controllers or implementing state changes - enforces resource extraction, thin controllers delegating to models, params.expect, and controller concerns for scoping
Use when designing database schema, writing migrations, or making data storage decisions - enforces UUIDs, account_id multi-tenancy, no foreign keys, and proper index patterns
Use when writing Hotwire (Turbo/Stimulus) code in Rails - enforces dom_id helpers, morph updates, focused Stimulus controllers, and JavaScript private methods
Use when writing background jobs or async operations - enforces thin job wrappers (3-5 lines) that delegate to models using _later/_now naming pattern
Use when writing Rails models - enforces state-as-records not booleans, concerns as adjectives namespaced under model, and concern extraction triggers
Use when naming classes, methods, routes in vanilla Rails codebases - enforces concern adjectives (-able/-ible only), no bangs for state, resource naming cascade, and commit message format
| name | shaping |
| description | Use after brainstorming to apply vanilla-rails patterns to a feature, producing structured handoff for implementation planning. Invoke with /shape. |
Position in workflow:
superpowers:brainstorming → explores what, clarifies requirements/shape (this) → applies patterns, defines right things to dosuperpowers:writing-plans → detailed implementation stepsWhen invoked, execute this workflow. Do not skip phases.
If brainstorming already happened, summarize:
If not, ask these questions before proceeding.
Check each vanilla-rails skill. For each, state whether it applies:
Always apply:
Apply if relevant:
Say: "These skills apply: [list]. Loading each to apply patterns."
For each applicable skill, invoke it and document the decision:
**data-modeling:** UUID primary key, account_id, state-as-records
**models:** State as records → `has_one :pin`, not `pinned: boolean`
**models:** Concern as adjective → `Card::Pinnable`
**controllers:** Resource extraction → `resource :pinning`
**naming:** Resource noun → `Pin` (create = pin, destroy = unpin)
Ask the user to confirm or adjust decisions.
Using work-breakdown patterns, propose PRs:
PR 1: "Add pinning to cards" (migration + model + concern + tests) - 4 files
PR 2: "Add UI for pinning cards" (controller + views + tests) - 4 files
PR 3: "Sort pinned cards first" (scope + view + tests) - 3 files
Check: Does any PR title have "and"? Split it.
Write to docs/shaping/YYYY-MM-DD-feature-name.md:
# [Feature] Shaping
## Scope
- Problem: [what problem this solves]
- In scope: [list]
- Out of scope: [list]
- Users: [who can use this]
## Pattern Decisions
[from Phase 3 - which skills applied and how]
## PRs
[from Phase 4 - ordered list of PRs with file counts]
## Open Questions
[any unresolved items]
Ask: "Ready to create implementation plan?"
If yes, invoke superpowers:writing-plans with the shaping document as context.
The writing-plans skill will create detailed, step-by-step implementation tasks for each PR.
| Skill | When to Apply |
|---|---|
| routing | Routes, nesting, namespaces |
| data-modeling | New tables, migrations, schema |
| delegated-types | 5+ types in unified timeline/feed |
| models | State tracking, concerns, associations |
| controllers | Endpoints, resources, state changes |
| views | ERB templates, partials, collection rendering |
| jobs | Background processing |
| hotwire | Dynamic UI, Turbo frames/streams |
| writing-affordances | 3+ related methods, prefix clusters |
| work-breakdown | Always (PR structure) |
| testing | Always |
| style | Always |
| naming | Always (new code) |
Remember: This is a command. Execute each phase in order. Do not skip to code.