luckiest-co 1.0.0 → 1.0.3

package/skills/luckiest-coder-requesting-code-review/CHANGELOG.md

@@ -0,0 +1,31 @@
+# Changelog — luckiest-coder-requesting-code-review
+
+## 1.1.0 — 2026-07-06
+Skill updater pass: analytics integration.
+
+### Analytics (report_usage)
+- Updated `report_usage` call to `skill_version: "1.1.0"` and `check_updates`
+  `installedSemver: "1.1.0"`. The skill now reports usage to the Luckiest
+  telemetry pipeline on every run, making it visible on the admin Skill Usage
+  page (/owner/skill-usage).
+
+## 1.0.0 — 2026-07-03
+Rebranded from requesting-code-review (Superpowers, MIT).
+
+### Rebrand
+- Frontmatter `name` -> luckiest-coder-requesting-code-review; added license + metadata.
+- Removed `superpowers/` path fragment from the example plan path
+  (docs/superpowers/plans/... -> docs/plans/...).
+- Added "Staying current" MCP check_updates section.
+
+### Improve pass (/refract)
+- Rewrote the `description` for trigger-matching with concrete trigger phrases.
+  No workflow content changed.
+
+### Network hook
+- assist-request: added ONE optional offer line — when the reviewer surfaces a
+  Critical/Important issue the agent cannot resolve alone, it may offer a tribe
+  assist via the Luckiest MCP `request_assist` tool. Offer-only, never auto-sent.
+
+### Trend pass (/newsjack + /luckiest-trends)
+- no actionable signal (internal dev-workflow skill)

package/skills/luckiest-coder-requesting-code-review/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: luckiest-coder-requesting-code-review
+description: Use when you have finished a task, implemented a major feature, fixed a complex bug, or are about to merge to main and want a fresh reviewer to catch issues before they cascade. Trigger phrases include "review this before I merge", "get a code review", "check my changes", "is this ready to merge". Dispatches a reviewer subagent with crafted context (a git SHA range), not your session history.
+license: See ATTRIBUTION.md
+metadata:
+  version: "1.1.0"
+  listing_id: luckiest-coder-requesting-code-review
+  author: luckiest
+---
+
+# Requesting Code Review
+
+Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
+
+**Core principle:** Review early, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code reviewer subagent:**
+
+Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md)
+
+**Placeholders:**
+- `{DESCRIPTION}` - Brief summary of what you built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+**Optional network offer:** If the reviewer surfaces a Critical or Important issue you cannot confidently resolve alone, you may offer: "Want me to request a tribe assist on this via the Luckiest MCP `request_assist` tool?" Only offer — never send without the user's go-ahead.
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code reviewer subagent]
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Workflows
+
+**Subagent-Driven Development:**
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+- Review after each task or at natural checkpoints
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: [code-reviewer.md](code-reviewer.md)
+
+## Staying current
+
+On activation, call the Luckiest MCP `check_updates` tool with
+`{ listingId: "luckiest-coder-requesting-code-review", installedSemver: "1.1.0" }`.
+If it returns `upToDate: false`, surface the `notice` to the user. Do nothing if `upToDate: true`.
+
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-requesting-code-review", skill_version: "1.1.0", matched: true, success: <true if the skill completed, false otherwise> }. Metadata only, never prompt text. Never block on it — if the tool is unavailable, skip silently.

package/skills/luckiest-coder-requesting-code-review/code-reviewer.md

