Claude Skill

goal-prompt

Turn a task, plan, or feature request into a ready-to-paste Claude Code /goal command — a single completion condition with a measurable end state, a demonstrable proof, and the constraints that must not drift. Use when the user says "give me a goal", "goal prompt", "make this a /

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download techwolf-ai-ai-first-toolkit-plugins_session-tools_skills_goal-prompt-2ee7841.zip · 1 KB

techwolf-ai/ai-first-toolkit 129 5 forks MIT Updated 2d ago

Part of techwolf-ai/ai-first-toolkit — 20 skills

Install

skills CLI npx skills add https://github.com/techwolf-ai/ai-first-toolkit/tree/main/plugins/session-tools/skills/goal-prompt

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install techwolf-ai-ai-first-toolkit@llmmart

Git git clone https://github.com/techwolf-ai/ai-first-toolkit.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole techwolf-ai/ai-first-toolkit collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

goal-prompt

Produce a ready-to-paste /goal ... command from whatever the user is trying to accomplish.

Why the shape matters

/goal runs Claude autonomously until a separate fast-model evaluator decides, after a turn, that the condition is met. The evaluator does NOT run commands or read files itself — it only reads Claude's output. So the completion condition must be demonstrable by Claude's own output, never by hidden side effects.

A good goal has three parts

Measurable end state — one concrete finish line: a test/exit code, a file that must exist, a count, an empty queue, named sections present.
Stated proof — exactly how Claude demonstrates it: the command to run and its expected result, or the grep/check whose output shows done. Phrase it as "Prove it by showing X."
Constraints that must not drift — what stays unchanged on the way there: files not to touch, framing to keep, no network/prod, don't modify tests.

How to write it

One sentence of objective, then Done when: <end state + proof>, then Constraints that must not change: <list>.
If the full spec is long, point to a plan/doc file (e.g. a path under ~/.claude/plans/ or docs/) and keep the goal itself scannable.
Make the proof something the transcript can show: prefer command exits 0 + a summary line, or grep for markers, over vague "it works".
Translate conditions the evaluator can't see ("the UI looks good") into an observable check.
Keep constraints tight enough to stop scope creep, not so rigid they block the obvious path.

Output

Give the user a single fenced block starting with /goal, then 2-3 lines explaining the end state, the proof, and why it's demonstrable. Nothing else.

Example

/goal Add a --json flag to the export CLI per docs/export-json.md. Done when: `pytest tests/test_export.py -q` exits 0 and `python -m app.export --json` prints valid JSON whose top-level keys include "rows" and "meta". Prove it by showing the pytest summary and the piped `... --json | jq keys` output. Constraints that must not change: only edit app/export.py and add tests/test_export.py; do not alter the existing CSV output path; no network.

Its finish line is a passing test plus a schema check, both visible in Claude's transcript; the constraints pin the blast radius so the autonomous run can't wander.

Files (ai-first-toolkit)

SKILL.md 2.7 KB

---
name: goal-prompt
description: Turn a task, plan, or feature request into a ready-to-paste Claude Code /goal command — a single completion condition with a measurable end state, a demonstrable proof, and the constraints that must not drift. Use when the user says "give me a goal", "goal prompt", "make this a /goal", "turn this into a goal", or wants an autonomous long-running objective for Claude Code.
---

# goal-prompt

Produce a ready-to-paste `/goal ...` command from whatever the user is trying to accomplish.

## Why the shape matters
`/goal` runs Claude autonomously until a separate fast-model evaluator decides, after a turn, that the condition is met. The evaluator does NOT run commands or read files itself — it only reads Claude's output. So the completion condition must be demonstrable by Claude's own output, never by hidden side effects.

## A good goal has three parts
1. **Measurable end state** — one concrete finish line: a test/exit code, a file that must exist, a count, an empty queue, named sections present.
2. **Stated proof** — exactly how Claude demonstrates it: the command to run and its expected result, or the grep/check whose output shows done. Phrase it as "Prove it by showing X."
3. **Constraints that must not drift** — what stays unchanged on the way there: files not to touch, framing to keep, no network/prod, don't modify tests.

## How to write it
- One sentence of objective, then `Done when: <end state + proof>`, then `Constraints that must not change: <list>`.
- If the full spec is long, point to a plan/doc file (e.g. a path under `~/.claude/plans/` or `docs/`) and keep the goal itself scannable.
- Make the proof something the transcript can show: prefer `command exits 0` + a summary line, or `grep` for markers, over vague "it works".
- Translate conditions the evaluator can't see ("the UI looks good") into an observable check.
- Keep constraints tight enough to stop scope creep, not so rigid they block the obvious path.

## Output
Give the user a single fenced block starting with `/goal`, then 2-3 lines explaining the end state, the proof, and why it's demonstrable. Nothing else.

## Example
```
/goal Add a --json flag to the export CLI per docs/export-json.md. Done when: `pytest tests/test_export.py -q` exits 0 and `python -m app.export --json` prints valid JSON whose top-level keys include "rows" and "meta". Prove it by showing the pytest summary and the piped `... --json | jq keys` output. Constraints that must not change: only edit app/export.py and add tests/test_export.py; do not alter the existing CSV output path; no network.
```
Its finish line is a passing test plus a schema check, both visible in Claude's transcript; the constraints pin the blast radius so the autonomous run can't wander.