@kennethsolomon/shipkit 3.0.4 → 3.0.7

package/README.md

@@ -84,7 +84,7 @@ Brainstorm → Plan → Branch → [Schema] → Write Tests → Implement → Co
 | 1 | read `tasks/todo.md` | Pick the next task |
 | 2 | read `tasks/lessons.md` | Review past corrections |
 | 3 | `/sk:brainstorm` | Clarify requirements — no code |
-| 4 | `/sk:frontend-design` | UI design spec *(skip if backend-only)* |
+| 4 | `/sk:frontend-design` | UI design spec *(skip if backend-only)*. Add `--pencil` to also generate a Pencil visual mockup |
 | 5 | `/sk:api-design` | API contracts *(skip if no new endpoints)* |
 | 6 | `/sk:accessibility` | WCAG 2.1 AA audit on design *(skip if no frontend)* |
 | 7 | `/sk:write-plan` | Write plan to `tasks/todo.md` |
@@ -170,7 +170,7 @@ Requirement changes → /sk:change → re-enter at correct step
 | Command | Description |
 |---------|-------------|
 | `/sk:brainstorm` | Explore requirements and design before writing any code |
-| `/sk:frontend-design` | Create UI design specs and mockups |
+| `/sk:frontend-design` | Create UI design specs and mockups. After the design summary, it asks if you want a Pencil visual mockup. Use `--pencil` flag to jump directly to the Pencil phase *(requires Pencil app + MCP)* |
 | `/sk:api-design` | Design REST or GraphQL API contracts |
 | `/sk:accessibility` | WCAG 2.1 AA audit on design or existing frontend |
 | `/sk:write-plan` | Write a decision-complete plan to `tasks/todo.md` |

package/commands/sk/config

@@ -0,0 +1,92 @@
+#!/usr/bin/env python3
+"""Manage ShipKit project configuration."""
+
+import json
+import os
+import sys
+from pathlib import Path
+
+def get_defaults():
+    return {
+        "profile": "balanced",
+        "auto_commit": True,
+        "skip_gates": [],
+        "coverage_threshold": 100,
+        "branch_pattern": "feature/{slug}",
+        "model_overrides": {}
+    }
+
+def get_config():
+    """Read current config or return defaults."""
+    config_file = Path(".shipkit/config.json")
+    if config_file.exists():
+        try:
+            with open(config_file) as f:
+                return json.load(f)
+        except json.JSONDecodeError:
+            return get_defaults()
+    return get_defaults()
+
+def get_models_for_profile(profile):
+    """Get model assignments for a profile."""
+    models = {
+        "full-sail": {"planning": "opus", "implementation": "opus", "audits": "opus", "gates": "sonnet"},
+        "quality": {"planning": "opus", "implementation": "sonnet", "audits": "sonnet", "gates": "sonnet"},
+        "balanced": {"planning": "sonnet", "implementation": "sonnet", "audits": "sonnet", "gates": "haiku"},
+        "budget": {"planning": "sonnet", "implementation": "sonnet", "audits": "haiku", "gates": "haiku"}
+    }
+    return models.get(profile, models["balanced"])
+
+def display_config(config):
+    """Display current configuration in a table."""
+    print("\n## Current Configuration\n")
+    print("| Setting | Value | Description |")
+    print("|---------|-------|-------------|")
+    print(f"| `profile` | `{config['profile']}` | Model routing profile (full-sail / quality / balanced / budget) |")
+    print(f"| `auto_commit` | `{str(config['auto_commit']).lower()}` | Auto-run `/sk:smart-commit` after each gate passes |")
+    skip_gates_str = ", ".join(config['skip_gates']) if config['skip_gates'] else "(none)"
+    print(f"| `skip_gates` | `{skip_gates_str}` | Gates to skip |")
+    print(f"| `coverage_threshold` | `{config['coverage_threshold']}%` | Minimum test coverage on new code |")
+    print(f"| `branch_pattern` | `{config['branch_pattern']}` | Branch naming pattern |")
+    print(f"| `model_overrides` | `{json.dumps(config['model_overrides'])}` | Per-skill model overrides |")
+
+    profile = config['profile']
+    models = get_models_for_profile(profile)
+    print(f"\n## Model Assignments — `{profile}` profile\n")
+    print("| Skill group | Model |")
+    print("|-------------|-------|")
+    print(f"| brainstorm, write-plan, debug, execute-plan, review | `{models['planning']}` |")
+    print(f"| write-tests, frontend-design, api-design, security-check | `{models['implementation']}` |")
+    print(f"| perf, schema-migrate, accessibility | `{models['audits']}` |")
+    print(f"| lint, test | `{models['gates']}` |")
+    print(f"| smart-commit, branch, update-task | `haiku` |")
+
+def save_config(config):
+    """Save config to .shipkit/config.json."""
+    Path(".shipkit").mkdir(exist_ok=True)
+    config_file = Path(".shipkit/config.json")
+
+    with open(config_file, "w") as f:
+        json.dump(config, f, indent=2)
+
+    # Add to .gitignore
+    gitignore = Path(".gitignore")
+    if gitignore.exists():
+        content = gitignore.read_text()
+        if ".shipkit/config.json" not in content:
+            with open(gitignore, "a") as f:
+                f.write("\n.shipkit/config.json\n")
+    else:
+        gitignore.write_text(".shipkit/config.json\n")
+
+    print(f"\n✅ Config saved to `.shipkit/config.json`")
+
+def main():
+    config = get_config()
+    display_config(config)
+
+    print("\n---\n")
+    print("To change a setting, run: `/sk:set-profile <profile>` or edit `.shipkit/config.json` directly")
+
+if __name__ == "__main__":
+    main()

package/commands/sk/finish-feature.md

@@ -1,7 +1,10 @@
-<!-- Generated by /sk:setup-claude -->
-<!-- Template Hash: 7deba6efd53c -->
+---
+description: "Finalize a feature/bug-fix: changelog, arch log, verification, and PR creation."
+---
 
