> ## Documentation Index
> Fetch the complete documentation index at: https://gump.top/sdlc-harness-docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent onboarding

> Help Codex, Claude Code, and other coding agents consistently discover and follow the repository protocol.

SDLC Harness does not depend on a specific agent. Any agent that can read repository files, run commands, and modify code can follow the same protocol.

## New repositories

`init` generates `AGENTS.md` in the repository root. At the start of a task, have the agent read:

1. `AGENTS.md` and the workflow pages it references.
2. The current active, ready, and blocked features in `feature_list.json`.
3. The current feature's `source_refs`, dependencies, and verification.
4. The latest session checkpoint in `progress.md`.

A practical startup prompt is:

```text theme={null}
Read AGENTS.md and follow its Routing Map. Check status and validate.
Advance exactly one ready feature; before completion, run verify, record an independent review,
use feature complete, and run session close before ending the session.
```

## The repository already has `AGENTS.md`

`adopt` does not overwrite the file. It writes `AGENTS.sdlc-harness.md` instead. Add an explicit reference to the original `AGENTS.md`, for example:

```md theme={null}
Before starting any development task, you must also read and follow `AGENTS.sdlc-harness.md`.
```

The `[agents-onboarding]` check in `validate` verifies this discovery chain. Repository validation fails when the sidecar exists but the root protocol does not reference it.

## Claude Code

In addition to the shared `AGENTS.md`, the template generates lightweight entry points under `.claude/skills/` to help Claude Code discover the requirements, architecture, user story, feature decomposition, milestone, TDD, self-acceptance, deployment, and feedback workflows. Repository files remain the final source of truth.

## Multi-agent collaboration

* Use `owner` to identify the responsible party, and `actor` to distinguish separate agent sessions started by that `owner`.
* `claim` uniqueness is always determined per feature; `actor` does not allow two agents to own the same feature at once.
* Each agent works only on features for which it holds a valid `claim`.
* Use `workspace create` to isolate parallel changes in separate `worktree` directories.
* A review agent cannot be the `owner` of the feature's `claim`.
* Run `session close` at the end of every session, and record the next step and any blockers in `progress.md`.

<Tip>
  Before an agent reports completion, ask it to show the actual output from `feature complete`, `validate`, and `session close`, not just a natural-language summary.
</Tip>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.