Agent Blueprint
Get started

Workflow

How a feature moves from idea to pull request.

Each skill hands its work to the next through your repository, and the loop they form is the same for every feature. The drawings below show that loop, what each skill leaves behind, the four pipelines that run long stretches of it for you, and the five quality gates.

Fig. 1

Every feature takes the same loop.

Six steps, from getting oriented to merging the branch, each with its own skills. The loop closes through docs/: what one feature records there, the next session reads first.

  1. Orient

    Load context with ab-project-status or ab-resume-session, or set up with ab-project-start.

  2. Ideate, optional

    ab-ideation reads the codebase, the learnings and the git history and ranks improvement ideas.

  3. Design

    ab-brainstorming lays out the tradeoffs and gets your approval before any code is written.

  4. Plan

    The approved design becomes tasks that record decisions, not code: file paths, each test and what it asserts, signatures, and a review focus list. You review the saved plan. Then deepen it with research (ab-deepen-plan), run it one task at a time (ab-subagent-driven-development or ab-executing-plans), or run it as team work (ab-orchestrate).

  5. Build

    Test-driven development, verification with evidence, and a review from a helper.

  6. Ship

    Merge the branch, update the project docs with ab-session-wrap, and record what was learned for the next session.

Drawing
The development loop
Steps
6
Pipelines
4
Quality gates
5
Skills
53
Source
README.md

Fig. 2

Each skill leaves something the next one reads.

What a skill leaves is a design, a plan, commits, review findings or a handoff note. Most of it is files in your repository, so a new session or a different tool can pick up where the last one stopped.

  1. leaves docs/plans/<date>-<topic>-design.md, The design you approved, section by section

    Read by

  2. leaves docs/plans/<date>-<feature>.md, The plan, saved for review before anything runs

    Read by

  3. leaves one commit per task, The work, committed task by task

    Read by

  4. leaves findings by priority, Each finding ranked from must-fix to suggestion

    Read by

  5. Into the next session

    leaves docs/context/STATUS.md, The handoff note: what was done, what is left, where to start

    Read by

  6. leaves docs/solutions/, One document per solved problem, with its root cause and search terms

    Read by

Fig. 3

Four pipelines run the skills in order for you.

A pipeline is a skill that starts other skills, stage by stage. Pick one by how much of the work you want to watch. Each line below is one pipeline's stages, with the skill each stage runs.

ab-build-pipeline

Use it forA feature you approve stage by stage

Runs a feature through eight supervised stages (discuss, brainstorm, plan, execute, review, verify, optional deploy check, knowledge capture) with a checkpoint after each

A checkpoint after every stage

  1. Discuss
  2. Brainstorm
  3. Plan
  4. Execute
  5. Review
  6. Verify
  7. Deploy check, optional
  8. Compound

ab-ship-pipeline

Use it forA well-defined feature you want built hands-off

Ships a feature end to end with no checkpoints, tracked in .agent-blueprint/run/state.json; the ship runner drives it unattended

Eight stages

  1. InitializePicks up an earlier run at the stage that needs work
  2. RequirementsLocks assumptions as decisions in docs/context/DECISIONS.md
  3. Plan
  4. Deepen plan
  5. Execute
  6. Iterative review
  7. Compound
  8. Ship itCommits and writes the pull request body
Unattended runs guide

ab-quick-fix

Use it forUnder three files, obvious approach

A small, well-understood change through a short test-first loop, then a commit on a branch

Five stages

  1. QualifyUnder three files, obvious approach
  2. Failing test
  3. FixThe least code that makes the test pass
  4. VerifyThe whole test suite, the build and the linter
  5. CommitOne commit on a branch

ab-orchestrate

Use it forFour or more tasks, some independent

Runs a plan as team work: ledger, dependency-ordered waves, file ownership or worktrees, lead-only commits, review and sign-off

Six stages

  1. LedgerThe plan as a task list in .agent-blueprint/team/<run>/
  2. WavesOne helper per task; tasks that share a file never share a wave
  3. Lead commitsOnly the lead commits each finished task
  4. Integration checkAfter every wave
  5. Review, optional
  6. Sign-off, optionalOnce the P1 findings are fixed
Team work and swarms guide

Fig. 4

Five quality gates hold at every stage.

Each rule names what has to happen first, and one skill enforces it.

  1. No code without design approval

    Enforced by

  2. No production code without a failing test first

    Enforced by

  3. No fix without a root cause investigation

    Enforced by

  4. No completion claim without fresh verification evidence

    Enforced by

  5. No merge without code review

    Enforced by

Every skill, by phase.

The README sorts every skill into a phase. A skill's name opens its page, and a phase opens the catalog filtered to it.

53 skills, nine phases

Pipelines, 4 skills

Design, 8 skills

Execution, 7 skills

Quality, 9 skills

Completion, 5 skills

Session management, 8 skills

Operations, 7 skills

Orchestration primitives, 2 skills

Meta, 3 skills