claude-put-in-work

A framework for autonomous, multi-session app building with Claude Code. Describe what you want built, run build.sh, and let Claude build it end-to-end — overnight if you want.

How It Works

 1. PLAN                  2. REVIEW               3. BUILD

 Your idea/plan           You review &             ./build.sh
       │                  approve the spec               │
       v                        │                        v
/autonomous-build               │              ┌───────────────────┐
       │                        │              │ Claude Code loop   │
       v                        v              │ session 1 -> 2 ... │
┌─────────────┐          ┌─────────────┐       └────────┬──────────┘
│  PROMPT.md   │────────>│  PROMPT.md   │               │
│  build.sh   │          │  (approved)  │               v
└─────────────┘          └─────────────┘       ┌─────────────────┐
                                               │ BUILD_PROGRESS.md│
                                               │ (session handoff)│
                                               └─────────────────┘
                                               "ALL PHASES COMPLETE"
                                                  -> stops early

1. Plan — Describe your idea and run /autonomous-build. The skill analyzes your plan and generates a PROMPT.md spec and build.sh runner.
2. Review — Read the generated PROMPT.md. Check the tech stack, architecture, phases, and security rules. Edit anything that's off.
3. Build — Run ./build.sh. Claude Code runs in a loop, reading BUILD_PROGRESS.md each session to pick up where it left off. No human intervention needed until it's done.

The key insight: BUILD_PROGRESS.md acts as a handoff document between sessions, giving Claude continuity across the entire build.

Quick Start

1. Plan

Describe your idea and let the skill generate your build spec:

/autonomous-build a task management app with categories and due dates

The skill analyzes your plan, asks clarifying questions, then generates PROMPT.md and build.sh in your target project directory.

Or manually: Copy SAMPLE_PROMPT.md to PROMPT.md in your project and fill in the placeholders. See SAMPLE_PROMPT.md for the annotated template with guidance and a concrete example.

2. Review

Read the generated PROMPT.md before running anything. Check:

• Tech stack and library choices
• Architecture and API design
• Phase breakdown and verification steps
• Security rules

Edit anything that doesn't match your intent. This is your last checkpoint before autonomous execution.

3. Build

chmod +x build.sh
./build.sh

The script will:

• Confirm before starting (pass --yes to skip)
• Run Claude Code up to N sessions (configurable in build.sh)
• Log each session to build-logs/
• Stop early if BUILD_PROGRESS.md indicates all phases are complete

Check BUILD_PROGRESS.md anytime to see what's been completed, what's in progress, and what's next.

File Reference

Anatomy of a Good PROMPT.md

A well-structured prompt has these sections:

1. Multi-session continuity block — Instructions to read BUILD_PROGRESS.md and assess project state before doing anything
2. Mission — What you're building and why
3. Core workflows — What users can DO with the app
4. Context — Files, repos, and docs the agent needs to read
5. Tech stack — Explicit language, framework, database, and library choices
6. Design requirements — UI specs, colors, component patterns (if applicable)
7. Architecture — How pieces connect, data models, storage, API endpoints
8. Documentation rules — What docs to maintain and when to update them
9. Build order — Phased plan where each phase is testable and completable in one session
10. Security & commit rules — Safety rails for git operations and secret protection

See the Tips section in SAMPLE_PROMPT.md for detailed advice.

Configuring build.sh

Edit build.sh to adjust:

MAX_RUNS=10          # Maximum number of Claude sessions
sleep 5              # Pause between sessions (seconds)

Security Considerations

The script uses --dangerously-skip-permissions so Claude can execute shell commands, write files, and commit code without prompting for approval. This is what makes unattended builds possible — but it means Claude has full system access during the run.

What this means:

• Claude can run any shell command, read/write any file, and make git commits
• There are no interactive "allow this action?" prompts
• Your PROMPT.md security rules are the primary guardrails

How to mitigate risk:

• Always include the security & commit rules section in your PROMPT.md (the template includes these by default)
• Run builds in an isolated environment (container, VM, or dedicated machine) when possible
• Review build-logs/ and git log after the build completes
• Keep sensitive files (.env, credentials) outside the project directory or in .gitignore
• Never store API keys, tokens, or passwords in files within the project — use environment variables

Running interactively: Remove --dangerously-skip-permissions from build.sh if you'd rather approve each action — but each session will block waiting for your input.

Tips

• Phase sizing matters — Each phase should be completable in one session (~1-3 hours of agent work). If a phase has 15+ tasks, split it.
• Absolute paths — Use full paths in your prompt so they work across sessions.
• Verification steps — Include concrete test steps in each phase ("Test: create X -> see Y"). This lets Claude confirm its own work.
• Reference projects — "Follow the architecture of /path/to/project" is more precise than pages of architecture description.
• Security rules prevent disasters — Without explicit rules, the agent may git add . and commit secrets or generated files.
• Early completion — The build runner checks BUILD_PROGRESS.md for completion markers after each session. When Claude writes "ALL PHASES COMPLETE" at the top, the runner stops — no wasted sessions.

Prerequisites

• Claude Code CLI installed and authenticated
• A shell environment (bash/zsh)

License

MIT