القائمة
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.