This resonates a lot. The CLAUDE.md hierarchy + indexed artifacts is exactly the kind of structural thinking that most "how to prompt Claude" content skips over entirely.

The piece I keep running into with solo builders is that even when they have a good structure, the failure mode is trusting Claude's output too uniformly — treating fast generation as a proxy for correctness. The code looks clean, tests pass, ships fine... and then a month later nobody (including you) can reason about it because the decisions that shaped it never got persisted anywhere. Your decision capture artifact solves exactly that.

One thing I've been exploring from a complementary angle: rather than scaffolding the SDLC, building a clearer internal model of how Claude reasons — where it's reliable vs. where it needs human review gates. Working on a free starter pack around this (panavy.gumroad.com/l/skmaha) — would be curious if any of this maps to patterns you've seen with the scaffold.

How does your framework compare to spec-driven development e.g. https://github.com/github/spec-kit? In my experience, spec-kit produces a lot of markdown files and little source code.

Thoughts on publishing an example output perhaps in another repo? Perhaps just the first two phases? Would be interesting to see what the output looks like practically speaking (before committing to using it for a project).

Please show your benchmarks and evals to prove that your template actually makes any sense and doesn't waste the credits/tokens/requests/etc.

I built a big brain download of how I think the day to day SDLC rolls now and used it to teleport my ideas into any harness as needed.

We have built something similar for our SDLC, but it is based on Claude Code slash commands:

  - /tasks:capture — Quick capture idea/bug/task to tasks/ideas/

  - /tasks:groom — Expand with detailed requirements → tasks/backlog/

  - /tasks:plan — Create implementation plan → tasks/planned/

  - /tasks:implement — Execute plan, run tests → tasks/done/

  - /tasks:review-plan — Format plan for team review (optionally Slack)

  - /tasks:send — Send to autonomous dev pipeline via GitHub issue

  - /tasks:fast-track — Capture → groom → plan → review in one pass

  - /tasks:status — Kanban-style overview of all tasks

Workflow: capture → groom → plan → implement → done (with optional review-plan before implement, or send for autonomous execution).

Figma would make this even more amazing but great work!

[dead]

[dead]

[dead]