# Goal Driven Development

> Use this skill to orchestrate an existing goal or spec through the dev flow. Load when the user asks for end-to-end feature execution, a goal-to-PR pipeline, or any task that crosses spec → implementation → review → knowledge capture. The skill is a thin router: it names the 6 phases (spec intake, blast-radius check, implementation, verification, review gate, knowledge capture) and the skill that does the work for each phase. Do NOT use for: a single review (load the matching `*-code-reviewer` directly), or for a generic author-craft task like TDD / debugging / brainstorming (use obra/superpowers). Complementary to the 17 enterprise-flow skills; for the planned v0.6.1+ skills, the orchestrator names which of them does the work for each phase.

- Skill: `liyown/goal-driven-development` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add liyown/goal-driven-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/liyown/goal-driven-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: liyown (https://skillmd.com/u/liyown)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/liyown/goal-driven-development

---


# Goal Driven Development

Use this skill to orchestrate an existing goal or spec through the dev flow. The skill itself is a thin router — the actual work is done by the language-specific reviewers and the planned enterprise-flow skills in `docs/rfcs/2026-06-10-enterprise-flow-skills.md`.

## Required Loading

Always load:

- `prompts/workflow.md`
- `prompts/codegraph.md`

## Orchestration Contract

The 6 phases below are how a spec becomes code in this collection. Each phase names the skill that does the heavy lifting; this skill's job is to name them, in order, and stop the run if any phase finds an issue that should be raised before continuing.

1. **Spec intake** — read the spec, extract acceptance criteria. (The dedicated `spec-intake` skill is not yet shipped; until it is, this phase uses the prompt shape in `prompts/workflow.md` Phase 1.)
2. **Blast-radius check** — before implementing, find every caller, every consumer, every shared kernel that the change touches. Currently this is done inline; the dedicated `code-ownership-impact` skill is in v0.5.0+ RFC.
3. **Implementation** — minimal scoped change. Do not expand into unrelated refactors.
4. **Verification** — run the nearest tests, builds, or page checks. Record the inability to run if it applies.
5. **Review gate** — invoke the matching `*-code-reviewer` (java / react / go / python / node) for the touched files.
6. **Knowledge capture** — invoke `project-knowledge-capture` to write the durable post-impl note.

If any of `*-code-reviewer` surfaces Critical / High, fix or explicitly mark `需要结合上下文确认` before moving to phase 6. Never silently skip.

## CodeGraph Fallback

If CodeGraph is unavailable, fall back to `rg` and source reading, and **declare** the fallback in the final report using the exact line `CodeGraph unavailable; context was gathered by rg/file inspection.` — never silently downgrade. The current CodeGraph tool list is in `prompts/codegraph.md`; the prompt references `codegraph_explore` as the primary walk tool.

## Related Skills

- **Future enterprise-flow skills** (proposed in `docs/rfcs/2026-06-10-enterprise-flow-skills.md`): `data-lineage-trace`, `code-ownership-impact`, `incident-call-trace`, `progressive-rollout-checklist`, `compliance-control-walk`, `cross-team-rfc-draft`, `observability-coverage-audit`, `pr-authoring`. Each of those sits in a different phase and complements this orchestrator.
- **Already shipped:** `spec-doc-linter` (keeps `DevAgent.md` and `CONTEXT.md` honest after the code has moved); the 5 language-specific reviewers invoked in phase 5.

See `README.md` for install instructions and the combined install command.