luckiest-co 1.0.38 → 1.0.40

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

@@ -1,226 +0,0 @@
----
-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: "3ebf2650-feb3-4682-b6de-d47a0558bbf8", 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/SKILL.md

@@ -1,118 +0,0 @@
----
-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: "010a144f-99ed-4b6e-a43e-9ab51574c45b", 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-shipping/CHANGELOG.md

@@ -1,48 +0,0 @@
-# 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/SKILL.md

@@ -1,148 +0,0 @@
----
-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: "29b23fab-2386-4547-a8f3-b60583dda01d", 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-subagent-driven-development/CHANGELOG.md

@@ -1,28 +0,0 @@
-# Changelog — luckiest-coder-subagent-driven-development
-
-## 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 subagent-driven-development (Superpowers, MIT).
-Cross-references remapped via the name map (requesting-code-review,
-git-worktrees, writing-plans, executing-plans, tdd, finishing-a-branch).
-Script `.superpowers/sdd/` workspace path fragments replaced with
-`.luckiest-coder/sdd/` in sdd-workspace, review-package, task-brief, and SKILL.md.
-
-### Improve pass (/refract)
-- no changes beyond rebrand — the controller process, review-loop discipline,
-  and file-handoff mechanics are the load-bearing content and were kept intact.
-
-### Network hook
-- share-with-tribe: the final whole-branch review produces a shareable review
-  package; added one optional OFFER line to share it with the tribe.
-
-### Trend pass (/newsjack + /luckiest-trends)
-- no actionable signal (internal dev-workflow skill)