Summary

• eli5: plain-language conceptual explanation followed by a concrete step-by-step data walkthrough for whatever's currently on the table , a bug, a system, or a change just made. For bugs, shows the broken trace and the fixed trace side by side.
• send-it: end-to-end execution of an already-aligned design/task , opens an isolated worktree, delegates implementation to subagents, requires test coverage and observability instrumentation before any slice is "done", battle-tests agent-feature changes (prompt/tool/skill/playbook) via playbook-instruction-eval/subagent-runner before commit, runs thermo-review via a fresh impartial subagent, opens the PR with a CloudWatch/Axiom "verify in prod" section, then monitors CI and Greptile to green , fixing everything, including all valid Greptile comments, not just the small ones. Fix-retry loops are bounded (3 rounds) and escalate over Slack past that.
• deploy-watch: pick a time period + env (staging/prod), see what actually deployed in that window, choose which features to watch, and stand up an hourly cloud routine (via the schedule skill, not the session-scoped CronCreate) that Slack-pings only on a genuine regression. Read-only , reuses monitor-change's telemetry mapping but never auto-opens a fix PR. Guards against spinning up a duplicate routine for the same env.

Test plan

• All three are plain-Markdown skills (SKILL.md + reference files) , no code to typecheck or unit test.
• Frontmatter validated (only name/description, per this repo's skill-creator conventions).
• Cross-references checked: relative links to thermo-review, monitor-change, and fix-bug/references/observability.md point at files that exist in this repo.
• Design was reviewed against Libra's pre-commit flags (unbounded fix loops, duplicate-monitor risk) and fixed in a follow-up commit before push.

🤖 Generated with Claude Code

Confidence Score: 4/5

The PR should not merge until deploy-watch derives candidates from successful deployments rather than treating every base-branch merge as deployed.

Findings

1.  Merges Are Not Deployments ▶
2.  Discovery Silently Truncates Results ▶

### Issue 1
.claude/skills/deploy-watch/SKILL.md:69-71
This treats every merge into `staging` or `main` as a successful deployment. Staging can cancel an in-progress deployment when a newer push arrives, and deployment validation or change-scope checks can also stop or skip a release. The skill can therefore offer a PR as deployed and start monitoring behavior that is not actually running in the selected environment. Candidate discovery should use successful deployment records or deployed SHAs rather than merge timestamps alone.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

### Issue 2
.claude/skills/deploy-watch/SKILL.md:81-82
The query returns at most 50 PRs even though the skill promises