luckiest-co 1.0.0 → 1.0.3

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

@@ -0,0 +1,30 @@
+# Attribution
+
+This skill adapts the `analyze` command from GitHub's Spec Kit
+(https://github.com/github/spec-kit), used under the MIT License. Spec Kit's version
+performs cross-artifact analysis over its fixed `spec.md` / `plan.md` / `tasks.md`
+trio and `.specify` scaffolding. This adaptation drops that infrastructure and
+retargets the same consistency-detection idea at a plan ↔ code diff ↔ constitution
+comparison, as a standalone read-only gate.
+
+MIT License
+
+Copyright (c) GitHub, Inc.
+
+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-consistency/CHANGELOG.md

@@ -0,0 +1,26 @@
+# Changelog — luckiest-coder-consistency
+
+## 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
+Adapted from the `analyze` command in GitHub Spec Kit (MIT). Retargeted from Spec Kit's
+fixed spec/plan/tasks artifact trio to a plan ↔ code diff ↔ constitution comparison;
+dropped the `.specify` scaffolding and extension hooks.
+
+### Improve pass (/refract)
+- Added an explicit **scope-creep** pass (code with no mapped intent) — the original focused on requirements-without-tasks; unrequested code is the more common drift in ad-hoc dev sessions.
+- Defined graceful degradation: with no intent artifact, downgrade to a constitution-only check rather than reverse-engineering a plan from the diff to grade against.
+- Drew a hard line against verification overlap: this checks intent-match, not runtime pass/fail.
+
+### Network hook
+- N/A (internal read-only gate; emits no shareable artifact, same as luckiest-coder-verification and -constitution)
+
+### Trend pass (/newsjack + /luckiest-trends)
+- no actionable signal (internal dev-workflow skill)

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

@@ -0,0 +1,98 @@
+---
+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: "luckiest-coder-consistency", 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/ATTRIBUTION.md

@@ -0,0 +1,28 @@
+# Attribution
+
+This skill adapts the `constitution` concept and command from GitHub's Spec Kit
+(https://github.com/github/spec-kit), used under the MIT License. The spec-kit
+`.specify` infrastructure, extension hooks, and cross-template propagation were
+intentionally dropped; this is a leaner, standalone adaptation.
+
+MIT License
+
+Copyright (c) GitHub, Inc.
+
+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-constitution/CHANGELOG.md

@@ -0,0 +1,25 @@
+# Changelog — luckiest-coder-constitution
+
+## 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
+Adapted from the `constitution` command in GitHub Spec Kit (MIT). Leaner standalone
+version: dropped the `.specify` scaffolding, extension hooks, and cross-template
+propagation; kept the checked, versioned principles doc as the load-bearing primitive.
+
+### Improve pass (/refract)
+- Specified the gate's absent-file behavior: do not block, offer to create — so the Constitution Check degrades gracefully in repos without a constitution.
+- Capped principles at 3–7 and required a nameable check per principle, to keep the doc enforceable rather than aspirational.
+
+### Network hook
+- N/A (internal gate; emits no shareable artifact, same as luckiest-coder-verification)
+
+### Trend pass (/newsjack + /luckiest-trends)
+- no actionable signal (internal dev-workflow skill)

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

@@ -0,0 +1,115 @@
+---
+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: "luckiest-coder-constitution", 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/ATTRIBUTION.md

@@ -0,0 +1,26 @@
+# Attribution
+
+This skill is adapted from the "systematic-debugging" 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-debugging/CHANGELOG.md

@@ -0,0 +1,22 @@
+# 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/CREATION-LOG.md

@@ -0,0 +1,119 @@
+# Creation Log: Systematic Debugging Skill
+
+Reference example of extracting, structuring, and bulletproofing a critical skill.
+
+## Source Material
+
+Extracted debugging framework from `~/.claude/CLAUDE.md`:
+- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
+- Core mandate: ALWAYS find root cause, NEVER fix symptoms
+- Rules designed to resist time pressure and rationalization
+
+## Extraction Decisions
+
+**What to include:**
+- Complete 4-phase framework with all rules
+- Anti-shortcuts ("NEVER fix symptom", "STOP and re-analyze")
+- Pressure-resistant language ("even if faster", "even if I seem in a hurry")
+- Concrete steps for each phase
+
+**What to leave out:**
+- Project-specific context
+- Repetitive variations of same rule
+- Narrative explanations (condensed to principles)
+
+## Structure Following skill-creation/SKILL.md
+
+1. **Rich when_to_use** - Included symptoms and anti-patterns
+2. **Type: technique** - Concrete process with steps
+3. **Keywords** - "root cause", "symptom", "workaround", "debugging", "investigation"
+4. **Flowchart** - Decision point for "fix failed" → re-analyze vs add more fixes
+5. **Phase-by-phase breakdown** - Scannable checklist format
+6. **Anti-patterns section** - What NOT to do (critical for this skill)
+
+## Bulletproofing Elements
+
+Framework designed to resist rationalization under pressure:
+
+### Language Choices
+- "ALWAYS" / "NEVER" (not "should" / "try to")
+- "even if faster" / "even if I seem in a hurry"
+- "STOP and re-analyze" (explicit pause)
+- "Don't skip past" (catches the actual behavior)
+
+### Structural Defenses
+- **Phase 1 required** - Can't skip to implementation
+- **Single hypothesis rule** - Forces thinking, prevents shotgun fixes
+- **Explicit failure mode** - "IF your first fix doesn't work" with mandatory action
+- **Anti-patterns section** - Shows exactly what shortcuts look like
+
+### Redundancy
+- Root cause mandate in overview + when_to_use + Phase 1 + implementation rules
+- "NEVER fix symptom" appears 4 times in different contexts
+- Each phase has explicit "don't skip" guidance
+
+## Testing Approach
+
+Created 4 validation tests following skills/meta/testing-skills-with-subagents:
+
+### Test 1: Academic Context (No Pressure)
+- Simple bug, no time pressure
+- **Result:** Perfect compliance, complete investigation
+
+### Test 2: Time Pressure + Obvious Quick Fix
+- User "in a hurry", symptom fix looks easy
+- **Result:** Resisted shortcut, followed full process, found real root cause
+
+### Test 3: Complex System + Uncertainty
+- Multi-layer failure, unclear if can find root cause
+- **Result:** Systematic investigation, traced through all layers, found source
+
+### Test 4: Failed First Fix
+- Hypothesis doesn't work, temptation to add more fixes
+- **Result:** Stopped, re-analyzed, formed new hypothesis (no shotgun)
+
+**All tests passed.** No rationalizations found.
+
+## Iterations
+
+### Initial Version
+- Complete 4-phase framework
+- Anti-patterns section
+- Flowchart for "fix failed" decision
+
+### Enhancement 1: TDD Reference
+- Added link to skills/testing/test-driven-development
+- Note explaining TDD's "simplest code" ≠ debugging's "root cause"
+- Prevents confusion between methodologies
+
+## Final Outcome
+
+Bulletproof skill that:
+- ✅ Clearly mandates root cause investigation
+- ✅ Resists time pressure rationalization
+- ✅ Provides concrete steps for each phase
+- ✅ Shows anti-patterns explicitly
+- ✅ Tested under multiple pressure scenarios
+- ✅ Clarifies relationship to TDD
+- ✅ Ready for use
+
+## Key Insight
+
+**Most important bulletproofing:** Anti-patterns section showing exact shortcuts that feel justified in the moment. When Claude thinks "I'll just add this one quick fix", seeing that exact pattern listed as wrong creates cognitive friction.
+
+## Usage Example
+
+When encountering a bug:
+1. Load skill: skills/debugging/systematic-debugging
+2. Read overview (10 sec) - reminded of mandate
+3. Follow Phase 1 checklist - forced investigation
+4. If tempted to skip - see anti-pattern, stop
+5. Complete all phases - root cause found
+
+**Time investment:** 5-10 minutes
+**Time saved:** Hours of symptom-whack-a-mole
+
+---
+
+*Created: 2025-10-03*
+*Purpose: Reference example for skill extraction and bulletproofing*