luckiest-co 1.0.38 → 1.0.40

package/skills/luckiest-coder-git-worktrees/SKILL.md

@@ -1,215 +0,0 @@
----
-name: luckiest-coder-git-worktrees
-description: Use when starting feature work that needs isolation from your current workspace, or before executing an implementation plan, to guarantee an isolated workspace exists. Sets up isolation via your platform's native worktree tools or a manual git worktree fallback, verifies the directory is gitignored, runs project setup, and confirms a clean test baseline. Trigger phrases include "set up a worktree", "isolate this work", "create an isolated workspace", "work on a separate branch safely", or before starting any multi-step implementation.
-license: See ATTRIBUTION.md
-metadata:
-  version: "1.1.0"
-  listing_id: luckiest-coder-git-worktrees
-  author: luckiest
----
-
-# Using Git Worktrees
-
-## Overview
-
-Ensure work happens in an isolated workspace. Prefer your platform's native worktree tools. Fall back to manual git worktrees only when no native tool is available.
-
-**Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness.
-
-**Announce at start:** "I'm using the luckiest-coder-git-worktrees skill to set up an isolated workspace."
-
-## Step 0: Detect Existing Isolation
-
-**Before creating anything, check if you are already in an isolated workspace.**
-
-```bash
-GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
-GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
-BRANCH=$(git branch --show-current)
-```
-
-**Submodule guard:** `GIT_DIR != GIT_COMMON` is also true inside git submodules. Before concluding "already in a worktree," verify you are not in a submodule:
-
-```bash
-# If this returns a path, you're in a submodule, not a worktree — treat as normal repo
-git rev-parse --show-superproject-working-tree 2>/dev/null
-```
-
-**If `GIT_DIR != GIT_COMMON` (and not a submodule):** You are already in a linked worktree. Skip to Step 2 (Project Setup). Do NOT create another worktree.
-
-Report with branch state:
-- On a branch: "Already in isolated workspace at `<path>` on branch `<name>`."
-- Detached HEAD: "Already in isolated workspace at `<path>` (detached HEAD, externally managed). Branch creation needed at finish time."
-
-**If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout.
-
-Has the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree:
-
-> "Would you like me to set up an isolated worktree? It protects your current branch from changes."
-
-Honor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2.
-
-## Step 1: Create Isolated Workspace
-
-**You have two mechanisms. Try them in this order.**
-
-### 1a. Native Worktree Tools (preferred)
-
-The user has asked for an isolated workspace (Step 0 consent). Do you already have a way to create a worktree? It might be a tool with a name like `EnterWorktree`, `WorktreeCreate`, a `/worktree` command, or a `--worktree` flag. If you do, use it and skip to Step 2.
-
-Native tools handle directory placement, branch creation, and cleanup automatically. Using `git worktree add` when you have a native tool creates phantom state your harness can't see or manage.
-
-Only proceed to Step 1b if you have no native worktree tool available.
-
-### 1b. Git Worktree Fallback
-
-**Only use this if Step 1a does not apply** — you have no native worktree tool available. Create a worktree manually using git.
-
-#### Directory Selection
-
-Follow this priority order. Explicit user preference always beats observed filesystem state.
-
-1. **Check your instructions for a declared worktree directory preference.** If the user has already specified one, use it without asking.
-
-2. **Check for an existing project-local worktree directory:**
-   ```bash
-   ls -d .worktrees 2>/dev/null     # Preferred (hidden)
-   ls -d worktrees 2>/dev/null      # Alternative
-   ```
-   If found, use it. If both exist, `.worktrees` wins.
-
-3. **If there is no other guidance available**, default to `.worktrees/` at the project root.
-
-#### Safety Verification (project-local directories only)
-
-**MUST verify directory is ignored before creating worktree:**
-
-```bash
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
-```
-
-**If NOT ignored:** Add to .gitignore, commit the change, then proceed.
-
-**Why critical:** Prevents accidentally committing worktree contents to repository.
-
-#### Create the Worktree
-
-```bash
-# Determine path based on chosen location
-path="$LOCATION/$BRANCH_NAME"
-
-git worktree add "$path" -b "$BRANCH_NAME"
-cd "$path"
-```
-
-**Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), tell the user the sandbox blocked worktree creation and you're working in the current directory instead. Then run setup and baseline tests in place.
-
-## Step 2: Project Setup
-
-Auto-detect and run appropriate setup:
-
-```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
-
-# Rust
-if [ -f Cargo.toml ]; then cargo build; fi
-
-# Python
-if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
-if [ -f pyproject.toml ]; then poetry install; fi
-
-# Go
-if [ -f go.mod ]; then go mod download; fi
-```
-
-## Step 3: Verify Clean Baseline
-
-Run tests to ensure workspace starts clean:
-
-```bash
-# Use project-appropriate command
-npm test / cargo test / pytest / go test ./...
-```
-
-**If tests fail:** Report failures, ask whether to proceed or investigate.
-
-**If tests pass:** Report ready.
-
-### Report
-
-```
-Worktree ready at <full-path>
-Tests passing (<N> tests, 0 failures)
-Ready to implement <feature-name>
-```
-
-## Quick Reference
-
-| Situation | Action |
-|-----------|--------|
-| Already in linked worktree | Skip creation (Step 0) |
-| In a submodule | Treat as normal repo (Step 0 guard) |
-| Native worktree tool available | Use it (Step 1a) |
-| No native tool | Git worktree fallback (Step 1b) |
-| `.worktrees/` exists | Use it (verify ignored) |
-| `worktrees/` exists | Use it (verify ignored) |
-| Both exist | Use `.worktrees/` |
-| Neither exists | Check instruction file, then default `.worktrees/` |
-| Directory not ignored | Add to .gitignore + commit |
-| Permission error on create | Sandbox fallback, work in place |
-| Tests fail during baseline | Report failures + ask |
-| No package.json/Cargo.toml | Skip dependency install |
-
-## Common Mistakes
-
-### Fighting the harness
-
-- **Problem:** Using `git worktree add` when the platform already provides isolation
-- **Fix:** Step 0 detects existing isolation. Step 1a defers to native tools.
-
-### Skipping detection
-
-- **Problem:** Creating a nested worktree inside an existing one
-- **Fix:** Always run Step 0 before creating anything
-
-### Skipping ignore verification
-
-- **Problem:** Worktree contents get tracked, pollute git status
-- **Fix:** Always use `git check-ignore` before creating project-local worktree
-
-### Assuming directory location
-
-- **Problem:** Creates inconsistency, violates project conventions
-- **Fix:** Follow priority: explicit instructions > existing project-local directory > default
-
-### Proceeding with failing tests
-
-- **Problem:** Can't distinguish new bugs from pre-existing issues
-- **Fix:** Report failures, get explicit permission to proceed
-
-## Red Flags
-
-**Never:**
-- Create a worktree when Step 0 detects existing isolation
-- Use `git worktree add` when you have a native worktree tool (e.g., `EnterWorktree`). This is the #1 mistake — if you have it, use it.
-- Skip Step 1a by jumping straight to Step 1b's git commands
-- Create worktree without verifying it's ignored (project-local)
-- Skip baseline test verification
-- Proceed with failing tests without asking
-
-**Always:**
-- Run Step 0 detection first
-- Prefer native tools over git fallback
-- Follow directory priority: explicit instructions > existing project-local directory > default
-- Verify directory is ignored for project-local
-- Auto-detect and run project setup
-- Verify clean test baseline
-
-## Staying current
-
-On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "5d932bcb-3dab-4b66-915e-4dffbec3ef59", 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-git-worktrees", 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-guard/CHANGELOG.md

