ahoy
Skill2 starsChanged 33 days agoMITView on GitHub
Recap visible session events and guide the captain through visibly unanswered decisions when the captain explicitly invokes /ahoy, with a Bearings fallback when /ahoy is the session's first real captain message.
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- kunchenguid/firstmateedited, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- kunchenguid/firstmate★ 8.7k96% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- afkSkill
- agent-skill-trigger-indexSkill
- ask-user-authoritySkill
- away-quiet-supervisionSkill
- bearingsSkill
- bootstrap-diagnosticsSkill
- captain-hold-lifecycleSkill
- control-firstmateSkill
- decision-hold-lifecycleSkill
- diagnostic-reasoningSkill
- firstmate-codexappSkill
- firstmate-coding-guidelinesSkill
- firstmate-orcaSkill
- fmx-respondSkill
- harness-adaptersSkill
- operational-home-layoutSkill
- process-event-sourcesSkill
- project-managementSkill
- quietSkill
- quota-array-dispatchSkill
- scout-completionSkill
- secondmate-provisioningSkill
- session-start-recoverySkill
- ship-landingSkill
- stowSkill
- stuck-crewmate-recoverySkill
- updatefirstmateSkill
- validation-supervisionSkill
- verify-firstmateSkill
- stowSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 14 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Before anything else, check whether this session has already taken the helm: a SESSION START digest for this home must be visible in the …
- Very specific: line 14
If it is not, run bin/fm-session-start.sh once and read its digest before producing any recap.
- Distinctive: line 15
Run-tier harness surfaces run it automatically at session open, so this step is normally already satisfied and costs one glance.
- Distinctive: line 27
Never infer captain authorship merely because a synthetic message appears in the user-role transcript.
- Very specific: line 31
If no prior real captain message exists, load ../bearings/SKILL.md and follow it exactly.
- Distinctive: line 33
Do not restate that contract or combine a session recap with Bearings output.
- Distinctive: line 34
If a prior real captain message exists, preserve the ordinary recap interval: recap what happened after that message and before the current …
- Distinctive: line 36
Use captain-facing outcome language and preserve every full PR URL present in that interval.
- Distinctive: line 39
Treat a decision as closed only when a later visible response substantively resolves it, chooses an option, declines it, grants or denies …
- Distinctive: line 42
Do not call Bearings, shell commands, fleet snapshots, status readers, GitHub or browser APIs, tools, or file reads or writes.
- Distinctive: line 43
Create no report, persist nothing, and do not guess current live state beyond the last visible event.
- Distinctive: line 44
If no ordinary events occurred after the previous captain message but an older visibly open decision exists, report that decision instead …
- Distinctive: line 45
If neither ordinary events nor visibly open decisions exist, say directly in one sentence that nothing happened after the previous captain …
- Distinctive: line 47
After the normal recap, when the existing visibly open decision inventory contains decisions, begin a guided decision-clearing flow by …
- Distinctive: line 50
When the captain answers the presented decision, present the next highest-impact decision from that existing inventory in the same form.
- Distinctive: line 55
If context compaction makes the prior boundary unavailable, state that the exact session boundary is unavailable and summarize only visibly …
- Distinctive: line 57
Do not silently invoke Bearings unless this is genuinely the first real captain message.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
ahoy
Give the captain a concise session-only recap without gathering fresh state.
- Before anything else, check whether this session has already taken the helm: a
SESSION STARTdigest for this home must be visible in the session history. If it is not, runbin/fm-session-start.shonce and read its digest before producing any recap. Run-tier harness surfaces run it automatically at session open, so this step is normally already satisfied and costs one glance; it is the safety net for surfaces that cannot run it on a hook, and for any path where a skill would otherwise act first. Taking the helm always precedes this skill's own logic, and the digest it produces is operational input, never a captain message or a recap event. - Inspect only conversation or session history already visible to the current first mate.
- Find the most recent real captain-authored message before the current
/ahoyinvocation. A captain boundary is an ordinary user-role message unless it matches one of the narrow operational exclusions below. Exclude messages that begin with the current U+2063FIRSTMATE_OP:injection prefix. Exclude legacy bare-marker away-mode injections only when U+2063 is immediately followed bySupervisor escalate (. Exclude a message that is exactly a record-backed operational doorbell thatbin/fm-operational-input.sh doorbell-kindrecognizes from its stdin; Claude Code, which strips U+2063, receives away-mode escalations this way. Exclude the exact legacy unmarked session-start payloadRun `bin/fm-session-start.sh` now, exactly once, before executing any other instructions.Custom-role messages such as Pi'sfirstmate-sessionstart-nudgeare not captain messages. System, developer, tool, watcher, guard, away-mode, and other injected operational messages are not captain messages. Never infer captain authorship merely because a synthetic message appears in the user-role transcript. Do not exclude an ordinary captain message merely because it begins with U+2063 followed by other text, contains ASCIIFIRSTMATE_OP:without a leading U+2063, quotes or embeds a current operational message after ordinary captain text, quotes or mentions the legacy session-start payload, or adds any text to that payload. Apply the current exclusion only when U+2063FIRSTMATE_OP:begins at the first character of the whole message:Captain quote:followed by that current prefix is a captain boundary. Apply the legacy startup exclusion as a literal whole-message match:Captain quote: Run `bin/fm-session-start.sh` now, exactly once, before executing any other instructions.is a captain boundary. - If no prior real captain message exists, load
../bearings/SKILL.mdand follow it exactly. Bearings alone owns its gathering, artifact, and response contract. Do not restate that contract or combine a session recap with Bearings output. - If a prior real captain message exists, preserve the ordinary recap interval: recap what happened after that message and before the current invocation. Include concrete outcomes, landed work, failures, decisions made, new decisions needed, and work still running only when those events appear in that visible interval. Use captain-facing outcome language and preserve every full PR URL present in that interval.
- Additionally inspect the entire session history visible to the current first mate before the current invocation for every explicit captain decision that remains unanswered, including decisions raised before the ordinary recap boundary. A later unrelated captain message establishes a recap boundary but does not close an earlier decision. Treat a decision as closed only when a later visible response substantively resolves it, chooses an option, declines it, grants or denies the requested approval, or otherwise directly addresses that decision. Include every visibly supported open decision once, and deduplicate by the decision's substance when the ordinary interval recap already represents it or its wording differs.
- The normal recap branch is session-history-only, apart from the step 0 helm check. Do not call Bearings, shell commands, fleet snapshots, status readers, GitHub or browser APIs, tools, or file reads or writes. Create no report, persist nothing, and do not guess current live state beyond the last visible event.
- If no ordinary events occurred after the previous captain message but an older visibly open decision exists, report that decision instead of claiming nothing happened. If neither ordinary events nor visibly open decisions exist, say directly in one sentence that nothing happened after the previous captain message.
- After the normal recap, when the existing visibly open decision inventory contains decisions, begin a guided decision-clearing flow by presenting only the single open decision judged most impactful by the first mate. Say the ordering is the first mate's pick. Give enough escalation-quality context to decide easily: the decision, why it matters, the options, and a recommendation.
- When the captain answers the presented decision, present the next highest-impact decision from that existing inventory in the same form. Continue one decision at a time until none remain, without starting this flow when the inventory is empty.
The current /ahoy message is outside the recap interval.
A previous /ahoy is a real captain message and may be the next interval boundary.
If context compaction makes the prior boundary unavailable, state that the exact session boundary is unavailable and summarize only visibly supported events.
Compacted history supports an open decision only when both its request and its still-unanswered status are visible; report uncertainty instead of reconstructing hidden requests or answers.
Do not silently invoke Bearings unless this is genuinely the first real captain message.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

