AgentFlow SDLC

AgentFlow SDLC is an open-source process layer for AI-assisted software delivery. It makes agent work understandable, reviewable, resumable, and safe to ship through GitHub.

AI assistants can write code quickly. AgentFlow helps teams keep the surrounding delivery system clear: what was requested, why decisions were made, what changed, what was validated, who reviewed it, and what should happen next.

This repository is both the distributable framework and a live example of the workflow in use. Its own issues, workflow-status comments, handover comments, PR manifests, hooks, and validators demonstrate the intended operating model.

What this is

AgentFlow SDLC is a process layer for software projects that use AI coding agents. It does not generate an application or dictate your tech stack. Instead, it installs a repeatable delivery system around your existing project:

role-based phases from analysis through PR readiness;
default single-agent execution with optional role routing to other agent CLIs;
deterministic issue, branch, commit, and PR contracts;
local hooks and validators that catch workflow drift early;
reusable templates for role passes, workflow status, handovers, and PR bodies;
optional extension packs for reusable engineering approaches and handoff governance;
project-local configuration for stack-specific commands, bounded work, routing, and conventions.

Use it when you want agent-assisted work to be reviewable, auditable, and easy to resume instead of being hidden in one chat session.

Why this matters now

AI-native engineering has created a new failure mode: the code may be fast, but the work can become hard to understand. Important requirements, architecture tradeoffs, validation evidence, and review boundaries often remain trapped in a single LLM conversation. That makes adoption harder for teams that need GitHub history, compliance evidence, repeatable handoffs, or clear human approval gates.

AgentFlow SDLC turns that hidden session work into a visible delivery path. It keeps humans and agents on the same contribution contract, stores durable evidence in GitHub, and uses local validators and templates to reduce process drift.

Read the short overview: docs/agentflow-in-5-minutes.md.

Fastest path: LLM-assisted onboarding

Adding this to an existing project is easiest with the LLM-assisted onboarding guide. The assistant inspects existing instructions, validates tools read-only, asks you to choose agents and workflow defaults, proposes setup commands, and preserves project-specific conventions before any installation runs.

Copy this prompt into your agent:

Use the AgentFlow SDLC assisted onboarding guide:
https://github.com/smota/agentflow-sdlc/blob/main/docs/assisted-onboarding.md

Apply it to this existing project. First inspect existing agent instructions and project docs. Validate the environment read-only. Ask me to choose agents, execution mode, branch strategy, validation commands, and GitHub automation. Propose install/setup commands but do not execute them without explicit approval. Preserve or merge existing instructions instead of overwriting them.

Prefer command output? Print the same LLM onboarding message locally:

node bin/cli.mjs onboarding-prompt --target /path/to/your-project

See docs/assisted-onboarding.md and docs/environment-tools.md. The environment guide documents required, recommended, and optional tools compatible with doctor-env.

Already adopted this framework? Use the LLM-assisted update path in docs/assisted-update.md, or print it with node bin/cli.mjs update-prompt --target /path/to/your-project, to plan a read-only, approval-gated update before running sync. Manual commands remain available as a reference path, but the recommended evaluation experience is assistant-guided inspection first. The proposed next step is a deterministic update-plan flow documented in docs/deterministic-assisted-update.md.

How the workflow becomes evidence

flowchart LR
  Request["Request or GitHub issue"] --> Analyze["Analyst: acceptance criteria"]
  Analyze --> Architect["Architect: approach and risk"]
  Architect --> Plan["Developer planning: files and checks"]
  Plan --> Build["Developer: scoped implementation"]
  Build --> Test["Tester: validation evidence"]
  Test --> Review["Review: self-review or human gate"]
  Review --> Docs["Tech writer: docs decision"]
  Docs --> PR["PR readiness: manifest"]
  PR --> Evidence["GitHub issue comments, commits, and PR body"]

See docs/agentflow-in-5-minutes.md and the examples in docs/examples/ for concrete issue, review, and PR evidence shapes.

Who it is for

This framework is for AI engineering teams, platform / DevEx teams, open-source maintainers, compliance-minded product teams, and solo maintainers who want agentic development to be manageable, auditable, and easier to reason about:

