diff --git a/.agents/skills/stow/SKILL.md b/.agents/skills/stow/SKILL.md
index 672894bd56..14cf8702fe 100644
--- a/.agents/skills/stow/SKILL.md
+++ b/.agents/skills/stow/SKILL.md
@@ -52,6 +52,9 @@ Never describe the session as reset-safe while the memory total is over budget o
 3. **Write within the existing boundaries.**
    - Captain preferences and fleet-local operational facts belong in the destination selected by AGENTS.md after the required whole-file curation pass.
      Create `data/learnings.md` only for a genuinely new local learning with no stronger owner.
+   - For a completed ship task, if `data/captain.md` configures a project-insights directory, save a dated learnings retrospective there as a durable captain-facing record, in addition to curating the fleet-local operational facts into `data/learnings.md`.
+     Name it `<project>-<scope>-learnings.md` and cover what was built, key decisions, and operational lessons.
+     This is distinct from the curated `data/learnings.md` entries: the insights file is a standalone retrospective, while `data/learnings.md` holds the concise operational rule that survives the next startup-memory pass.
    - In a primary home, curate shared captain preferences only under the existing primary-authoritative shared-preference contract.
      In a secondmate home, route a newly discovered shared preference to the main firstmate through marked status or a document pointer instead of editing the inherited file.
    - Project-intrinsic knowledge never goes directly into a project's `AGENTS.md`.
diff --git a/AGENTS.md b/AGENTS.md
index 14a97ad7fb..2bcf0a2fde 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -338,6 +338,7 @@ A captain instruction to merge is explicit authority; `yolo` is the only standin
 For any custom `state/<id>.check.sh` you write yourself, keep it an ordinary single-link mode-`0700` file, print one line only when firstmate should wake, print nothing otherwise, finish before `FM_CHECK_TIMEOUT`, then bind its current bytes with `bin/fm-check-register.sh <id>` before the watcher may execute it.
 
 Tear down a ship task only after landing is confirmed.
+Before teardown of any completed ship task, instruct the worker to `/stow`, then write a dated learnings file to the captain's insights directory if `data/captain.md` configures one; a teardown that skips stow loses durable knowledge.
 A teardown refusal for uncommitted or unlanded work is a stop-and-investigate result, never an obstacle to bypass.
 Never force teardown without explicit discard authority.
 After successful teardown, record completion, retain only the configured recent Done history, and re-evaluate queued work whose blockers and time gates have cleared.
@@ -511,6 +512,7 @@ These skills are not captain-invocable; load them only at their precise triggers
 - `fmx-respond` - load on an `x-mention <request_id>` `check:` wake to handle the mention, on an `x-mode-error ...` `check:` wake to report the X-mode configuration blocker, on a `public-followup ...` `check:` wake or a startup-surfaced public commitment, and on any milestone or terminal wake for an X-mode-linked task before posting its completion follow-up; relevant only when X mode is on.
 - `firstmate-codexapp` - load before coordinating a visible Codex Desktop thread, evaluating a Codex App backend request, or reconciling Codex Desktop host-tool smoke evidence for Firstmate work.
 - `firstmate-coding-guidelines` - load before changing firstmate's shared, tracked material, as defined by section 1's list, whether editing directly or briefing a crewmate for a firstmate-repo task.
+- `stage-uat` - load when the captain invokes `/stage-uat`, requests a UAT pass, or declares a stage milestone complete and the next stage is about to start.
 
 ## 14. X mode