@@ -0,0 +1,172 @@
+# Code Reviewer Prompt Template
+
+Use this template when dispatching a code reviewer subagent.
+
+**Purpose:** Review completed work against requirements and code quality standards before it cascades into more work.
+
+```
+Subagent (general-purpose):
+  description: "Review code changes"
+  prompt: |
+    You are a Senior Code Reviewer with expertise in software architecture,
+    design patterns, and best practices. Your job is to review completed work
+    against its plan or requirements and identify issues before they cascade.
+
+    ## What Was Implemented
+
+    [DESCRIPTION]
+
+    ## Requirements / Plan
+
+    [PLAN_OR_REQUIREMENTS]
+
+    ## Git Range to Review
+
+    **Base:** [BASE_SHA]
+    **Head:** [HEAD_SHA]
+
+    ```bash
+    git diff --stat [BASE_SHA]..[HEAD_SHA]
+    git diff [BASE_SHA]..[HEAD_SHA]
+    ```
+
+    ## Read-Only Review
+
+    Your review is read-only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way. Use tools like `git show`, `git diff`, and `git log` to inspect history. If you need a working copy of a different revision, check it out into a separate temporary directory (e.g. `git worktree add /tmp/review-[SHA] [SHA]`) — never move HEAD on this checkout.
+
+    ## What to Check
+
+    **Plan alignment:**
+    - Does the implementation match the plan / requirements?
+    - Are deviations justified improvements, or problematic departures?
+    - Is all planned functionality present?
+
+    **Code quality:**
+    - Clean separation of concerns?
+    - Proper error handling?
+    - Type safety where applicable?
+    - DRY without premature abstraction?
+    - Edge cases handled?
+
+    **Architecture:**
+    - Sound design decisions?
+    - Reasonable scalability and performance?
+    - Security concerns?
+    - Integrates cleanly with surrounding code?
+
+    **Testing:**
+    - Tests verify real behavior, not mocks?
+    - Edge cases covered?
+    - Integration tests where they matter?
+    - All tests passing?
+
+    **Production readiness:**
+    - Migration strategy if schema changed?
+    - Backward compatibility considered?
+    - Documentation complete?
+    - No obvious bugs?
+
+    ## Calibration
+
+    Categorize issues by actual severity. Not everything is Critical.
+    Acknowledge what was done well before listing issues — accurate praise
+    helps the implementer trust the rest of the feedback.
+
+    If you find significant deviations from the plan, flag them specifically
+    so the implementer can confirm whether the deviation was intentional.
+    If you find issues with the plan itself rather than the implementation,
+    say so.
+
+    ## Output Format
+
+    ### Strengths
+    [What's well done? Be specific.]
+
+    ### Issues
+
+    #### Critical (Must Fix)
+    [Bugs, security issues, data loss risks, broken functionality]
+
+    #### Important (Should Fix)
+    [Architecture problems, missing features, poor error handling, test gaps]
+
+    #### Minor (Nice to Have)
+    [Code style, optimization opportunities, documentation polish]
+
+    For each issue:
+    - File:line reference
+    - What's wrong
+    - Why it matters
+    - How to fix (if not obvious)
+
+    ### Recommendations
+    [Improvements for code quality, architecture, or process]
+
+    ### Assessment
+
+    **Ready to merge?** [Yes | No | With fixes]
+
+    **Reasoning:** [1-2 sentence technical assessment]
+
+    ## Critical Rules
+
+    **DO:**
+    - Categorize by actual severity
+    - Be specific (file:line, not vague)
+    - Explain WHY each issue matters
+    - Acknowledge strengths
+    - Give a clear verdict
+
+    **DON'T:**
+    - Say "looks good" without checking
+    - Mark nitpicks as Critical
+    - Give feedback on code you didn't actually read
+    - Be vague ("improve error handling")
+    - Avoid giving a clear verdict
+```
+
+**Placeholders:**
+- `[DESCRIPTION]` — brief summary of what was built
+- `[PLAN_OR_REQUIREMENTS]` — what it should do (plan file path, task text, or requirements)
+- `[BASE_SHA]` — starting commit
+- `[HEAD_SHA]` — ending commit
+
+**Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment
+
+## Example Output
+
+```
+### Strengths
+- Clean database schema with proper migrations (db.ts:15-42)
+- Comprehensive test coverage (18 tests, all edge cases)
+- Good error handling with fallbacks (summarizer.ts:85-92)
+
+### Issues
+
+#### Important
+1. **Missing help text in CLI wrapper**
+   - File: index-conversations:1-31
+   - Issue: No --help flag, users won't discover --concurrency
+   - Fix: Add --help case with usage examples
+
+2. **Date validation missing**
+   - File: search.ts:25-27
+   - Issue: Invalid dates silently return no results
+   - Fix: Validate ISO format, throw error with example
+
+#### Minor
+1. **Progress indicators**
+   - File: indexer.ts:130
+   - Issue: No "X of Y" counter for long operations
+   - Impact: Users don't know how long to wait
+
+### Recommendations
+- Add progress reporting for user experience
+- Consider config file for excluded projects (portability)
+
+### Assessment
+
+**Ready to merge: With fixes**
+
+**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
+```