compliance-minded teams that need durable evidence for AI-assisted work;
maintainers coordinating multiple agents, sessions, or contributors without losing context;
engineers who want less cognitive burden from remembering every branch, PR, handover, and review rule;
projects that need one consistent way to run issues with Claude, Codex, Agy, Pi, or humans;
teams that want PRs to explain what happened, why it happened, what was validated, and what remains;
organizations that need safe defaults for branch discipline, self-review, and high-assurance human review;
projects that want optional multi-agent handoffs without ad hoc discovery or undocumented routing;
teams that want reusable local skills/tooling synced across repositories.

What it is not

Not an app generator: it does not create your product or choose your stack.
Not a GitHub replacement: it uses issues, comments, commits, and PRs as the durable evidence plane.
Not multi-agent theater: single-agent execution is the default; optional multi-agent routing is explicit and evidenced.
Not a blind installer: onboarding and updates start with LLM-assisted, read-only inspection and require approval before setup or sync commands run.

Why these choices

The framework is intentionally structured as a control system for agent-assisted delivery, not as ceremony for its own sake.

Core Tenets Matrix

Tenet	Problem Addressed	AgentFlow Solution
Traceability	Context loss across ephemeral chat sessions.	Durable state in GitHub issues, PR manifests, and commits.
Predictability	Agents skipping steps or inventing undocumented processes.	A machine-checkable, role-based phase state machine.
Efficiency	Wasted token context, API calls, redundant data transfer.	Single-agent default; Dual-Write handoffs & Architect Sprints.
Compliance	Opaque code generation without clear boundaries or review.	Built-in review rules, PR manifests, and validation hooks.
Parity	Agents and humans following different contribution rules.	Exact same public contribution contract for humans and agents.

Human and Agent Parity

A core rule of AgentFlow SDLC is Human/Agent Parity. Humans and agents use the exact same public contribution contract. Agents do not get a "shortcut" past review gates or phase completions, and humans do not skip workflow-status updates. This parity ensures all work is equally verifiable, auditable, and seamlessly interchangeable regardless of the executor.

Roles reduce ambiguity. Analyst, architect, developer, tester, reviewer, tech writer, and PR-readiness passes each have a small job. That keeps the agent from mixing product decisions, implementation, validation, and review into one opaque step.
Single-agent execution is the default. One executor carrying context end to end reduces coordination overhead and avoids recreating a noisy multi-agent process for routine work.
Optional routing supports specialization. Projects can route roles to agy, codex, claude, or pi when it helps, but owners, fallbacks, and handovers are documented so agent availability or quota issues do not turn into on-the-fly process design.
Multi-agent claims are evidenced, not assumed. A run that claims multi-agent mode must show its SDLC roles actually alternated across independent intelligences — a role attribution matrix, not just one Implemented by field. See docs/agent-workflow.md §4a.
Execution targets are explicit, not inferred from chat. A bare with claude/with agy/with pi names who is being asked, not how the work runs (local CLI, provider API, subagent, or a separate session/worktree). See docs/execution-targets.md.
Locally managed skills reduce setup drift. Workflow skills and tooling live with the project so agents do not have to rediscover commands, templates, or handoff rules on every run.
Issue comments and PR manifests support compliance. Workflow-status comments, handover comments, and PR manifests create durable evidence that survives session loss and can be reviewed by humans later.
Hooks and validators reduce cognitive load. Branch checks, manifest validation, bounded-work checks, and workflow verification let humans and agents rely on executable guardrails instead of memory.
Follow-up issues prevent hidden drift. Non-blocking findings are tracked as issues rather than buried as TODOs or lost in chat context.

See docs/index.md for the detailed map of roles, workflows, templates, hooks, validators, and defaults.

What is included

Area	Files
Policy	`AGENTS.md`, `CLAUDE.md`, `CODEX.md`, `AGY.md`
Workflow docs	`docs/agentflow-in-5-minutes.md`, `docs/agent-workflow.md`, `docs/issue-standards.md`, `docs/project-config.md`, `docs/agent-routing.md`, `docs/execution-targets.md`, `docs/index.md`
Onboarding/update docs	`docs/assisted-onboarding.md`, `docs/assisted-update.md`, `docs/deterministic-assisted-update.md`, `docs/environment-tools.md`, `docs/project-setup.md`, `docs/default-skills.md`
Skills/workflows	`agents/workflows/orchestrate/SKILL.md`, `agents/workflows/scan/SKILL.md`
Templates	`agents/templates/role-pass.md`, `pr-manifest.md`, `workflow-status-comment.md`, `handover-comment.md`, `stack-conventions.md`
Hooks	`.github/hooks/*` branch checks, session status, commit readiness, formatting support
Validators	`scripts/validate-spec.mjs`, `validate-bounded.mjs`, `validate-pr-manifest.mjs`, `validate-role-routing.mjs`, `validate-role-attribution.mjs`, `resolve-execution-target.mjs`
Examples	`docs/examples/simple-bugfix-flow.md`, `docs/examples/multi-agent-review-flow.md`, `docs/examples/high-assurance-flow.md`
Extension packs	`extensions/evidence-driven-engineering`, `extensions/agent-handoff-governance`
Distribution	`bin/cli.mjs`, `lib/install.mjs`, `lib/framework-files.mjs`, `agent-framework-lock.json` in consuming repos