@@ -1,48 +0,0 @@
-# Changelog — luckiest-coder-guard
-
-## 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 `careful` + `freeze` + `guard` + `unfreeze` skills
-(MIT, Copyright (c) 2026 Garry Tan) into one hook-driven safety skill. Frontmatter
-`name`/`listing_id` set to `luckiest-coder-guard`; Staying-current `check_updates` hook added.
-
-### Security pass
-- PASS — the two hook scripts read stdin JSON and emit permission decisions only; no
-  credential access, no network calls, no obfuscation. The sole side effect in the originals
-  was a local-only analytics append, which was removed.
-
-### Best-practices pass
-- Four source skills collapsed into one. This exploits the fact that the freeze hook is a
-  no-op when no boundary file exists: "careful" is just the skill active with no boundary,
-  "freeze"/"guard" set a boundary, "unfreeze" clears it — one skill, four behaviors, no
-  cross-skill hook-path dependency (gstack's `guard` reached into sibling `../careful/bin`
-  and `../freeze/bin`; this skill owns both scripts).
-- Removed the gstack analytics/telemetry writes to `~/.gstack/analytics/skill-usage.jsonl`
-  from both scripts and the skill body.
-- Rebranded hook state root from `~/.gstack` to `~/.luckiest` (still honors
-  `CLAUDE_PLUGIN_DATA`); warning/deny message prefix changed to `[guard]`.
-- Added an honest "Limits" section (not a security boundary; Bash can still write outside the
-  freeze dir; session-scoped; symlink-resolution edge) — the original scattered these caveats.
-
-### Improve pass (/refract)
-- Boundary-set step now hard-fails if the path does not resolve to an existing directory,
-  instead of silently writing an empty/garbage boundary.
-
-### Verification
-- Smoke-tested the scripts: destructive commands warn (`rm -rf /var/data`, `git push -f`),
-  safe/build-artifact deletes allow (`rm -rf node_modules`, `ls`), no-boundary allows all
-  edits, a set boundary allows edits inside (including new files) and denies edits outside.
-
-### Network hook
-- N/A — a guardrail skill emits no shareable artifact.
-
-### Trend pass (/newsjack + /luckiest-trends)
-- no actionable signal — safety-guardrail tooling is not news-driven.

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