-# Finish Feature Command
+# /sk:finish-feature
+
+Finalize a feature/bug-fix branch and create a pull request.
 
 Finalize a feature/bug-fix branch: changelog, arch log, security gate, verification, and PR creation.
 
@@ -80,22 +83,24 @@ If unresolved Critical/High findings remain, warn the user before proceeding.
 
    Tests should have been created during `/sk:execute-plan`. Verify:
 
+   Detect the project stack from `CLAUDE.md`, `package.json`, `composer.json`, etc. before running checks.
+
    a) **Automated Tests**
-      - Execute: `npm test`
+      - Execute the detected test runner (e.g. `npm test`, `./vendor/bin/pest`, `python -m pytest`)
       - Verify all tests pass with no failures
-      - Check test coverage (target: >80% for new code in `Unknown` projects)
+      - Check test coverage (target: >80% for new code)
       - No skipped tests (`test.skip`, `it.skip`, `@skip`, etc.)
-      - Run other CI checks: lint (`npm run lint` or equivalent), build (`npm run build` or equivalent)
+      - Run other CI checks: lint and build using project-detected commands
 
-   b) **Manual Testing - Unknown / Unknown**
-      - For frontend (Unknown): Render the component/page in browser, verify state updates work correctly, test all user interactions (clicks, form inputs, navigation), verify conditional rendering, check edge cases and error states
-      - For backend/API (Unknown): Test HTTP status codes and responses, verify request/response bodies match spec, test error cases and input validation, check database transactions/state, verify authentication/authorization if applicable
-      - For CLI/desktop (Unknown): Test command-line arguments and flags, verify output format and readability, test error messages and help text, check file I/O operations
-      - Using Unknown framework: Verify test structure matches project conventions, assertions are clear and specific, setup/teardown is properly handled
+   b) **Manual Testing**
+      - For frontend (if detected): Render the component/page in browser, verify state updates work correctly, test all user interactions (clicks, form inputs, navigation), verify conditional rendering, check edge cases and error states
+      - For backend/API (if detected): Test HTTP status codes and responses, verify request/response bodies match spec, test error cases and input validation, check database transactions/state, verify authentication/authorization if applicable
+      - For CLI/desktop (if detected): Test command-line arguments and flags, verify output format and readability, test error messages and help text, check file I/O operations
+      - Verify test structure matches project conventions, assertions are clear and specific, setup/teardown is properly handled
 
    c) **Regression Testing**
       - Test related existing functionality to ensure no breakage
-      - For Unknown projects: check related components/endpoints/commands work correctly
+      - Check related components/endpoints/commands work correctly
       - Verify no new console errors, warnings, or debug statements
       - Confirm existing tests still pass
 
@@ -104,7 +109,7 @@ If unresolved Critical/High findings remain, warn the user before proceeding.
       - Proper error handling and validation
       - No debugging code (`console.log`, `debugger`, `pdb`, `print` statements, etc.)
       - Comments explain *why*, not *what*
-      - Follows Unknown conventions and style guide (see `CLAUDE.md`)
+      - Follows project conventions and style guide (see `CLAUDE.md`)
 
 6. **Security Gate**
    - If `/sk:security-check` has not been run on this branch, recommend: "Run `/sk:security-check` before creating a PR."

package/commands/sk/help.md

@@ -2,6 +2,16 @@
 description: "Show all ShipKit commands and workflow overview."
 ---
 
+# Meta
+
+| Command | Description |
+|---------|-------------|
+| `/sk:help` | Show all commands and workflow overview |
+| `/sk:status` | Show workflow and task status at a glance |
+| `/sk:skill-creator` | Create or improve ShipKit skills |
+
+---
+
 # /sk:help — ShipKit
 
 A structured workflow toolkit for Claude Code.
@@ -19,7 +29,6 @@ Run these commands in order for a complete, quality-gated feature build.
 | `/sk:schema-migrate` | Analyze schema changes *(skip if no DB changes)* |
 | `/sk:write-tests` | TDD red: write failing tests first |
 | `/sk:execute-plan` | TDD green: implement until tests pass |
-| `/sk:change` | Requirements changed? Re-enter at the right step |
 | `/sk:smart-commit` | Conventional commit with approval |
 | `/sk:lint` | **GATE** — all linters must pass |
 | `/sk:test` | **GATE** — 100% coverage on new code |
@@ -63,14 +72,14 @@ Requirements change mid-workflow? Run `/sk:change` — it classifies the scope a
 | `/sk:execute-plan` | Implement plan in batches |
 | `/sk:features` | Sync docs/sk:features/ specs with codebase |
 | `/sk:finish-feature` | Changelog + PR creation |
-| `/sk:frontend-design` | UI mockup + design spec before implementation |
+| `/sk:frontend-design` | UI mockup + design spec before implementation. Add `--pencil` to also generate a Pencil visual mockup (requires Pencil app + MCP) |
 | `/sk:hotfix` | Emergency fix workflow (skips design/TDD) |
 | `/sk:laravel-init` | Configure existing Laravel project |
 | `/sk:laravel-new` | Scaffold new Laravel project |
 | `/sk:lint` | Auto-detect and run all linters |
 | `/sk:perf` | Performance audit |
 | `/sk:plan` | Create/refresh task planning files |
-| `/sk:release` | Version bump + changelog + tag |
+| `/sk:release` | Automate releases: bump version, update CHANGELOG, create tag, push to GitHub. Use --android and/or --ios flags for App Store / Play Store readiness audit |
 | `/sk:review` | Self-review of branch changes |
 | `/sk:schema-migrate` | Multi-ORM schema change analysis |
 | `/sk:security-check` | OWASP security audit |
@@ -113,4 +122,4 @@ Config lives in `.shipkit/config.json` — per project, gitignored by default.
 
 ---
 
-**ShipKit** by Kenneth Solomon · `npm install -g @kennethsolomon/shipkit` to install/update
+**ShipKit** by Kenneth Solomon · `npx @kennethsolomon/shipkit` to install/update

