# Updatefirstmate

Self-update a running firstmate and its secondmates to the latest from origin, or from...

- Repository: https://github.com/kunchenguid/firstmate (8480 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kunchenguid/firstmate --skill updatefirstmate -g -a claude-code -y`
Codex: `npx skills add kunchenguid/firstmate --skill updatefirstmate -g -a codex -y`
Cursor: `npx skills add kunchenguid/firstmate --skill updatefirstmate -g -a cursor -y`
Gemini CLI: `npx skills add kunchenguid/firstmate --skill updatefirstmate -g -a gemini-cli -y`

## Description

Self-update a running firstmate and its secondmates to the latest from origin, or from a configured self-update source. Use when the captain invokes /updatefirstmate (e.g. "/updatefirstmate", "update firstmate", "pull the latest firstmate").

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# updatefirstmate

Self-update firstmate in place.
Firstmate is its own repo, behind the same no-mistakes gate as any project, so new tracked material (`AGENTS.md`, `bin/`, `.agents/skills/`, and public `skills/`) reaches `main` and then sits there until each running firstmate pulls it.
Only `AGENTS.md`, `bin/`, and `.agents/skills/` are a running firstmate instruction surface; public `skills/` is installer-facing and is not loaded by firstmate.
This skill performs that pull for the running main firstmate and every secondmate, without disturbing any in-flight work.
Updating is consumption, not publication: it only pulls from upstream, so every home runs it regardless of role, and the firstmate-repository publication boundary (`firstmate-self-repo`) never applies to it.

Pulling the files is only half of it.
A running agent holds `AGENTS.md` and every skill it has already loaded frozen from the moment it launched, and no verified harness offers a reload, so new bytes on disk change nothing for it until it starts a fresh conversation.
A re-read cannot substitute: it appends a second copy of the mate's own job description with no defined precedence, and it cannot reach a skill that is already loaded.
Replacing the agent is also the only thing that re-resolves the launch-time wiring - turn-end hooks, harness flags, per-harness feature switches - which the mate froze when it started and which nothing on disk describes.

That is why **every live second mate is restarted after a successful update, including one that was already on the target commit.**
Launch-time wiring is not derivable from a file diff, so an unchanged tracked surface is not evidence the running agent is already on the current behavior.
The only live mates that do not restart are the ones whose home the update pass had to skip, and the ones whose runtime cannot prove a restart; the updater keeps both cases honest and neither is reported as a reload.

The rest: https://github.com/kunchenguid/firstmate/blob/HEAD/.agents/skills/updatefirstmate/SKILL.md