Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →backnotprop/plannotator-setup-goal
Turn an idea or objective into a goal package for /goal. Interviews the user, builds a reviewed fact sheet via Plannotator, then explores the codebase to produce an execution plan.
Passed 8 of 14 test cases with the skill, and 4 of 14 without it.
and 5 more in the full report
8 fixed4 passed either way8 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
Where must the facts review bundle JSON file be generated for a goal package with slug `email-templates`?
| Checked | Without skill | With skill |
|---|---|---|
| Specify the path goals/email-templates/facts-review.json | Missed | Passed |
The instructions your model reads when the skill loads.
Turn an idea into a goal package at goals/<slug>/ through structured discovery, user interview, and codebase exploration.
State back what the user wants in your own words. If the conversation already has rich context, summarize it. If the goal is bare or vague, do minimal shallow exploration of the codebase to ground your understanding. Keep it to 2-3 sentences. Wait for the user to confirm or correct before continuing.
Create the goal directory once the slug is clear:
mkdir -p goals/<slug>
Use goals/<slug>/ for both working JSON files and final docs. The JSON files are provenance and iteration state; the markdown files are the human-readable authoritative goal package.
Browser session patience rule: Plannotator goal setup is a user-driven browser session. After launching an interview or facts command, be absolutely patient and keep waiting on the user until they submit, dismiss, or explicitly ask you to stop. Do not close, kill, restart, refresh, or open a second copy just because the UI is idle or the user is taking time. Never close and reopen the session as a way to update state; if a rerun is needed after the prior session ends, update the working JSON file and launch a new command from that file.
Optional: grill first (deep, one-at-a-time interview). Before building the compact interview bundle, suggest a grilling pass whenever the goal is vague or carries many interdependent decisions — and run one whenever the user asks for it ("grill me first"). This is opt-in: for a clear, well-scoped goal, skip it and go straight to the bundle, so grilling never fights the bundle's "fewer, higher-leverage questions" philosophy. When you grill, run the protocol below verbatim, then fold the resolved decisions forward into a higher-quality interview bundle (Phase 2) — or, if grilling fully resolves scope, straight into the fact sheet (Phase 3).
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.
Build a compact bundle of questions that can derive every "fact" this goal should produce. Package the questions together so the user can answer them quickly in the Plannotator goal setup UI. For each question, include your recommended answer and use options when they make answering faster.
Do not ask obvious confirmation questions. If the answer can be inferred from the user's request, from the conversation, or from shallow codebase exploration, infer it and move on. If an obvious area has meaningful nuance, present the inferred answer as a recommendation with options or a custom "add/correct this" path rather than asking the user to restate the obvious.
Question areas that usually matter:
test cases passed, vs 4 / 14 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.