luckiest-co 1.0.0 → 1.0.3

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

@@ -0,0 +1,160 @@
+---
+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: "luckiest-coder-qa", 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-qa/references/issue-taxonomy.md

@@ -0,0 +1,85 @@
+# QA Issue Taxonomy
+
+## Severity Levels
+
+| Severity | Definition | Examples |
+|----------|------------|----------|
+| **critical** | Blocks a core workflow, causes data loss, or crashes the app | Form submit causes error page, checkout flow broken, data deleted without confirmation |
+| **high** | Major feature broken or unusable, no workaround | Search returns wrong results, file upload silently fails, auth redirect loop |
+| **medium** | Feature works but with noticeable problems, workaround exists | Slow page load (>5s), form validation missing but submit still works, layout broken on mobile only |
+| **low** | Minor cosmetic or polish issue | Typo in footer, 1px alignment issue, hover state inconsistent |
+
+## Categories
+
+### 1. Visual/UI
+- Layout breaks (overlapping elements, clipped text, horizontal scrollbar)
+- Broken or missing images
+- Incorrect z-index (elements appearing behind others)
+- Font/color inconsistencies
+- Animation glitches (jank, incomplete transitions)
+- Alignment issues (off-grid, uneven spacing)
+- Dark mode / theme issues
+
+### 2. Functional
+- Broken links (404, wrong destination)
+- Dead buttons (click does nothing)
+- Form validation (missing, wrong, bypassed)
+- Incorrect redirects
+- State not persisting (data lost on refresh, back button)
+- Race conditions (double-submit, stale data)
+- Search returning wrong or no results
+
+### 3. UX
+- Confusing navigation (no breadcrumbs, dead ends)
+- Missing loading indicators (user doesn't know something is happening)
+- Slow interactions (>500ms with no feedback)
+- Unclear error messages ("Something went wrong" with no detail)
+- No confirmation before destructive actions
+- Inconsistent interaction patterns across pages
+- Dead ends (no way back, no next action)
+
+### 4. Content
+- Typos and grammar errors
+- Outdated or incorrect text
+- Placeholder / lorem ipsum text left in
+- Truncated text (cut off without ellipsis or "more")
+- Wrong labels on buttons or form fields
+- Missing or unhelpful empty states
+
+### 5. Performance
+- Slow page loads (>3 seconds)
+- Janky scrolling (dropped frames)
+- Layout shifts (content jumping after load)
+- Excessive network requests (>50 on a single page)
+- Large unoptimized images
+- Blocking JavaScript (page unresponsive during load)
+
+### 6. Console/Errors
+- JavaScript exceptions (uncaught errors)
+- Failed network requests (4xx, 5xx)
+- Deprecation warnings (upcoming breakage)
+- CORS errors
+- Mixed content warnings (HTTP resources on HTTPS)
+- CSP violations
+
+### 7. Accessibility
+- Missing alt text on images
+- Unlabeled form inputs
+- Keyboard navigation broken (can't tab to elements)
+- Focus traps (can't escape a modal or dropdown)
+- Missing or incorrect ARIA attributes
+- Insufficient color contrast
+- Content not reachable by screen reader
+
+## Per-Page Exploration Checklist
+
+For each page visited during a QA session:
+
+1. **Visual scan** — Take annotated screenshot (`snapshot -i -a -o`). Look for layout issues, broken images, alignment.
+2. **Interactive elements** — Click every button, link, and control. Does each do what it says?
+3. **Forms** — Fill and submit. Test empty submission, invalid data, edge cases (long text, special characters).
+4. **Navigation** — Check all paths in/out. Breadcrumbs, back button, deep links, mobile menu.
+5. **States** — Check empty state, loading state, error state, full/overflow state.
+6. **Console** — Run `console --errors` after interactions. Any new JS errors or failed requests?
+7. **Responsiveness** — If relevant, check mobile and tablet viewports.
+8. **Auth boundaries** — What happens when logged out? Different user roles?

package/skills/luckiest-coder-qa/references/qa-report-template.md

@@ -0,0 +1,126 @@
+# QA Report: {APP_NAME}
+
+| Field | Value |
+|-------|-------|
+| **Date** | {DATE} |
+| **URL** | {URL} |
+| **Branch** | {BRANCH} |
+| **Commit** | {COMMIT_SHA} ({COMMIT_DATE}) |
+| **PR** | {PR_NUMBER} ({PR_URL}) or "—" |
+| **Tier** | Quick / Standard / Exhaustive |
+| **Scope** | {SCOPE or "Full app"} |
+| **Duration** | {DURATION} |
+| **Pages visited** | {COUNT} |
+| **Screenshots** | {COUNT} |
+| **Framework** | {DETECTED or "Unknown"} |
+| **Index** | [All QA runs](./index.md) |
+
+## Health Score: {SCORE}/100
+
+| Category | Score |
+|----------|-------|
+| Console | {0-100} |
+| Links | {0-100} |
+| Visual | {0-100} |
+| Functional | {0-100} |
+| UX | {0-100} |
+| Performance | {0-100} |
+| Accessibility | {0-100} |
+
+## Top 3 Things to Fix
+
+1. **{ISSUE-NNN}: {title}** — {one-line description}
+2. **{ISSUE-NNN}: {title}** — {one-line description}
+3. **{ISSUE-NNN}: {title}** — {one-line description}
+
+## Console Health
+
+| Error | Count | First seen |
+|-------|-------|------------|
+| {error message} | {N} | {URL} |
+
+## Summary
+
+| Severity | Count |
+|----------|-------|
+| Critical | 0 |
+| High | 0 |
+| Medium | 0 |
+| Low | 0 |
+| **Total** | **0** |
+
+## Issues
+
+### ISSUE-001: {Short title}
+
+| Field | Value |
+|-------|-------|
+| **Severity** | critical / high / medium / low |
+| **Category** | visual / functional / ux / content / performance / console / accessibility |
+| **URL** | {page URL} |
+
+**Description:** {What is wrong, expected vs actual.}
+
+**Repro Steps:**
+
+1. Navigate to {URL}
+   ![Step 1](screenshots/issue-001-step-1.png)
+2. {Action}
+   ![Step 2](screenshots/issue-001-step-2.png)
+3. **Observe:** {what goes wrong}
+   ![Result](screenshots/issue-001-result.png)
+
+---
+
+## Fixes Applied (if applicable)
+
+| Issue | Fix Status | Commit | Files Changed |
+|-------|-----------|--------|---------------|
+| ISSUE-NNN | verified / best-effort / reverted / deferred | {SHA} | {files} |
+
+### Before/After Evidence
+
+#### ISSUE-NNN: {title}
+**Before:** ![Before](screenshots/issue-NNN-before.png)
+**After:** ![After](screenshots/issue-NNN-after.png)
+
+---
+
+## Regression Tests
+
+| Issue | Test File | Status | Description |
+|-------|-----------|--------|-------------|
+| ISSUE-NNN | path/to/test | committed / deferred / skipped | description |
+
+### Deferred Tests
+
+#### ISSUE-NNN: {title}
+**Precondition:** {setup state that triggers the bug}
+**Action:** {what the user does}
+**Expected:** {correct behavior}
+**Why deferred:** {reason}
+
+---
+
+## Ship Readiness
+
+| Metric | Value |
+|--------|-------|
+| Health score | {before} → {after} ({delta}) |
+| Issues found | N |
+| Fixes applied | N (verified: X, best-effort: Y, reverted: Z) |
+| Deferred | N |
+
+**PR Summary:** "QA found N issues, fixed M, health score X → Y."
+
+---
+
+## Regression (if applicable)
+
+| Metric | Baseline | Current | Delta |
+|--------|----------|---------|-------|
+| Health score | {N} | {N} | {+/-N} |
+| Issues | {N} | {N} | {+/-N} |
+
+**Fixed since baseline:** {list}
+**New since baseline:** {list}

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

@@ -0,0 +1,26 @@
+# Attribution
+
+This skill is adapted from the "receiving-code-review" skill in Superpowers
+(https://github.com/obra/superpowers) by Jesse Vincent, used under the MIT License.
+
+MIT License
+
+Copyright (c) 2025 Jesse Vincent
+
+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-receiving-code-review/CHANGELOG.md

@@ -0,0 +1,28 @@
+# 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)

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

@@ -0,0 +1,226 @@
+---
+name: luckiest-coder-receiving-code-review
+description: Use when you receive code review feedback (from a human, a reviewer subagent, or a GitHub PR comment) and are about to respond or implement, especially if a suggestion seems unclear, technically questionable, or conflicts with prior decisions. Trigger phrases include "the reviewer said", "respond to this review", "should I make this change they suggested". Enforces verify-before-implement and bans performative agreement like "You're absolutely right".
+license: See ATTRIBUTION.md
+metadata:
+  version: "1.1.0"
+  listing_id: luckiest-coder-receiving-code-review
+  author: luckiest
+---
+
+# Code Review Reception
+
+## Overview
+
+Code review requires technical evaluation, not emotional performance.
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
+
+```
+WHEN receiving code review feedback:
+
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
+```
+
+## Forbidden Responses
+
+**NEVER:**
+- "You're absolutely right!" (explicit instruction-file violation)
+- "Great point!" / "Excellent feedback!" (performative)
+- "Let me implement that now" (before verification)
+
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+**Example:**
+```
+your human partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+
+❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
+✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
+```
+
+## Source-Specific Handling
+
+### From your human partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
+
+### From External Reviewers
+```
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
+
+IF suggestion seems wrong:
+  Push back with technical reasoning
+
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+
+IF conflicts with your human partner's prior decisions:
+  Stop and discuss with your human partner first
+```
+
+**your human partner's rule:** "External feedback - be skeptical, but check carefully"
+
+## YAGNI Check for "Professional" Features
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
+```
+
+**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
+
+## Implementation Order
+
+```
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
+```
+
+## When To Push Back
+
+Push back when:
+- Suggestion breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for this stack
+- Legacy/compatibility reasons exist
+- Conflicts with your human partner's architectural decisions
+
+**How to push back:**
+- Use technical reasoning, not defensiveness
+- Ask specific questions
+- Reference working tests/code
+- Involve your human partner if architectural
+
+**If you're uncomfortable pushing back out loud:** Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty.
+
+## Acknowledging Correct Feedback
+
+When feedback IS correct:
+```
+✅ "Fixed. [Brief description of what changed]"
+✅ "Good catch - [specific issue]. Fixed in [location]."
+✅ [Just fix it and show in the code]
+
+❌ "You're absolutely right!"
+❌ "Great point!"
+❌ "Thanks for catching that!"
+❌ "Thanks for [anything]"
+❌ ANY gratitude expression
+```
+
+**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
+
+**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
+
+## Gracefully Correcting Your Pushback
+
+If you pushed back and were wrong:
+```
+✅ "You were right - I checked [X] and it does [Y]. Implementing now."
+✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
+
+❌ Long apology
+❌ Defending why you pushed back
+❌ Over-explaining
+```
+
+State the correction factually and move on.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or just act |
+| Blind implementation | Verify against codebase first |
+| Batch without testing | One at a time, test each |
+| Assuming reviewer is right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+| Partial implementation | Clarify all items first |
+| Can't verify, proceed anyway | State limitation, ask for direction |
+
+## Real Examples
+
+**Performative Agreement (Bad):**
+```
+Reviewer: "Remove legacy code"
+❌ "You're absolutely right! Let me remove that..."
+```
+
+**Technical Verification (Good):**
+```
+Reviewer: "Remove legacy code"
+✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
+```
+
+**YAGNI (Good):**
+```
+Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
+✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
+```
+
+**Unclear Item (Good):**
+```
+your human partner: "Fix items 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
+```
+
+## GitHub Thread Replies
+
+When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.
+
+## The Bottom Line
+
+**External feedback = suggestions to evaluate, not orders to follow.**
+
+Verify. Question. Then implement.
+
+No performative agreement. Technical rigor always.
+
+## Staying current
+
+On activation, call the Luckiest MCP `check_updates` tool with
+`{ listingId: "luckiest-coder-receiving-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-receiving-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/ATTRIBUTION.md

@@ -0,0 +1,26 @@
+# Attribution
+
+This skill is adapted from the "requesting-code-review" skill in Superpowers
+(https://github.com/obra/superpowers) by Jesse Vincent, used under the MIT License.
+
+MIT License
+
+Copyright (c) 2025 Jesse Vincent
+
+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.