luckiest-co 1.0.38 → 1.0.40

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

@@ -1,98 +0,0 @@
----
-name: luckiest-coder-consistency
-description: Use before finishing a branch, opening a PR, or calling a multi-step feature done — a read-only cross-check that what was built matches what was planned, with no drift, scope creep, or constitution violations. Trigger on "does this match the plan", "check for drift", "did we build what we said", "consistency check", or the moment implementation is complete and you are about to ship. Distinct from verification (does it run) — this checks does it match intent.
-license: See ATTRIBUTION.md
-metadata:
-  version: "1.1.0"
-  listing_id: luckiest-coder-consistency
-  author: luckiest
----
-
-# Consistency Check
-
-## Overview
-
-Tests answer "does it run and pass." This answers "does what we built match what we
-said we would build." They are different axes. Passing tests on the wrong feature is
-still the wrong feature.
-
-**Core principle:** Match intent to implementation before shipping, not after review.
-
-This is **read-only**. It produces a report and, if asked, a remediation list. It does
-not edit code — fixing the drift is a separate, explicit step.
-
-## When to use
-
-Run before finishing a branch, opening a PR, or declaring a multi-step feature done —
-after `luckiest-coder-verification` confirms it runs, before you ship. On a one-line
-fix it is overkill; use it when a plan existed and work spanned several steps.
-
-## Inputs
-
-Gather three things. Skip any that genuinely does not exist, and say so.
-
-1. **Intent** — the plan (from `luckiest-coder-writing-plans`), the spec, the issue, or the brainstorm agreement. What was promised.
-2. **Implementation** — the branch diff (`git diff main...HEAD`) and the resulting files.
-3. **Constitution** — `.luckiest/constitution.md` if present. Its principles are non-negotiable in this check.
-
-If no intent artifact exists at all, say so and downgrade to a constitution-only check —
-do not invent a plan retroactively to grade against.
-
-## Detection passes
-
-Build a short mental inventory of promised items (requirements, user actions, plan
-steps), then run these passes. Report high-signal findings only.
-
-- **Coverage gaps** — a promised item with no corresponding code change. The most important pass.
-- **Scope creep** — a code change that maps to no promised item. Unrequested work is drift even when it is good code; flag it for a decision, do not silently bless it.
-- **Drift** — built differently than planned (different approach, data shape, endpoint, dependency) without the deviation being noted and agreed.
-- **Constitution violations** — any diff element conflicting with a MUST principle. Automatically the top severity.
-- **Terminology drift** — the same concept named differently across plan and code, which hides coverage.
-- **Contradiction** — two parts of the implementation that disagree, or an implementation that contradicts a stated constraint.
-
-## Severity
-
-- **CRITICAL** — violates a constitution MUST, or a core promised item has zero implementation.
-- **HIGH** — significant unagreed drift, or scope creep touching security, data, or money paths.
-- **MEDIUM** — a secondary item uncovered, terminology drift, minor unagreed deviation.
-- **LOW** — wording, cosmetic redundancy, harmless extra.
-
-## Report format
-
-Output Markdown, write nothing:
-
-```
-## Consistency Report
-
-| ID | Category | Severity | Where | Finding | Recommendation |
-|----|----------|----------|-------|---------|----------------|
-| C1 | Coverage gap | CRITICAL | plan step 3 | No code for waitlist opt-in | Implement or drop from scope |
-
-**Coverage:** N of M promised items implemented (X%).
-**Scope creep:** <count> changes with no mapped intent.
-**Constitution:** PASS / <n> violations.
-```
-
-Then a **Next actions** line: if any CRITICAL/HIGH exists, resolve before shipping; if
-only LOW/MEDIUM, may ship with the noted follow-ups. Offer a remediation list only if
-the user asks — never edit in this skill.
-
-## Red flags
-
-- Editing code from inside this check → it is read-only; drift fixes are separate and explicit.
-- Blessing scope creep because "it's good code" → unrequested work is still a scope decision for the user.
-- Grading against a plan you reverse-engineered from the diff → circular; say the intent artifact is missing instead.
-- Reporting a clean pass without having read the actual diff → read it first.
-
-## The bottom line
-
-Tests prove it works. This proves it is the thing you agreed to build. Run both before
-shipping.
-
-## Staying current
-
-On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "de4ae0d9-e7fd-4b6d-900a-2b921f7f019f", 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-consistency", 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-constitution/SKILL.md

