goal-from-spec

Stars11

Forks0

UpdatedJune 30, 2026 at 20:22

Emit a /goal command pointed at a feature directory containing a blueprint.md (or the legacy prd.md + tech-spec.md). Use whenever the user wants to implement, build, ship, or run a feature whose design lives in a docs/features/<name>/ directory (or similar). Do NOT use for design discussions or one-shot edits.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

thrawn01

thrawn01/claude-dotfiles

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	goal-from-spec
description	Emit a /goal command pointed at a feature directory containing a blueprint.md (or the legacy prd.md + tech-spec.md). Use whenever the user wants to implement, build, ship, or run a feature whose design lives in a docs/features/<name>/ directory (or similar). Do NOT use for design discussions or one-shot edits.

Goal from Spec

Emit a /goal command pointed at a feature directory. The user pastes it to launch — Claude Code's slash commands are parsed from user input, not from model output.

What to do

Identify the feature directory path. Ask once if ambiguous; otherwise read it from the conversation.
Check which design docs are present, and pick the matching template:
- Prefer blueprint.md — the current single-document design artifact (product what + technical how in one file). Use the Blueprint template.
- Fall back to the legacy prd.md + tech-spec.md (+ optional user-stories.md) for older feature directories that predate the Blueprint. Use the Legacy template.
Emit the command using the matching template below, in a fenced code block, with no commentary after.

Blueprint template

/goal Implement the feature specified in <feature-dir>/. Follow <feature-dir>/blueprint.md as the source of truth for both WHAT correct means and HOW to build it, matching the existing codebase's patterns, conventions, and terminology so the new code fits naturally rather than inventing divergent structure. The feature is complete only when every acceptance criterion in the Blueprint is satisfied AND demonstrably verified: all new and existing tests pass, the build is green, and lint is clean. Treat the Blueprint as the source of truth for correctness — if the implementation and the Blueprint disagree, the implementation is wrong. For each acceptance criterion, there must be a passing test that exercises it through the system's surface — its public interface (HTTP endpoints, CLI entry points, exported functions), never internal functions; use the surface-testing skill to guide the testing strategy. For every invariant or illegal-state constraint stated in the Blueprint, there must also be a surface test that attempts to violate it and verifies the system rejects the operation. Derive every test from the Blueprint, never from your own implementation; for each, confirm it fails against the unimplemented behavior before writing the code that makes it pass. Do not mark complete until that coverage exists and passes. If the implementation is large or complex — many files, many independent components, or many acceptance criteria that can be tackled in parallel — use a workflow to plan the orchestration and run subagents in parallel; each subagent prompt that writes tests must carry the same surface-testing instruction.

Legacy template

Use only when there is no blueprint.md and the directory still carries the older prd.md / tech-spec.md split.

/goal Implement the feature specified in <feature-dir>/. Follow <feature-dir>/tech-spec.md as the implementation guide for HOW to build it, matching the existing codebase's patterns, conventions, and terminology so the new code fits naturally rather than inventing divergent structure. The feature is complete only when every acceptance criterion in <feature-dir>/prd.md is satisfied AND demonstrably verified: all new and existing tests pass, the build is green, and lint is clean. Treat the PRD as the source of truth for correctness — if the implementation and the PRD disagree, the implementation is wrong. For each PRD acceptance criterion, there must be a passing test that exercises it through the system's surface — its public interface (HTTP endpoints, CLI entry points, exported functions), never internal functions; use the surface-testing skill to guide the testing strategy. For every invariant or illegal-state constraint stated in the PRD or tech-spec, there must also be a surface test that attempts to violate it and verifies the system rejects the operation. Derive every test from the PRD/tech-spec, never from your own implementation; for each, confirm it fails against the unimplemented behavior before writing the code that makes it pass. Do not mark complete until that coverage exists and passes. If the implementation is large or complex — many files, many independent components, or many acceptance criteria that can be tackled in parallel — use a workflow to plan the orchestration and run subagents in parallel; each subagent prompt that writes tests must carry the same surface-testing instruction.

The Blueprint already folds in user stories — there is no separate user-stories.md in the Blueprint flow. For the Legacy template only: if user-stories.md is present, append Each user story in <feature-dir>/user-stories.md must also be satisfied with a passing test., and if tech-spec.md is absent, drop the second sentence ("Follow … HOW to build it.").
The word "workflow" in the template is load-bearing — it triggers Claude Code's Dynamic Workflows. Don't remove or rephrase it.
"surface" and "surface-testing skill" are also load-bearing — they trigger the surface-testing skill and keep tests on the public interface. Keep them in the template, and keep the clause requiring subagent prompts to repeat the instruction so parallel workers inherit it rather than relying on ambient CLAUDE.md.