package/commands/sk/security-check.md

@@ -53,36 +53,38 @@ Read each file in scope before auditing.
 - **A09 Logging Failures** — Missing audit logs, PII in logs, no alerting on security events
 - **A10 SSRF** — Unvalidated URLs, internal network access, DNS rebinding
 
-### 2. Stack-Specific Checks (Unknown / Unknown)
+### 2. Stack-Specific Checks
 
-**If Unknown includes React/Next.js:**
+Detect the project stack from `CLAUDE.md`, `package.json`, `composer.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, etc. Apply the relevant checks below for every detected framework/language.
+
+**If the project uses React/Next.js:**
 - `dangerouslySetInnerHTML` usage without sanitization
 - Client-side secrets (API keys in browser bundles)
 - Missing CSP headers
 - Server component data leaking to client
 - `getServerSideProps`/Server Actions exposing internal data
 
-**If Unknown includes Express/Node.js:**
+**If the project uses Express/Node.js:**
 - Missing helmet/security headers
 - Unsanitized user input in `req.params`, `req.query`, `req.body`
 - Path traversal via `req.params` in file operations
 - Missing rate limiting on auth endpoints
 - Prototype pollution
 
-**If Unknown is Python:**
+**If the project uses Python:**
 - `eval()`, `exec()`, `pickle.loads()` with untrusted input
 - SQL string formatting instead of parameterized queries
 - `subprocess.shell=True` with user input
 - Missing input validation on FastAPI/Django endpoints
 - Jinja2 `| safe` filter misuse
 
-**If Unknown is Go:**
+**If the project uses Go:**
 - Unchecked error returns on security-critical operations
 - `html/template` vs `text/template` confusion
 - Missing context cancellation/timeouts
 - Race conditions on shared state
 
-**If Unknown is PHP:**
+**If the project uses PHP/Laravel:**
 - `include`/`require` with user-controlled paths
 - `mysqli_query` without prepared statements
 - Missing CSRF tokens
@@ -112,7 +114,7 @@ Write findings to `tasks/security-findings.md` using this format:
 # Security Audit — YYYY-MM-DD
 
 **Scope:** Changed files on branch `<branch-name>` | Full project scan
-**Stack:** Unknown / Unknown
+**Stack:** `<detected stack — e.g. Laravel / React>`
 **Files audited:** N
 
 ## Critical (must fix before deploy)

package/commands/sk/set-profile

@@ -0,0 +1,113 @@
+#!/usr/bin/env python3
+"""Switch ShipKit model routing profile."""
+
+import json
+import sys
+from pathlib import Path
+
+VALID_PROFILES = ["full-sail", "quality", "balanced", "budget"]
+
+def get_defaults():
+    return {
+        "profile": "balanced",
+        "auto_commit": True,
+        "skip_gates": [],
+        "coverage_threshold": 100,
+        "branch_pattern": "feature/{slug}",
+        "model_overrides": {}
+    }
+
+def get_config():
+    """Read current config or return defaults."""
+    config_file = Path(".shipkit/config.json")
+    if config_file.exists():
+        try:
+            with open(config_file) as f:
+                return json.load(f)
+        except json.JSONDecodeError:
+            return get_defaults()
+    return get_defaults()
+
+def get_models_for_profile(profile):
+    """Get model assignments for a profile."""
+    models = {
+        "full-sail": {"planning": "opus", "implementation": "opus", "audits": "opus", "gates": "sonnet"},
+        "quality": {"planning": "opus", "implementation": "sonnet", "audits": "sonnet", "gates": "sonnet"},
+        "balanced": {"planning": "sonnet", "implementation": "sonnet", "audits": "sonnet", "gates": "haiku"},
+        "budget": {"planning": "sonnet", "implementation": "sonnet", "audits": "haiku", "gates": "haiku"}
+    }
+    return models.get(profile, models["balanced"])
+
+def get_profile_description(profile):
+    """Get profile philosophy and use case."""
+    descriptions = {
+        "full-sail": ("Opus on everything that matters", "High-stakes work, client projects, production features"),
+        "quality": ("Opus for planning + review, Sonnet for implementation", "Most professional projects"),
+        "balanced": ("Sonnet across the board", "Day-to-day development (default)"),
+        "budget": ("Haiku where possible, Sonnet for gates", "Side projects, exploration, prototyping")
+    }
+    return descriptions.get(profile, ("", ""))
+
+def save_config(config):
+    """Save config to .shipkit/config.json."""
+    Path(".shipkit").mkdir(exist_ok=True)
+    config_file = Path(".shipkit/config.json")
+
+    with open(config_file, "w") as f:
+        json.dump(config, f, indent=2)
+
+    # Add to .gitignore
+    gitignore = Path(".gitignore")
+    if gitignore.exists():
+        content = gitignore.read_text()
+        if ".shipkit/config.json" not in content:
+            with open(gitignore, "a") as f:
+                f.write("\n.shipkit/config.json\n")
+    else:
+        gitignore.write_text(".shipkit/config.json\n")
+
+def main():
+    # Get profile argument
+    profile = None
+    if len(sys.argv) > 1:
+        profile = sys.argv[1].lower()
+
+    # Validate profile
+    if profile and profile not in VALID_PROFILES:
+        print(f"❌ Invalid profile: `{profile}`")
+        print(f"\nValid profiles: {' · '.join(VALID_PROFILES)}")
+        sys.exit(1)
+
+    # If no profile provided, show options
+    if not profile:
+        print("## Available Profiles\n")
+        print("| Profile | Philosophy | Best for |")
+        print("|---------|-----------|---------|")
+        for p in VALID_PROFILES:
+            philosophy, use_case = get_profile_description(p)
+            default = " *(default)*" if p == "balanced" else ""
+            print(f"| `{p}` | {philosophy}{default} | {use_case} |")
+        print("\nUsage: `/sk:set-profile <profile>`")
+        sys.exit(0)
+
+    # Read current config
+    config = get_config()
+    old_profile = config['profile']
+
+    # Update profile
+    config['profile'] = profile
+    save_config(config)
+
+    # Confirm and display new assignments
+    models = get_models_for_profile(profile)
+    print(f"\n✅ Profile set to: `{profile}` (was `{old_profile}`)\n")
+    print("## Model assignments for this project:\n")
+    print(f"  brainstorm, write-plan, debug, execute-plan, review → `{models['planning']}`")
+    print(f"  write-tests, frontend-design, api-design, security-check → `{models['implementation']}`")
+    print(f"  perf, schema-migrate, accessibility → `{models['audits']}`")
+    print(f"  lint, test → `{models['gates']}`")
+    print(f"  smart-commit, branch, update-task → `haiku`\n")
+    print("Run `/sk:config` to see all settings or make further changes.")
+
+if __name__ == "__main__":
+    main()

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kennethsolomon/shipkit",
-  "version": "3.0.4",
+  "version": "3.0.7",
   "description": "A structured workflow toolkit for Claude Code.",
   "keywords": [
     "claude",

package/skills/sk:frontend-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sk:frontend-design
-description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Produces design direction, mockups, and visual specifications — NOT code.
+description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Produces design direction, mockups, and visual specifications — NOT code. Use --pencil flag to also generate a Pencil visual mockup (requires Pencil app + MCP).
 license: Complete terms in LICENSE.txt
 ---
 
@@ -95,15 +95,21 @@ End every `/sk:frontend-design` session with a structured summary:
 [Specific Tailwind classes, CSS patterns, or gotchas for /sk:execute-plan]
 ```
 