Defaults

Execution: single-agent by default.
Roles: product/JTBD when needed, analyst, architect, developer planning, developer, tester, review, tech writer, PR readiness.
Routing: optional; projects may route roles to agy, codex, claude, or pi with fallbacks.
Execution targets: deterministic per agent (claude-cli/anthropic-api, agy-cli/agy-session, pi-parent/pi-subagent/pi-session/pi-subagent-model, codex-cli/provider-api); ambiguous requests resolve from project config or require a clarifying question, never silent inheritance.
Evidence: GitHub issue comments and PR bodies are durable; .agent-runs/ files are local scratch and are not committed.
Review: bounded/standard work may use explicit self-review; high-assurance work requires human review before merge.
Branching: use the project branch strategy from docs/agent-workflow.md and agent-workflow.config.json; do not edit protected integration/trunk branches directly.
Follow-ups: create follow-up issues instead of hidden TODOs or silent omissions.
Extension packs: evidence-driven-engineering and agent-handoff-governance are available for repositories that want stricter decision, evidence, and handoff discipline.

License

Licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

Contribute

This is the canonical contributor entry point for this repository. It is for both human contributors and agent contributors. It summarizes the expected path, but it is not the policy authority. Before doing issue work, architecture proposals, file writes, commits, PR readiness, or gate decisions, follow the reading order in AGENTS.md: repository policy, the active adapter (CLAUDE.md, CODEX.md, AGY.md, or equivalent), docs/agent-workflow.md, docs/issue-standards.md, then the active issue or SPEC.md.

Required principles

Issue-first work: start from a GitHub issue or explicit maintainer direction. If the work needs a new issue, use the title and label rules in docs/issue-standards.md.
Deterministic phases: run the workflow phases that apply, record role-pass evidence, and keep durable state in GitHub issue comments, PR bodies, commits, and closure metadata.
Bounded branches: do implementation work on a short-lived work branch allowed by docs/agent-workflow.md and agent-workflow.config.json; do not edit protected integration or trunk branches directly.
Evidence-backed validation: every contribution names the commands or manual checks used to verify it, or explains why a check was not applicable.
Follow-ups over drift: useful out-of-scope findings become follow-up issues instead of hidden TODOs, silent omissions, or unapproved scope expansion.
Safety: never include secrets, credentials, tokens, or private local-only data in issues, PRs, commits, workflow evidence, or handover comments.
Human and agent parity: humans and agents use the same public contribution contract; agent-specific evidence requirements are linked from this section rather than duplicated here.

Contributor workflow

Choose or open an issue. Confirm the issue has a valid Conventional Commit title, a primary type/domain label, and drafted-by:<agent> when an agent drafted it. For new issues, include acceptance criteria, a test plan or validation plan, open questions, and workflow classification.
Plan the work. Read the required policy documents, classify the workflow profile, identify files likely to change, and decide which checks will prove the change. Use docs/project-config.md and agent-workflow.config.json for project-specific branch, validation, routing, and bounded-work rules.
Create a work branch. Prefer work/<theme>, feature/<theme>, fix/<theme>, hotfix/<theme>, or spike/<theme> unless project configuration says otherwise.
Implement narrowly. Keep commits issue-scoped. Do not rewrite governance, templates, or unrelated docs unless the issue explicitly includes that scope.
Validate. Run the relevant repository checks, such as pnpm test, pnpm test:workflow, pnpm format:check, node scripts/validate-role-routing.mjs, or a focused validator named by the issue. Record exact commands and outcomes.
Open the PR. Use agents/templates/pr-manifest.md. For PRs into an integration branch, use Implements #<issue> lines; for PRs into default/trunk when GitHub should auto-close the issue, use Closes #<issue>. Include workflow evidence, validation status, agent review fields, merge owner, and follow-up issue status.

