About the GSD framework

GSD (“Get Shit Done”) is the planning + execution framework Frank’s Fed is built with. This page explains, in plain terms, what you’re looking at on the rest of this site — and where you can dig in if you want the depth.

If you want the source: github.com/gsd-build/get-shit-done

The one-line version

Every change to Frank’s Fed goes through the same four-step loop: discuss → plan → execute → verify. Each step produces a small, named markdown artefact. Those artefacts are what the Build Status page on this site is summarising. Nothing is in someone’s head; nothing is on a sticky note.

Why this exists

Solo-founder builds drift. Notes get scattered across Notion / Linear / Slack / DMs / scratch files. By the time something ships, nobody remembers exactly why a decision was made or what was tested. GSD imposes one rule: if it matters, it lives in .planning/ as a named markdown file. The framework gives you the file names, the headings, and a workflow for moving through them.

The cost is a few minutes per phase to write things down. The benefit is that this entire site — the live status, the metrics, the blockers — is generated from those files. No second copy. No drift.

The four-step loop

Each phase of the build (Phase 0 Foundation, Phase 1 Schema, Phase 2 Auth & Onboarding, …) goes through these four:

1. Discuss

What it is — a structured Q&A that surfaces unknowns, locks decisions, and produces a <phase>-CONTEXT.md file.

What it answers — Have we thought about this enough to plan it?

Slash command in Claude Code — /gsd-discuss-phase <N>

2. Plan

What it is — break the phase into individual plans (<phase>-NN-PLAN.md), each scoped to roughly one commit’s worth of work. Plans declare verification criteria up front.

What it answers — What’s the sequence of moves, and what’s “done” for each?

Slash command — /gsd-plan-phase <N>

3. Execute

What it is — work through each plan in order, committing as you go. Each plan ends with a <phase>-NN-SUMMARY.md that records what landed, what changed from the plan, and any deferred items.

What it answers — Did the work match the plan? What got deferred?

Slash command — /gsd-execute-phase <N>

4. Verify

What it is — a phase-level check (<phase>-VERIFICATION.md) that asserts every Success Criterion (SC) is met, with evidence. Verification is what closes a phase.

What it answers — Is the phase actually done? What still needs human eyes?

Slash command — /gsd-verify-phase <N>

If a phase has things that only a human can verify (e.g. “do two iPhones agree on widget state after 24 hours?”), they’re tagged human_needed and surface on this site as open UAT items. They don’t block the phase from being technically verified — they just stay open until a human signs them off.

The artefacts you’ll see referenced on this site

The slash commands /gsd-discuss-phase, /gsd-plan-phase, etc. all live in github.com/gsd-build/get-shit-done as Claude Code skills.

What this site is showing you

Open the Build Status tab and you’re looking at the contents of STATE.md + ROADMAP.md + every phase’s summary, rendered for humans:

• Plans complete (32 / 32) — count of <phase>-NN-SUMMARY.md files across done phases.
• Phases done (4 / 7) — count of phases with verification closed.
• Phase 3 verify (5/5 + 2 manual) — Phase 3’s VERIFICATION.md says 5 of 5 SCs passed programmatically, with 2 human_verification items still open. Those are surfaced as soft blockers on the page.
• Phase breakdown — one row per phase, with the live status badge derived from each phase’s verification state.
• Current position — STATE.md ## Current Position block.
• Open gates & blockers — the union of BACKLOG.md open items + every phase’s human_verification items, with hard/soft tier and originating phase.

The publish skill (/franks-fed-status-publish) regenerates this page from those source files. Nothing is hand-typed into the live HTML. If a number on the page is wrong, the source file is wrong; fix that and re-publish.

Voice constraints (Bible §14)

The Frank’s Fed Product Bible bans certain words across the product and its planning artefacts: alert, warning, overdue, failed, missed, violation, restricted, error. The publish skill paraphrases anything stale that creeps in. So the report will say “outstanding” not “failed”, “open” not “blocked”, “not yet started” not “missed deadline”. This isn’t decoration — it’s part of the product’s voice and shows up in every UI string the team writes too.

Commit conventions

Every commit ties to a specific plan or quick task:

feat(<plan>): <short>          ← code change for plan
docs(<phase>): <short>         ← documentation under a phase
test(<plan>): <short>          ← tests for a specific plan
fix(<plan>): <short>           ← in-flight fix during execution
chore(<scope>): <short>        ← infra / tooling
docs(state): <short>           ← STATE.md or ROADMAP.md updates

If you’re reviewing a PR and a commit doesn’t fit any of these, ask — usually it means a plan got missed.

Where to dig in

TL;DR for the team

If you only remember one thing: STATE.md is the cursor, ROADMAP.md is the map, and every phase has a VERIFICATION.md that tells you what’s been signed off and what still needs human eyes. The Build Status page on this site is a live render of those three. Everything else is supporting evidence.