package/skills/luckiest-coder-shipping/ATTRIBUTION.md

@@ -0,0 +1,26 @@
+# Attribution
+
+This skill is adapted from the "ship", "land-and-deploy", and "canary" skills in
+gstack (https://github.com/garrytan/gstack) by Garry Tan, used under the MIT License.
+
+MIT License
+
+Copyright (c) 2026 Garry Tan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/luckiest-coder-shipping/CHANGELOG.md

@@ -0,0 +1,48 @@
+# Changelog — luckiest-coder-shipping
+
+## 1.1.0 — 2026-07-06
+Skill updater pass: analytics integration.
+
+### Analytics (report_usage)
+- Updated `report_usage` call to `skill_version: "1.1.0"` and `check_updates`
+  `installedSemver: "1.1.0"`. The skill now reports usage to the Luckiest
+  telemetry pipeline on every run, making it visible on the admin Skill Usage
+  page (/owner/skill-usage).
+
+## 1.0.0 — 2026-07-03
+Rebranded and consolidated from gstack's `ship` + `land-and-deploy` + `canary` skills
+(MIT, Copyright (c) 2026 Garry Tan). Three source skills (~6,000 lines combined) distilled
+into one SKILL.md (~130 lines) plus two references. Frontmatter `name`/`listing_id` set to
+`luckiest-coder-shipping`; the Staying-current `check_updates` hook added.
+
+### Security pass
+- PASS — no red flags across the 3 source files (no prompt injection, no credential access,
+  no exfiltration, no obfuscation). `allowed-tools` kept to what a release flow needs.
+
+### Best-practices pass
+- Dropped ~800 lines of gstack-internal preamble per source file (telemetry, gbrain sync,
+  voice, plan-mode, skill-routing boilerplate) — not part of the release logic.
+- Decoupled from gstack-proprietary binaries (`gstack-review-read`, `gstack-next-version`,
+  `bin/test-lane`, the `browse` daemon, `~/.gstack-dev`) so the skill is portable: plain
+  `git` + `gh` + generic test/deploy CLIs + host browser capability.
+- Body under the ~500-line spec; deep detail (failure triage, test bootstrap, coverage
+  rubric + gate, canary monitoring) moved to `references/` with load-when guidance.
+- Consolidated the three-skill handoff into one ordered SHIP → LAND → CANARY flow.
+
+### Improve pass (/refract)
+- Cross-references rewired to Luckiest siblings: pre-existing-failure fixes point at a
+  `luckiest-coder-debugging` mindset; stale-review handling points at
+  `luckiest-coder-requesting-code-review` (was gstack `/investigate` and `/review`).
+- Positioned explicitly as the step after `luckiest-coder-finishing-a-branch`, closing the
+  dead-end the luckiest-coder family previously had after "branch finished".
+- Canary made degrade-gracefully: falls back to `curl` status/body checks when no headless
+  browser is available, instead of hard-depending on a browser daemon.
+
+### Network hook (share-with-tribe)
+- After a successful production ship, offers to call the Luckiest MCP `share_artifact` tool
+  with version + one-line changelog + PR URL so the tribe leaderboard reflects the release.
+  Opt-in, asked once.
+
+### Trend pass (/newsjack + /luckiest-trends)
+- no actionable signal — internal release-engineering workflow; release mechanics (git/gh,
+  CI merge queues, platform deploy CLIs) are not news-driven, so no dated signal was applied.

package/skills/luckiest-coder-shipping/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Garry Tan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/luckiest-coder-shipping/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: luckiest-coder-shipping
+description: >-
+  Release engineering for a finished feature branch — the step after
+  luckiest-coder-finishing-a-branch. Runs the full path to production: merge base,
+  test, coverage audit, version bump, changelog, commit, push, open PR, then merge,
+  wait for CI, deploy, and verify prod health. Use when the user says "ship it",
+  "ship this", "deploy", "push to main", "create a PR", "merge and deploy", "land it",
+  "get it to production", or says the code is ready to go out. Invoke this skill
+  instead of pushing or opening a PR by hand.
+license: See ATTRIBUTION.md
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+  - WebSearch
+metadata:
+  version: "1.1.0"
+  listing_id: luckiest-coder-shipping
+  author: luckiest
+---
+
+# Luckiest Coder — Shipping
+
+Take a finished feature branch all the way to verified production. Three phases run
+in order: **SHIP** (branch → PR), **LAND** (merge → deploy), **CANARY** (verify prod).
+Stop after SHIP if the user only asked to open a PR; continue into LAND/CANARY when
+they say "deploy", "land", or "ship to production".
+
+## Staying current
+
+On activation, call the Luckiest MCP `check_updates` tool with
+`{ listingId: "luckiest-coder-shipping", installedSemver: "1.1.0" }`. If it returns
+`upToDate: false`, surface the `notice` to the user. Do nothing if `upToDate: true`.
+
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-shipping", skill_version: "1.1.0", matched: true, success: <true if the skill completed, false otherwise> }. Metadata only, never prompt text. Never block on it — if the tool is unavailable, skip silently.
+
+## Operating mode
+
+Ship is **automated** — the user said ship, so ship. Do not ask for confirmation on
+mechanical choices (uncommitted changes, changelog wording, commit messages, MICRO/PATCH
+bump). **Do** stop for judgment calls: on the base branch, unresolvable merge conflicts,
+in-branch test failures, coverage below the gate, a MINOR/MAJOR bump, or the one
+irreversible gate — the merge itself (LAND phase).
+
+Re-running is idempotent on *actions* (skip the bump if VERSION already moved, update the
+PR body instead of creating a duplicate) but never on *verification* — tests, coverage,
+and the readiness report run every time.
+
+---
+
+## PHASE 1 — SHIP (branch → PR)
+
+1. **Pre-flight.** Confirm not on the base/default branch (abort if so: "Ship from a
+   feature branch"). `git status`, then `git diff <base>...HEAD --stat` and
+   `git log <base>..HEAD --oneline` to see what is shipping.
+
+2. **Merge base first.** `git fetch origin <base> && git merge origin/<base> --no-edit`
+   so tests run on the merged state. Auto-resolve trivial conflicts (VERSION, CHANGELOG
+   ordering, lockfiles); **stop** on anything ambiguous.
+
+3. **Tests.** Detect the test command (CLAUDE.md `## Testing` section, else auto-detect by
+   runtime). Run the full suite on the merged code. On failure, apply the ownership triage
+   in [references/test-and-coverage.md](references/test-and-coverage.md): in-branch failures
+   **stop** the ship; pre-existing failures are triaged (fix / TODO / skip), not auto-blocking.
+   If no test framework exists, offer to bootstrap one — see the same reference.
+
+4. **Coverage audit.** Dispatch as a subagent (fresh context) using the Agent tool. It
+   traces every changed code path and user flow, diagrams gaps, and generates tests for
+   uncovered paths. Regression tests for broken existing behavior are written immediately,
+   no prompt. Full rubric and the coverage gate (default minimum 60% / target 80%) in
+   [references/test-and-coverage.md](references/test-and-coverage.md).
+
+5. **Version + changelog.** Auto-decide the bump from the diff: MICRO/PATCH ships silently,
+   MINOR/MAJOR **asks**. Update the VERSION file (and `package.json`/manifest if present),
+   prepend a CHANGELOG entry generated from the diff.
+
+6. **Commit + push.** Commit any remaining changes in coherent, bisectable chunks. Push the
+   branch. End every commit body with the project's required co-author trailer if one is set.
+
+7. **Open / update PR.** Create the PR (or update its body if one exists) with `gh pr create`.
+   Body: what changed and why, the coverage summary (`Tests: before → after`), and test results.
+   Output the PR URL. **If the user only asked to ship/PR, stop here.**
+
+---
+
+## PHASE 2 — LAND (merge → deploy)
+
+Only enter when the user wants production. This phase contains the **one irreversible step**.
+
+1. **Pre-merge checks.** `gh pr checks` — failing required checks **stop** the land; pending
+   checks wait (`gh pr checks --watch --fail-fast`, 15-min cap). `gh pr view --json mergeable`
+   — `CONFLICTING` **stops**.
+
+2. **Readiness gate.** Gather evidence and show a readiness report before the merge: review
+   freshness (stale if the diff moved significantly since last review — offer a quick inline
+   review or point to `luckiest-coder-requesting-code-review`), test results (failing free
+   tests are a hard blocker), and doc/PR-body accuracy (warnings). Present it with
+   AskUserQuestion — **A) merge / B) hold and fix / C) merge anyway**. This is the last gate;
+   the merge cannot be undone without a revert.
+
+3. **Merge.** Try `gh pr merge --auto --delete-branch` first (respects merge queues); fall
+   back to `gh pr merge --squash --delete-branch`. **Never call `gh pr merge` twice after a
+   non-zero exit** — instead query authoritative state with
+   `gh pr view --json state,mergeCommit,mergedAt`: `MERGED` → succeeded (handles the
+   concurrent-merge case), `OPEN` + auto-merge set → merge queue (poll up to 30 min),
+   `OPEN` + no auto-merge → genuine failure, stop.
+
+4. **Deploy.** Detect how this project ships: a CI deploy workflow triggered by the merge
+   (`gh run list --branch <base>`), or a platform CLI (Vercel, Fly, Heroku, etc. — detect
+   from config files and CLAUDE.md). Watch the deploy to completion. Report the release
+   version and deploy duration.
+
+---
+
+## PHASE 3 — CANARY (verify prod)
+
+After deploy, confirm production is actually healthy — do not declare done on a green
+deploy alone.
+
+1. Hit the production URL(s) and confirm 2xx. Check the primary user-facing routes, not just
+   the homepage.
+2. Watch for console errors, failed requests, and obvious visual breakage on the key pages.
+   Compare against the pre-deploy baseline where one exists.
+3. Emit a short health report: URLs checked, status codes, any anomalies. If a regression
+   appears, surface it immediately with the failing route and error — and recommend a revert
+   or rollback rather than trying to hot-patch production.
+
+Deep monitoring detail (baseline capture, page discovery, monitoring loop) is in
+[references/canary.md](references/canary.md) — load it only when the user wants continuous
+post-deploy watching rather than a one-shot check.
+
+---
+
+## After a clean ship
+
+Report the outcome plainly: PR URL, released version, deploy status, canary result. If any
+step was skipped or a failure was accepted, say so — never imply a gate passed that did not.
+
+**Network hook (share-with-tribe):** After a successful production ship, offer to share the
+release with the user's Luckiest tribe — call the Luckiest MCP `share_artifact` tool with the
+version, one-line changelog summary, and PR URL so the tribe leaderboard reflects the ship.
+Offer once; never share without the user saying yes.