Template and checklist decisions

The canonical Contribute section uses existing workflow templates instead of creating new contributor templates here:

Contributor need	Decision	Source
New contributor quickstart checklist	`include-inline`	`README.md#contribute`
Issue selection / issue creation checklist	`link-existing`	`docs/issue-standards.md`
Branch naming checklist	`link-existing`	`docs/agent-workflow.md`, `agent-workflow.config.json`
PR body checklist	`link-existing`	`agents/templates/pr-manifest.md`, PR readiness rules in `docs/agent-workflow.md`
Validation evidence checklist	`include-inline`	contributor workflow step 5
Follow-up issue checklist	`include-inline`	required principles and contributor workflow

Quick checklist

I have an issue or explicit maintainer direction.
I read AGENTS.md, the active adapter, workflow docs, issue standards, and the active issue/spec.
I am on an allowed work branch, not a protected integration/trunk branch.
My change is scoped to the issue and records follow-ups for anything outside scope.
I ran the relevant validation commands or documented why they were not applicable.
My PR body uses the project manifest, the correct issue reference keyword, workflow evidence, validation evidence, agent review fields, merge owner, and follow-up status.

Install / initialize in a project

1. Add skills/tooling

Install the skill-shaped workflow content using your preferred skill mechanism. For example, when using a skill installer:

npx skills add https://github.com/smota/agentflow-sdlc

This makes the workflow skills available to supported agents. The exact destination depends on the consuming agent/tooling setup.

2. Install framework files

From a checkout of this repository, initialize another project:

git clone https://github.com/smota/agentflow-sdlc.git
cd agentflow-sdlc
pnpm install
node bin/cli.mjs init --target /path/to/your-project

init installs framework-owned files and seeds project-owned starter files such as AGENTS.md and docs/stack-conventions.md once.

3. Commit the lockfile in the consuming project

cd /path/to/your-project
git add agent-framework-lock.json AGENTS.md docs/stack-conventions.md
git commit -m "chore: initialize agent SDLC framework"

The lockfile lets future syncs update unmodified framework files safely.

4. Configure your project

Create or update agent-workflow.config.json in the consuming project. Start with CI commands and bounded-work settings:

{
  "ciCommands": ["pnpm lint", "pnpm test", "pnpm build"],
  "bounded": {
    "allowedExactPaths": ["README.md"],
    "allowedPathPrefixes": ["docs/", "src/"],
    "deniedPathFragments": ["/auth/", "/billing/", "/migrations/"]
  }
}

See docs/project-setup.md for a guided setup checklist and docs/project-config.md for the complete configuration contract.

5. Choose project defaults

Before the first real issue, make these choices explicit:

enabled agents (claude, codex, agy, pi);
execution mode: keep the single-agent default or allow optional multi-agent role routing;
role owners and fallbacks when routing is enabled;
per-agent defaultExecutionTarget (e.g. claude-cli vs anthropic-api) so a bare with <agent> resolves deterministically — see docs/execution-targets.md;
branch strategy and protected branches;
CI-equivalent validation commands;
bounded-work and sensitive-path rules;
skill provenance and local overrides;
GitHub integration automation for closing issues when PRs merge to the integration branch;
release versioning strategy: default main.minor.fix, custom tag format, package version source, and approval expectations.

Use docs/project-setup.md for copyable examples, docs/default-skills.md for skill provenance, docs/release-versioning.md for release choices, and the validators listed in those docs to check the setup. The installed GitHub workflow .github/workflows/integration-lifecycle.yml uses scripts/integration-lifecycle.mjs to comment, label, and close issues referenced with implementation/closure keywords such as Implements #... or Closes #... after a PR merges into the configured integration branch. Related references such as Refs #... are ignored by lifecycle automation.

Validate local tooling without installing anything:

node bin/cli.mjs doctor-env --target /path/to/your-project
node bin/cli.mjs doctor-env --target /path/to/your-project --json

doctor-env is read-only. It reports found/missing tools and proposes installation options, but it never runs install commands.

Sync / update framework files

For already-adopted projects, start with the assisted update workflow so the agent/operator inspects the lockfile, classifies conflicts, and asks for approval before writing:

node /path/to/agentflow-sdlc/bin/cli.mjs update-prompt --target /path/to/your-project

If the adopting project predates the AgentFlow SDLC rename, check and apply the narrow rename migration before sync:

