agents/skills/plannotator-setup-goal/SKILL.md
Create reviewed Codex goal setup packages for long-running /goal work. Use when the user wants to turn an idea, backlog, project mission, or vague objective into durable goal files under a project goals slug folder, with Plannotator review gates for brief, narrative plan with acceptance criteria, verification, blockers, and the final /goal prompt.
npx skillsauth add drn/dots plannotator-setup-goalInstall 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.
Create a durable goal package in the current project at goals/<slug>/ so Codex /goal has a clear mission, guardrails, proof of done, and external memory. Use Plannotator as the user review UI: every critical document must be gated with plannotator annotate <document.md> --gate and revised until approved.
Confirm the working directory is the project root, or use the user-provided project directory.
Gather enough context to name the goal, define the intended outcome, identify constraints, find likely project docs, and determine proof of done.
Ask focused questions whenever the goal is vague, risky, too broad, missing a finish line, or missing verification. Do not proceed with guessed critical requirements.
Create a slug from the goal name and scaffold goals/<slug>/ with:
python3 <skill_dir>/scripts/scaffold_goal.py --root . --slug <slug> --title "<goal title>" --objective "<one sentence outcome>"
Draft and refine the critical documents in this order:
brief.mdplan.mdverification.mdblockers.mdgoal-prompt.mdGate each critical document with Plannotator before moving on:
plannotator annotate goals/<slug>/<document.md> --gate
If Plannotator returns denial, comments, or markup, treat that as user feedback. Revise the document, then run the same gate again. Continue until approved.
After all gates pass, present the final path and the exact /goal prompt from goal-prompt.md.
brief.md must state the mission, context, constraints, non-goals, ask-before rules, and concise done condition.
plan.md is the central reviewed planning artifact. It must read like a clear solution narrative, not just a technical checklist. Include what is being built, why this approach is appropriate, how the solution will work, the main implementation slices, risks, phase boundaries, and acceptance criteria. Every important acceptance item needs observable evidence. For large missions, prefer several sequential goals over one endless goal.
verification.md must list exact verification commands and manual checks. Include expected pass conditions and where evidence should be recorded.
blockers.md must capture open questions, user-decision points, dangerous operations that require approval, and conditions that should pause the goal.
goal-prompt.md must contain the final command the user can paste into Codex. It should reference the goal package files as the durable source of truth, tell Codex to append evidence to progress.jsonl, and define when to stop or ask.
progress.jsonl is append-only evidence. Do not gate it. During execution, append concrete progress and proof, not summaries of intent.
Use Plannotator as the review surface, not as a passive preview. The command plannotator annotate <document.md> --gate presents the document to the user and captures approval or denial feedback.
Do not skip gates for critical documents. Do not mark a document ready because it seems reasonable. The user must approve it through the gate.
If a document is denied, update the document from the captured feedback and rerun the gate. Keep the loop tight: one document, one review, one revision cycle.
Write the final /goal prompt as a compact product brief, not a raw todo dump.
Include:
goals/<slug>/ as the durable plan and append evidence to progress.jsonlAvoid:
Before finalizing, verify:
/goal prompt tells Codex where the goal files live.development
Walk every unresolved review thread on a PR, triage each one, reply with a rationale of whether or not the comment will be acted upon, make the code change if warranted, and mark the thread resolved. Use when the user asks to address only the open PR comments without re-running CI, respond to review feedback, resolve review threads, or clear bot comments on a PR.
tools
Iteratively run /rereview, fix the findings, and loop until reviewers approve clean. Use for iterative automated review, when you want /rereview to loop until clean, or for a paranoid pre-merge review that auto-addresses every blocker.
development
Generate self-contained HTML visualizations with Plannotator theming. Use for implementation plans, PR explainers, architecture diagrams, data tables, slide decks, and any visual explanation of technical concepts. Plans and PR explainers follow Plannotator's prescriptive approach; all other visual content delegates to nicobailon/visual-explainer.
development
Open Plannotator's browser-based code review UI for the current worktree or a pull request URL, then act on the feedback that comes back.