@kennethsolomon/shipkit 3.0.6 → 3.1.0

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