Turn a feature idea or request into a concrete, buildable plan — requirements, affected files, components, data needs, edge cases, and build order.
SkillScore68Maintained
Automatic
◆Coding pack
Last verified 8/3/2026
What it changes
Passed 15 of 22 test cases with the skill, and 9 of 22 without it.
Without skill41%
With skill68%
Checks it passed that the model alone missed
The plan explicitly lists functional requirements.
The plan includes explicit edge cases for file size limits.
The plan explicitly flags database schema changes as high-risk.
and 5 more in the full report
6 fixed9 passed either way7 still failing0 broke
Pass-rate lift
+27 pp
Tokens
+9%
Agent turns
0%
Response time
-25%
Model gemini-3.6-flashMeasured 8/3/2026v115 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
Our team wants to build an in-app notification center that handles real-time alerts, read/unread states, and filtering by category. This touches our backend routes, web sockets, frontend global state, and UI header components. Please draft a detailed feature development plan that breaks down affected files, lists potential edge cases, identifies risks, and sets up a logical staging order for the implementation.
What was checked, without and with the skill
Checked
Without skill
With skill
The plan includes a 1-2 sentence goal statement defining end-user capability.
Missed
Passed
The plan explicitly lists functional requirements.
Missed
Passed
The plan explicitly flags high-risk architectural areas for review.
Passed
Passed
case-03 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md63 linessingle file
Plan the Feature Skill
Purpose
Convert a feature request into a clear, ordered implementation plan so coding proceeds with minimal rework, conflicts, or missed edge cases.
When to Use
The request describes a feature, flow, or capability rather than a specific code edit.
The feature will touch multiple files, layers (UI, data, state), or screens.
The build order matters (e.g. data layer before UI, or types before components).
When Not to Use
The task is a small, single-file change with an obvious implementation.
A plan already exists (from a previous turn) and is still valid/unchanged.
Required Inputs
The feature request (clarified via the Clarify the Request Skill if needed).
Project context from the Understand the Project Skill (framework, structure, conventions).
Assumptions
The plan should follow existing project conventions and the default architecture rule of thumb only where no stronger convention exists.
The plan may be adjusted later via the Rethink or Reframe Skill if it proves too complex or wrong.
Step-by-Step Workflow
Restate the goal in one or two sentences: what should the user be able to do after this feature ships?
List requirements: functional requirements (what it must do) and constraints (performance, permissions, platforms).
Identify affected areas:
Screens/routes involved.
Components to create or extend.
Data/API needs (new endpoints, existing endpoints to reuse, new types).
State changes (local, shared, global, server/cache state).
Backend/database changes if any.
List edge cases: empty states, error states, permission/role differences, slow network, no data, max/min values, concurrent actions.
Map files: for each affected area, name the specific file(s) to create or modify, following existing structure (or the default rule of thumb if none exists).
Determine build order: typically types/data layer → state/hooks → components → page/screen assembly → polish (loading/error/empty states) → tests/validation. Adjust based on dependencies.
Flag risks: anything touching auth, schema, shared components used elsewhere, or config — note for the Risk Review Skill.
Confirm scope is appropriate: if the plan reveals the feature is much larger or more complex than expected, surface this before starting (see Rethink or Reframe Skill).
Rules and Best Practices
Keep the plan proportional — a 2-file feature doesn't need a 10-step plan.
Reuse existing components, services, and types before planning new ones.