# Guide: Individual Developer

This guide is for a single engineer adopting `harness-copilot` on a personal project or as the first user on a team.

## Prerequisites

- **VS Code** with **GitHub Copilot** and **Copilot Chat** extensions.
- A git repository you control.
- Node 18+ (for the one-time `npx harness-copilot init` install).

## The 30-Minute Setup

The bare minimum to get measurable leverage from Copilot.

### 1. Install the harness (1 min)

```bash
cd /path/to/your/project
npx harness-copilot init --yes
```

This scaffolds:

- `.github/copilot-instructions.md` (template — needs filling in)
- `.github/instructions/typescript.instructions.md` (or pick the language file relevant to your project)
- `.github/instructions/tests.instructions.md`
- `.github/prompts/harness-*.prompt.md` (16 slash commands)
- `.github/agents/planner.md`, `.github/agents/reviewer.md`
- `AGENTS.md` (template — needs filling in)
- `.vscode/mcp.json` (example, commented out)

### 2. Fill in `.github/copilot-instructions.md` (15 min)

Open `.github/copilot-instructions.md` and let Copilot help you populate it:

```
/harness-copilot-instructions
```

Copilot will scan your project, propose a draft, and stop for your review. **Read every line and edit.** Auto-generated context that you adopt verbatim is worse than no context at all — it gives you false confidence while drifting from reality.

### 3. Set up verification (10 min)

```
/harness-verify
```

This installs or documents a test runner, linter, type-checker, and a unified `verify.sh` script. The single most valuable thing you can do for Copilot is give it a way to know whether its output is correct.

### 4. Run an audit (4 min)

```
/harness-audit
```

This grades your harness on a 100-point scale, identifies the highest-impact gaps, and proposes a plan. Stop at the report (`--report-only`) until you're ready to apply changes.

## The 2-Hour Investment

Once you've done the 30-minute setup, add these to compound the value.

### Scoped instructions

For each distinct zone in your project (tests, migrations, generated code, frontend, backend), generate a scoped instructions file:

```
/harness-instructions
```

Copilot proposes a set of `.github/instructions/<zone>.instructions.md` files with `applyTo` globs that activate only when relevant files are in chat context.

### Reusable prompts

Identify three workflows you re-type often — code review, draft PR, write spec. Generate them:

```
/harness-prompts
```

Now `/code-review`, `/draft-pr`, `/write-spec` are first-class Copilot slash commands.

### Custom agents

Pick two specialized personas to install:

```
/harness-agents
```

The **planner** agent reads but never writes — useful when you want a spec before code. The **reviewer** agent critiques diffs without editing files.

### CI and pre-commit

```
/harness-ci
/harness-hooks
```

A pre-commit hook catches issues before they leave your laptop; CI catches them before they reach main. Both should fail loudly with remediation messages Copilot can parse and fix.

## The Daily Loop

Once your harness is in place, your day-to-day Copilot use changes shape.

### Starting a non-trivial change

1. Switch to the **planner** custom agent in the agent picker.
2. Describe the change.
3. Let planner ask clarifying questions and produce a numbered plan with verification steps.
4. Switch back to the default Copilot agent.
5. Tell Copilot to execute the plan.

### Reviewing your own work

Before pushing:

```
/code-review
```

This invokes the reusable `/code-review` prompt you generated above. It runs against the staged diff and produces a structured findings report.

### After a merge

If the PR touched architecture, dependencies, or build/deploy:

```
/harness-maintain
```

This produces surgical edits to `.github/copilot-instructions.md`, `AGENTS.md`, and `ARCHITECTURE.md` to keep them in sync.

## Working Habits That Compound

| Habit | What it gives you |
|-------|-------------------|
| Run `./verify.sh` after every change | Copilot can fix what you can verify; what you can't verify, it can't fix. |
| Keep `.github/copilot-instructions.md` under 150 lines | The shorter and sharper, the higher the signal. |
| Reload VS Code after editing customization files | Copilot caches; reloading ensures changes take effect. |
| Run `/harness-help` on a fresh project | The recommended-next-action heuristic gets the basics in place fast. |
| Use planner mode for anything > 2 hours | Specs prevent rework. |
| Run `/harness-audit` quarterly | The harness rots if you don't maintain it. |

## Anti-Patterns to Avoid

- **Editing customization files inside the installed `.github/prompts/`**. They get refreshed by `npx harness-copilot update`. Edit the source in `skills/` if you're contributing back, or fork.
- **Writing one mega instructions file**. Scoped files with narrow `applyTo` globs are dramatically more useful than a single 500-line monolith.
- **Adopting `.github/copilot-instructions.md` verbatim from the template**. The template is a scaffold. Your job is to make it accurate.
- **Skipping verification**. Without `verify.sh`, every Copilot suggestion is a guess that requires human review.

## What's Next

- Read [docs/principles.md](../docs/principles.md) — the discipline behind these mechanics.
- Read [docs/anti-patterns.md](../docs/anti-patterns.md) — the failure modes.
- If you're rolling this out to a team, read [guides/small-team.md](small-team.md).