-After presenting the design summary, ask the user:
+After presenting the design summary, you **MUST** stop and ask — do not continue or summarize further:
 
-**"Would you like me to create a Pencil visual mockup? (y/n)"**
+> **"Would you like me to create a Pencil visual mockup? (Requires Pencil app open + Pencil MCP connected) (y/n)"**
+
+Wait for the user's response before doing anything else.
+
+You can also trigger the Pencil phase directly by running `/sk:frontend-design --pencil`.
 
 ---
 
 ## Pencil Visual Mockup Phase
 
-Only run this phase if the user answers **y** or **yes**.
+Only run this phase if:
+- The user answers **y** or **yes** to the prompt above, OR
+- The user invoked the skill with `--pencil`
 
 ### Step 1 — Find or create the .pen file
 

package/skills/sk:setup-claude/SKILL.md

@@ -36,7 +36,6 @@ After bootstrapping a project, the recommended workflow becomes:
 - `plan.md` — creates/refreshes planning files and starts planning
 - `status.md` — prints a compact progress summary
 - `finish-feature.md` — branch finalization checklist (stack-aware)
-- `features.md` — sync `docs/sk:features/` specs with current codebase; creates the spec system from scratch if it doesn't exist
 - `security-check.md` — audit changed files (or full project with `--all`) for security best practices, OWASP Top 10, and production-grade quality
 
 ### Project Docs (in `.claude/docs/`)

package/skills/sk:setup-claude/templates/CLAUDE.md.template

@@ -70,7 +70,7 @@ Progress is tracked in `tasks/workflow-status.md`. This file persists across con
 1.  **Read** `tasks/todo.md` — pick the next incomplete task
 2.  **Read** `tasks/lessons.md` — review past corrections before writing code
 3.  **Explore** — run `/brainstorm` to clarify requirements, constraints, and approach. No code in this step.
-4.  **Design** — run `/frontend-design` for UI mockup or `/api-design` for API contracts. No code — design only. Skip if pure backend with no UI and no new API. After `/frontend-design`, the skill prompts to create a Pencil visual mockup (saved to `docs/design/`). Requires Pencil app open and Pencil MCP connected.
+4.  **Design** — run `/frontend-design` for UI mockup or `/api-design` for API contracts. No code — design only. Skip if pure backend with no UI and no new API. After the design summary, the skill asks if you want a Pencil visual mockup — answer `y` only if you have the Pencil app open and Pencil MCP connected. Use `/frontend-design --pencil` to jump directly to the Pencil phase.
 5.  **Accessibility** — run `/accessibility` to audit the design spec for WCAG 2.1 AA compliance. Produces `tasks/accessibility-findings.md`. Skip if backend-only with no frontend.
 6.  **Plan** — run `/write-plan` to write a decision-complete plan into `tasks/todo.md` using brainstorm + design outputs. No code in this step.
 7.  **Branch** — run `/branch` to create a feature branch auto-named from the current task.

package/skills/sk:test/SKILL.md

