# Genesis

> Implement a feature or change with a tight plan, build, and verify loop.

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

---


Build the feature or change described in `$ARGUMENTS` cleanly and correctly: plan it,
match the codebase, ship it in small steps, and verify it works.

## 1. Clarify the goal

State in one sentence what you're building and what "done" looks like (the acceptance
criteria). Derive both from `$ARGUMENTS`. Only ask the user if the request is genuinely
ambiguous (conflicting requirements, missing a critical decision); otherwise proceed.

## 2. Survey existing patterns

Before writing anything, read the neighboring code your change will live among. You're
looking for the conventions to match, not inventing your own:

- **Naming and structure**: how files, functions, and modules are named and laid out.
- **Error handling**: how this codebase reports and recovers from failures.
- **Tests**: where tests live, the framework, and the style of existing cases.

New code should look like it was always there.

## 3. Plan

Write a short checklist of the concrete edits using the todo tooling, one item per file
or logical change, in the order you'll make them. Keep it to the actual work; this is a
plan, not a design doc.

## 4. Build in small steps

Work through the checklist one item at a time. Follow the patterns from step 2. Where a
test suite exists, prefer test-driven: write or extend a failing test that pins the new
behavior, then make it pass. Keep each change focused and self-contained.

Build exactly what was asked: no speculative abstractions, no unrequested refactors, no
extra config "for later" (YAGNI). Do not add comments that merely restate what the code
does.

## 5. Dispatch gate

Decide how to execute before charging ahead:

- **Large or parallelizable**: fan out `Task` subagents, one bounded task each (e.g. one
  per independent module), and integrate the results. Give each a clear, self-contained brief.
- **Small or tightly coupled**: just do it inline. Don't add coordination overhead a
  one-file change doesn't need.

## 6. Verify

Run the project's own checks (typecheck, tests, lint) and read the output. Fix anything
you broke until they pass. Confirm the acceptance criteria from step 1 are actually met.

Report what changed, which files, and how you verified it. Do not commit, push, or open a
PR unless the user explicitly asks; this command implements and verifies, nothing more.