How the Yolo Autonomy Flag Affects Approval Authority in Firstmate

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 §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. 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 §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 (lines 242-244), the system passes both the delivery mode and yolo posture explicitly to bin/fm-brief.sh, bin/fm-spawn.sh, and bin/fm-promote.sh.

Project Configuration

Register the autonomy setting in data/projects.md (or via .agents/skills/project-management/SKILL.md lines 38-51):

# Example entry in data/projects.md

my-cool-app  +yolo  no-mistakes

Brief Generation and Deviation Handling

The bin/fm-brief.sh script receives the resolved flag as an environment variable:

# 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 §7.1-7.2 (lines 280-284).

Worker Spawning

The bin/fm-spawn.sh script checks the YOLO variable and adds the --yolo argument (alias for --force) when the posture is "on":

# 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 §7.6-7.8 (lines 324-328), a direct merge command from the captain prevails even if yolo would otherwise reject the action:

# 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 §1-2 and stored per-project in 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, bin/fm-spawn.sh, and bin/fm-promote.sh during task execution.
• Captain instructions always override yolo restrictions per 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 §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 §7.6-7.8.

Where is the yolo posture configured?

The yolo posture is recorded per-project in data/projects.md and managed via the project-management skill at .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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}