@@ -72,7 +72,7 @@ npm install -D vitest @testing-library/react @testing-library/jest-dom @testing-
 
 Create `vitest.config.ts`:
 ```ts
-import { defineConfig } from 'vitest/sk:config';
+import { defineConfig } from 'vitest/config';
 import react from '@vitejs/plugin-react';
 
 export default defineConfig({

package/commands/sk/features.md

@@ -1,238 +0,0 @@
----
-name: features
-description: "Sync docs/sk:features/ specs with the current codebase. Auto-detects changed areas and updates only affected specs. Creates the spec system from scratch if it doesn't exist."
----
-
-<!-- Generated by /sk:setup-claude -->
-
-# /sk:features
-
-Keep feature specifications in `docs/sk:features/` in sync with the actual codebase.
-Works with **any project** — framework-agnostic, auto-discovers source structure.
-
-## What This Does
-
-Maintains `docs/sk:features/` as a platform-agnostic feature specification system —
-the single source of truth shared between web, mobile, and any other platform
-that uses the same backend. Each spec covers: DB schema, business logic, API
-contract, permissions, edge cases, error states, web/mobile UI behavior, and
-platform divergences.
-
----
-
-## Steps
-
-### Step 1: Detect Project State
-
-Check what exists:
-
-```bash
-ls docs/sk:features/ 2>/dev/null && echo "EXISTS" || echo "MISSING"
-ls docs/FEATURES.md 2>/dev/null && echo "INDEX_EXISTS" || echo "INDEX_MISSING"
-```
-
-**If `docs/sk:features/` does not exist:**
-Ask the user: "No feature specification system found. Create one from scratch?"
-- Yes → jump to **[Create From Scratch](#create-from-scratch)** below
-- No → stop
-
-**If `docs/sk:features/` exists:**
-Continue to Step 2.
-
----
-
-### Step 2: Determine Update Scope
-
-Present three options:
-
-> **What would you like to update?**
-> **A. Auto-detect** *(recommended)* — scan recent git changes, update only affected specs
-> **B. Select features** — pick which specs to update from the list
-> **C. Refresh all** — update every spec from current source code
-
-Wait for the user's choice.
-
----
-
-### Step 3A: Auto-detect Changed Features
-
-```bash
-git log --since="7 days ago" --name-only --pretty=format: | grep -v '^$' | sort -u
-```
-
-Map changed file paths to feature specs using these rules:
-
-1. **Read `docs/FEATURES.md`** to get the list of all spec files and their names.
-2. For each changed file, determine which spec it belongs to:
-   - Match by **feature name similarity**: if the spec is `expenses.md`, look for changed files containing `expense` in their path.
-   - Match by **directory**: if the spec is `budgets.md`, match files under any `budgets/` or `budget/` directory.
-   - Match by **schema files**: if any migration file, `schema.sql`, `schema.prisma`, `database.ts`, or similar schema file changed → mark ALL specs as potentially affected (schema changes ripple everywhere).
-3. Deduplicate the affected spec list.
-4. Report which specs will be updated and ask for confirmation.
-
----
-
-### Step 3B: User Selects Features
-
-List all `.md` files in `docs/sk:features/` (excluding `_template.md`).
-Let the user pick which ones to update.
-
----
-
-### Step 3C: Refresh All
-
-Set update list = all `.md` files in `docs/sk:features/` (excluding `_template.md`).
-
----
-
-### Step 4: Update Each Affected Spec
-
-For each spec file to update, follow this sequence:
-
-#### 4a. Read the existing spec
-Understand its current content and section structure.
-
-#### 4b. Discover relevant source files
-
-Use a three-step lookup — no hardcoded paths:
-
-1. **Name-based search**: the feature name from the spec filename (e.g., `expenses.md` → feature name `expenses`). Search the repo:
-   ```bash
-   # Find files whose name contains the feature keyword
-   find . -type f \( -name "*expense*" -o -name "*expenses*" \) \
-     ! -path "*/node_modules/*" ! -path "*/.git/*" ! -path "*/docs/*" \
-     2>/dev/null | head -30
-   ```
-   Adjust the keyword to match the feature name.
-
-2. **Related Docs in spec**: read the `## Related Docs` section of the existing spec — it lists previously referenced files. Read those files too.
-
-3. **DB schema hint**: read the `## Database Schema` section — it names tables. Search migrations and schema files for those table names.
-
-#### 4c. Read the source files
-Read all discovered source files to understand the current implementation.
-
-#### 4d. Identify what changed
-Compare the current source code against what the spec describes:
-- New or removed DB columns / tables / constraints
-- Changed business logic rules or state transitions
-- New/changed API payloads or query patterns
-- Updated permission keys or tier requirements
-- New edge cases, error codes, or recovery paths
-
-#### 4e. Update only changed sections
-Rewrite only the sections that are out of date. **Preserve all unchanged sections verbatim.**
-Update the `> Status` block if the implementation status on either platform changed.
-
----
-
-### Step 5: Handle New Features
-
-If source code has a clear new feature (new hook, new route group, new major component) with no corresponding spec:
-
-1. Create `docs/sk:features/<feature-name>.md` using `docs/sk:features/_template.md` as base.
-   If `_template.md` doesn't exist, use this 11-section structure:
-   ```
-   Status → Overview → Database Schema → Business Logic → API Contract
-   → Permissions & Access Control → Edge Cases → Error States
-   → UI/UX Behavior (### Web + ### Mobile) → Platform Notes → Related Docs
-   ```
-2. Fill all 11 sections from current source code.
-3. Add the new spec to `docs/FEATURES.md` under the appropriate section.
-
----
-
-### Step 6: Update Master Index
-
-Review `docs/FEATURES.md`:
-- Add links for any new specs
-- Update status columns (Web / Mobile) if implementation status changed
-- Update any tier/feature tables if permissions changed
-
----
-
-### Step 7: Report and Commit
-
-Show a summary:
-- ✅ **Updated**: `spec-name.md` — what changed (1 sentence each)
-- ➕ **Added**: any new spec files
-- ⏭️ **Skipped**: specs with no detected changes
-
-Ask: **"Commit the updated specs?"**
-- Yes → stage only files under `docs/` and commit:
-  `docs(features): update feature specs to reflect current implementation`
-- No → leave changes unstaged for the user to review
-
----
-
-## Create From Scratch
-
-When `docs/sk:features/` doesn't exist, discover and document all features:
-
-### Discovery Phase
-
-1. **Detect source structure** — find where feature logic lives:
-   ```bash
-   # Look for hooks, services, controllers, models, routes
-   ls src/ lib/ app/ 2>/dev/null
-   find . -maxdepth 4 -type f \
-     \( -name "use-*.ts" -o -name "use-*.js" \
-        -o -name "*.service.ts" -o -name "*.controller.ts" \
-        -o -name "*.model.ts" -o -name "*.router.ts" \) \
-     ! -path "*/node_modules/*" ! -path "*/.git/*" 2>/dev/null | head -50
-   ```
-
-2. **Detect schema files** — migrations, ORM schemas:
-   ```bash
-   find . -maxdepth 5 \
-     \( -name "schema.sql" -o -name "*.schema.prisma" \
-        -o -name "database.ts" -o -name "*.migration.*" \) \
-     ! -path "*/node_modules/*" ! -path "*/.git/*" 2>/dev/null
-   ls supabase/migrations/ 2>/dev/null | tail -10
-   ls prisma/ 2>/dev/null
-   ```
-
-3. **Identify feature domains** from the discovered files — group related files into named features.
-
-4. **Report discovered features** and ask the user to confirm/adjust the list before creating anything.
-
-### Creation Phase
-
-For each confirmed feature:
-1. Read all relevant source files.
-2. Create `docs/sk:features/<feature-name>.md` with all 11 sections — based entirely on source code.
-
-Also create:
-- `docs/FEATURES.md` — master index with:
-  - How-to-use section (web path + mobile path via `../project-name/docs/`)
-  - Feature table grouped by domain
-  - Tier/subscription overview (if the project has tiers)
-- `docs/sk:features/_template.md` — 11-section template for future specs
-
-Commit: `docs: add feature specification system`
-
----
-
-## Quality Rules (Always Apply)
-
-- **Source-verified only** — every claim must be findable in source code; never invent behavior
-- **No placeholders** — no `// TODO`, no `false // will be computed`, no assumed values
-- **Surgical updates** — only rewrite what changed; preserve unchanged sections verbatim
-- **Numeric JSX coercion** — when documenting frontend behavior, note `!!value` (not `value &&`) for numerics to avoid rendering `0` as text in React/React Native
-- **Local date, not UTC** — for any time-bounded query (current month, today, etc.), document that implementations must use local `new Date()`, not `toISOString()` which returns UTC and causes off-by-one for users in non-UTC timezones
-- **All 11 sections required** — mark "N/A" only if genuinely not applicable
-
-## Source Discovery Heuristics (Reference)
-
-When locating source files for a feature named `<name>`:
-
-| What to look for | Search pattern |
-|---|---|
-| Hooks / composables | `use-<name>.*`, `use<Name>.*` |
-| Components | directories or files matching `<name>/`, `*<name>*` |
-| API routes / controllers | `<name>.route.*`, `<name>.controller.*`, `api/<name>/` |
-| Services / repositories | `<name>.service.*`, `<name>.repo.*` |
-| DB schema | `migrations/` containing table name, `schema.prisma`, `database.ts` |
-| Tests | `<name>.test.*`, `<name>.spec.*` |
-
-These are starting points — read broadly and verify before updating any section.