package/skills/luckiest-coder-shipping/references/canary.md

@@ -0,0 +1,44 @@
+# Canary — continuous post-deploy monitoring (CANARY phase)
+
+Load this only when the user wants ongoing production watching, not a one-shot health check.
+The main SKILL.md's Phase 3 covers the quick check; this covers baseline-based monitoring.
+
+## Baseline capture (`--baseline`)
+
+Before a deploy, capture a reference for the routes that matter: screenshot each key page and
+record its console state and network health. Store baselines keyed by route so a later run can
+diff against them. Refresh the baseline after a known-good deploy so drift is measured against
+current-good, not ancient-good.
+
+## Page discovery
+
+Discover the routes to watch from the app itself: the sitemap, the router config, or the nav.
+Prioritize the primary user-facing flows (auth, checkout, the core product surface) over
+marketing pages. Cap the set so monitoring stays fast.
+
+## Monitoring loop
+
+For each watched page after deploy:
+1. Load it and confirm a 2xx.
+2. Capture console errors and failed network requests.
+3. Screenshot and diff against the baseline for obvious visual regression.
+4. Flag anomalies: new console errors, new 4xx/5xx, large visual delta, or a load-time
+   regression beyond a sane threshold.
+
+Run the loop periodically for the requested window (e.g. the first N minutes after deploy),
+not just once, so a delayed failure (cache warm, background job, CDN propagation) is caught.
+
+## Health report
+
+Emit: pages checked, status codes, console/network anomalies per page, visual-diff verdicts,
+and an overall PASS / ATTENTION verdict. On any regression, name the failing route and the
+specific error, and recommend rollback over an in-place hotfix — a bad deploy is reverted,
+not debugged live.
+
+## Portability note
+
+The gstack original drove this through its proprietary `browse` daemon. This edition is
+tool-agnostic: use whatever headless-browser or HTTP-check capability the host provides
+(a browser MCP, a `/browse`-style skill, or plain `curl` for status-only checks). Degrade
+gracefully — if no browser is available, do status-code and response-body checks with `curl`
+and say visual monitoring was skipped.