More from this repository

same repository

blueprint-adr-audit

thrawn01/claude-dotfiles

Audit a blueprint (or other plan/design/spec/diff) against the repository's Accepted ADRs to find where it VIOLATES or CONTRADICTS a binding decision — using parallel sub-agents that each own a slice of the ADR corpus, then a synthesized verdict. This is a companion to blueprint-review, meant to run during blueprint work once the design is drafted and before the build starts. Use when the user says "check the blueprint against our ADRs", "does this violate any ADRs", "audit the plan for ADR compliance", "make sure the blueprint doesn't contradict an ADR", or "/blueprint-adr-audit". It is READ-ONLY: it reports findings and does not edit the plan, the ADRs, or any code. Do NOT use it to WRITE a new ADR (that is adr-write), to REVIEW the blueprint for gaps/correctness (that is blueprint-review), to review code for bugs (/code-review), or to check a spec's documentation quality (review-openapi).

2026-07-2111

blueprint-review

thrawn01/claude-dotfiles

Review an existing Blueprint (the single product + technical design document) for gaps, inconsistencies, unresolved questions, correctness holes, and ambiguities that would force decisions during the build, then produce an updated version. Use when the user asks to "review the blueprint", "check the blueprint", or "update the blueprint". Reviews both halves and the user-stories section in one pass. Do NOT use to start a new Blueprint from scratch (use blueprint-create) or to make minor wording edits that don't need a structured review.

2026-07-2111

captain-done

thrawn01/claude-dotfiles