package/commands/sk/release.md

@@ -1,72 +0,0 @@
----
-description: "Automate releases: bump version, update CHANGELOG, create tag, push to GitHub. Use --android and/or --ios flags for App Store / Play Store readiness audit."
----
-
-<!-- Generated by /sk:setup-claude -->
-
-# /sk:release
-
-Automate the release process for your project. Supports optional mobile store submission review.
-
-## Usage
-
-```
-/sk:release                    # Git release only
-/sk:release --android          # Git release + Play Store audit
-/sk:release --ios              # Git release + App Store audit
-/sk:release --android --ios    # Git release + both store audits
-```
-
-## Hard Rules
-
-- **DO NOT** release without reviewing CHANGELOG.md changes
-- **DO NOT** proceed if CHANGELOG.md has no [Unreleased] section
-- You **must** have a git remote origin (GitHub, GitLab, etc.)
-- Version format must follow semantic versioning (e.g., v1.0.0, v0.2.0-beta)
-- When `--android` or `--ios` flags are present, **always run the store audit after the git release**
-
-## Steps
-
-1. **Parse flags** — Check for `--android` and/or `--ios` in the user's invocation.
-
-2. **Verify CHANGELOG.md** — Check that the [Unreleased] section has the changes you want to release. If not, update CHANGELOG.md first and commit.
-
-3. **Run the release script** — This will:
-   - Auto-detect: project name, current version, GitHub URL
-   - Prompt for: new version number
-   - Suggest: release title based on changes
-   - Update: CHANGELOG.md (move [Unreleased] -> [Version])
-   - Update: version in CLAUDE.md (if it has a Version line)
-   - Create: git commit with release message
-   - Create: annotated git tag
-   - Push: tag to GitHub (with confirmation at each step)
-
-4. **Complete the release on GitHub** — The script will show you the GitHub releases link. Go there and:
-   - Click "Create release from tag"
-   - Use the suggested title
-   - Copy the changelog section as release notes
-   - Publish the release
-
-5. **(If --android or --ios)** **Run Store Readiness Audit** — The release skill will:
-   - Auto-detect the mobile framework (Expo, React Native, Flutter, native, Capacitor)
-   - Detect if this is a first-time submission or an update
-   - Walk through every item in the store checklist, checking config files
-   - Report status for each item: PASS / FAIL / WARN / MANUAL CHECK NEEDED
-   - Propose fixes for config issues (with your approval)
-   - Guide you through manual steps (screenshots, store listing, etc.)
-   - Present a summary report with next steps and build/submit commands
-
-## When Done
-
-> "Release {version} completed! Check GitHub to finalize the release."
-
-If store flags were used:
-> "Store readiness audit complete. See the summary report above for remaining action items."
-
-## Notes
-
-- Each step (commit, tag, push) requires your confirmation
-- You can skip any step and do it manually later
-- The script works with any project type: Node, Python, Go, Rust, etc.
-- Requires: CHANGELOG.md file with [Unreleased] section
-- Store audits support: Expo, React Native, Flutter, native Android/iOS, Capacitor/Ionic, .NET MAUI

package/skills/sk:setup-claude/templates/commands/features.md.template

