make-a-goal
Produce a fully-filled autonomous-run mega-prompt at .agents/goals/<slug>.md by interviewing the user for the missing context. The output file is the "set the goal · walk away · come back to shipped work" prompt — drop it into a fresh Claude Code / Codex session to run end-to-end without hand- holding. Use when Stevie says "/make-a-goal", "/make-a-goal <outcome>", "make a goal", "set a goal", "build me a goal prompt", or similar. The skill does NOT execute the goal — it only produces the artifact. Named `make-a-goal` (not `goal`) because `/goal` is a reserved system slash.
Best use case
make-a-goal is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Produce a fully-filled autonomous-run mega-prompt at .agents/goals/<slug>.md by interviewing the user for the missing context. The output file is the "set the goal · walk away · come back to shipped work" prompt — drop it into a fresh Claude Code / Codex session to run end-to-end without hand- holding. Use when Stevie says "/make-a-goal", "/make-a-goal <outcome>", "make a goal", "set a goal", "build me a goal prompt", or similar. The skill does NOT execute the goal — it only produces the artifact. Named `make-a-goal` (not `goal`) because `/goal` is a reserved system slash.
Teams using make-a-goal should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/make-a-goal/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How make-a-goal Compares
| Feature / Agent | make-a-goal | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Produce a fully-filled autonomous-run mega-prompt at .agents/goals/<slug>.md by interviewing the user for the missing context. The output file is the "set the goal · walk away · come back to shipped work" prompt — drop it into a fresh Claude Code / Codex session to run end-to-end without hand- holding. Use when Stevie says "/make-a-goal", "/make-a-goal <outcome>", "make a goal", "set a goal", "build me a goal prompt", or similar. The skill does NOT execute the goal — it only produces the artifact. Named `make-a-goal` (not `goal`) because `/goal` is a reserved system slash.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
# /make-a-goal — autonomous-run mega-prompt builder
## What it does
`/make-a-goal [outcome line]` interviews Stevie for the operating context
an autonomous coding agent needs, then writes a filled mega-prompt to
`.agents/goals/<slug>.md`. Stevie runs the goal by pasting the file
contents into a fresh session — this skill never executes the run.
The mega-prompt template lives at `assets/mega-prompt.md.tmpl`. The stub
plan handed to `/interview` lives at `assets/stub-plan.md.tmpl`.
## Trigger
- `/make-a-goal` — no args, interview asks for the outcome line too
- `/make-a-goal <outcome>` — outcome line pre-fills `{{OUTCOME}}`,
interview gathers the rest
- Natural language: "make a goal", "set a goal", "build me a goal prompt"
## Flow
### 1. Capture the outcome line
If `$ARGUMENTS` is non-empty, treat it as the final-outcome line and
slugify it. Else, use `AskUserQuestion` with a single open question:
"What does done look like — in one line?"
The outcome line is the most important field. Push back on vague answers
("ship the app") and demand specificity ("deploy v1 of the dashboard at
dashboard.example.com with login + 3 charts working"). One sentence,
present-tense, observable.
### 2. Generate slug + paths
- Slug: kebab-case the outcome line, strip stopwords, truncate to 50
chars. Example: "deploy v1 of the dashboard with login" →
`deploy-v1-dashboard-with-login`.
- Plan path: `.agents/goals/<slug>.plan.md`
- Spec path: `.agents/goals/<slug>.plan-spec.md` (what `/interview` writes)
- Goal path: `.agents/goals/<slug>.md` (the final mega-prompt)
Create `.agents/goals/` if missing. If `<slug>.md` already exists,
append a numeric suffix (`<slug>-2.md`).
### 3. Write the stub plan
Read `assets/stub-plan.md.tmpl`, substitute `{{OUTCOME}}`, and write to
the plan path. The stub is deliberately prescriptive — it tells
`/interview` exactly which fields to extract so the resulting spec maps
back to the mega-prompt without guesswork.
### 4. Delegate to /interview
Invoke the `/interview` skill against `<slug>.plan.md`. `/interview`
will use its mandatory structured-user-prompt tool (`AskUserQuestion` on
Claude Code) and produce the spec at `<slug>.plan-spec.md`.
Per `/interview`'s contract, it runs iteratively until "all major areas
are covered". Trust it.
### 5. Map spec → mega-prompt fields, fill gaps
Read `<slug>.plan-spec.md`. Extract:
| Mega-prompt field | Likely spec source |
|---|---|
| `{{PROJECT}}` | Executive Summary · Objectives → Primary Goals |
| `{{STACK}}` | Technical Requirements → Components / Architecture |
| `{{CURRENT_STATE}}` | Implementation Notes · context paragraphs |
| `{{WORKING_DIR}}` | Constraints section · or not present |
| `{{CONSTRAINTS}}` | Constraints & Dependencies → Technical / Timeline |
| `{{AUDIENCE}}` | User Experience intro · or not present |
| `{{SUCCESS_1..3}}` | Objectives → Success Metrics |
Fields not reliably in `/interview`'s spec template:
**working dir**, **audience**, **current state**. If those are missing
or thin in the spec, run one `AskUserQuestion` round with only the
unfilled fields. Don't re-ask anything the spec already answers.
If the spec produced more than three success metrics, ask Stevie which
three are the hard-gates for "done". If it produced fewer than three,
ask for the remainder — three is the minimum the template needs.
### 6. Render the mega-prompt
Read `assets/mega-prompt.md.tmpl`. Substitute every `{{FIELD}}` token
with the gathered value. Multi-line values: keep them single-line where
the template uses a single line (Context block) — join with `; ` if
needed. The Operating Rules / Quality Bar / Final Deliverable blocks
are verbatim — never edit them.
Write to `<slug>.md`.
### 7. Report back
Tell Stevie:
- where the goal file landed (absolute path)
- where the spec landed (in case he wants to revise context without
re-interviewing)
- one-line instruction to run it: paste the contents of `<slug>.md`
into a fresh Claude Code or Codex session
- the slug (so he can refer to it later)
Caveman mode by default. Address as **Stevie**.
## Non-goals
- **Do not execute the goal.** This skill only produces the artifact.
- **Do not commit `.agents/goals/`.** Leave that decision to Stevie —
the directory may or may not be gitignored per repo.
- **Do not edit the Operating Rules / Quality Bar / Final Deliverable
blocks** in the template. They're intentionally non-negotiable across
every run.
## Edge cases
- **No `/interview` skill available** (e.g. a host without it deployed):
fall back to running the question set directly via `AskUserQuestion`
using the field list from `assets/stub-plan.md.tmpl`. Skip the spec
artifact in this mode and render straight to the mega-prompt.
- **Outcome line is multi-sentence**: ask Stevie to compress to one
line before slugging. The mega-prompt's first line is the contract.
- **Existing goal with same slug**: append `-2`, `-3`, …
- **Working dir is "this repo"**: capture the absolute path of `$PWD`
at goal-generation time, not the literal string "this repo".Related Skills
make-github-issues
Review codebase and create GitHub issues for identified problems
workflow
Guide through structured delivery workflow with plan, implement, validate phases
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
validate
Verify implementation against specifications
ui-ux-pro-max
UI/UX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, Astro, Nuxt, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, Jetpack Compose). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient.
tui-style-guide
TUI style guide for consistent terminal interface design
token-usage
Show Claude Code token usage across sessions — daily, weekly, per-project, and per-session breakdowns. Parses {{HOME_TOOL_DIR}}/projects/**/*.jsonl for consumption data. Use when the user asks about token usage, costs, how many tokens were used, session statistics, or wants a usage report.
tmux-status
Show status of all tmux sessions including dev environments, spawned agents, and running processes
tmux-monitor
Monitor and report status of all tmux sessions including dev environments, spawned agents, and running processes. Uses tmuxwatch for enhanced visibility.
tmux-message
Reliable peer-to-peer message delivery to other Claude Code instances via tmux send-keys. Use as a fallback when claude-peers MCP send_message fails to surface in the receiver's inbox (delivered server-side but receiver never picks it up — observed behaviour). Also use when sending a directive to a known Claude Code TUI session by tmux session name or fuzzy hint, or when injecting a multi-line directive into a peer's prompt and submitting it. Trigger phrases — "claude-peers fallback", "tmux send-keys", "send to peer via tmux", "inject directive", "deliver to nanoclaw/hermes peer", "peer message". Tmux-only — won't reach peers running outside tmux.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle with test-first approach.
test-ainb
Run tests for the ainb (agents-in-a-box) Rust workspace via a 5-layer strategy — unit, insta snapshot, mock-plugin compositing, real-plugin spawn, vhs recording. Wraps cargo + insta + vhs into one CLI. Use when Stevie says "/test-ainb", "test ainb", "run ainb tests", "snapshot <component>", "regenerate vhs tapes", or any phrasing about validating ainb test layers. The skill autodetects which ainb-tui worktree the cwd sits in and dispatches to scripts/run.sh.