# How the Yolo Autonomy Flag Affects Approval Authority in Firstmate

> Understand how the yolo autonomy flag impacts approval authority in Firstmate. Learn how it enables autonomous routine task approvals while reserving critical decisions for the captain.

- Repository: [Kun Chen/firstmate](https://github.com/kunchenguid/firstmate)
- Tags: deep-dive
- Published: 2026-08-13

---

**When enabled, the `yolo` autonomy flag grants Firstmate standing authority to approve routine tasks like merging green PRs and simple fixes autonomously, while reserving high-impact, destructive, or contract-expanding decisions for the captain.**

The `yolo` autonomy flag in `kunchenguid/firstmate` serves as a per-project posture setting that fundamentally shifts decision ownership for routine approvals. Defined in [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §1-2 (lines 28-30), this flag determines whether Firstmate must escalate every merge and fix to the captain or may proceed independently within the boundaries of the original task scope.

## Understanding Yolo States

The `yolo` flag operates as a binary state recorded per-project in [`data/projects.md`](https://github.com/kunchenguid/firstmate/blob/main/data/projects.md). It represents the only standing relaxation for routine decisions in the Firstmate architecture.

### Yolo Off vs. Yolo On

| `yolo` State | Routine Decision Owner | Captain-Only Decisions |
|--------------|------------------------|------------------------|
| **Off** (`+yolo` not set) | **Captain** owns all ask-user findings, PR merges, and local-only approvals | No routine decisions are auto-approved; every merge requires explicit captain instruction |
| **On** (`+yolo` set) | **Firstmate** approves routine gates within the original request | Destructive, irreversible, security-sensitive, or contract-expanding actions |

When `yolo` is **on**, Firstmate may autonomously merge green PRs and approve simple fixes. However, as specified in [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §7.3-7.5 (lines 318-322), it *never* authorizes ask-user fixes that would materially expand the engineering contract beyond the original request.

## Technical Architecture

The `yolo` posture is resolved at task intake and propagated through the execution pipeline. According to [`docs/architecture.md`](https://github.com/kunchenguid/firstmate/blob/main/docs/architecture.md) (lines 242-244), the system passes both the delivery mode and `yolo` posture explicitly to [`bin/fm-brief.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-brief.sh), [`bin/fm-spawn.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-spawn.sh), and [`bin/fm-promote.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-promote.sh).

### Project Configuration

Register the autonomy setting in [`data/projects.md`](https://github.com/kunchenguid/firstmate/blob/main/data/projects.md) (or via [`.agents/skills/project-management/SKILL.md`](https://github.com/kunchenguid/firstmate/blob/main/.agents/skills/project-management/SKILL.md) lines 38-51):

```bash

# Example entry in data/projects.md

my-cool-app  +yolo  no-mistakes

```

### Brief Generation and Deviation Handling

The [`bin/fm-brief.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-brief.sh) script receives the resolved flag as an environment variable:

```bash

# bin/fm-brief.sh (excerpt)

echo "Delivery mode: ${MODE}"
echo "Yolo posture : ${YOLO}"   # YOLO = "on" or "off"

```

If a task drops below its registered rigor, Firstmate prints a deviation notice and continues processing, as documented in [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §7.1-7.2 (lines 280-284).

### Worker Spawning

The [`bin/fm-spawn.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-spawn.sh) script checks the `YOLO` variable and adds the `--yolo` argument (alias for `--force`) when the posture is "on":

```bash

# bin/fm-spawn.sh (excerpt)

if [[ "$YOLO" == "on" ]]; then
    ARGS+=(--yolo)   # alias for --force, runs everything without extra prompts

fi
exec "${HARNASS[@]}" "${ARGS[@]}"

```

This allows the worker to proceed without waiting for manual approval prompts.

### Captain Override Precedence

Explicit captain instructions always override the standing `yolo` rule. As implemented in [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §7.6-7.8 (lines 324-328), a direct merge command from the captain prevails even if `yolo` would otherwise reject the action:

```bash

# Captain override example

bin/fm-pr-merge.sh "$TASK_ID" "https://github.com/.../pull/42"

```

## Summary

- The `yolo` autonomy flag is defined in [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §1-2 and stored per-project in [`data/projects.md`](https://github.com/kunchenguid/firstmate/blob/main/data/projects.md).
- When **off**, the captain owns all decisions; no routine approvals occur without explicit instruction.
- When **on**, Firstmate may auto-approve routine gates and merge green PRs, but cannot approve contract-expanding or destructive changes.
- The flag propagates through [`bin/fm-brief.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-brief.sh), [`bin/fm-spawn.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-spawn.sh), and [`bin/fm-promote.sh`](https://github.com/kunchenguid/firstmate/blob/main/bin/fm-promote.sh) during task execution.
- Captain instructions always override `yolo` restrictions per [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §7.6-7.8.

## Frequently Asked Questions

### What happens when the yolo autonomy flag is disabled?

When `yolo` is off (the default), the captain owns all "ask-user" findings, PR merges, and local-only merge approvals. No routine decisions are auto-approved; every merge, fix, or release-gate requires an explicit captain instruction according to [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §1-2.

### Can captains override yolo decisions?

Yes. An explicit captain instruction always overrides the standing `yolo` rule. If the captain issues a concrete merge command, that instruction prevails regardless of the project's autonomy posture, as specified in [`AGENTS.md`](https://github.com/kunchenguid/firstmate/blob/main/AGENTS.md) §7.6-7.8.

### Where is the yolo posture configured?

The `yolo` posture is recorded per-project in [`data/projects.md`](https://github.com/kunchenguid/firstmate/blob/main/data/projects.md) and managed via the project-management skill at [`.agents/skills/project-management/SKILL.md`](https://github.com/kunchenguid/firstmate/blob/main/.agents/skills/project-management/SKILL.md) (lines 38-51). It is the only standing relaxation for routine decisions in the Firstmate system.

### Does yolo allow merging failing PRs?

No. Even with `yolo` enabled, Firstmate only merges **green** work. The flag does not bypass validation gates or quality checks. Additionally, `yolo` never authorizes actions that would materially expand the engineering contract beyond the original request scope.