@@ -1,126 +0,0 @@
----
-name: luckiest-coder-guard
-description: >-
-  Safety guardrails for risky sessions. Warns before destructive shell commands
-  (rm -rf, DROP TABLE, TRUNCATE, git push --force, git reset --hard, kubectl delete,
-  docker prune) and can hard-block file edits outside a chosen directory. Use when
-  touching production, debugging live systems, or working in a shared repo. Trigger
-  phrases: "be careful", "safety mode", "prod mode", "guard mode", "full safety",
-  "lock it down", "freeze edits to this folder", "restrict edits", and "unfreeze" /
-  "unlock edits" to clear the boundary.
-license: See ATTRIBUTION.md
-allowed-tools:
-  - Bash
-  - Read
-  - AskUserQuestion
-hooks:
-  PreToolUse:
-    - matcher: "Bash"
-      hooks:
-        - type: command
-          command: "bash ${CLAUDE_SKILL_DIR}/bin/check-careful.sh"
-          statusMessage: "Checking for destructive commands..."
-    - matcher: "Edit"
-      hooks:
-        - type: command
-          command: "bash ${CLAUDE_SKILL_DIR}/bin/check-freeze.sh"
-          statusMessage: "Checking freeze boundary..."
-    - matcher: "Write"
-      hooks:
-        - type: command
-          command: "bash ${CLAUDE_SKILL_DIR}/bin/check-freeze.sh"
-          statusMessage: "Checking freeze boundary..."
-metadata:
-  version: "1.1.0"
-  listing_id: luckiest-coder-guard
-  author: luckiest
----
-
-# Luckiest Coder — Guard
-
-Session-scoped safety rails, enforced by PreToolUse hooks (not by remembering to be
-careful). Two protections, independently controllable:
-
-- **Careful** — every Bash command is screened for destructive patterns and you are asked
-  to confirm before it runs. Active as soon as this skill is on. Nothing to configure.
-- **Freeze** — Edit/Write to any file outside a chosen directory is *blocked* (denied, not
-  just warned). Off until you set a boundary.
-
-"Guard mode" is simply both at once: careful is always on, plus a freeze boundary.
-
-## Staying current
-
-On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "b5c418c2-ccae-4d25-bb50-45ddad56d121", installedSemver: "1.1.0" }`. If it returns
-`upToDate: false`, surface the `notice`. 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-guard", 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.
-
-## Activating
-
-Tell the user careful mode is now active: destructive commands will prompt for
-confirmation before running, and they can always override. Then ask what they want:
-
-- **Just careful** (warnings only) → done, no boundary needed.
-- **Freeze / guard** (also lock edits to one folder) → run the Set a boundary step below.
-
-## Set a boundary (freeze / guard)
-
-Ask, via AskUserQuestion with a free-text answer, which directory edits should be
-restricted to. Files outside it will be blocked. Then persist it:
-
-```bash
-BOUNDARY=$(cd "<user-provided-path>" 2>/dev/null && pwd -P)
-[ -z "$BOUNDARY" ] && { echo "That path does not exist — pick an existing directory."; exit 1; }
-STATE_DIR="${CLAUDE_PLUGIN_DATA:-$HOME/.luckiest}"
-mkdir -p "$STATE_DIR"
-printf '%s/\n' "${BOUNDARY%/}" > "$STATE_DIR/freeze-dir.txt"
-echo "Freeze boundary set: ${BOUNDARY%/}/"
-```
-
-Tell the user: edits are now restricted to that directory; any Edit or Write outside it is
-blocked. To change it, run this step again. To remove it, run the Unfreeze step.
-
-## Unfreeze (clear the boundary)
-
-Removes the edit restriction without ending the session. Careful-mode warnings stay on.
-
-```bash
-STATE_DIR="${CLAUDE_PLUGIN_DATA:-$HOME/.luckiest}"
-if [ -f "$STATE_DIR/freeze-dir.txt" ]; then
-  PREV=$(cat "$STATE_DIR/freeze-dir.txt")
-  rm -f "$STATE_DIR/freeze-dir.txt"
-  echo "Freeze boundary cleared (was: $PREV). Edits allowed everywhere again."
-else
-  echo "No freeze boundary was set."
-fi
-```
-
-## What careful mode catches
-
-| Pattern | Example | Risk |
-|---|---|---|
-| `rm -rf` / `rm -r` / `--recursive` | `rm -rf /var/data` | Recursive delete |
-| `DROP TABLE` / `DROP DATABASE` | `DROP TABLE users;` | Data loss |
-| `TRUNCATE` | `TRUNCATE orders;` | Data loss |
-| `git push --force` / `-f` | `git push -f origin main` | History rewrite |
-| `git reset --hard` | `git reset --hard HEAD~3` | Uncommitted work loss |
-| `git checkout .` / `git restore .` | `git checkout .` | Uncommitted work loss |
-| `kubectl delete` | `kubectl delete pod x` | Production impact |
-| `docker rm -f` / `system prune` | `docker system prune -a` | Container/image loss |
-
-**Safe exceptions** (no warning): recursive delete of `node_modules`, `.next`, `dist`,
-`build`, `__pycache__`, `.cache`, `.turbo`, `coverage`.
-
-## Limits (be honest about these)
-
-- This prevents *accidents*, it is not a security boundary. A Bash command like `sed -i` or
-  `> file` can still modify files outside the freeze boundary — only the Edit/Write tools are
-  gated. Careful screens command *text*; it does not sandbox execution.
-- Hooks and the boundary are **session-scoped**. Warnings and blocks stop when the
-  conversation ends; the boundary state file is cleared by the Unfreeze step or ignored once
-  the hooks are no longer registered.
-- Boundary matching resolves symlinks; if both the boundary and a target's parent directory
-  are unresolvable, a path may be over-blocked. Point the boundary at a directory that exists.
-
-Network hook: N/A — a guardrail emits no shareable artifact.

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

@@ -1,160 +0,0 @@
----
-name: luckiest-coder-qa
-description: >-
-  Systematically QA-test a running web app in a real browser, then fix the bugs it
-  finds. Explores pages, drives interactions, captures screenshot evidence, scores app
-  health, then iteratively fixes each bug in source — one atomic commit per fix — and
-  re-verifies with a before/after pair plus a regression test. Use when asked to "qa",
-  "QA this", "test this site", "test the app", "find bugs", "does this work?", "test and
-  fix", or "fix what's broken". For a bug report with no code changes, run in report-only
-  mode ("just report bugs", "qa report only", "test but don't fix"). Suggest it when the
-  user says a feature is ready to test.
-license: See ATTRIBUTION.md
-allowed-tools:
-  - Bash
-  - Read
-  - Write
-  - Edit
-  - Glob
-  - Grep
-  - AskUserQuestion
-  - WebSearch
-metadata:
-  version: "1.1.0"
-  listing_id: luckiest-coder-qa
-  author: luckiest
----
-
-# Luckiest Coder — QA
-
-Drive a real browser against a running app, find bugs with evidence, score health, then
-fix and re-verify. Two outcomes:
-
-- **Test → Fix → Verify (default):** find bugs, fix them in source, prove each fix.
-- **Report-only:** run the test half and produce a report — never touch code. Use when the
-  user says "just report bugs" / "don't fix". Stop after the Report phase; skip Fix Loop on.
-
-## Staying current
-
-On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "9f4d60ff-052b-49b6-8125-dd93159db07d", installedSemver: "1.1.0" }`. If it returns
-`upToDate: false`, surface the `notice`. 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-qa", 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.
-
-## Browser capability (read first)
-
-This skill needs to drive a browser. Use whatever the host provides — a browser MCP, a
-`/browse`-style skill, or the built-in preview tools — for: navigate, screenshot, snapshot
-the accessibility tree, read console errors, inspect elements, fill/click, resize viewport.
-The steps below are tool-agnostic; map each action to your host's equivalent. If no browser
-is available, say so and fall back to `curl` for status/response checks only, noting that
-visual and interaction testing was skipped.
-
-## Modes
-
-- **Diff-aware** (default on a feature branch with no URL): read `git diff <base>...HEAD`,
-  map changed files to affected routes/pages, detect the running local app (common dev
-  ports), and test only those pages plus adjacent regressions. Cross-reference commits/PR
-  intent — verify the change does what it claims. Fall back to Quick if the diff maps to no
-  obvious page (backend/config still needs the app verified).
-- **Full** (default when a URL is given): systematic exploration of every reachable page.
-- **Quick** (`--quick`): 30-second smoke test — homepage + top 5 nav targets; loads? console
-  errors? broken links?
-- **Regression** (`--regression <baseline>`): run Full, then diff against a prior
-  `baseline.json` — fixed vs new issues, score delta.
-
-Tiers control how much gets fixed later: **Quick** = critical+high, **Standard** = +medium,
-**Exhaustive** = +cosmetic.
-
----
-
-## Test phase (both modes run this)
-
-**1. Initialize.** Create an output dir for screenshots and the report; copy the report
-template from [references/qa-report-template.md](references/qa-report-template.md). Start a timer.
-
-**2. Authenticate (if needed).** Log in via the form, or import a cookie file. **Never write
-real passwords into the report — redact them.** For 2FA/CAPTCHA, ask the user and wait.
-
-**3. Orient.** Load the target, screenshot, map navigation links, check landing-page console.
-Detect the framework (Next.js, Rails, WordPress, SPA) and note it. For SPAs, find nav via the
-accessibility snapshot since link-mapping returns little.
-
-**4. Explore.** Visit pages systematically. At each, run the per-page checklist in
-[references/issue-taxonomy.md](references/issue-taxonomy.md): visual scan, click every
-interactive element, fill/submit forms (empty, invalid, edge cases), check navigation in/out,
-check empty/loading/error/overflow states, re-check console after interactions, and test a
-mobile viewport where relevant. Spend depth on core features (dashboard, checkout, search),
-less on secondary pages.
-
-**5. Document each issue immediately** (don't batch). Interactive bugs get a before/action/
-after screenshot sequence plus repro steps; static bugs get one annotated screenshot. Write
-each into the report using the template, classified by the taxonomy's severity + category.
-
-**6. Wrap up.** Compute the health score (rubric below), write "Top 3 Things to Fix", a
-console-health summary, severity counts, and metadata. Save a `baseline.json`
-(`{date, url, healthScore, issues[], categoryScores}`) for future regression runs.
-
-### Health score
-
-Each category starts at 100; weighted average is the final score.
-- Console (15%): 0 err→100, 1-3→70, 4-10→40, 10+→10.
-- Links (10%): -15 per broken link.
-- Visual (10%), Functional (20%), UX (15%), Performance (10%), Content (5%),
-  Accessibility (15%): deduct per finding — critical -25, high -15, medium -8, low -3.
-
-`score = Σ(category_score × weight)`, min 0 per category.
-
-**Report-only mode stops here** — write the report and hand it over. No code changes.
-
----
-
-## Fix phase (default mode only)
-
-**7. Triage.** Sort issues by severity; fix the set the tier allows (Quick: crit+high,
-Standard: +medium, Exhaustive: all). Mark anything unfixable from source (third-party
-widgets, infra) as deferred.
-
-**8. Fix loop** — per issue, in severity order:
-- **Locate** the responsible source file(s) via grep/glob on error text, component names,
-  routes. Touch only files directly related to the bug.
-- **Fix minimally** — the smallest change that resolves it. No refactoring or unrelated
-  "improvements" (invoke a `luckiest-coder-debugging` mindset for root cause when the bug is
-  non-obvious).
-- **Commit atomically:** `git commit -m "fix(qa): ISSUE-NNN — <desc>"`. One commit per fix,
-  never bundled. End with the project's co-author trailer if one is required.
-- **Re-test:** reload the page, capture a before/after screenshot pair, check console, verify
-  the intended effect.
-- **Classify:** *verified* (re-test confirms, no new errors), *best-effort* (applied but
-  unverifiable), or *reverted* (`git revert HEAD`, mark deferred) on regression.
-- **Regression test** (skip if not verified, or pure CSS, or no test framework): match the
-  nearest existing tests' conventions, reproduce the exact precondition that triggered the
-  bug, assert correct behavior (never "it renders"), add an attribution comment
-  (`// Regression: ISSUE-NNN — <what broke>, found by luckiest-coder-qa <date>`), run just the
-  new file, commit as `test(qa): regression test for ISSUE-NNN` on green.
-
-**Self-regulation.** Every 5 fixes (or after any revert) compute a WTF-likelihood: +15% per
-revert, +5% per fix touching >3 files, +1% per fix past 15, +20% for touching unrelated
-files. **Over 20% → STOP**, show what you've done, ask whether to continue. **Hard cap: 50
-fixes.**
-
-**9. Final QA.** Re-run the test phase on affected pages, recompute the health score. If the
-final score is *worse* than baseline, warn prominently — something regressed.
-
-**10. Report.** Write the full report (template) with per-issue fix status, commit SHA, files
-changed, before/after screenshots, and a summary: issues found, fixes (verified/best-effort/
-reverted), deferred, and health delta. Include a one-line PR summary:
-"QA found N issues, fixed M, health score X → Y." If a `TODOS.md` exists, add new deferred
-bugs and annotate any it listed that you fixed.
-
----
-
-## After QA
-
-Report plainly: issues found, fixed, deferred, health before → after. State the ship verdict
-honestly — do not call an app ship-ready if critical/high issues remain deferred.
-
-**Network hook (share-with-tribe):** After a QA run that fixed bugs, offer once to call the
-Luckiest MCP `share_artifact` tool with the health-score delta and fix count so the tribe
-leaderboard reflects the quality pass. Never share without the user's yes.

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

@@ -1,28 +0,0 @@
-# Changelog — luckiest-coder-receiving-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 receiving-code-review (Superpowers, MIT).
-
-### Rebrand
-- Frontmatter `name` -> luckiest-coder-receiving-code-review; added license + metadata.
-- No cross-skill references in body; no path fragments to change.
-- Added "Staying current" MCP check_updates section.
-
-### Improve pass (/refract)
-- Rewrote the `description` for trigger-matching with concrete trigger phrases
-  (human/subagent/GitHub sources). No reception guidance changed.
-
-### Network hook
-- N/A (skill consumes a review; produces no shareable artifact).
-
-### Trend pass (/newsjack + /luckiest-trends)
-- no actionable signal (internal dev-workflow skill)