Get started

See the process.
Then make it yours.

Start with a read-only source evaluation. No AI subscription or API key is required to inspect roles, validate records or preview adoption. AI-assisted execution requires a supported client and any subscription or API access it needs.

Explore without installing

Understand the decision loop.

Compare routine, cross-team and sensitive work in the illustrative model. See why missing evidence changes the next step.

Try the workflow illustration →

Run it locally

Inspect a real adoption plan.

Use the implemented CLI to examine roles and exact proposed changes before approving any project writes.

Start the source evaluation ↓

1. Get the implemented source.

Use the verified 2.0 implementation revision. These commands work in PowerShell and a POSIX shell.

Source checkout
git clone https://github.com/smota/agentflow-sdlc.git
cd agentflow-sdlc
git checkout a54d693258821832af8dad59e629fce1a3d6b5d7
pnpm install --frozen-lockfile

A local, reproducible checkout. Nothing is installed globally.

2. Inspect the roles.

Run a command that reads the shipped role catalog. No project setup or model call is needed.

Role inspection
node bin/cli.mjs roles catalog --json

JSON describing the nine lifecycle roles and optional QA expert, with their inputs, outputs and boundaries.

3. Preview your project.

Replace ../my-project with the path to your repository. Keep paths containing spaces inside quotes. Both commands below are read-only for that project.

Read-only project preview
node bin/cli.mjs doctor-env --target "../my-project"
node bin/cli.mjs adopt plan --profile standard --target "../my-project" --json

An environment report and a plan listing proposed actions, conflicts and a plan token. No target files are applied.

4. Ask your assistant for a proposal.

The generated onboarding prompt asks your assistant to inspect existing conventions and propose a setup before writing.

Onboarding prompt
node bin/cli.mjs onboarding-prompt --target "../my-project"

A review-first setup brief for your preferred assistant. Review its proposal before authorizing changes.

Adopt with an explicit boundary.

Apply a reviewed plan

Resolve all conflicts first. Use the current plan token and put the receipt outside the target repository. Replace both placeholders with your reviewed values.

Approved adoption
node bin/cli.mjs adopt apply --profile standard --target "../my-project" --confirm "<plan-token>" --receipt "../agentflow-receipt.json" --json

Apply stages writes, writes lockfile v2 last and rolls back if the operation fails. A changed target invalidates the plan.

Verify the result
Adoption verification
node bin/cli.mjs adopt plan --profile standard --target "../my-project" --json
node bin/cli.mjs sdlc validate --target "../my-project" --json
node bin/cli.mjs sdlc validate-authority --target "../my-project" --json

Then run your project's own validation commands. Commit only reviewed generated files and the lockfile; keep the external receipt out of Git.

Roll back or recover

Use the receipt token to request rollback. Rollback refuses files that have changed since apply. An interrupted transaction requires explicit recovery; it is never silently retried.

Read exact rollback and recovery commands ↗

Review legacy state before fresh adoption.

2.0 removes old install/update commands, v1 lockfile support and the static harness capability matrix. There is no automatic in-place v1 conversion and no compatibility shim.

  1. Preserve your current project.

    Commit or back up its existing state. Evaluate 2.0 from a separate source checkout.

  2. Review what the old setup owns.

    Identify old managed files and local policy. Remove or replace legacy state only through an explicit, reviewed change. Do not delete project-owned instructions blindly.

  3. Preview a fresh 2.0 adoption.

    Choose a composition profile, inspect the proposed actions and resolve conflicts. Apply only the reviewed current plan.

Read the breaking-change record ↗

Common questions

A small start.
No hidden prerequisites.

Do I need to run several AI agents?

No. Single-agent execution is the default. Roles separate responsibilities; they do not force a separate agent or paid account for every phase.

Does AgentFlow make software delivery fully automatic?

No. It provides explicit contracts and checks. Your selected harness executes the work, specialists own judgment, and humans retain consequential approval.

What if a harness capability is unavailable?

The provider records availability and limits. An explicitly permitted sequential or manual fallback can be used. If the capability is required, the plan is blocked rather than silently weakened.

Is the website example executing my project?

No. It is a local illustrative interaction. It makes no model calls, reads no repository and uploads no project content.

Where should technical users go next?

Complete documentation, provider authoring and role methods describe the current implementation and extension contracts.

Preview scope

Evaluate the baseline. Track the delivery update.

The pinned source checkout above is the existing evaluation baseline. It does not include the new run workflow or project-contained receipt storage. Those improvements are in local implementation and validation, with release acceptance still pending.

Available baseline

Use the documented source checkout and preview adoption before changing your repository. The external-receipt instructions above apply to that baseline.

Next delivery update

Current-invocation checks, guarded recovery, environment inspection and project-contained transactions are being added for 2.0.

Before release

Require the packaged consumer checks, supported-platform validation and actual human review. No npm 2.0 release or live-provider certification is implied.

Development preview · release acceptance pending · AgentFlow requires a supported AI client and any necessary subscription or API access.