build

Files (1)

• SKILL.md

SKILL.md (first lines)

# Build

Request: $ARGUMENTS

Settings:
!`${CLAUDE_PLUGIN_ROOT}/scripts/settings.sh 2>&1 || true`

Current branch:
!`git branch --show-current 2>&1 || true`

Run the whole workflow for this request. Each phase is a skill of this plugin: invoke it with the Skill tool and follow it.

## 1. Plan

Compare the current branch above with the target from the settings above. If they differ, a switch is needed: note it for the plan below. If it can't happen (for example the target branch doesn't exist, or local changes block it), stop here and report why — don't create anything.

1. If AskUserQuestion isn't available, no one can approve a plan (headless session): skip plan mode and follow Headless below instead of steps 2 and 3 here. EnterPlanMode and ExitPlanMode are deferred tools, so finding them says nothing about whether a user is there. Otherwise enter plan mode with the EnterPlanMode tool, unless it is already active.
2. Invoke `sdlc:design` with the request. In plan mode, it puts the stated design and the doc edits in the plan file.
3. Exit plan mode with ExitPlanMode. Design states the design; this plan is what the user approves, so write these into it in its own words — a design the plan doesn't name isn't approved, and neither is a setting it doesn't show:
   - the design and the doc edits
   - the branch switch above, if any
   - the integration mode, target branch, parallel limit and default review level, each named with the value from the settings above
   - what happens next: applying the doc edits and committing them if anything changed, splitting the plan into tasks for their approval, and dispatching

   If the user asks for changes, revise the plan and ask again.

Design is one phase of this workflow, not the end of it. Don't stop to report it: go on to Create below, as soon as the plan is approved.

## 2. Create

1. Apply the doc edits from the approved plan.
2. Switch to the target branch if step 1 found a switch was needed — already approved with the plan, so no need to ask again. Then, only if the doc edits changed anything (`git status --porcelain -- *.md`), commit them there: `git add -- *.md`, then `git commit -m <message>`. Tasks live in beads, not git, so doc edits are the only thing to commit. Workers branch from committed code, so uncommitted edits are invisible to them.
3. Invoke `sdlc:split` on the approved plan, so the request becomes exactly one top-level epic (no nested epics — group large work with parent tasks instead). Split shows the task graph and asks the user to approve it. If the user doesn't, stop here. Carry the epic's id to Dispatch below.

## 3. Dispatch

Invoke `sdlc:dispatch` with the epic id from Create. The plan already covered dispatching, the integration mode, target branch, parallel limit and review level, so dispatch doesn't need to ask again. It dispatches the tasks and reports the moment a task needs a person, restarting itself to keep the rest going, until nothing is left.

## Headless

No plan mode, no approvals. Run every step below in this session, in order, and report once at the end:

1. Invoke `sdlc:design` with the request: it states the design in the conversation and makes the doc edits directly. It closes by suggesting `/sdlc:split` as the next step — in this workflow that step is yours to take, not to hand back.
2. Commit the doc edits if anything changed, as in Create above.
3. Invoke `sdlc:split` on the stated design, then `sdlc:dispatch` on the epic it creates, as in Create and Dispatch above. Nothing here waits for approval.

The request is built when the dispatched work has landed, not when the design is written.

From Igosuki/agentic-sdlc, MIT.

More from Igosuki/agentic-sdlc