Finish a Linear ticket from inside its worktree and hand it back to the captain: verify the PR merged, set the ticket to Done, and post a `## Ticket Done` entry to the ticket's PROJECT status-update timeline (never a ticket comment) so the orchestrating /captain picks it up on its next re-hydrate. Use when a ticket's PR is merged and you're closing it out — 'captain done', '/captain-done', 'finish this ticket and tell the captain', 'mark this done for the captain', 'hand this back to the captain'. This is the worker-side finishing counterpart to /captain (the orchestrator) and a specialization of /linear-handoff for the merged-and-closed moment. Do NOT use to pause mid-ticket (use /linear-handoff), to hand off one long-running ticket's own progress as a ticket comment (that's /linear-handoff issue mode), or when the work isn't part of a captain-managed project.

2026-07-2111

captain

thrawn01/claude-dotfiles

Manage a Linear project across sessions as an orchestrator: each invocation it re-hydrates project state from Linear (the source of truth) plus its own last project status update (its memory), tells you what changed and what's ready next, and on your go launches the next ticket as a herdr worktree + Claude session via the captain-next wrapper. It sequences work (what's next, what's parallel-safe), keeps Linear current by writing the next project status update, and reconciles finished worktrees. Use when the user says 'run the captain for <project>', '/captain', 'what's next on <project>', 'manage the git-server build', 'start the next ticket', or 'I finished <ticket>, what now'. It is the ongoing, managing counterpart to /linear-resume (a one-shot read) and it drives /linear-start via the launcher. You can also ask it to help plan the project or create tickets WITHIN that already-managed project — the loop below is its default job, not its limit. Do NOT use captain to create or capture a standalone ticket, sp

2026-07-2111

linear-start

thrawn01/claude-dotfiles

Pick up a Linear ticket and start working it. Fetch the ticket, verify the current branch matches Linear's own git branch name (the worktree is created before the session, e.g. by a claude-branch-style wrapper), then classify the ticket (bug / improvement / feature) from its Linear labels — falling back to its content when unlabeled. Bugs and trivial improvements start immediately; features with enough detail hand off to /blueprint-create. Use when the user says 'pick up <TEAM>-<NUM>', 'work this ticket', 'start <ticket>', 'start working ENG-42', '/linear-start', or gives a Linear id/URL and asks to begin. This is greenfield only — to *resume* an in-flight build or long-running ticket from its latest handoff, use /linear-resume first. Do NOT use to merely create a ticket or to open a PR — those belong to the ticket-creation and PR skills.

2026-07-2111

writing-style

thrawn01/claude-dotfiles

Write or edit writing in the user's practitioner blog voice — experience-backed, conversational, story-driven, opinionated but humble. Use for blog posts, tech specs, engineering communications, and any long-form writing the user asks for. Activated when the user asks to "write a post", "draft a blog", "write up X", "edit this for style", "review this for my style", or invokes /writing-style directly.

2026-07-2111

name	goal-from-spec
description	Emit a /goal command pointed at a feature directory containing a blueprint.md (or the legacy prd.md + tech-spec.md). Use whenever the user wants to implement, build, ship, or run a feature whose design lives in a docs/features/<name>/ directory (or similar). Do NOT use for design discussions or one-shot edits.

Goal from Spec

Emit a /goal command pointed at a feature directory. The user pastes it to launch — Claude Code's slash commands are parsed from user input, not from model output.

What to do

Identify the feature directory path. Ask once if ambiguous; otherwise read it from the conversation.
Check which design docs are present, and pick the matching template:
- Prefer blueprint.md — the current single-document design artifact (product what + technical how in one file). Use the Blueprint template.
- Fall back to the legacy prd.md + tech-spec.md (+ optional user-stories.md) for older feature directories that predate the Blueprint. Use the Legacy template.
Emit the command using the matching template below, in a fenced code block, with no commentary after.

Blueprint template

/goal Implement the feature specified in <feature-dir>/. Follow <feature-dir>/blueprint.md as the source of truth for both WHAT correct means and HOW to build it, matching the existing codebase's patterns, conventions, and terminology so the new code fits naturally rather than inventing divergent structure. The feature is complete only when every acceptance criterion in the Blueprint is satisfied AND demonstrably verified: all new and existing tests pass, the build is green, and lint is clean. Treat the Blueprint as the source of truth for correctness — if the implementation and the Blueprint disagree, the implementation is wrong. For each acceptance criterion, there must be a passing test that exercises it through the system's surface — its public interface (HTTP endpoints, CLI entry points, exported functions), never internal functions; use the surface-testing skill to guide the testing strategy. For every invariant or illegal-state constraint stated in the Blueprint, there must also be a surface test that attempts to violate it and verifies the system rejects the operation. Derive every test from the Blueprint, never from your own implementation; for each, confirm it fails against the unimplemented behavior before writing the code that makes it pass. Do not mark complete until that coverage exists and passes. If the implementation is large or complex — many files, many independent components, or many acceptance criteria that can be tackled in parallel — use a workflow to plan the orchestration and run subagents in parallel; each subagent prompt that writes tests must carry the same surface-testing instruction.

Legacy template

Use only when there is no blueprint.md and the directory still carries the older prd.md / tech-spec.md split.

/goal Implement the feature specified in <feature-dir>/. Follow <feature-dir>/tech-spec.md as the implementation guide for HOW to build it, matching the existing codebase's patterns, conventions, and terminology so the new code fits naturally rather than inventing divergent structure. The feature is complete only when every acceptance criterion in <feature-dir>/prd.md is satisfied AND demonstrably verified: all new and existing tests pass, the build is green, and lint is clean. Treat the PRD as the source of truth for correctness — if the implementation and the PRD disagree, the implementation is wrong. For each PRD acceptance criterion, there must be a passing test that exercises it through the system's surface — its public interface (HTTP endpoints, CLI entry points, exported functions), never internal functions; use the surface-testing skill to guide the testing strategy. For every invariant or illegal-state constraint stated in the PRD or tech-spec, there must also be a surface test that attempts to violate it and verifies the system rejects the operation. Derive every test from the PRD/tech-spec, never from your own implementation; for each, confirm it fails against the unimplemented behavior before writing the code that makes it pass. Do not mark complete until that coverage exists and passes. If the implementation is large or complex — many files, many independent components, or many acceptance criteria that can be tackled in parallel — use a workflow to plan the orchestration and run subagents in parallel; each subagent prompt that writes tests must carry the same surface-testing instruction.

The Blueprint already folds in user stories — there is no separate user-stories.md in the Blueprint flow. For the Legacy template only: if user-stories.md is present, append Each user story in <feature-dir>/user-stories.md must also be satisfied with a passing test., and if tech-spec.md is absent, drop the second sentence ("Follow … HOW to build it.").
The word "workflow" in the template is load-bearing — it triggers Claude Code's Dynamic Workflows. Don't remove or rephrase it.
"surface" and "surface-testing skill" are also load-bearing — they trigger the surface-testing skill and keep tests on the public interface. Keep them in the template, and keep the clause requiring subagent prompts to repeat the instruction so parallel workers inherit it rather than relying on ambient CLAUDE.md.