# Harness Readiness Assessment

*Is your project ready for harness engineering? Use this checklist to find out.*

Score each item: check the box if your project meets the criterion. Your total score determines your readiness level and recommended starting point.

---

## Category 1: Codebase Foundation (10 items)

- [ ] **Version control.** The project uses Git (or equivalent) with a clear branching strategy.
- [ ] **Build from clean checkout.** A new developer can clone the repo and build successfully by following documented steps.
- [ ] **Dependencies are pinned.** Package versions are locked (lockfile exists and is committed).
- [ ] **No secrets in the repo.** Credentials, API keys, and tokens are managed via environment variables or a secrets manager, not committed to the repo.
- [ ] **Consistent code style.** A formatter is configured (`dotnet format`, EditorConfig, Prettier, etc.) and the codebase follows it.
- [ ] **Linter / analyzers are configured.** Roslyn analyzers, PSScriptAnalyzer, ESLint, or equivalent runs without errors.
- [ ] **Type checking / strict build (if applicable).** `<Nullable>enable</Nullable>` + `<TreatWarningsAsErrors>true</TreatWarningsAsErrors>` in `*.csproj`, TypeScript strict mode, or equivalent is enabled and passing.
- [ ] **Modular architecture.** The codebase has clear module/package boundaries, not a single monolithic file.
- [ ] **README with setup instructions.** A developer can go from zero to running the project by following the README.
- [ ] **No major known bugs blocking development.** The project is in a stable enough state for agents to work on.

**Category 1 Score: ___ / 10**

---

## Category 2: Testing (8 items)

- [ ] **Tests exist.** The project has at least some automated tests.
- [ ] **Tests pass.** All existing tests pass on the main branch right now.
- [ ] **Tests run in under 5 minutes.** The full test suite completes fast enough for iterative development.
- [ ] **Test command is a single command.** Running tests is one command (e.g., `dotnet test`, `Invoke-Pester`, `pnpm test`), not a multi-step process.
- [ ] **Tests are deterministic.** Tests don't fail randomly due to timing, external services, or order dependence.
- [ ] **Test coverage is measured.** You know your current coverage percentage.
- [ ] **Test coverage is above 50%.** At least half the codebase has test coverage.
- [ ] **Tests cover critical paths.** The most important business logic has dedicated test cases.

**Category 2 Score: ___ / 8**

---

## Category 3: Documentation (6 items)

- [ ] **Architecture is documented somewhere.** There is a document, diagram, or wiki page that explains how the system is structured.
- [ ] **API contracts are defined.** API endpoints have documented request/response schemas (OpenAPI, GraphQL schema, etc.).
- [ ] **Key decisions are recorded.** Major architectural decisions are documented (ADRs, design docs, or at minimum, comments explaining "why").
- [ ] **Conventions are written down.** Coding conventions, naming patterns, and project-specific rules exist in written form (even if informal).
- [ ] **Onboarding documentation exists.** A new team member has a document to read to understand the project.
- [ ] **Documentation was updated in the last 3 months.** The docs are not completely stale.

**Category 3 Score: ___ / 6**

---

## Category 4: CI/CD (6 items)

- [ ] **CI pipeline exists.** Commits or PRs trigger automated checks.
- [ ] **CI runs tests.** The test suite runs automatically on every PR.
- [ ] **CI runs linting.** Code style and lint checks are part of the pipeline.
- [ ] **CI blocks on failure.** PRs cannot be merged if CI fails (branch protection is enabled).
- [ ] **CI runs in under 10 minutes.** The pipeline is fast enough to provide timely feedback.
- [ ] **Deployment is automated.** There is a defined deployment process (not necessarily continuous deployment, but not purely manual).

**Category 4 Score: ___ / 6**

---

## Category 5: Team Readiness (5 items)

- [ ] **At least one person has used an AI coding tool.** Someone on the team has hands-on experience.
- [ ] **The team is open to trying AI tools.** There is no active resistance to AI-assisted development.
- [ ] **Code review is a standard practice.** PRs are reviewed before merging, providing a natural checkpoint for agent-generated code.
- [ ] **The team communicates about conventions.** There is a culture of discussing and agreeing on how things should be done.
- [ ] **Someone is willing to champion the effort.** At least one person will drive the initial setup and evangelize the practice.

**Category 5 Score: ___ / 5**

---

## Scoring

### Calculate your total

| Category | Your Score | Maximum |
|----------|-----------|---------|
| Codebase Foundation | ___ | 10 |
| Testing | ___ | 8 |
| Documentation | ___ | 6 |
| CI/CD | ___ | 6 |
| Team Readiness | ___ | 5 |
| **Total** | **___** | **35** |

### Interpret your score

**30-35: Highly Ready**
Your project is an excellent candidate for harness engineering. You have the infrastructure to support AI agents effectively. Start with the [Individual Developer Guide](../guides/individual-developer.md) and expect to see results within days.

**Recommended starting point:** Jump directly to creating your AGENTS.md and configuring your first verification loop.

---

**22-29: Ready with Gaps**
Your project is ready for harness engineering, but there are gaps that will reduce agent effectiveness. Address the gaps in parallel with your harness setup.

**Recommended starting point:** Spend one day filling the most critical gaps (usually testing or documentation), then start with the [Individual Developer Guide](../guides/individual-developer.md).

**Priority fixes by category:**
- Testing gaps: Write tests for your 5 most critical functions before starting
- Documentation gaps: Write a minimal architecture overview (1 page)
- CI/CD gaps: Set up a basic pipeline that runs tests and lint
- Codebase gaps: Fix linter errors and pin dependencies

---

**14-21: Needs Preparation**
Your project needs foundational work before harness engineering will be effective. Agents without tests or CI will produce unreliable output that costs more to review than to write manually.

**Recommended starting point:** Spend 1-2 weeks on fundamentals before introducing AI agents.

**Priority actions:**
1. Write a test suite (even 20-30 tests covering critical paths)
2. Set up CI that runs tests and linting on every PR
3. Document your architecture and conventions
4. Pin dependencies and clean up the build process

---

**Below 14: Foundation First**
Focus on software engineering fundamentals before adopting AI agents. A weak foundation will amplify problems rather than solving them.

**Recommended starting point:** Follow standard software engineering best practices for your stack. Come back to harness engineering once you score above 20.

---

## Gap Analysis

For each unchecked item, assess:

| Question | Impact |
|----------|--------|
| How hard is this to fix? | Trivial (< 1 hour) / Moderate (1 day) / Significant (1 week+) |
| How much does this affect agent performance? | Critical / Important / Nice to have |
| Who can fix this? | You / Your team / Requires organizational support |

### Priority matrix

Fix items that are **easy AND critical** first:

| | Easy to fix | Hard to fix |
|---|---|---|
| **Critical for agents** | Fix immediately | Plan and schedule |
| **Nice to have** | Fix when convenient | Defer |

### Critical items for agent performance

These items have the highest impact on agent effectiveness. If you have gaps here, address them before or immediately after starting harness engineering:

1. **Tests exist and pass** -- Without tests, agents cannot verify their own output
2. **Test command is a single command** -- Agents need to run tests easily
3. **Linter is configured** -- Catches entire categories of mistakes
4. **Build from clean checkout works** -- Agents start from scratch each session
5. **Architecture is documented** -- Agents need to understand the system structure

---

## Re-Assessment Schedule

Run this assessment:
- **Before starting** harness engineering (baseline)
- **After 1 month** of harness engineering (early progress)
- **Quarterly** thereafter (ongoing health check)

Track your score over time. A healthy project's score should increase as harness engineering drives improvements in testing, documentation, and CI/CD.