node /path/to/agentflow-sdlc/bin/cli.mjs migrate-rename --target /path/to/your-project
node /path/to/agentflow-sdlc/bin/cli.mjs migrate-rename --target /path/to/your-project --write

Run sync whenever this framework changes and the update plan is approved:

node /path/to/agentflow-sdlc/bin/cli.mjs sync --target /path/to/your-project

Inspect drift without writing files:

node /path/to/agentflow-sdlc/bin/cli.mjs doctor --target /path/to/your-project

sync updates framework files only when they are unchanged since the last install/sync. Local project edits are reported as conflicts instead of being overwritten. sync also seeds missing seed-once project files such as AGENTS.md and docs/stack-conventions.md without touching them after they exist.

If you hand-merge framework adapter content into a project-owned file at a framework path, do not register that file as a normal tracked hash. Mark it as permanently hand-merged instead:

node /path/to/agentflow-sdlc/bin/cli.mjs mark-merged CLAUDE.md --target /path/to/your-project

Marked files show separately in sync/doctor output and are never fast-forwarded over local additions.

Day-to-day usage

1. Create or choose an issue

Use the issue standards in docs/issue-standards.md. Agent-created issues should use the required type and lifecycle labels.

Prompt example:

Create a feature request for adding CSV import validation. Include acceptance criteria, test plan, open questions, and workflow classification.

2. Start a work branch

Use the configured branch strategy. A common default is a short-lived work branch:

git checkout development
git checkout -b work/csv-import-validation

3. Run the orchestrator

Ask the agent to run the issue through the workflow:

orchestrate #123

Issue Lifecycle Flowchart

flowchart TD
  Issue["GitHub issue / SPEC.md"] --> Roles["Phase 1-8 Execution"]
  Roles --> Artifacts["Local Role-Pass / Scratch Artifacts"]
  Artifacts --> Compliance["Workflow-status & Handover Comments"]
  Compliance --> Commit["Issue-Scoped Commit"]
  Commit --> PR["PR Manifest & CI Validation"]
  PR --> Merge["Human Review / Auto-Merge"]

The orchestrator should:

read AGENTS.md, the adapter, workflow docs, and the issue;
classify the work;
execute the role phases;
write role-pass evidence locally;
post/update workflow-status and handover comments on the issue;
run validation;
prepare the PR manifest;
commit, push, and open a PR with explicit Implements #123 lines for integration-branch PRs.

For multiple IDs in one request, such as orchestrate #123 #124 #125, the orchestrator processes the IDs in order and opens the PR after the final requested issue is complete.

4. Review and merge the PR

The PR body should include workflow evidence, validation results, agent review fields, merge owner, and follow-up status. A human/operator merges by default. If you explicitly want auto-merge after checks pass, tell the orchestrator to use the standard command:

gh pr merge --squash --delete-branch --auto

For high-assurance work, open the PR first, then request human security/acceptance review before merge.

Copy-paste prompt examples

Product discovery and shaping

Brainstorm before creating issues:

Brainstorm a feature for improving onboarding for first-time maintainers. Ask clarifying questions, identify the job-to-be-done, risks, non-goals, and likely acceptance criteria before opening any issues.

Turn an idea into a feature request:

Turn this idea into a product-ready feature request: <idea>. Include user value, acceptance criteria, non-goals, open questions, and a suggested workflow classification.

Break a feature into an epic and child issues:

Break this feature request into an epic and ordered child issues. Identify dependencies, parallelizable work, validation needs, and any high-assurance review gates.

Create GitHub issues with this project's standards:

Create GitHub issues for this epic using our issue standards, labels, acceptance criteria, workflow classification, and test plans.

Orchestration

Run one issue:

orchestrate #123

Run multiple issues and open one final PR after the last ID:

orchestrate #123 #124 #125 as one coherent workstream; defer PR creation until the final issue is complete.

Ask for PR readiness:

Run PR readiness for #123. Verify the PR body, integration references, workflow evidence, validation status, handover comments, and GitHub checks.

Optional scenarios

Run exploratory QA with the optional qa-expert sidecar role:

Plan an exploratory QA session for #123 using the qa-expert role. Focus on negative paths and boundaries not covered by the deterministic tester phase. Record findings as linked issues and apply needs-test to bugs that require regression automation.

Run a focused scan before implementation:

/scan "scan workflow scripts for branch-policy assumptions before implementation; summarize risks, affected files, and recommended follow-up issues"

Use configured routing only when it helps:

