plugins/ideation/skills/get-goal-prompt/SKILL.md
Generate a /goal command to execute an ideation project's specs autonomously. Reads the contract, builds a goal prompt with phase ordering and spec paths, copies it to clipboard, and prints it. The user pastes the /goal command to start autonomous execution. Use when the user says 'goal', 'run as goal', 'get goal prompt', 'goal prompt', or wants to execute specs via /goal instead of /ideation:autopilot.
npx skillsauth add nicknisi/claude-plugins get-goal-promptInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Build a /goal command that will autonomously execute all specs in an ideation project, then copy it to the user's clipboard.
$ARGUMENTS, use it./docs/ideation/*/contract.mdRead contract.md and extract:
git log --oneline --grep="spec-phase" to find commits referencing spec files. Exclude completed phases from the goal.If no uncompleted phases remain, tell the user and stop.
Construct a /goal condition under 4000 characters. The condition serves as both the directive (what Claude should do) and the completion check (what the evaluator verifies).
Use this template, filling in the project-specific values:
/goal Execute all implementation specs for {project-name} in dependency order. For each phase, read the spec file, implement all changes following the spec's implementation details, run validation commands from the spec, and commit with a descriptive message referencing the spec.
Phases (execute in this order, respecting dependencies):
{numbered list of phases with spec paths and dependency notes}
How to execute each phase:
1. Read the spec file completely before starting
2. Follow the spec's "Implementation Details" section for what to build
3. Use the spec's "Feedback Strategy" inner-loop command after each component
4. Run all "Validation Commands" from the spec before committing
5. Commit only when all validations pass — message format: "feat({slug}): implement phase N — {title}"
Done when: git log shows a commit for every listed phase with passing validation. If a phase's validation fails after 3 attempts, stop and report which phase failed and why.
Phase list format — one line per phase:
1. {title} → {spec-path} (blocking)
2. {title} → {spec-path} (after phase 1)
3. {title} → {spec-path} (after phase 1, parallel with 2)
Omit completed phases from the list. If phases were skipped, note: "Phases {list} already committed — starting from phase {N}."
Keep it under 4000 characters. If the phase list is long, abbreviate notes. The spec files contain all the detail — the goal prompt just needs ordering and paths.
Copy the full /goal command to clipboard:
echo '<goal command>' | pbcopy # macOS
On Linux, try xclip -selection clipboard or xsel --clipboard.
Print the command to screen so the user can see what they're about to run:
Copied to clipboard. Paste to start:
/goal Execute all implementation specs for ...
Remind the user: "Make sure auto mode is enabled so tool calls don't block each turn. Run /auto first if needed."
That's it. The skill's job is done once the command is on the clipboard. /goal handles the rest.
testing
Socratic tutor that drills the user until they deeply understand a change — the problem, the solution, the design decisions, the edge cases, and what it impacts. Use after completing or reviewing work (a diff, PR, or session) when the user wants to truly own it, not just skim it — or when the user says /socratic-tutor, "teach me what we just did", "quiz me on this", "walk me through this change", or "make sure I understand this". Restates-first, quizzes, and does not stop until the user demonstrates mastery.
development
Go up a layer of abstraction and map the surrounding architecture. Use when the user is unfamiliar with an area of code, asks "how does this fit in", "what calls this", "give me the big picture", "where am I", "map this out", "I'm lost", "explain this area", or needs to understand how a file, module, or function connects to the rest of the system. Also use when the user says /zoom-out or "zoom out" mid-conversation — even without a specific file reference, orient them based on whatever code is currently in context.
development
Build a throwaway prototype to answer a design question before committing to real implementation. Generates either a runnable terminal app (for state machines, data models, business logic) or several radically different UI variations on one route (for visual/layout decisions). Use when the user wants to prototype, spike, POC, sanity-check a data model, mock up a UI, explore design options, or says "prototype this", "spike this out", "let me play with it", "try a few designs", "sketch this in code", "I want to try something before building it for real", "quick and dirty version", or "validate this approach" — even if they don't use the word "prototype."
development
Comprehensive, codebase-wide quality sweep that dispatches parallel subagents to find and fix structural issues. Covers deduplication, type consolidation, dead code removal, circular dependencies, weak types, defensive try/catch, deprecated paths, and AI slop. Primary support for JS/TS projects (knip, madge, TypeScript types); other languages get grep-based analysis. Use when the user asks to "deep clean the whole repo", "run a full codebase audit", "nuclear cleanup", "deslop everything", or "sweep the entire codebase for quality issues". Do NOT use for single-file fixes, branch-scoped diffs (use de-slopify instead), or targeted refactors.