Dev Log: Building Groundwork

This is a working dev-log entry while I build Groundwork, an SDLC-discipline plugin for Claude Code that adds structured requirements, plans, and review checkpoints to agentic development. The goal is to make the agent stop and think — gather requirements, write a plan, get it reviewed — before it writes code.

The fastest way to find out whether a requirements workflow actually works is to point it at something real. So I'm dogfooding: using Codagatchi — a small desktop tamagotchi — as the proof-of-concept, and letting Groundwork's requirements skill drive the elicitation end to end.

The baseline Groundwork produced

I ran Groundwork's requirements workflow against Codagatchi and let it drive the clarify → hypothesize → summarize loop. Here's the artifact it generated, unedited:

Overview — A minimal desktop tamagotchi built with Electron: a single virtual pet living persistently in a small always-on-top window and system tray, with stats that decay over real time (even while the app is closed), requiring the user to tend to it regularly.

Functional requirements

• Pet entity with hunger, happiness, and health stats persisted to disk
• Time-based stat decay calculated from real elapsed time (including when the app is closed)
• Three core interactions: feed, play, clean
• A pixel-art sprite with at least three mood states: happy, neutral, hungry/sick
• Neglect consequences: stats hit zero → pet gets sick → pet dies and resets
• A system-tray icon and a small always-on-top desktop window

Acceptance criteria

• Pet stats persist between app restarts
• Stats decay correctly based on real elapsed time when the app was closed
• Feed, play, and clean each restore the relevant stat
• The sprite visually reflects the current mood state
• The pet dies and resets when neglected to zero across all stats
• The app appears in the system tray and stays on screen

Constraints — Electron + web tech (HTML/CSS/JS), cross-platform (Windows / Mac / Linux).

Out of scope — Multiple pet types, evolution, audio, OS notifications, a settings UI, multiple save slots.

Not bad for an unattended pass: it's scoped, the acceptance criteria are roughly testable, and it draws an explicit out-of-scope line.

It did get one thing wrong in hindsight, buried in that Constraints line: Electron. Building Codagatchi out, I switched to Tauri — Electron bundles a whole Chromium runtime, which is comically huge for a desktop pet, whereas Tauri leans on the OS's native webview for a fraction of the footprint. Tellingly, nothing in the requirements questioned that stack choice or set a binary-size budget — a preview of the biggest gap below.

Run through the requirements research I'd done earlier, the gaps get specific.

Where the gaps are (what's next)

Graded against that research, the baseline is a solid draft but shows exactly where the plugin is still thin. The high-impact gaps — and they're mostly low-effort fixes — are:

• EARS notation isn't enforced. Functional requirements come out as free-form bullets. EARS (ubiquitous / event-driven / state-driven / unwanted-behavior / optional / complex) is the structural move that makes FRs testable and parseable by downstream workflows.
• No ISO 25010 NFR walkthrough. The entire non-functional side is missing — there isn't a single performance, reliability, or security requirement above, because nothing prompts for them. NFR omission is a prompting problem, not a model-capability one: walk the nine ISO 25010 quality characteristics explicitly and coverage jumps. A single performance-efficiency / resource-use prompt would have surfaced the footprint question that later forced the Electron-to-Tauri switch.
• Commonly-missed categories aren't elicited. Error and exception paths, data retention and migration, accessibility, operational concerns (backup, monitoring) — none surfaced, because nothing asks.
• Acceptance criteria aren't in Given/When/Then form. Checkboxes capture intent but not executable spec; Gherkin doubles as a test.
• Assumptions aren't a first-class section. Forcing the model to externalize its assumptions is one of the highest-leverage anti-hallucination moves, and the artifact has nowhere to put them.
• There's no self-critique pass. No vague-qualifier lint, no compound-requirement detector, no implementation-bias flag between the conversation and the summary.

Below those sit medium items — per-requirement rationale, 5-Whys to reach the why, numbered-option questions — and larger structural bets: BABOK's four-tier hierarchy, six-part quality-attribute scenarios for NFRs, atomic requirement files with stable IDs, and downstream emission of Gherkin, test stubs, and ADRs from the same artifact. Encouragingly, the effort skews low for the high-impact ones, so that's the next iteration.

---