| name | project-spec-generator |
| description | Use when the user wants to design a practice/dummy development project calibrated to their learning goals and current skill level. Produces a detailed spec (objectives, stack, requirements, milestones, stretch goals) without writing any code. |
Project Spec Generator
Design a practice development project — a throwaway build whose purpose is to exercise specific skills, not ship a product.
When to use this skill
- The user says they want to "practice X" or "get better at Y" and asks for a project idea.
- The user wants a take-home-style exercise to work through a tech stack.
- The user is learning a new language/framework and wants a scoped build.
Do not use this skill to design a real product, a portfolio piece intended for public release, or a production system. For those, the scope-shaping priorities are different.
Inputs
Elicit (in one message, not a drip):
- Learning objectives — what they want to practice.
- Tech stack — languages, frameworks, tools.
- Proficiency per item — graded (1–5, beginner/intermediate/advanced) or described.
- Constraints — time budget, form factor, offline-only, no paid APIs, etc.
- Domain preference — optional flavour (finance, games, home-automation…).
Calibration rules
- Difficulty floor = the user's weakest stated skill.
- Scope ceiling = user's stated time budget, or ~4–20 hours if unspecified.
- Every stated learning objective must be exercised meaningfully — not just name-dropped. If an objective can't be worked in, say so and propose dropping it or swapping the project.
- Prefer projects with a crisp "done" state over open-ended explorations.
- Avoid paid APIs, proprietary SDKs, or heavy cloud setup unless the user opted in.
Output structure
Single markdown doc:
- Title + one-line pitch
- Learning objectives (each mapped to how the project exercises it)
- Tech stack (each item with its role)
- Functional requirements
- Non-functional requirements
- Suggested architecture (short — modules, data flow, key abstractions)
- Milestones with exit criteria
- Stretch goals
- "Things to deliberately struggle with" — named hard parts tied to the user's weak spots
- Out of scope
Style
- Name the project memorably ("Ledger-Lite", "Packet-Pigeon") — not "Finance App".
- Be specific. "Implement a retry policy with jittered exponential backoff" beats "handle errors".
- Call out the learning moments explicitly — where the user will likely get stuck, and why that's the point.
- Do not generate implementation code. Spec only.
Saving
Offer to write the spec to ./project-specs/<kebab-case-name>.md. Confirm path before writing. Don't write unprompted.