@@ -1,238 +0,0 @@
----
-name: features
-description: "Sync docs/features/ specs with the current codebase. Auto-detects changed areas and updates only affected specs. Creates the spec system from scratch if it doesn't exist."
----
-
-<!-- Generated by /setup-claude -->
-
-# /features
-
-Keep feature specifications in `docs/features/` in sync with the actual codebase.
-Works with **any project** — framework-agnostic, auto-discovers source structure.
-
-## What This Does
-
-Maintains `docs/features/` as a platform-agnostic feature specification system —
-the single source of truth shared between web, mobile, and any other platform
-that uses the same backend. Each spec covers: DB schema, business logic, API
-contract, permissions, edge cases, error states, web/mobile UI behavior, and
-platform divergences.
-
----
-
-## Steps
-
-### Step 1: Detect Project State
-
-Check what exists:
-
-```bash
-ls docs/features/ 2>/dev/null && echo "EXISTS" || echo "MISSING"
-ls docs/FEATURES.md 2>/dev/null && echo "INDEX_EXISTS" || echo "INDEX_MISSING"
-```
-
-**If `docs/features/` does not exist:**
-Ask the user: "No feature specification system found. Create one from scratch?"
-- Yes → jump to **[Create From Scratch](#create-from-scratch)** below
-- No → stop
-
-**If `docs/features/` exists:**
-Continue to Step 2.
-
----
-
-### Step 2: Determine Update Scope
-
-Present three options:
-
-> **What would you like to update?**
-> **A. Auto-detect** *(recommended)* — scan recent git changes, update only affected specs
-> **B. Select features** — pick which specs to update from the list
-> **C. Refresh all** — update every spec from current source code
-
-Wait for the user's choice.
-
----
-
-### Step 3A: Auto-detect Changed Features
-
-```bash
-git log --since="7 days ago" --name-only --pretty=format: | grep -v '^$' | sort -u
-```
-
-Map changed file paths to feature specs using these rules:
-
-1. **Read `docs/FEATURES.md`** to get the list of all spec files and their names.
-2. For each changed file, determine which spec it belongs to:
-   - Match by **feature name similarity**: if the spec is `expenses.md`, look for changed files containing `expense` in their path.
-   - Match by **directory**: if the spec is `budgets.md`, match files under any `budgets/` or `budget/` directory.
-   - Match by **schema files**: if any migration file, `schema.sql`, `schema.prisma`, `database.ts`, or similar schema file changed → mark ALL specs as potentially affected (schema changes ripple everywhere).
-3. Deduplicate the affected spec list.
-4. Report which specs will be updated and ask for confirmation.
-
----
-
-### Step 3B: User Selects Features
-
-List all `.md` files in `docs/features/` (excluding `_template.md`).
-Let the user pick which ones to update.
-
----
-
-### Step 3C: Refresh All
-
-Set update list = all `.md` files in `docs/features/` (excluding `_template.md`).
-
----
-
-### Step 4: Update Each Affected Spec
-
-For each spec file to update, follow this sequence:
-
-#### 4a. Read the existing spec
-Understand its current content and section structure.
-
-#### 4b. Discover relevant source files
-
-Use a three-step lookup — no hardcoded paths:
-
-1. **Name-based search**: the feature name from the spec filename (e.g., `expenses.md` → feature name `expenses`). Search the repo:
-   ```bash
-   # Find files whose name contains the feature keyword
-   find . -type f \( -name "*expense*" -o -name "*expenses*" \) \
-     ! -path "*/node_modules/*" ! -path "*/.git/*" ! -path "*/docs/*" \
-     2>/dev/null | head -30
-   ```
-   Adjust the keyword to match the feature name.
-
-2. **Related Docs in spec**: read the `## Related Docs` section of the existing spec — it lists previously referenced files. Read those files too.
-
-3. **DB schema hint**: read the `## Database Schema` section — it names tables. Search migrations and schema files for those table names.
-
-#### 4c. Read the source files
-Read all discovered source files to understand the current implementation.
-
-#### 4d. Identify what changed
-Compare the current source code against what the spec describes:
-- New or removed DB columns / tables / constraints
-- Changed business logic rules or state transitions
-- New/changed API payloads or query patterns
-- Updated permission keys or tier requirements
-- New edge cases, error codes, or recovery paths
-
-#### 4e. Update only changed sections
-Rewrite only the sections that are out of date. **Preserve all unchanged sections verbatim.**
-Update the `> Status` block if the implementation status on either platform changed.
-
----
-
-### Step 5: Handle New Features
-
-If source code has a clear new feature (new hook, new route group, new major component) with no corresponding spec:
-
-1. Create `docs/features/<feature-name>.md` using `docs/features/_template.md` as base.
-   If `_template.md` doesn't exist, use this 11-section structure:
-   ```
-   Status → Overview → Database Schema → Business Logic → API Contract
-   → Permissions & Access Control → Edge Cases → Error States
-   → UI/UX Behavior (### Web + ### Mobile) → Platform Notes → Related Docs
-   ```
-2. Fill all 11 sections from current source code.
-3. Add the new spec to `docs/FEATURES.md` under the appropriate section.
-
----
-
-### Step 6: Update Master Index
-
-Review `docs/FEATURES.md`:
-- Add links for any new specs
-- Update status columns (Web / Mobile) if implementation status changed
-- Update any tier/feature tables if permissions changed
-
----
-
-### Step 7: Report and Commit
-
-Show a summary:
-- ✅ **Updated**: `spec-name.md` — what changed (1 sentence each)
-- ➕ **Added**: any new spec files
-- ⏭️ **Skipped**: specs with no detected changes
-
-Ask: **"Commit the updated specs?"**
-- Yes → stage only files under `docs/` and commit:
-  `docs(features): update feature specs to reflect current implementation`
-- No → leave changes unstaged for the user to review
-
----
-
-## Create From Scratch
-
-When `docs/features/` doesn't exist, discover and document all features:
-
-### Discovery Phase
-
-1. **Detect source structure** — find where feature logic lives:
-   ```bash
-   # Look for hooks, services, controllers, models, routes
-   ls src/ lib/ app/ 2>/dev/null
-   find . -maxdepth 4 -type f \
-     \( -name "use-*.ts" -o -name "use-*.js" \
-        -o -name "*.service.ts" -o -name "*.controller.ts" \
-        -o -name "*.model.ts" -o -name "*.router.ts" \) \
-     ! -path "*/node_modules/*" ! -path "*/.git/*" 2>/dev/null | head -50
-   ```
-
-2. **Detect schema files** — migrations, ORM schemas:
-   ```bash
-   find . -maxdepth 5 \
-     \( -name "schema.sql" -o -name "*.schema.prisma" \
-        -o -name "database.ts" -o -name "*.migration.*" \) \
-     ! -path "*/node_modules/*" ! -path "*/.git/*" 2>/dev/null
-   ls supabase/migrations/ 2>/dev/null | tail -10
-   ls prisma/ 2>/dev/null
-   ```
-
-3. **Identify feature domains** from the discovered files — group related files into named features.
-
-4. **Report discovered features** and ask the user to confirm/adjust the list before creating anything.
-
-### Creation Phase
-
-For each confirmed feature:
-1. Read all relevant source files.
-2. Create `docs/features/<feature-name>.md` with all 11 sections — based entirely on source code.
-
-Also create:
-- `docs/FEATURES.md` — master index with:
-  - How-to-use section (web path + mobile path via `../project-name/docs/`)
-  - Feature table grouped by domain
-  - Tier/subscription overview (if the project has tiers)
-- `docs/features/_template.md` — 11-section template for future specs
-
-Commit: `docs: add feature specification system`
-
----
-
-## Quality Rules (Always Apply)
-
-- **Source-verified only** — every claim must be findable in source code; never invent behavior
-- **No placeholders** — no `// TODO`, no `false // will be computed`, no assumed values
-- **Surgical updates** — only rewrite what changed; preserve unchanged sections verbatim
-- **Numeric JSX coercion** — when documenting frontend behavior, note `!!value` (not `value &&`) for numerics to avoid rendering `0` as text in React/React Native
-- **Local date, not UTC** — for any time-bounded query (current month, today, etc.), document that implementations must use local `new Date()`, not `toISOString()` which returns UTC and causes off-by-one for users in non-UTC timezones
-- **All 11 sections required** — mark "N/A" only if genuinely not applicable
-
-## Source Discovery Heuristics (Reference)
-
-When locating source files for a feature named `<name>`:
-
-| What to look for | Search pattern |
-|---|---|
-| Hooks / composables | `use-<name>.*`, `use<Name>.*` |
-| Components | directories or files matching `<name>/`, `*<name>*` |
-| API routes / controllers | `<name>.route.*`, `<name>.controller.*`, `api/<name>/` |
-| Services / repositories | `<name>.service.*`, `<name>.repo.*` |
-| DB schema | `migrations/` containing table name, `schema.prisma`, `database.ts` |
-| Tests | `<name>.test.*`, `<name>.spec.*` |
-
-These are starting points — read broadly and verify before updating any section.

package/skills/sk:setup-claude/templates/commands/release.md.template

@@ -1,74 +0,0 @@
----
-description: "Automate releases: bump version, update CHANGELOG, create tag, push to GitHub. Use --android and/or --ios flags for App Store / Play Store readiness audit."
----
-
-<!-- Generated by /setup-claude -->
-
-# /release
-
-**Workflow:** Read → Explore → Design → Accessibility → Plan → Branch → Migrate → Write Tests → Implement → Lint → Verify Tests → Security → Performance → Review → Finalize → **Release**
-
-Automate the release process for your project. Supports optional mobile store submission review.
-
-## Usage
-
-```
-/release                    # Git release only
-/release --android          # Git release + Play Store audit
-/release --ios              # Git release + App Store audit
-/release --android --ios    # Git release + both store audits
-```
-
-## Hard Rules
-
-- **DO NOT** release without reviewing CHANGELOG.md changes
-- **DO NOT** proceed if CHANGELOG.md has no [Unreleased] section
-- You **must** have a git remote origin (GitHub, GitLab, etc.)
-- Version format must follow semantic versioning (e.g., v1.0.0, v0.2.0-beta)
-- When `--android` or `--ios` flags are present, **always run the store audit after the git release**
-
-## Steps
-
-1. **Parse flags** — Check for `--android` and/or `--ios` in the user's invocation.
-
-2. **Verify CHANGELOG.md** — Check that the [Unreleased] section has the changes you want to release. If not, update CHANGELOG.md first and commit.
-
-3. **Run the release script** — This will:
-   - Auto-detect: project name, current version, GitHub URL
-   - Prompt for: new version number
-   - Suggest: release title based on changes
-   - Update: CHANGELOG.md (move [Unreleased] -> [Version])
-   - Update: version in CLAUDE.md (if it has a Version line)
-   - Create: git commit with release message
-   - Create: annotated git tag
-   - Push: tag to GitHub (with confirmation at each step)
-
-4. **Complete the release on GitHub** — The script will show you the GitHub releases link. Go there and:
-   - Click "Create release from tag"
-   - Use the suggested title
-   - Copy the changelog section as release notes
-   - Publish the release
-
-5. **(If --android or --ios)** **Run Store Readiness Audit** — The release skill will:
-   - Auto-detect the mobile framework (Expo, React Native, Flutter, native, Capacitor)
-   - Detect if this is a first-time submission or an update
-   - Walk through every item in the store checklist, checking config files
-   - Report status for each item: PASS / FAIL / WARN / MANUAL CHECK NEEDED
-   - Propose fixes for config issues (with your approval)
-   - Guide you through manual steps (screenshots, store listing, etc.)
-   - Present a summary report with next steps and build/submit commands
-
-## When Done
-
-> "Release {version} completed! Check GitHub to finalize the release."
-
-If store flags were used:
-> "Store readiness audit complete. See the summary report above for remaining action items."
-
-## Notes
-
-- Each step (commit, tag, push) requires your confirmation
-- You can skip any step and do it manually later
-- The script works with any project type: Node, Python, Go, Rust, etc.
-- Requires: CHANGELOG.md file with [Unreleased] section
-- Store audits support: Expo, React Native, Flutter, native Android/iOS, Capacitor/Ionic, .NET MAUI