Use the configured role routing for #123. If the selected owner is unavailable, record the fallback in the handover comment and continue with the configured fallback.

Stay single-agent unless delegation adds value:

Keep this single-agent unless broad discovery or advisory review would materially reduce risk; if you delegate, validate the output before using it.

Create a follow-up instead of drifting scope:

Create a follow-up issue for the non-blocking docs gap found during review. Include acceptance criteria and a test plan.

Development integration and promotion

Close implementation tracking when work reaches the integration branch:

After this PR merges to development, mark linked issues integrated and prepare a promotion summary for development -> main.

Create a promotion issue:

Create a promotion issue for the current development branch: list integrated PRs, linked issues, validation needed before main, and release notes.

Live example: this repository

This repository uses its own process. Look at its GitHub issues and PRs for examples of:

feature requests with acceptance criteria and test plans;
workflow-status comments on issues;
role handover comments;
PR manifests with Closes #... lines;
validation evidence such as pnpm test, pnpm test:workflow, and pnpm format:check;
follow-up issues for deferred work.

Because the framework is developed using itself, the repo is the best live reference for expected behavior.

Documentation map

Start with docs/index.md for the full documentation index.

Key references:

AGENTS.md — repository policy authority
docs/agent-workflow.md — phases, role-pass contract, evidence, branch and PR rules
docs/issue-standards.md — issue titles, labels, and issue body updates
docs/project-setup.md — guided project choices for agents, mode, branches, validation, and bounded work
docs/project-config.md — agent-workflow.config.json
docs/default-skills.md — default skills, upstream sources, and provenance notes
docs/agent-routing.md — optional role routing and handovers
agents/workflows/orchestrate/SKILL.md — orchestrator workflow
agents/workflows/scan/SKILL.md — advisory scan workflow

Common mistakes

Starting without AGENTS.md: stop and restore/document policy authority first.
Committing .agent-runs/: these are local scratch artifacts and should stay uncommitted.
Opening a PR with only Closes #123: use the PR manifest structure.
Skipping handover comments: role transitions need issue-visible handover evidence.
Treating routing as required: routing is optional; single-agent execution is the default.
Claiming multi-agent mode without a role attribution matrix: Mode: multi-agent with only one role intelligence, or with developer/review sharing an intelligence and no self-review disclosure, fails validate-pr-manifest.mjs.
Leaving TODOs in code/docs: create follow-up issues instead.

Verifying this repository

pnpm install
pnpm test
pnpm test:workflow
pnpm format:check

Additional checks:

node scripts/verify-hooks.mjs
node scripts/validate-role-routing.mjs
node scripts/validate-pr-manifest.mjs --path .agent-runs/issues/<issue>/pr-manifest.md

Name		Name	Last commit message	Last commit date
Latest commit History 53 Commits
.agy		.agy
.claude		.claude
.codex		.codex
.github		.github
agents		agents
bin		bin
docs		docs
extensions		extensions
lib		lib
scripts		scripts
.gitattributes		.gitattributes
.gitignore		.gitignore
.prettierignore		.prettierignore
AGENTS.md		AGENTS.md
AGY.md		AGY.md
CLAUDE.md		CLAUDE.md
CODEX.md		CODEX.md
LICENSE		LICENSE
README.md		README.md
agent-workflow.config.json		agent-workflow.config.json
package.json		package.json
pnpm-lock.yaml		pnpm-lock.yaml
prettier.config.js		prettier.config.js
vitest.config.mjs		vitest.config.mjs

Folders and files

Latest commit

History

Repository files navigation

AgentFlow SDLC

What this is

Why this matters now

Fastest path: LLM-assisted onboarding

How the workflow becomes evidence

Who it is for

What it is not

Why these choices

Core Tenets Matrix

Human and Agent Parity

What is included

Defaults

License

Contribute

Required principles

Contributor workflow

Template and checklist decisions

Quick checklist

Install / initialize in a project

1. Add skills/tooling

2. Install framework files

3. Commit the lockfile in the consuming project

4. Configure your project

5. Choose project defaults

Sync / update framework files

Day-to-day usage

1. Create or choose an issue

2. Start a work branch

3. Run the orchestrator

Issue Lifecycle Flowchart

4. Review and merge the PR

Copy-paste prompt examples

Product discovery and shaping

Orchestration

Optional scenarios

Development integration and promotion

Live example: this repository

Documentation map

Common mistakes

Verifying this repository

About

Topics

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases 8

Contributors

Uh oh!

Languages