create-agentic-app 1.1.58 → 1.1.59

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-agentic-app",
-  "version": "1.1.58",
+  "version": "1.1.59",
   "description": "Scaffold a new agentic AI application with Next.js, Better Auth, and AI SDK",
   "type": "module",
   "bin": {

package/template/.agents/skills/checkpoint/SKILL.md

@@ -10,7 +10,7 @@ description: >
 
 # Checkpoint Commit
 
-Create a comprehensive checkpoint commit that captures all current changes with a detailed, well-structured commit message.
+Create a checkpoint commit that captures all current changes — but only after the code passes lint, type check, and build.
 
 ## Instructions
 
@@ -23,7 +23,17 @@ Run these commands to understand the full picture:
 3. `git diff --cached` — see already-staged changes
 4. `git log -5 --oneline` — understand this repo's commit message style
 
-### Step 2: Stage Everything
+### Step 2: Quality Checks
+
+Run all three checks. If any fail, fix the issues before proceeding — do not skip or ignore failures.
+
+1. `npm run lint` — fix any lint errors
+2. `npm run type-check` — fix any type errors (if the script doesn't exist, try `npx tsc --noEmit`)
+3. `npm run build` — fix any build errors
+
+Iterate until all three pass cleanly. Only then move to the next step.
+
+### Step 3: Stage Everything
 
 Stage all changes — tracked modifications, deletions, and new untracked files:
 
@@ -31,20 +41,16 @@ Stage all changes — tracked modifications, deletions, and new untracked files:
 git add -A
 ```
 
-### Step 3: Craft the Commit Message
+### Step 4: Craft the Commit Message
 
 Write a commit message following the project's existing conventions (observed from `git log`). Structure:
 
 - **First line**: clear, concise summary in imperative mood (50-72 chars)
   - Use conventional commit prefixes where the project uses them: `feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, etc.
-- **Body** (separated by blank line): detailed description including:
-  - What changes were made (key modifications)
-  - Why these changes were made (purpose/motivation)
-  - Important technical details or decisions
-  - Breaking changes or migration notes if applicable
+- **Body** (separated by blank line): a short TL;DR of the changes — 1-3 sentences max. No bullet lists, no file-by-file breakdowns, no lengthy explanations.
 - **Footer**: co-author attribution
 
-### Step 4: Commit
+### Step 5: Commit
 
 Create the commit using a heredoc for proper formatting:
 
@@ -52,14 +58,14 @@ Create the commit using a heredoc for proper formatting:
 git commit -m "$(cat <<'EOF'
 {first line}
 
-{body}
+{tldr}
 
 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 EOF
 )"
 ```
 
-### Step 5: Report
+### Step 6: Report
 
 Display:
 - The commit hash and message summary
@@ -70,6 +76,7 @@ Display:
 
 - Stage and commit everything — do not skip files unless they are clearly sensitive (`.env`, credentials)
 - If the repo has no git history, run `git init` first
-- Make the commit message descriptive enough that someone reading `git log` understands what was accomplished
+- All quality checks (lint, type-check, build) MUST pass before committing — fix issues, don't skip them
+- Keep the commit body short — a TL;DR, not an essay
 - Follow the project's existing commit conventions (check the log first)
 - Do not push — only commit locally

package/template/.agents/skills/ship-it/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: ship-it
+description: >
+  Push the current branch to GitHub and create a pull request. Use this skill when the user says
+  "ship it", "ship this", "push to github", "create a pr", "open a pull request", "send for review",
+  "get this reviewed", or wants to push their work and open a PR. Also use when the user says
+  "/ship-it". This skill handles prerequisites, branching, pushing, and PR creation — it does not
+  commit or run quality checks (use checkpoint for that first).
+---
+
+# Ship It
+
+Push your work to GitHub and open a pull request — handling prerequisites, branch creation, pushing, and PR generation automatically.
+
+This skill complements `checkpoint`. Use `checkpoint` to commit locally (with quality gates), then `ship-it` to get the code to GitHub for review.
+
+## Instructions
+
+### Step 0: Prerequisites
+
+Verify tooling before doing anything else.
+
+1. **GitHub CLI installed?**
+   ```bash
+   gh --version
+   ```
+   If the command fails (not found):
+   - Detect the platform and attempt to install:
+     - **Windows:** `winget install --id GitHub.cli`
+     - **macOS:** `brew install gh`
+     - **Linux (Debian/Ubuntu):** follow the official apt instructions
+   - If auto-install fails, tell the user what to install and stop.
+
+2. **GitHub CLI authenticated?**
+   ```bash
+   gh auth status
+   ```
+   If not authenticated, tell the user:
+   ```
+   GitHub CLI is not logged in. Please run this in the prompt:
+     ! gh auth login
+   Then re-run /ship-it.
+   ```
+   Stop here — do not proceed until auth is confirmed.
+
+3. **Git remote exists?**
+   ```bash
+   git remote -v
+   ```
+   If no remote named `origin` exists, stop and tell the user:
+   ```
+   No git remote found. Add one with:
+     git remote add origin https://github.com/{user}/{repo}.git
+   ```
+
+### Step 1: Detect the Environment
+
+Run these commands to understand the current state:
+
+1. `git branch --show-current` — get the current branch name
+2. Detect the default branch:
+   ```bash
+   gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
+   ```
+3. `git status --porcelain` — check for uncommitted changes
+
+If there are uncommitted changes, stop and tell the user:
+```
+You have uncommitted changes. Run /checkpoint first to commit them, then /ship-it to push.
+```
+
+Store the default branch name for use throughout the remaining steps.
+
+### Step 2: Check for Unpushed Commits
+
+Determine if there are commits that haven't been pushed yet.
+
+**If on a feature branch with a remote tracking branch:**
+```bash
+git log @{upstream}..HEAD --oneline
+```
+
+**If on a feature branch with no remote tracking branch, or on the default branch:**
+```bash
+git log origin/{default_branch}..HEAD --oneline
+```
+
+If there are **no unpushed commits**, stop and tell the user:
+```
+Nothing to ship — all commits are already pushed.
+```
+
+Save the list of unpushed commit messages for use in later steps.
+
+### Step 3: Handle Branching
+
+**If already on a feature branch** (not the default branch):
+- Stay on it. No branching needed.
+- Skip to Step 4.
+
+**If on the default branch:**
+- Generate a branch name from the unpushed commit messages:
+  - Read the commit subjects
+  - Derive a kebab-case branch name with a conventional prefix: `feat/`, `fix/`, `refactor/`, `chore/`, `docs/` based on the commit content
+  - Keep it short (3-5 words max after the prefix), e.g., `feat/add-user-auth`, `fix/login-redirect-loop`
+  - Strip special characters, lowercase everything
+- Create and switch to the new branch:
+  ```bash
+  git checkout -b {branch_name}
+  ```
+- Tell the user: `Created branch {branch_name}`
+
+### Step 4: Push to Origin
+
+```bash
+git push -u origin {branch_name}
+```
+
+If the branch already has a remote tracking branch, a regular `git push` is fine.
+
+### Step 5: Check for Existing PR
+
+Before creating a new PR, check if one already exists for this branch:
+
+```bash
+gh pr view --json number,url,title,state 2>/dev/null
+```
+
+If a PR already exists and is **open**:
+- Do NOT create a new one
+- Skip to Step 7 and report the existing PR with a note that new commits were pushed.
+
+If no PR exists (or it is closed/merged), proceed to Step 6.
+
+### Step 6: Create the Pull Request
+
+Generate the PR title and body from the unpushed commits:
+
+- **Title**: concise summary under 70 chars. If single commit, use its subject. If multiple, synthesize a short summary. Imperative mood.
+- **Body**: TL;DR of the changes in 2-4 bullet points max.
+
+```bash
+gh pr create --base {default_branch} --head {branch_name} --title "{title}" --body "$(cat <<'EOF'
+## Summary
+{2-4 bullet points}
+
+---
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+EOF
+)"
+```
+
+### Step 7: Report
+
+Display the result clearly:
+
+```
+Shipped to GitHub:
+  Branch: {branch_name}
+  PR: #{number} — {title}
+  URL: {url}
+```
+
+## Important
+
+- Do NOT run lint, type-check, or build — that is checkpoint's job
+- Do NOT commit anything — only push existing commits and create a PR
+- If the user has uncommitted changes, tell them to run /checkpoint first
+- Keep the PR body short — a TL;DR, not an essay
+- Always check for an existing open PR before creating a new one to avoid duplicates
+- Detect the default branch dynamically — do not hardcode `main` or `master`
+- When creating a branch from the default branch, use conventional prefixes (`feat/`, `fix/`, etc.) with kebab-case names
+- Never run destructive git operations (no `--force`, no `reset --hard`)
+- If `gh` is not installed or authenticated, help the user get set up before proceeding

package/template/.claude/skills/checkpoint/SKILL.md

@@ -10,7 +10,7 @@ description: >
 
 # Checkpoint Commit
 
-Create a comprehensive checkpoint commit that captures all current changes with a detailed, well-structured commit message.
+Create a checkpoint commit that captures all current changes — but only after the code passes lint, type check, and build.
 
 ## Instructions
 
@@ -23,7 +23,17 @@ Run these commands to understand the full picture:
 3. `git diff --cached` — see already-staged changes
 4. `git log -5 --oneline` — understand this repo's commit message style
 
-### Step 2: Stage Everything
+### Step 2: Quality Checks
+
+Run all three checks. If any fail, fix the issues before proceeding — do not skip or ignore failures.
+
+1. `npm run lint` — fix any lint errors
+2. `npm run type-check` — fix any type errors (if the script doesn't exist, try `npx tsc --noEmit`)
+3. `npm run build` — fix any build errors
+
+Iterate until all three pass cleanly. Only then move to the next step.
+
+### Step 3: Stage Everything
 
 Stage all changes — tracked modifications, deletions, and new untracked files:
 
@@ -31,20 +41,16 @@ Stage all changes — tracked modifications, deletions, and new untracked files:
 git add -A
 ```
 
