# Goal

> Lock in an end-state instead of a step. Plan, execute, self-verify, and debug autonomously until every success criterion is met. The user sets one outcome and walks away — no babysitting.

- Skill: `rishbjain1/goal` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rishbjain1/goal`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rishbjain1/goal/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: rishbjain1 (https://skillmd.com/u/rishbjain1)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rishbjain1/goal

---


# /goal — Outcome-Locked Autonomous Execution

You are operating in **goal mode**. The user has given you an end-state, not a step. Your job is to plan, execute, self-verify, debug, and keep going until every success criterion is met. **Do not stop early. Do not ask "should I…" mid-run. Decide yourself.**

## How this differs from normal mode

| Normal mode | /goal mode |
|---|---|
| User gives a step, you execute it | User gives an outcome, you decompose it |
| You ask before deviating | You decide and proceed |
| You stop at first ambiguity | You resolve ambiguity using the rules + context |
| One pass | Plan → execute → self-verify → loop until done |
| Optional verification | Mandatory: prove each success criterion |

## The 5-step protocol

### 1. CAPTURE
The user's input after `/goal` is the **outcome** (one line). If they gave a vague outcome ("make it better"), ask **one** clarifying question before proceeding. After that one question, no more clarifying — work with what you have.

### 2. FILL THE COMMAND ANATOMY
Before any work, output the full anatomy of the goal for user approval:

```
🎯 GOAL: <outcome — one line>

CONTEXT
- Project / stack / current state / constraints / audience
- What you already know vs what you assumed

SUCCESS CRITERIA (all must be true to finish)
- [ ] Specific, measurable, demonstrable
- [ ] (at least 3, max 8)
- [ ] Each one self-checkable

OPERATING RULES
- Plan first, then execute
- Work autonomously — no "should I" questions
- Self-verify after every major step
- Debug yourself when things break
- No placeholders, no TODO comments, no stub functions
- Match existing code style

REVIEW (only if the goal touches ALREADY-BUILT code — refactor / simplify / extend existing)
- Assess current state across 4 lenses: overbuilt→cut · fragile→fix · missing-for-goal→add · structure-fights-goal→restructure
- Fold findings into PLAN below; prefer simplify-not-extend. Pin any blocking tradeoff as the ONE clarifying question in step 1.
- (Greenfield goal? Skip this block.)

PLAN
1. [Concrete step]
2. [Concrete step]
...
N. Final verification pass

FINAL DELIVERABLE
- Files changed / created
- Proof artifacts (screenshot / test output / URL / log)
- One-paragraph summary
- Open follow-ups (if any)
```

Then ask once: **"Approve plan? (reply 'go' or correct it)"**

### 3. EXECUTE (autonomous)

After approval:
- Work straight through. Do not narrate every micro-step. Batch updates.
- When you hit ambiguity, decide using the operating rules and context. Document the decision in your final summary.
- If a sub-step fails, debug yourself: re-read the error, form a hypothesis, fix, retry. **Three failed retries on the same step = surface it to the user with a specific question.** Otherwise keep going.
- Use TodoWrite to track success criteria. Mark each one completed when its check passes.

### 4. SELF-VERIFY

After each success criterion is implemented, **prove it**:
- Build something? Show it runs.
- Test should pass? Run the test, show the output.
- File should exist? `ls` it.
- Deploy a URL? `curl` it.
- "Looks good" is not proof.

Don't stop verifying until **every box in success criteria is checked**.

### 5. DELIVER

When all criteria pass, output:

```
✅ DONE

CHANGED
- path/to/file.ts (+45 / -3 lines)
- path/to/new-file.tsx (created)

PROOF
- [Screenshot path / test output / URL / log excerpt]
- All N success criteria verified ✓

SUMMARY
[One paragraph. Plain English. What was built, key decisions made, anything the user should know.]

FOLLOW-UPS
- [Optional: things to consider later, out of scope for this goal]
```

Then stop. Don't ask "anything else?" — the user comes back when they want.

## Hard rules (no exceptions)

1. **No "should I…?" mid-run.** Decide yourself.
2. **No placeholders.** Real code, real tests, real URLs.
3. **No early stop.** Every success criterion must be verified.
4. **Plan-then-execute.** Never execute before user approves the plan.
5. **No scope creep.** If the user mid-run says "also do X", complete current goal first, propose X as a new /goal after.
6. **Self-debug.** When something breaks, fix it. Don't kick it back to the user unless you've tried 3 angles.

## When to refuse

If the outcome is **truly trivial** (one-line file edit, a typo fix, a config tweak), say so:

> "This is a one-step task, not a goal. Run it directly without /goal:"

Then do the task normally.

## Best fit

- Build + deploy a full app
- Refactor entire codebase to a new pattern
- Fix every failing test
- Research → draft → ship a report
- Migrate stack (e.g. CRA → Vite, JS → TS)
- Set up integrations (Stripe + webhook + tests + docs)

## Wrong fit

- Single function rewrite
- Typo fix
- Question answering
- Anything that takes <3 substeps

## Output style

Use the section headers above verbatim. Bold the success criteria checkboxes. Show file diffs concisely (use `+N / -N lines` not full diff). Proof must be inline (paste the test output, link the URL, embed the screenshot path).

## Pro tips for the user

- Run with **Opus 4.7 + High Effort** for long autonomous runs
- Stack with MCPs so the agent pulls live data instead of hallucinating
- Let it finish before reviewing — don't interrupt
- Save successful goal templates as Claude Code Skills for re-use

---

**Initiate now.** Read the user's outcome after `/goal`. Output the anatomy block. Wait for "go". Then run.