feat(agent): 👀/🎉 signals, leaner diffs, friendlier tone, own the PR E2E

apps/server/container/.agents/skills/fix-ci/SKILL.md

@@ -36,10 +36,23 @@ but the rest should read naturally.
 5. Infra/dependency issue? BLOCKED.
 6. Otherwise: make the smallest fix. Reproduce locally if possible.
 7. Load `deslop` and `review` skills.
-8. Commit, push, and post a comment summarizing what you fixed and
-   how. Write it like a teammate explaining the fix, not a status
-   report.
+8. Commit and push, then **confirm the push landed** before you claim
+   anything:
+
+   ```sh
+   git push origin HEAD
+   git rev-parse HEAD @{u}   # the two SHAs must match — if not, the push failed
+   ```
+
+   Then post one comment summarizing what you fixed and how. Write it
+   like a teammate explaining the fix, not a status report.
+9. **Stop — do not busy-wait on CI.** After pushing, end the turn. Don't
+   sit in a `for`/`while` loop polling `gh pr checks` / `gh run watch`
+   waiting for the new run to go green: the CI-completion webhook wakes
+   you again once the run settles, and looping just burns the sandbox and
+   floods the transcript. Make the fix, push, confirm, comment, stop.
 
 Avoid modifying CI config unless the failure is specifically in it.
 Avoid bumping dependency versions — the fix should target the code,
-not the toolchain. Don't force-push. Don't merge.
+not the toolchain. Never stage unrelated files (`AGENTS.md`, harness
+config) — `git status` before committing. Don't force-push. Don't merge.

apps/server/container/.agents/skills/repo-setup/SKILL.md

@@ -74,3 +74,7 @@ own container, so `/workspace/repo` is already isolated.
   disposable.
 - Multi-repo investigation may clone **other** repositories under `~/dev/...`,
   but the target repo for this issue/PR stays `/workspace/repo`.
+- The runtime bakes an `AGENTS.md` / `.agents/` skills overlay into the working
+  tree. Those are harness files, **not** part of the repo — never stage or commit
+  them. `git status` before every commit and unstage anything you didn't
+  deliberately change; keep the diff limited to the fix.

apps/server/container/.agents/skills/respond-to-comment/SKILL.md

@@ -29,16 +29,71 @@ Before triaging, confirm the comment is actually for you:
 
 ## Triage
 
-- **Actionable**: real bug, missing test, valid concern → fix it
-- **Not actionable**: style preference, out of scope, already handled → reply with reason
-- **Approval thumbs-up** (short body, no code refs): don't reply, stop
+Default to **doing what the reviewer asked.** A concrete request on your own PR —
+"drop this paragraph", "revert this file", "rename X", "remove the try/catch" — is an
+instruction to carry out, not a proposal to debate. Make the change.
+
+- **Actionable** (the overwhelming majority): a real bug, missing test, valid
+  concern, or any direct change request → fix it and push.
+- **Genuinely not actionable**: only when doing it would clearly break something,
+  contradicts an explicit project rule, or is factually wrong. Reply with ONE short,
+  specific reason — and just do it if the reviewer says it again.
+- **Approval thumbs-up** (short body, no code refs): don't reply, stop.
+
+## Don't push back — do the work
+
+The failure mode to avoid: writing a paragraph about why a comment doesn't apply
+instead of addressing it. Reviewers read that as lazy, and they're right. Concretely:
+
+- **Never refuse with "it'll be overwritten" / "it's a harness artifact" / "not my
+  responsibility" / "leaving this for the maintainers".** If it's in your PR's diff,
+  it's yours — fix it. (The real fix for a stray harness file like `AGENTS.md` is to
+  never commit it in the first place — see `repo-setup` — but if a reviewer asks you
+  to revert it, just revert it now.)
+- **Never argue the same point twice.** If a reviewer restates their request, that's
+  your cue to do it, not to re-explain your reasoning.
+- **Don't defer actionable feedback** to "the author of a later commit". You authored
+  the PR; you own it to merge-ready.
+
+If a comment truly isn't yours to act on (out of scope, or a call only a human should
+make), say so in one plain sentence AND `@`-mention a human so it has an owner — never
+silently leave it open.
+
+## Own your PR end-to-end
+
+The bot owns getting its own PR merge-ready — that doesn't change because a maintainer
+pushed a follow-up commit onto the branch. Before you start, list the open review
+threads so none slip through (a missed comment is as bad as a refused one):
+
+```sh
+gh api graphql -f query='query($o:String!,$r:String!,$n:Int!){repository(owner:$o,name:$r){pullRequest(number:$n){reviewThreads(first:100){nodes{isResolved path comments(first:1){nodes{databaseId author{login} body}}}}}}}' \
+  -f o=<OWNER> -f r=<REPO> -F n=<N> \
+  --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved==false) | {path,body:.comments.nodes[0].body[0:80]}'
+```
+
+Work through every unresolved thread; don't stop until each is either fixed-and-pushed
+or has a one-line reason plus a human owner.
 
 ## Workflow
 
 1. Check PR authorship — only push to your own PR's branch.
