// Use when you have a written implementation plan to execute in a separate session with review checkpoints
Build interface design with craft and consistency. Use for dashboards, admin panels, SaaS apps, tools, settings pages, and data interfaces. NOT for landing pages or marketing sites.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for submitting diffs or cleanup
Quiz engineers on AI-generated code to deepen understanding. Uses adaptive difficulty and Socratic teaching to build debugging skills. Use after writing code when the user says "grill me", "challenge me", "quiz me on these changes", or wants to verify they understand what was generated.
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
| name | executing-plans |
| description | Use when you have a written implementation plan to execute in a separate session with review checkpoints |
Load plan, review critically, execute tasks in batches, report for review between batches.
Core principle: Batch execution with checkpoints for architect review.
Announce at start: "I'm using the executing-plans skill to implement this plan."
Default: First 3 tasks
For each task:
When batch complete:
Based on feedback:
After all tasks complete and verified:
STOP executing immediately when:
Ask for clarification rather than guessing.
Return to Review (Step 1) when:
Don't force through blockers - stop and ask.