How to Automate App Builds with Claude Code

TL;DR

Use a GitHub project board to route well-defined tickets through separate Builder, QA, and Reviewer stages until each feature is merged, blocked, or skipped. Lint acceptance criteria before dispatching headless Claude Code workers, keep autonomous changes on a develop branch, and reserve human intervention for genuine blockers or revision limits.

Transcript

While I was sleeping last night, Clocku shipped four pull requests for me. It pick up tickets from my GitHub project board, build the feature, run the QA against the acceptance criteria, did a full code review, and only then merge into develop branch. And if the QA fail or the reviewer push back, it didn't just ship it anyway. It sent the ticket ba... Read More

Key Insights

• Superboard is a GitHub project pipeline that moves issues through Ready, Building, QA, Review, and Done while routing exceptional work to Blocked or Skipped. It continues draining the board until no actionable tickets remain.
• The orchestrator is responsible for reading each issue's board status and triggering the appropriate specialized agent. A ticket in Building goes to the Builder, a ticket in QA goes to the tester, and a ticket in Review goes to the Reviewer.
• The Builder is responsible for implementing the feature described by a ticket before moving it into QA. Autonomous changes can be committed to a separate develop branch, which keeps the production branch isolated from work produced during unattended runs.
• The QA stage is a gate that tests the implemented feature against the ticket's acceptance criteria. A passing result advances the ticket to Review, while a failure returns it to the Builder with specific feedback for another implementation attempt.
• The Reviewer is a separate quality gate that conducts a code review after QA succeeds. Reviewer objections do not get ignored, because the ticket returns to the Builder with exact feedback and enters another revision loop.
• Ticket linting is required to make headless execution practical because autonomous workers cannot pause to ask the user questions. The lint command checks Ready issues for clear success criteria and highlights vague requirements before the pipeline is dispatched.
• Blocked and Skipped are explicit human-control states for work that cannot proceed autonomously. Examples mentioned include missing API tokens and payment subscriptions, while the described workflow also stops at genuine human gates or after a maximum of three revisions.
• Parallel Claude Code sessions can keep the board moving while one ticket is caught in a revision loop. The system can work on another issue simultaneously, and the full pipeline can be triggered from a single Telegram message for unattended execution.

Questions & Answers

Q: How does Superboard automate Claude Code development?

Superboard treats a GitHub project board as the control system for an autonomous development pipeline. An orchestrator selects issues from Ready, assigns them to a Builder, moves completed implementations into QA, and then sends passing work to a Reviewer. Failed tests or review objections return the ticket to the Builder with specific feedback, allowing repeated iterations before merging into the develop branch.

Q: How do I install the Superboard skills in a repository?

Download the provided skill package, start a Claude Code session in the existing repository, drag the ZIP file into that session, and ask Claude to unzip it and install the relevant skills in the current repository. After installation, verify that Super Build, Super Board, Super QA, and Super Review appear in the Claude skills folder and that the installation has been committed to the main branch.

Q: How do I onboard a project into Superboard?

Start a new Claude Code session and run the board onboarding command. The onboarding process detects the current repository, checks GitHub authorization, and identifies missing project configuration. Select the full build-feature pipeline, choose or create the GitHub project that Superboard should drain, and specify the branch that should receive autonomous merges, such as a separate develop branch rather than the production branch.

Q: What columns does the autonomous GitHub board need?

The demonstrated board contains Ready, Building, QA, Review, Done, Blocked, and Skipped columns. New actionable tickets begin in Ready, active implementation moves into Building, completed code advances through QA and Review, and accepted work reaches Done. Tickets requiring human action can move to Blocked, while work that should not continue can move to Skipped.

Q: Why should tickets be linted before autonomous dispatch?

Ticket linting verifies that every Ready issue contains sufficiently clear success and acceptance criteria before headless Claude Code workers start. Those workers cannot stop during an unattended run to ask clarifying questions, so vague tickets can prevent reliable execution. The Superboard lint command reviews the issues, identifies missing details, and prompts the user to clarify requirements before the orchestrator begins draining the board.

Q: What happens when QA or code review fails?

A failed QA check does not advance the issue toward completion. Instead, the tester returns the ticket to the Builder with feedback, and the orchestrator assigns it for another implementation attempt. The Reviewer works similarly: objections send the issue back with exact comments. The described workflow repeats these revision loops while preserving QA and review as separate gates, with a maximum of three revisions noted.

Q: When does the pipeline stop and ask for human help?

The pipeline stops treating a ticket as autonomously actionable when it reaches a genuine human gate, becomes blocked, or is skipped. The source gives API tokens and payment subscriptions as examples of requirements that may need human involvement. The described safeguards also include a maximum of three revisions, preventing an issue from looping indefinitely when Builder, QA, and Reviewer cannot reach an acceptable result.

Q: How can Superboard run development work overnight?

Place well-defined issues in the Ready column, lint them to confirm their acceptance criteria, and dispatch the pipeline, including through a single Telegram message. Separate Claude Code sessions can then build, test, and review tickets without continuous supervision. One session may continue revising a failed issue while another works on the next ticket, leaving only completed and blocked work for morning review.

Summary & Key Takeaways

• Superboard converts a GitHub project board into an autonomous development pipeline with Ready, Building, QA, Review, Done, Blocked, and Skipped columns. An orchestrator reads each ticket's current status, assigns the corresponding specialized skill, and advances the work only after that stage completes successfully or returns actionable feedback for another iteration.

• Installation involves adding the provided skill package to an existing repository, asking Claude Code to unzip and install it, and verifying the four skills under the Claude skills folder. The onboarding command then identifies the repository, checks GitHub authorization, creates missing configuration, establishes a project board, and selects a safe base branch.

• Reliable autonomous runs depend on tickets containing explicit success and acceptance criteria. The lint command examines issues in the Ready column, identifies vague requirements, and requests clarification before headless workers begin. Once dispatched, Builder, QA, and Reviewer sessions can operate in parallel, repeat failed stages, and stop when human input is genuinely required.