@@ -1,115 +0,0 @@
----
-name: luckiest-coder-constitution
-description: Use to create, amend, or check a project's constitution — the small set of versioned, non-negotiable principles every plan, review, and implementation must obey. Trigger on "set up a constitution", "what are our project rules", "amend the constitution", "does this violate our principles", or the start of any multi-session build where the guardrails should be fixed in writing. Also runs as the Constitution Check gate inside planning and review.
-license: See ATTRIBUTION.md
-metadata:
-  version: "1.1.0"
-  listing_id: luckiest-coder-constitution
-  author: luckiest
----
-
-# Project Constitution
-
-## Overview
-
-A constitution is a short, versioned list of non-negotiable principles for a project.
-Unlike freeform notes in CLAUDE.md, it is declarative, testable, and gated: every plan
-and code review checks against it, so the same rule is not relearned each session.
-
-**Core principle:** Principles are checked, not remembered.
-
-The file lives at `.luckiest/constitution.md`. It supersedes convention and default
-behavior; only a direct user instruction overrides it.
-
-## When to use
-
-- **Create** — first time setting durable rules for a project, or the start of a build that will span many sessions.
-- **Amend** — a rule changes, is added, or is removed.
-- **Check** — before finalizing a plan and before finishing a review (the Constitution Check gate). This is the highest-value use: it catches drift.
-
-## What a principle is
-
-Each principle is one declarative, testable rule with a one-line rationale.
-
-```
-✅ III. Service-role writes MUST NOT depend on RLS being off — every table
-   migration ships `NO FORCE ROW LEVEL SECURITY`. (Rationale: FORCE RLS has
-   broken production writes 7 times.)
-❌ "Be careful with database security." (vague, untestable)
-```
-
-Use MUST / MUST NOT / SHOULD. If you cannot name the check that would catch a
-violation, the principle is too vague — sharpen it or drop it.
-
-Good sources for a first constitution: existing CLAUDE.md hard rules, past
-regressions, and stated user preferences. Keep it to 3–7 principles. A constitution
-nobody can recite is not enforced.
-
-## Creating or amending
-
-1. Read `.luckiest/constitution.md` if it exists; otherwise start from the structure below.
-2. Gather principles from the user, CLAUDE.md, and known past failures. Confirm each with the user before writing — do not invent rules.
-3. Write declarative principles with rationale. Remove anything vague.
-4. Bump the version (semver):
-   - **MAJOR** — a principle removed or redefined incompatibly.
-   - **MINOR** — a principle added or materially expanded.
-   - **PATCH** — wording, clarification, typo.
-5. Set `Last Amended` to today. Set `Ratified` on first creation only.
-6. Append a one-line entry to the amendment log.
-7. Report the version bump and its rationale to the user.
-
-Do not silently edit principles. Amendments are explicit and logged.
-
-## The Constitution Check gate
-
-When invoked as a gate (from planning, review, or on demand):
-
-1. Read `.luckiest/constitution.md`. If absent, say so and continue — do not block; offer to create one.
-2. For each principle, check the plan or diff against it.
-3. Report violations as `VIOLATION: <principle> — <where> — <fix>`. Report a clean pass explicitly.
-4. A violation blocks completion until fixed or the user explicitly waives it (waivers are noted, not assumed).
-
-## File structure
-
-```markdown
-# <Project> Constitution
-
-## Principles
-
-### I. <Name>
-<declarative MUST/SHOULD rule>. (Rationale: <why>.)
-
-### II. <Name>
-...
-
-## Governance
-
-This constitution supersedes convention and default behavior. Only a direct user
-instruction overrides it. Amendments are explicit, versioned, and logged below.
-
-**Version**: X.Y.Z | **Ratified**: YYYY-MM-DD | **Last Amended**: YYYY-MM-DD
-
-## Amendment log
-- YYYY-MM-DD vX.Y.Z — <what changed>
-```
-
-## Red flags
-
-- Writing a principle you cannot describe a check for → too vague.
-- More than ~7 principles → nobody enforces a wall of rules; keep the vital few.
-- Editing a principle without a version bump or log entry → silent drift.
-- Treating the constitution as advisory → it is a gate, not a suggestion.
-- Inventing rules the user never confirmed → confirm first.
-
-## The bottom line
-
-Fix the guardrails in writing once, then check every plan and diff against them.
-The constitution is only worth having if it is actually checked.
-
-## Staying current
-
-On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "6b0d7046-d85f-43b6-be52-d008fa229b99", 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-constitution", 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-debugging/CHANGELOG.md

@@ -1,22 +0,0 @@
-# Changelog — luckiest-coder-debugging
-
-## 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 systematic-debugging (Superpowers, MIT).
-
-### Improve pass (/refract)
-- no changes beyond rebrand (four-phase process kept intact; cross-references remapped to luckiest-coder-tdd and luckiest-coder-verification)
-
-### Network hook
-- N/A (debugging emits no shareable artifact)
-
-### Trend pass (/newsjack + /luckiest-trends)
-- no actionable signal (internal dev-workflow skill)

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