-### Step 3: Craft the Commit Message
+### Step 4: Craft the Commit Message
 
 Write a commit message following the project's existing conventions (observed from `git log`). Structure:
 
 - **First line**: clear, concise summary in imperative mood (50-72 chars)
   - Use conventional commit prefixes where the project uses them: `feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, etc.
-- **Body** (separated by blank line): detailed description including:
-  - What changes were made (key modifications)
-  - Why these changes were made (purpose/motivation)
-  - Important technical details or decisions
-  - Breaking changes or migration notes if applicable
+- **Body** (separated by blank line): a short TL;DR of the changes — 1-3 sentences max. No bullet lists, no file-by-file breakdowns, no lengthy explanations.
 - **Footer**: co-author attribution
 
-### Step 4: Commit
+### Step 5: Commit
 
 Create the commit using a heredoc for proper formatting:
 
@@ -52,14 +58,14 @@ Create the commit using a heredoc for proper formatting:
 git commit -m "$(cat <<'EOF'
 {first line}
 
-{body}
+{tldr}
 
 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 EOF
 )"
 ```
 
-### Step 5: Report
+### Step 6: Report
 
 Display:
 - The commit hash and message summary
@@ -70,6 +76,7 @@ Display:
 
 - Stage and commit everything — do not skip files unless they are clearly sensitive (`.env`, credentials)
 - If the repo has no git history, run `git init` first
