My Claude Code Workflow as a solo dev (with a released game)

Heya, folks! I had mentioned this before in a comment on another post, but I wanted to share my dev workflow in claude code.

Prerequisites:

• Load the obra/superpowers skill set
• Load the dbinky/dbinky-skill-set skills
• Install dbinky/ralph-o-matic

1 - Feature Spec Production

I start by using a prompt like this:

Use the superpowers:brainstorm skill to produce a product specification document (at docs/specs/some-feature-spec.md). We're going to concentrate on the product features and outcomes and will not bring any implementation details into the document. Here's what I'd like to discuss with you: {thorough description of the product feature}

The plugin scans the code and recent checkins and then goes into a Q&A loop with you to clarify details around the product specification.

2 - Feature Design Production

With that doc in hand, I then prompt it with:

Use the superpowers:brainstorm skill again to produce an implementation design for the spec we just wrote (at docs/specs/some-feature-spec.md). The implementation design may be multiple phases of work and we want to create a separate design document for each logical phase. Those documents will be stored as docs/superpowers/specs/some-feature-design-phase-*.md. Read through the spec thoroughly for context and then let's figure out the high level implementation details for these design docs.

The plugin does the code scan and reads the spec and then goes into a Q&A loop with you to clarify high-level implementation details around the product spec.

3 - Design Doc Alignment

Next, I tell it:

We have just produced a series of design documents that represent the high-level implementation details of the product spec at docs/specs/some-feature-spec.md. From that, you just produced a series of implementation design docs at docs/superpowers/specs/some-feature-design-phase-*.md. I want you to review the feature spec and the holistically review the design phase docs together for alignment both to the spirit of the feature spec and to each other. Check for end-to-end coherence between documents (aligned models, terminology, use cases, etc) and update them so they are correct as a body of work.

This does a review of the designs per the spec and ensures that there are no internal conflicts between the various representations.

4 - Implementation Plan Production

We need to write detailed implementation plans (using the superpowers:writing-plans skill) for all of the high-level design documents at docs/superpowers/specs/some-feature-design-phase-*.md. Each design phase may have multiple implementation tasks and I want you to store each of those tasks as a separate, detailed implementation file as docs/superpowers/plans/some-feature-implementation-phase-*-task-*.md. Write all of these plans in one end-to-end effort.

This now blows out the designs into multiple code-level-detail implementation plans

5 - Implementation Plan Alignment

We have just produced a series of implementation plans that represent the product spec at docs/specs/some-feature-spec.md which has been expressed as high-level design documents here: docs/superpowers/specs/some-feature-design-phase-*.md. From those, you just produced a series of detailed plans at docs/superpowers/plans/some-feature-implementation-phase-*-task-*.md. I want you to review the feature spec, the designs, and the plans and then holistically review the implementation plans together for alignment both to the spirit of the feature spec and to each other. Check for end-to-end coherence between documents (aligned models, terminology, use cases, etc) and update them so they are correct as a body of work.

6 - "Draft" Implementation

At this point, I tell it go ahead and do the entire implementation at once without my review:

We are going to implement the feature (spec located at docs/specs/some-feature-spec.md) using a series of detailed implementation plans here: docs/superpowers/specs/some-feature-design-phase-*.md. The user is unavailable for input. Use subagent-driven implementation and spawn a fresh subagent for each task of each phase. Review the plans, themselves, for dependencies and parallelize execution as much as is feasible. Do all phase and task implementations in one concerted effort - do not stop for review or permissions.

7 - Prepping For Refinement Loop

Next, I use the skill `/plan-to-ralph` (part of the dbinky-skill-set) to help create the Ralph Wiggum loop infrastructure. It asks a bunch of Q&A and then creates the RALPH.md and 2 tracking files that it uses to govern the work.

8 - Ralph-o-matic

Now, I feed all of this into the Ralph-o-matic using the `/direct-to-ralph` skill. I specify the number of iterations (I usually pick a high number like 200+) and tell it to work on my local repo and branch using the existing RALPH.md file (from step 7). This ships the work for refinement to the ROM server where it uses claude code as a "rock tumbler" for code. You can't work in that repo/branch while it's going, so I usually run this right before bedtime.

9 - PR Review

Lastly, I make a PR for the work and then run /pr-review (also from dbinky-skill-set) which is an oppositional review process that yields a suggested fix list. I usually tell it to fix "all but defer" (it ranks the fixes by Must, Should, Could, and Defer) and then let it do the work.

10 - Voila!

Every time I've used this process, I get *excellent* results. Low, low bug count, the functionality is well aligned with the spec.

I have a skill that I wrote for myself that orchestrates this process automatically, but these are the basic steps that I've been using for a few months to produce a lot of really solid project code.

I'd love to hear what everyone things!