@@ -1,309 +0,0 @@
----
-name: luckiest-coder-debugging
-description: Use when hunting the root cause of any bug, test failure, crash, or unexpected behavior — before proposing or attempting a fix. Trigger phrases include "debug this", "why is this failing", "find the root cause", "this test is flaky", "the build broke", "it works sometimes", or "/luckiest-coder-debugging". Enforces a four-phase root-cause-first process (investigate, pattern-match, hypothesize, implement) and blocks symptom fixes.
-license: See ATTRIBUTION.md
-metadata:
-  version: "1.1.0"
-  listing_id: luckiest-coder-debugging
-  author: luckiest
----
-
-# Systematic Debugging
-
-## Overview
-
-Random fixes waste time and create new bugs. Quick patches mask underlying issues.
-
-**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
-
-**Violating the letter of this process is violating the spirit of debugging.**
-
-## The Iron Law
-
-```
-NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
-```
-
-If you haven't completed Phase 1, you cannot propose fixes.
-
-## When to Use
-
-Use for ANY technical issue:
-- Test failures
-- Bugs in production
-- Unexpected behavior
-- Performance problems
-- Build failures
-- Integration issues
-
-**Use this ESPECIALLY when:**
-- Under time pressure (emergencies make guessing tempting)
-- "Just one quick fix" seems obvious
-- You've already tried multiple fixes
-- Previous fix didn't work
-- You don't fully understand the issue
-
-**Don't skip when:**
-- Issue seems simple (simple bugs have root causes too)
-- You're in a hurry (rushing guarantees rework)
-- Manager wants it fixed NOW (systematic is faster than thrashing)
-
-## The Four Phases
-
-You MUST complete each phase before proceeding to the next.
-
-### Phase 1: Root Cause Investigation
-
-**BEFORE attempting ANY fix:**
-
-1. **Read Error Messages Carefully**
-   - Don't skip past errors or warnings
-   - They often contain the exact solution
-   - Read stack traces completely
-   - Note line numbers, file paths, error codes
-
-2. **Reproduce Consistently**
-   - Can you trigger it reliably?
-   - What are the exact steps?
-   - Does it happen every time?
-   - If not reproducible → gather more data, don't guess
-
-3. **Check Recent Changes**
-   - What changed that could cause this?
-   - Git diff, recent commits
-   - New dependencies, config changes
-   - Environmental differences
-
-4. **Gather Evidence in Multi-Component Systems**
-
-   **WHEN system has multiple components (CI → build → signing, API → service → database):**
-
-   **BEFORE proposing fixes, add diagnostic instrumentation:**
-   ```
-   For EACH component boundary:
-     - Log what data enters component
-     - Log what data exits component
-     - Verify environment/config propagation
-     - Check state at each layer
-
-   Run once to gather evidence showing WHERE it breaks
-   THEN analyze evidence to identify failing component
-   THEN investigate that specific component
-   ```
-
-   **Example (multi-layer system):**
-   ```bash
-   # Layer 1: Workflow
-   echo "=== Secrets available in workflow: ==="
-   echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
-
-   # Layer 2: Build script
-   echo "=== Env vars in build script: ==="
-   env | grep IDENTITY || echo "IDENTITY not in environment"
-
-   # Layer 3: Signing script
-   echo "=== Keychain state: ==="
-   security list-keychains
-   security find-identity -v
-
-   # Layer 4: Actual signing
-   codesign --sign "$IDENTITY" --verbose=4 "$APP"
-   ```
-
-   **This reveals:** Which layer fails (secrets → workflow ✓, workflow → build ✗)
-
-5. **Trace Data Flow**
-
-   **WHEN error is deep in call stack:**
-
-   See `root-cause-tracing.md` in this directory for the complete backward tracing technique.
-
-   **Quick version:**
-   - Where does bad value originate?
-   - What called this with bad value?
-   - Keep tracing up until you find the source
-   - Fix at source, not at symptom
-
-### Phase 2: Pattern Analysis
-
-**Find the pattern before fixing:**
-
-1. **Find Working Examples**
-   - Locate similar working code in same codebase
-   - What works that's similar to what's broken?
-
-2. **Compare Against References**
-   - If implementing pattern, read reference implementation COMPLETELY
-   - Don't skim - read every line
-   - Understand the pattern fully before applying
-
-3. **Identify Differences**
-   - What's different between working and broken?
-   - List every difference, however small
-   - Don't assume "that can't matter"
-
-4. **Understand Dependencies**
-   - What other components does this need?
-   - What settings, config, environment?
-   - What assumptions does it make?
-
-### Phase 3: Hypothesis and Testing
-
-**Scientific method:**
-
-1. **Form Single Hypothesis**
-   - State clearly: "I think X is the root cause because Y"
-   - Write it down
-   - Be specific, not vague
-
-2. **Test Minimally**
-   - Make the SMALLEST possible change to test hypothesis
-   - One variable at a time
-   - Don't fix multiple things at once
-
-3. **Verify Before Continuing**
-   - Did it work? Yes → Phase 4
-   - Didn't work? Form NEW hypothesis
-   - DON'T add more fixes on top
-
-4. **When You Don't Know**
-   - Say "I don't understand X"
-   - Don't pretend to know
-   - Ask for help
-   - Research more
-
-### Phase 4: Implementation
-
-**Fix the root cause, not the symptom:**
-
-1. **Create Failing Test Case**
-   - Simplest possible reproduction
-   - Automated test if possible
-   - One-off test script if no framework
-   - MUST have before fixing
-   - Use the `luckiest-coder-tdd` skill for writing proper failing tests
-
-2. **Implement Single Fix**
-   - Address the root cause identified
-   - ONE change at a time
-   - No "while I'm here" improvements
-   - No bundled refactoring
-
-3. **Verify Fix**
-   - Test passes now?
-   - No other tests broken?
-   - Issue actually resolved?
-
-4. **If Fix Doesn't Work**
-   - STOP
-   - Count: How many fixes have you tried?
-   - If < 3: Return to Phase 1, re-analyze with new information
-   - **If ≥ 3: STOP and question the architecture (step 5 below)**
-   - DON'T attempt Fix #4 without architectural discussion
-
-5. **If 3+ Fixes Failed: Question Architecture**
-
-   **Pattern indicating architectural problem:**
-   - Each fix reveals new shared state/coupling/problem in different place
-   - Fixes require "massive refactoring" to implement
-   - Each fix creates new symptoms elsewhere
-
-   **STOP and question fundamentals:**
-   - Is this pattern fundamentally sound?
-   - Are we "sticking with it through sheer inertia"?
-   - Should we refactor architecture vs. continue fixing symptoms?
-
-   **Discuss with your human partner before attempting more fixes**
-
-   This is NOT a failed hypothesis - this is a wrong architecture.
-
-## Red Flags - STOP and Follow Process
-
-If you catch yourself thinking:
-- "Quick fix for now, investigate later"
-- "Just try changing X and see if it works"
-- "Add multiple changes, run tests"
-- "Skip the test, I'll manually verify"
-- "It's probably X, let me fix that"
-- "I don't fully understand but this might work"
-- "Pattern says X but I'll adapt it differently"
-- "Here are the main problems: [lists fixes without investigation]"
-- Proposing solutions before tracing data flow
-- **"One more fix attempt" (when already tried 2+)**
-- **Each fix reveals new problem in different place**
-
-**ALL of these mean: STOP. Return to Phase 1.**
-
-**If 3+ fixes failed:** Question the architecture (see Phase 4.5)
-
-## your human partner's Signals You're Doing It Wrong
-
-**Watch for these redirections:**
-- "Is that not happening?" - You assumed without verifying
-- "Will it show us...?" - You should have added evidence gathering
-- "Stop guessing" - You're proposing fixes without understanding
-- "Ultra-think this" - Question fundamentals, not just symptoms
-- "We're stuck?" (frustrated) - Your approach isn't working
-
-**When you see these:** STOP. Return to Phase 1.
-
-## Common Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. |
-| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. |
-| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. |
-| "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. |
-| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. |
-| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. |
-| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
-| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. |
-
-## Quick Reference
-
-| Phase | Key Activities | Success Criteria |
-|-------|---------------|------------------|
-| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
-| **2. Pattern** | Find working examples, compare | Identify differences |
-| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
-| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass |
-
-## When Process Reveals "No Root Cause"
-
-If systematic investigation reveals issue is truly environmental, timing-dependent, or external:
-
-1. You've completed the process
-2. Document what you investigated
-3. Implement appropriate handling (retry, timeout, error message)
-4. Add monitoring/logging for future investigation
-
-**But:** 95% of "no root cause" cases are incomplete investigation.
-
-## Supporting Techniques
-
-These techniques are part of systematic debugging and available in this directory:
-
-- **`root-cause-tracing.md`** - Trace bugs backward through call stack to find original trigger
-- **`defense-in-depth.md`** - Add validation at multiple layers after finding root cause
-- **`condition-based-waiting.md`** - Replace arbitrary timeouts with condition polling
-
-**Related skills:**
-- **luckiest-coder-tdd** - For creating failing test case (Phase 4, Step 1)
-- **luckiest-coder-verification** - Verify fix worked before claiming success
-
-## Real-World Impact
-
-From debugging sessions:
-- Systematic approach: 15-30 minutes to fix
-- Random fixes approach: 2-3 hours of thrashing
-- First-time fix rate: 95% vs 40%
-- New bugs introduced: Near zero vs common
-
-## Staying current
-
-On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "5b9728f7-04b0-4be9-9962-3453d4a11d9a", 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-debugging", 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.