-- Make the commit message descriptive enough that someone reading `git log` understands what was accomplished
+- All quality checks (lint, type-check, build) MUST pass before committing — fix issues, don't skip them
+- Keep the commit body short — a TL;DR, not an essay
 - Follow the project's existing commit conventions (check the log first)
 - Do not push — only commit locally

package/template/.claude/skills/ship-it/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: ship-it
+description: >
+  Push the current branch to GitHub and create a pull request. Use this skill when the user says
+  "ship it", "ship this", "push to github", "create a pr", "open a pull request", "send for review",
+  "get this reviewed", or wants to push their work and open a PR. Also use when the user says
+  "/ship-it". This skill handles prerequisites, branching, pushing, and PR creation — it does not
+  commit or run quality checks (use checkpoint for that first).
+---
+
+# Ship It
+
+Push your work to GitHub and open a pull request — handling prerequisites, branch creation, pushing, and PR generation automatically.
+
+This skill complements `checkpoint`. Use `checkpoint` to commit locally (with quality gates), then `ship-it` to get the code to GitHub for review.
+
+## Instructions
+
+### Step 0: Prerequisites
+
+Verify tooling before doing anything else.
+
+1. **GitHub CLI installed?**
+   ```bash
+   gh --version
+   ```
+   If the command fails (not found):
+   - Detect the platform and attempt to install:
+     - **Windows:** `winget install --id GitHub.cli`
+     - **macOS:** `brew install gh`
+     - **Linux (Debian/Ubuntu):** follow the official apt instructions
+   - If auto-install fails, tell the user what to install and stop.
+
+2. **GitHub CLI authenticated?**
+   ```bash
+   gh auth status
+   ```
+   If not authenticated, tell the user:
+   ```
+   GitHub CLI is not logged in. Please run this in the prompt:
+     ! gh auth login
+   Then re-run /ship-it.
+   ```
+   Stop here — do not proceed until auth is confirmed.
+
+3. **Git remote exists?**
+   ```bash
+   git remote -v
+   ```
+   If no remote named `origin` exists, stop and tell the user:
+   ```
+   No git remote found. Add one with:
+     git remote add origin https://github.com/{user}/{repo}.git
+   ```
+
+### Step 1: Detect the Environment
+
+Run these commands to understand the current state:
+
+1. `git branch --show-current` — get the current branch name
+2. Detect the default branch:
+   ```bash
+   gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
+   ```
+3. `git status --porcelain` — check for uncommitted changes
+
+If there are uncommitted changes, stop and tell the user:
+```
+You have uncommitted changes. Run /checkpoint first to commit them, then /ship-it to push.
+```
+
+Store the default branch name for use throughout the remaining steps.
+
+### Step 2: Check for Unpushed Commits
+
+Determine if there are commits that haven't been pushed yet.
+
+**If on a feature branch with a remote tracking branch:**
+```bash
+git log @{upstream}..HEAD --oneline
+```
+
+**If on a feature branch with no remote tracking branch, or on the default branch:**
+```bash
+git log origin/{default_branch}..HEAD --oneline
+```
+
+If there are **no unpushed commits**, stop and tell the user:
+```
+Nothing to ship — all commits are already pushed.
+```
+
+Save the list of unpushed commit messages for use in later steps.
+
+### Step 3: Handle Branching
+
+**If already on a feature branch** (not the default branch):
+- Stay on it. No branching needed.
+- Skip to Step 4.
+
+**If on the default branch:**
+- Generate a branch name from the unpushed commit messages:
+  - Read the commit subjects
+  - Derive a kebab-case branch name with a conventional prefix: `feat/`, `fix/`, `refactor/`, `chore/`, `docs/` based on the commit content
+  - Keep it short (3-5 words max after the prefix), e.g., `feat/add-user-auth`, `fix/login-redirect-loop`
+  - Strip special characters, lowercase everything
+- Create and switch to the new branch:
+  ```bash
+  git checkout -b {branch_name}
+  ```
+- Tell the user: `Created branch {branch_name}`
+
+### Step 4: Push to Origin
+
+```bash
+git push -u origin {branch_name}
+```
+
+If the branch already has a remote tracking branch, a regular `git push` is fine.
+
+### Step 5: Check for Existing PR
+
+Before creating a new PR, check if one already exists for this branch:
+
+```bash
+gh pr view --json number,url,title,state 2>/dev/null
+```
+
+If a PR already exists and is **open**:
+- Do NOT create a new one
+- Skip to Step 7 and report the existing PR with a note that new commits were pushed.
+
+If no PR exists (or it is closed/merged), proceed to Step 6.
+
+### Step 6: Create the Pull Request
+
+Generate the PR title and body from the unpushed commits:
+
+- **Title**: concise summary under 70 chars. If single commit, use its subject. If multiple, synthesize a short summary. Imperative mood.
+- **Body**: TL;DR of the changes in 2-4 bullet points max.
+
+```bash
+gh pr create --base {default_branch} --head {branch_name} --title "{title}" --body "$(cat <<'EOF'
+## Summary
+{2-4 bullet points}
+
+---
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+EOF
+)"
+```
+
+### Step 7: Report
+
+Display the result clearly:
+
+```
+Shipped to GitHub:
+  Branch: {branch_name}
+  PR: #{number} — {title}
+  URL: {url}
+```
+
+## Important
+
+- Do NOT run lint, type-check, or build — that is checkpoint's job
+- Do NOT commit anything — only push existing commits and create a PR
+- If the user has uncommitted changes, tell them to run /checkpoint first
+- Keep the PR body short — a TL;DR, not an essay
+- Always check for an existing open PR before creating a new one to avoid duplicates
+- Detect the default branch dynamically — do not hardcode `main` or `master`
+- When creating a branch from the default branch, use conventional prefixes (`feat/`, `fix/`, etc.) with kebab-case names
+- Never run destructive git operations (no `--force`, no `reset --hard`)
+- If `gh` is not installed or authenticated, help the user get set up before proceeding

package/template/AGENTS.md

@@ -17,7 +17,12 @@
 - Identify changes from the plan that can be implemented in parallel, and use sub-agents to implement the features efficiently
 - When using sub-agents to implement features, act as a coordinator only
 - Use the best model for the task - premium models for complex tasks (like coding) and mid-tier models for simpler tasks, like documentation
-- After completing features (large or small), always run commands like lint and type check to check code quality
+- After completing features (large or small), always run commands like lint, type check and next build to check code quality
+
+## DATABASE SCHEMA CHANGES
+
+- Whenever you make changes to the database schema, ALWAYS run the drizzle generate and migrate commands
+- NEVER run drizzle push!
 
 ## TESTING
 
@@ -27,5 +32,5 @@
 
 ## UI DESIGN
 
-- Always following the UI design system when creating or reviewing components or pages.
+- Always follow the UI design system when creating or reviewing components or pages.
 - Design System: @DESIGN.md