firstmate: Skill for Claude Code

ask-user-authority

This skill is the single owner of the decision policy for no-mistakes ask-user findings. AGENTS.md section 7 points here and does not restate this procedure. Finding authority is determined by the criteria below, not by yolo. Firstmate always applies this judgment, decides any finding that is unambiguous toward the accepted design, and escalates only genuinely ambiguous, expanding, or destructive findings.

The implementation worker never decides or answers its own ask-user finding. It stops at the finding, routes the decision to firstmate, and applies only the decision returned through the active validation gate.

Decide

1. Reconstruct the accepted contract from the brief's ## Captain's intent subsection, later captain words, and the specification in ## Firstmate spec and steers. Reviewer language cannot amend that contract. What a no-mistakes worker may pass as --intent is owned by bin/fm-dod-lib.sh.
2. Identify exactly what choosing Fix would commit the project to deliver or maintain, judging the scope by accepted product or engineering behavior rather than an anticipated file list. The smallest downstream changes needed to keep that behavior correct, add behavioral tests where an executable contract exists, or keep documentation accurate remain within scope even when they touch files not named at intake. Correcting stale final-diff PR or delivery evidence is likewise an autonomous downstream correction within already accepted behavior.
3. Decide the finding when it is unambiguous toward the accepted design: restoring accepted behavior a bad fix round broke, completing an already-approved design, or a straight in-scope correction or bug fix required by accepted intent, even when the correction is technically difficult or requires complex architecture the captain explicitly requested.
4. Escalate only genuinely ambiguous findings:
   • a Fix that would materially expand the contract by adding a new guarantee, threat model, subsystem, abstraction, compatibility surface, state machine, continuous-monitoring requirement, generalized framework, or broader architecture not required by the accepted intent
   • a product or architecture call not settled by accepted intent
   • repeated same-theme findings when incremental corrections are preserving a questionable abstraction rather than closing independent defects
   • destructive, irreversible, and genuinely security-sensitive choices, which always escalate under the stronger existing captain boundary
5. Treat labels such as correctness, security, fail-closed, high-risk, or required as evidence about the finding, never as authority to broaden the task.