# Goal

> Quick goal planning for technical tasks. Compressed vision-requirements-spec-plan into a single goal.md through a brief interview (3-6 questions). For tasks bigger than ad-hoc but not needing the full feature process.

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

---


# Goal Planning

## Overview
Compressed alternative to the full feature development process. Produces a single goal.md document through a quick conversational interview — typically 3-6 questions total.

One document instead of four. Plain language instead of formal requirement IDs. Quick interview instead of deep multi-phase discovery.

**When to use this:**
- Infrastructure work (deploy, configure, set up a service)
- Script or small tool development
- Technical configurations or migrations
- Anything bigger than a one-off task but not a full product feature

**When NOT to use this:**
- Full product features → use `/feature-vision`, `/feature-requirements`, `/feature-spec`, `/feature-plan`
- Simple one-off tasks → just do them or use plan mode

**IMPORTANT**: Start by creating a TODO list to track the 3 phases of goal creation. Mark the first phase as "in_progress" and others as "pending".

## Goal Document Structure

A goal.md is a single markdown file with four sections:

1. **Goal Statement** — One paragraph: what you're building, why, what success looks like
2. **Requirements** — Simple bullets in plain language (no REQ-X.X.X IDs, no user story format)
3. **Technical Approach** — Brief technical decisions: tools, languages, integration points, key choices
4. **Plan** — Ordered steps with checkboxes, ready to execute

**Target length:** 1-2 pages total. If it's getting longer, you're over-thinking it — use the full feature process instead.

## Process: Work Through These 3 Phases Sequentially

### Phase 1: Discovery (2-3 questions)

Understand what and why. Ask ONE question at a time:

- What are you trying to accomplish?
- Why does this need to be done? (What problem does it solve or what does it enable?)
- Any constraints or context I should know? (Existing systems, preferences, limitations)

**Keep it conversational.** Don't ask questions you can answer yourself from context — check the codebase, memory, and project docs first. If the goal is already clear from what the user said, skip straight to confirming your understanding rather than re-asking.

**Goal of this phase:** Enough understanding to write a clear goal statement and requirements bullets.

### Phase 2: Technical Approach (1-2 questions)

Understand how. Again, ONE question at a time:

- What tools, languages, or technologies should we use? (Or: here's what I'd suggest based on your stack — does that sound right?)
- Are there existing patterns or systems this needs to integrate with?

**Be opinionated.** If you know the user's stack and preferences, propose an approach and ask for confirmation rather than open-ended questions. Check the codebase for existing patterns before asking.

**Goal of this phase:** Key technical decisions made. Ready to write the document.

### Phase 3: Document Generation

Before generating, confirm the save location:
- **Default:** `goals/YYYY-MM-DD-brief-name/goal.md` relative to the current project root
- If the current project doesn't make sense, ask where to save it

Generate the goal.md with this structure:

```markdown
# Goal: [Brief Title]

## Goal Statement

[One paragraph — what you're building, why it's needed, what success looks like.]

## Requirements

- [Simple bullet — what the system must do]
- [Another capability]
- [Any constraints]
- [Keep these plain and practical]

## Technical Approach

[Brief — what tools, languages, frameworks. Key technical decisions and why.
Integration points with existing systems. 1-2 short paragraphs max.]

## Plan

- [ ] Step 1 — description
- [ ] Step 2 — description
- [ ] Step 3 — description
  - [ ] Sub-step if needed
- [ ] Step N — verify everything works
```

**After generating:** Mark all TODO phases complete. Ask if the user wants to start executing the plan or adjust anything first.

## Guidelines

- **Speed is the point.** Total interview: 3-6 questions. Don't fish for detail you don't need.
- **One question at a time.** Wait for the answer before asking the next.
- **Be opinionated.** Propose approaches based on what you know about the user's stack and preferences. Don't ask when you can suggest.
- **Plain language.** No corporate speak, no formal IDs, no jargon unless it's technical and necessary.
- **Check context first.** Read relevant files, memory, and project docs before asking questions the codebase can answer.
- **Single document.** No discussion-summary.md, no future.md, no cross-references. Just one goal.md.
- **Practical plans.** Steps should be concrete and executable. Include validation steps. No time estimates.