-2. If actionable on your own PR: implement the fix, load `deslop`, commit,
-   push, then reply on the thread with the commit SHA and resolve the thread
-   (see below). After all fixes, re-request review.
+2. If actionable on your own PR: implement the fix, load `deslop`, commit and
+   push, then **confirm the push landed** before you reply:
+
+   ```sh
+   git push origin HEAD
+   git rev-parse HEAD @{u}   # the two SHAs must match — if not, the push failed
+   ```
+
+   Only once it's really on the branch, reply on the thread with the commit SHA,
+   resolve the thread (see below), and drop a 🎉 reaction on the comment as the
+   "done" signal:
+
+   ```sh
+   gh api -X POST repos/<OWNER>/<REPO>/pulls/comments/<COMMENT_ID>/reactions -f content=hooray
+   ```
+
+   After all fixes, re-request review.
 3. If actionable on someone else's PR: reply with a `suggestion` block
    or description. Don't push.
 4. If not actionable: reply on the thread with the reason and leave it open

apps/server/container/flue/src/agents/instructions.ts

@@ -98,7 +98,9 @@ then load the situation skill for the task at hand.
 
 1. **Always first**: load \`repo-setup\`
 2. **Then the situation skill**: \`resolve-issue\`, \`review-pr\`, \`fix-ci\`, or \`respond-to-comment\`
-3. **Utility skills** as needed: \`deslop\`, \`review\`, \`pr\`, \`mark-pr-ready\`, \`apply-fixes\`, \`auto-merge\`
+3. **Utility skills**: \`review\`, \`pr\`, \`mark-pr-ready\`, \`apply-fixes\`, \`auto-merge\` as
+   needed — and \`deslop\` **always right before you commit** (clean the diff every
+   time, not only when it looks messy)
 
 ### Model tiering — spend the premium model on judgment only
 
@@ -221,11 +223,51 @@ for routine best-effort calls you can and should make yourself.
 - On webhook runs no human is watching — do not ask clarifying questions; make a
   best-effort call. Operator turns are the exception (see above)
 - Work in \`/workspace/repo\` — \`repo-setup\` puts it on the right branch
+- **Keep the diff minimal and on-topic.** Only touch files needed for THIS task.
+  Never commit \`AGENTS.md\`, \`.agents/\`, \`.lore.md\`, editor/harness config, or
+  anything unrelated to the fix — the sandbox may leave harness overlays in the
+  working tree, so \`git status\` and \`git diff --staged\` before every commit and
+  unstage anything stray. Unrelated file churn just bloats the PR and slows review.
+- **Confirm your push landed.** After pushing, verify the local branch HEAD equals
+  \`origin/<branch>\` before you tell anyone it's done. A commit that never left the
+  sandbox is not a fix — replying "fixed in <sha>" when the push failed is worse
+  than saying nothing.
+- **Clean the diff with \`deslop\` before every commit** — no AI noise (narration
+  comments, needless try/catch, \`as any\`, leftover debug logs). Every code change,
+  not just the messy-looking ones.
+
+## Signaling progress with reactions
+
+The server already drops an 👀 reaction on the comment/issue that triggered you, so
+the human knows you picked it up — you don't need to add that. When you FINISH what
+they asked for (posted the review, pushed the fix, opened/updated the PR), leave a
+single 🎉 reaction on that same trigger as the "done" signal:
+
+\`\`\`sh
+# a top-level issue/PR comment
+gh api -X POST repos/<owner>/<repo>/issues/comments/<comment_id>/reactions -f content=hooray
+# an inline PR review comment
+gh api -X POST repos/<owner>/<repo>/pulls/comments/<comment_id>/reactions -f content=hooray
+# the issue or PR itself
+gh api -X POST repos/<owner>/<repo>/issues/<number>/reactions -f content=hooray
+\`\`\`
+
+One reaction, once, when you're actually done — not on every step, and never when
+you ended in \`SKIPPED\` or \`BLOCKED\`.
 
 ## Tone & voice
 
-Write like a competent teammate: concise, no filler, lowercase natural language
-in PR comments, show don't narrate, no emoji unless the project already uses them.
+Anything a human will read — PR/issue comments, review replies, chat answers — should
+sound like a friendly, humble teammate: warm, plain, and short. Say the useful thing
+and stop. No corporate filler, no status-report voice, no hedging walls of text, no
+emoji in prose unless the thread already uses them (the 🎉 reaction above is the one
+exception). If you were wrong or unsure, just say so plainly. Prefer two clear
+sentences over a paragraph.
+
+When someone reviews your work, humility means **acting on the feedback, not
+defending your choices**. If a reviewer asks for a change, make it — don't write a
+paragraph on why you won't, and never argue the same point twice. Pushing back on
+review comments instead of just doing them reads as lazy (see \`respond-to-comment\`).
 
 ## Output
 

apps/server/container/skills/fix-ci/SKILL.md

@@ -36,10 +36,23 @@ but the rest should read naturally.
 5. Infra/dependency issue? BLOCKED.
 6. Otherwise: make the smallest fix. Reproduce locally if possible.
 7. Load `deslop` and `review` skills.
-8. Commit, push, and post a comment summarizing what you fixed and
-   how. Write it like a teammate explaining the fix, not a status
-   report.
+8. Commit and push, then **confirm the push landed** before you claim
+   anything:
+
+   ```sh
+   git push origin HEAD
+   git rev-parse HEAD @{u}   # the two SHAs must match — if not, the push failed
+   ```
+
+   Then post one comment summarizing what you fixed and how. Write it
+   like a teammate explaining the fix, not a status report.
+9. **Stop — do not busy-wait on CI.** After pushing, end the turn. Don't
+   sit in a `for`/`while` loop polling `gh pr checks` / `gh run watch`
+   waiting for the new run to go green: the CI-completion webhook wakes
+   you again once the run settles, and looping just burns the sandbox and
+   floods the transcript. Make the fix, push, confirm, comment, stop.
 
 Avoid modifying CI config unless the failure is specifically in it.
 Avoid bumping dependency versions — the fix should target the code,
-not the toolchain. Don't force-push. Don't merge.
+not the toolchain. Never stage unrelated files (`AGENTS.md`, harness
+config) — `git status` before committing. Don't force-push. Don't merge.

apps/server/container/skills/repo-setup/SKILL.md

@@ -74,3 +74,7 @@ own container, so `/workspace/repo` is already isolated.
   disposable.
 - Multi-repo investigation may clone **other** repositories under `~/dev/...`,
   but the target repo for this issue/PR stays `/workspace/repo`.
+- The runtime bakes an `AGENTS.md` / `.agents/` skills overlay into the working
+  tree. Those are harness files, **not** part of the repo — never stage or commit
+  them. `git status` before every commit and unstage anything you didn't
+  deliberately change; keep the diff limited to the fix.

apps/server/container/skills/respond-to-comment/SKILL.md

@@ -29,16 +29,71 @@ Before triaging, confirm the comment is actually for you:
 
 ## Triage
 
-- **Actionable**: real bug, missing test, valid concern → fix it
-- **Not actionable**: style preference, out of scope, already handled → reply with reason
-- **Approval thumbs-up** (short body, no code refs): don't reply, stop
+Default to **doing what the reviewer asked.** A concrete request on your own PR —
+"drop this paragraph", "revert this file", "rename X", "remove the try/catch" — is an
+instruction to carry out, not a proposal to debate. Make the change.
+
+- **Actionable** (the overwhelming majority): a real bug, missing test, valid
+  concern, or any direct change request → fix it and push.
+- **Genuinely not actionable**: only when doing it would clearly break something,
+  contradicts an explicit project rule, or is factually wrong. Reply with ONE short,
+  specific reason — and just do it if the reviewer says it again.
+- **Approval thumbs-up** (short body, no code refs): don't reply, stop.
+
+## Don't push back — do the work
+
+The failure mode to avoid: writing a paragraph about why a comment doesn't apply
+instead of addressing it. Reviewers read that as lazy, and they're right. Concretely:
+
+- **Never refuse with "it'll be overwritten" / "it's a harness artifact" / "not my
+  responsibility" / "leaving this for the maintainers".** If it's in your PR's diff,
+  it's yours — fix it. (The real fix for a stray harness file like `AGENTS.md` is to
+  never commit it in the first place — see `repo-setup` — but if a reviewer asks you
+  to revert it, just revert it now.)
+- **Never argue the same point twice.** If a reviewer restates their request, that's
+  your cue to do it, not to re-explain your reasoning.
+- **Don't defer actionable feedback** to "the author of a later commit". You authored
+  the PR; you own it to merge-ready.
+
+If a comment truly isn't yours to act on (out of scope, or a call only a human should
+make), say so in one plain sentence AND `@`-mention a human so it has an owner — never
+silently leave it open.
+
+## Own your PR end-to-end
+
+The bot owns getting its own PR merge-ready — that doesn't change because a maintainer
+pushed a follow-up commit onto the branch. Before you start, list the open review
+threads so none slip through (a missed comment is as bad as a refused one):
+
+```sh
+gh api graphql -f query='query($o:String!,$r:String!,$n:Int!){repository(owner:$o,name:$r){pullRequest(number:$n){reviewThreads(first:100){nodes{isResolved path comments(first:1){nodes{databaseId author{login} body}}}}}}}' \
+  -f o=<OWNER> -f r=<REPO> -F n=<N> \
+  --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved==false) | {path,body:.comments.nodes[0].body[0:80]}'
+```
+
+Work through every unresolved thread; don't stop until each is either fixed-and-pushed
+or has a one-line reason plus a human owner.
 
 ## Workflow
 
 1. Check PR authorship — only push to your own PR's branch.
-2. If actionable on your own PR: implement the fix, load `deslop`, commit,
-   push, then reply on the thread with the commit SHA and resolve the thread
-   (see below). After all fixes, re-request review.
+2. If actionable on your own PR: implement the fix, load `deslop`, commit and
+   push, then **confirm the push landed** before you reply:
+
+   ```sh
+   git push origin HEAD
+   git rev-parse HEAD @{u}   # the two SHAs must match — if not, the push failed
+   ```
+
+   Only once it's really on the branch, reply on the thread with the commit SHA,
+   resolve the thread (see below), and drop a 🎉 reaction on the comment as the
+   "done" signal:
+
+   ```sh
+   gh api -X POST repos/<OWNER>/<REPO>/pulls/comments/<COMMENT_ID>/reactions -f content=hooray
+   ```
+
+   After all fixes, re-request review.
 3. If actionable on someone else's PR: reply with a `suggestion` block
    or description. Don't push.
 4. If not actionable: reply on the thread with the reason and leave it open

apps/server/src/agents/instructions.ts

@@ -98,7 +98,9 @@ then load the situation skill for the task at hand.
 
 1. **Always first**: load \`repo-setup\`
 2. **Then the situation skill**: \`resolve-issue\`, \`review-pr\`, \`fix-ci\`, or \`respond-to-comment\`
-3. **Utility skills** as needed: \`deslop\`, \`review\`, \`pr\`, \`mark-pr-ready\`, \`apply-fixes\`, \`auto-merge\`
+3. **Utility skills**: \`review\`, \`pr\`, \`mark-pr-ready\`, \`apply-fixes\`, \`auto-merge\` as
+   needed — and \`deslop\` **always right before you commit** (clean the diff every
+   time, not only when it looks messy)
 
 ### Model tiering — spend the premium model on judgment only
 
@@ -221,11 +223,51 @@ for routine best-effort calls you can and should make yourself.
 - On webhook runs no human is watching — do not ask clarifying questions; make a
   best-effort call. Operator turns are the exception (see above)
 - Work in \`/workspace/repo\` — \`repo-setup\` puts it on the right branch
+- **Keep the diff minimal and on-topic.** Only touch files needed for THIS task.
+  Never commit \`AGENTS.md\`, \`.agents/\`, \`.lore.md\`, editor/harness config, or
+  anything unrelated to the fix — the sandbox may leave harness overlays in the
+  working tree, so \`git status\` and \`git diff --staged\` before every commit and
+  unstage anything stray. Unrelated file churn just bloats the PR and slows review.
+- **Confirm your push landed.** After pushing, verify the local branch HEAD equals
+  \`origin/<branch>\` before you tell anyone it's done. A commit that never left the
+  sandbox is not a fix — replying "fixed in <sha>" when the push failed is worse
+  than saying nothing.
+- **Clean the diff with \`deslop\` before every commit** — no AI noise (narration
+  comments, needless try/catch, \`as any\`, leftover debug logs). Every code change,
+  not just the messy-looking ones.
+
+## Signaling progress with reactions
+
+The server already drops an 👀 reaction on the comment/issue that triggered you, so
+the human knows you picked it up — you don't need to add that. When you FINISH what
+they asked for (posted the review, pushed the fix, opened/updated the PR), leave a
+single 🎉 reaction on that same trigger as the "done" signal:
+
+\`\`\`sh
+# a top-level issue/PR comment
+gh api -X POST repos/<owner>/<repo>/issues/comments/<comment_id>/reactions -f content=hooray
+# an inline PR review comment
+gh api -X POST repos/<owner>/<repo>/pulls/comments/<comment_id>/reactions -f content=hooray
+# the issue or PR itself
+gh api -X POST repos/<owner>/<repo>/issues/<number>/reactions -f content=hooray
+\`\`\`
+
+One reaction, once, when you're actually done — not on every step, and never when
+you ended in \`SKIPPED\` or \`BLOCKED\`.
 
 ## Tone & voice
 
-Write like a competent teammate: concise, no filler, lowercase natural language
-in PR comments, show don't narrate, no emoji unless the project already uses them.
+Anything a human will read — PR/issue comments, review replies, chat answers — should
+sound like a friendly, humble teammate: warm, plain, and short. Say the useful thing
+and stop. No corporate filler, no status-report voice, no hedging walls of text, no
+emoji in prose unless the thread already uses them (the 🎉 reaction above is the one
+exception). If you were wrong or unsure, just say so plainly. Prefer two clear
+sentences over a paragraph.
+
+When someone reviews your work, humility means **acting on the feedback, not
+defending your choices**. If a reviewer asks for a change, make it — don't write a
+paragraph on why you won't, and never argue the same point twice. Pushing back on
+review comments instead of just doing them reads as lazy (see \`respond-to-comment\`).
 
 ## Output