@allthingsclaude/blueprints 0.3.0-beta.9 → 0.3.2

package/content/commands/brainstorm.md

@@ -26,7 +26,7 @@ Before brainstorming, quickly assess the current project:
 **Is this an empty/new project?** If there are fewer than 5 source files and no meaningful project configuration, this is likely a **new project**. In that case:
 - Mention to the user that this looks like a new project and brainstorming is a great starting point
 - The brainstorm should focus heavily on **tech stack decisions** (see Step 1 below)
-- When brainstorming is complete, suggest `/auto` which will handle planning, bootstrapping, and implementation end-to-end
+- When brainstorming is complete, suggest `/autopilot` which will handle planning, bootstrapping, and implementation end-to-end
 
 ## Brainstorming Framework
 
@@ -80,18 +80,46 @@ Start by understanding what the user wants to build, then **always ask about the
 - What research or investigation is needed?
 - What would the implementation phases look like?
 
+## Critical Thinking (Always Active)
+
+Throughout brainstorming, actively use the `/critique`, `/verify`, and `/challenge` commands to stress-test ideas **as they emerge**. Don't wait until the end — run these after each step.
+
+### When to invoke each command
+
+- **`/critique`** — After exploring approaches (Steps 2-3). Run this against the ideas on the table to get direct, unfiltered feedback on what's wrong or suboptimal.
+- **`/verify`** — After converging on a direction (Steps 3-4). Run this to sanity-check that we're solving the right problem the right way, and to catch gotchas.
+- **`/challenge`** — After the user proposes or agrees to an approach (any step). Run this to question assumptions, surface trade-offs, and suggest alternatives.
+
+### How to apply
+
+- Invoke these commands naturally throughout the conversation — not as a rigid sequence
+- You can run them multiple times as ideas evolve
+- The goal is **unfiltered, honest exploration** — not polite agreement with whatever the user suggests
+- If an idea survives all three, it's probably solid
+
 ## Discussion Guidelines
 
-- **Ask questions** to clarify and probe deeper
-- **Suggest alternatives** even if they seem unconventional
-- **Challenge assumptions** constructively
+- **Be direct** — if an idea is bad, say so and explain why
+- **Ask hard questions** to probe deeper and expose weak spots
+- **Suggest alternatives** even if they contradict the user's initial direction
 - **Think out loud** about trade-offs and implications
 - **Reference existing code** when relevant for context
 - **Draw connections** to similar patterns in the codebase
 - **Be thorough** - we're not rushing to implementation
+- **Don't hedge** — if you're confident something won't work, say it plainly
+
+## Collecting Image References
+
+If the user shares images during brainstorming (screenshots, mockups, design references, wireframes, inspiration), **track their file paths**. These are critical for downstream plan creation.
+
+When brainstorming is complete and you suggest `/plan` or `/autopilot`:
+- Mention the collected image paths in your handoff so the plan agent copies them to `{{TASKS_DIR}}/references/`
+- If images were shared via the conversation (e.g., user provided a file path or pasted a screenshot), note them explicitly in the brainstorm summary
+
+This ensures future agents (implement, showcase, parallelize) have the visual context they need to design correctly.
 
 ## Tools You CAN Use
-- ✅ Read files for context and understanding
+- ✅ Read files for context and understanding (including reading images)
 - ✅ Grep/Glob to explore existing patterns
 - ✅ Bash (read-only: ls, cat, find, git log, etc.)
 - ✅ Research agents for investigation
@@ -112,14 +140,14 @@ Once we've thoroughly explored the problem space, settled on a tech stack, and c
 | Command | What it does |
 |---|---|
 | `/bootstrap {NAME}` | Generate a plan + bootstrap script to scaffold the project. Good when you want to review the scaffolding before building. |
-| `/auto {NAME}` | Full autonomous loop — planning, bootstrapping, implementation, and commit. Good when you want to go hands-off. |
+| `/autopilot {NAME}` | Full autonomous loop — planning, bootstrapping, implementation, and commit. Good when you want to go hands-off. |
 
 **For existing projects:**
 
 | Command | What it does |
 |---|---|
 | `/plan {NAME}` | Capture brainstorming findings into a structured implementation plan. Good when you want to review before implementing. |
-| `/auto {NAME}` | Full autonomous loop — planning, implementation, validation, and commit. Good when you want to go hands-off. |
+| `/autopilot {NAME}` | Full autonomous loop — planning, implementation, validation, and commit. Good when you want to go hands-off. |
 
 Always present the relevant options and let the user choose how they want to proceed.
 

package/content/commands/commit.md

@@ -40,6 +40,8 @@ The commit agent will:
 - Stage the relevant files and create the commit
 - Verify the commit was created successfully
 
+**IMPORTANT: Do NOT add a `Co-Authored-By` line to the commit message.**
+
 **This will create a git commit.** The agent will show you the proposed message before committing.
 
 Use the Task tool to launch the commit agent (subagent_type="commit") with any additional context from arguments.

package/content/commands/diagram.md

@@ -0,0 +1,51 @@
+---
+description: Generate Mermaid diagrams from your codebase
+argument-hint: [architecture | dependency | sequence | er | dataflow | component name or feature]
+author: "@markoradak"
+---
+
+# Generate Diagrams
+
+I'll analyze your codebase and generate Mermaid diagrams that visualize architecture, dependencies, data flow, and more.
+
+> **When to use**: You need visual documentation — architecture overviews, dependency graphs, sequence diagrams, ER diagrams, or data flow maps. Use `/explain` when you want a text walkthrough of how something works. Use `/docs architecture` for a full architecture document with diagrams embedded.
+
+## Current Context
+
+**Working Directory**: !`pwd`
+
+**Project**:
+!`cat package.json 2>/dev/null | head -10 || cat Cargo.toml 2>/dev/null | head -10 || cat pyproject.toml 2>/dev/null | head -10 || cat go.mod 2>/dev/null | head -5`
+
+**Structure**:
+!`ls -la src/ 2>/dev/null | head -20 || ls -la lib/ 2>/dev/null | head -20 || ls -la app/ 2>/dev/null | head -20 || ls -la`
+
+**Existing Docs**:
+!`ls docs/ 2>/dev/null | head -10; ls *.md 2>/dev/null | head -5`
+
+---
+
+## Diagram Target
+
+$ARGUMENTS
+
+---
+
+## Launching Diagram Agent
+
+The diagram agent will:
+1. **Analyze the codebase** — Trace imports, exports, routes, models, and data flow
+2. **Choose the right diagram type(s)** based on what's requested and what's useful
+3. **Generate Mermaid syntax** — Renderable on GitHub, VS Code, Notion, and most markdown tools
+4. **Write to file** — Saves diagrams as `.md` files (or appends to existing docs)
+
+**Diagram types**:
+- `architecture` — High-level system overview (components, layers, boundaries)
+- `dependency` — Module/package dependency graph (imports, who depends on whom)
+- `sequence` — Request/event flow through the system (step-by-step interactions)
+- `er` — Entity-relationship diagram (database models, types, relationships)
+- `dataflow` — How data moves through the system (input → transform → output)
+- `[feature or component]` — Auto-detect the best diagram type for the subject
+- No arguments — Survey the project and generate the most useful overview diagram
+
+Use the Task tool to launch the diagram agent (subagent_type="diagram") with the target and any additional context.

package/content/commands/history.md

@@ -0,0 +1,72 @@
+---
+description: Tell the narrative story of a file or function through its git history
+argument-hint: <file path> [optional: :function or symbol name]
+author: "@markoradak"
+---
+
+# File History
+
+Investigating the history of: **$ARGUMENTS**
+
+> **When to use**: You want to understand how a file evolved over time — who created it, what major changes shaped it, and whether it's a hot spot or stable code.
+
+## Context
+
+**Working Directory**: !`pwd`
+
+**File Exists**: !`test -f "$ARGUMENTS" && echo "Yes" || echo "File not found — check the path"`
+
+**File Size**: !`wc -l < "$ARGUMENTS" 2>/dev/null || echo "N/A"`
+
+## Git History
+
+**Full Log (following renames)**:
+!`git log --follow --format="%h|%an|%ar|%s" -- "$ARGUMENTS" 2>/dev/null || echo "No git history available"`
+
+**File Creation**:
+!`git log --follow --diff-filter=A --format="%h %an (%ar): %s" -- "$ARGUMENTS" 2>/dev/null || echo "Unable to determine creation"`
+
+**Contributors**:
+!`git log --follow --format="%an" -- "$ARGUMENTS" 2>/dev/null | sort | uniq -c | sort -rn || echo "N/A"`
+
+**Recent Activity (last 30 days)**:
+!`git log --since="30 days ago" --follow --format="%h %s (%ar)" -- "$ARGUMENTS" 2>/dev/null || echo "No recent changes"`
+
+**Change Frequency**:
+!`echo "Total commits: $(git log --follow --oneline -- "$ARGUMENTS" 2>/dev/null | wc -l | tr -d ' ')"`
+
+---
+
+## Instructions
+
+Using the git history data above, tell the story of this file as a narrative. Don't just list commits — interpret the history.
+
+### 1. Origin
+
+When was the file created, by whom, and why? Use the creation commit message and context to explain what purpose it originally served.
+
+### 2. Evolution
+
+Group commits into phases or themes. For example:
+- "Initial implementation" (first few commits)
+- "Feature expansion" (when significant functionality was added)
+- "Refactoring" (structural changes without new features)
+- "Bug fixes" (corrections and patches)
+
+Summarize each phase in 1-2 sentences rather than listing individual commits.
+
+### 3. Key Contributors
+
+Who has shaped this file the most? Mention the top 2-3 contributors and what kind of work each contributed.
+
+### 4. Current State
+
+- **Activity level** — Is this file actively changing or has it stabilized?
+- **Hot spot or stable?** — High commit frequency = hot spot (may need attention). Low frequency = stable (likely reliable).
+- **Size context** — Is the file large enough to consider splitting?
+
+### 5. Function Focus (if specified)
+
+If `$ARGUMENTS` includes a `:function` or symbol name after the file path, narrow the story to just that symbol. Use `git log -p` mentally to focus on commits that touched that specific function.
+
+**This is read-only. Do not modify any files.**

package/content/commands/i18n.md

@@ -0,0 +1,53 @@
+---
+description: Audit and set up internationalization for your project
+argument-hint: [optional: audit | setup | extract | add-locale <locale> | file path or component]
+author: "@markoradak"
+---
+
+# Internationalization
+
+I'll audit your project's internationalization readiness, extract hardcoded strings, and set up or improve your i18n infrastructure.
+
+> **When to use**: You want to make your project multilingual — extracting hardcoded strings, setting up i18n libraries, adding new locales, or auditing existing translations for completeness. Use `/a11y` for accessibility issues, or `/docs` for general documentation.
+
+## Current Context
+
+**Working Directory**: !`pwd`
+
+**Project**:
+!`cat package.json 2>/dev/null | head -15`
+
+**Existing i18n Setup**:
+!`cat package.json 2>/dev/null | grep -i "i18n\|intl\|locale\|next-intl\|react-intl\|react-i18next\|i18next\|vue-i18n\|@formatjs\|lingui\|messageformat\|rosetta\|typesafe-i18n\|paraglide" || echo "No i18n dependencies detected"`
+!`ls -d **/locales/ **/translations/ **/i18n/ **/lang/ **/messages/ src/i18n* src/locales* public/locales* 2>/dev/null || echo "No i18n directories found"`
+!`ls i18n.config* i18next.config* next-i18next.config* lingui.config* 2>/dev/null || echo "No i18n config files found"`
+
+**Frontend Files**:
+!`find src/ app/ pages/ components/ -name "*.tsx" -o -name "*.jsx" -o -name "*.vue" -o -name "*.svelte" 2>/dev/null | wc -l`
+
+---
+
+## i18n Scope
+
+$ARGUMENTS
+
+---
+
+## Launching i18n Agent
+
+The i18n agent will:
+1. **Detect existing i18n setup** — libraries, configs, locale files, translation patterns
+2. **Audit** — Find hardcoded strings, missing translations, inconsistent patterns
+3. **Report findings** with file:line references and proposed fixes
+4. **After confirmation** — Extract strings, create translation keys, set up infrastructure
+5. **Validate** after every change
+
+**Workflows**:
+- No argument → Full audit of i18n readiness + recommendations
+- `audit` → Scan for hardcoded strings and missing translations
+- `setup` → Set up i18n from scratch (detect framework, install library, create config)
+- `extract` → Extract hardcoded strings and replace with translation keys
+- `add-locale <locale>` → Add a new locale with translation stubs
+- `[file or component]` → Focused audit and extraction on specific files
+
+Use the Task tool to launch the i18n agent (subagent_type="i18n") with the scope and any additional context.

package/content/commands/implement.md

@@ -31,7 +31,8 @@ Launching the **implement agent** which will work independently in a separate co
 
 ### What the Agent Will Do
 
-- ✅ Load `{{PLANS_DIR}}/PLAN_{NAME}.md`
+- ✅ Load `{{PLANS_DIR}}/PLAN_{NN}_{NAME}.md`
+- ✅ Check `{{TASKS_DIR}}/references/` for design references (images, mockups, wireframes)
 - ✅ Parse all phases, tasks, and dependencies
 - ✅ Create comprehensive task tracking (TodoWrite)
 - ✅ Execute tasks systematically with validation
@@ -40,6 +41,7 @@ Launching the **implement agent** which will work independently in a separate co
 - ✅ Validate each phase before proceeding
 - ✅ Handle blockers (will pause and report)
 - ✅ Adapt plan if better approaches discovered
+- ✅ Run DRY checks after each phase to extract shared patterns
 - ✅ Return comprehensive summary when complete
 
 ### What You'll See

package/content/commands/kickoff.md

@@ -36,11 +36,12 @@ I'll work through this plan collaboratively with you:
 
 1. **Load & Review**: I'll load the plan and show you a summary
 2. **Environment Check**: Verify git status and project state
-3. **Task Tracking**: Set up TodoWrite for all plan tasks
-4. **Step-by-Step**: Execute tasks one at a time with your input
-5. **Validation**: Run type checks and lints after each task
-6. **Phase Approval**: Ask before moving between phases
-7. **Adapt Together**: Discuss blockers and adjustments as we go
+3. **Convention Discovery**: Scan the codebase for established patterns (error handling, styling, state management, data fetching, test infrastructure) and share findings so we're aligned on which patterns to follow. Look at how existing code is structured — never add inline styles unless absolutely necessary, always use the project's established styling method
+4. **Task Tracking**: Set up TodoWrite for all plan tasks
+5. **Step-by-Step**: Execute tasks one at a time with your input
+6. **Validation**: Run type checks and lints after each task
+7. **Phase Approval**: Ask before moving between phases
+8. **Adapt Together**: Discuss blockers and adjustments as we go
 
 ### Your Role
 
@@ -51,18 +52,27 @@ I'll work through this plan collaboratively with you:
 
 **This is collaborative implementation in the main conversation.**
 
+### Specialist Agents
+
+For tasks involving landing page / marketing page / homepage design, I'll suggest using the **showcase agent** (`/showcase`) which specializes in high-end page design with animations and micro-interactions. You can approve or override this.
+
 ---
 
 Now let me load the plan and we'll get started together.
 
-Use Read to load `{{PLANS_DIR}}/PLAN_{NAME}.md`, display a comprehensive summary with:
+**Before implementing**, scan the codebase for established conventions (error handling approach, styling method, state management, data fetching patterns, test infrastructure). Share the findings with the user so you're aligned on which patterns to follow throughout implementation. Use Grep/Glob to sample patterns — look for things like toast/notification usage, CSS module vs SCSS vs inline patterns, custom hooks, test frameworks, etc. Present a brief summary of discovered conventions before starting tasks.
+
+Use Read to load `{{PLANS_DIR}}/PLAN_{NN}_{NAME}.md`, display a comprehensive summary with:
 - Objective
 - Phases and task counts
 - Key files involved
 - Any open questions or risks
+- Reference files in `{{TASKS_DIR}}/references/` (if any exist — list them so the user knows what design context is available)
 
 Then ask: "Ready to start implementing? Which phase should we tackle first?"
 
 Use TodoWrite to create todos for all tasks from the plan once user confirms.
 
 Then begin executing tasks step-by-step, staying in the main context, validating as you go.
+
+After completing each phase, run `/dry` to check if any repeated patterns or duplicated code should be extracted into shared utilities, components, or constants. Fix any DRY violations before moving to the next phase.

package/content/commands/merge.md

@@ -0,0 +1,78 @@
+---
+description: Detect parent branch and merge the current branch into it
+author: "@markoradak"
+---
+
+# Merge into Parent Branch
+
+I'll detect which branch the current branch was created from, then merge into it.
+
+> **When to use**: You're done working on a feature branch and want to merge it back into the parent branch. This detects the parent automatically so you don't have to remember or type it.
+
+## Current State
+
+**Working Directory**: !`pwd`
+
+**Current Branch**: !`git branch --show-current 2>/dev/null || echo "Not a git repository"`
+
+**Status**:
+!`git status --short`
+
+**Uncommitted Changes**:
+!`git diff --stat`
+
+---
+
+## Steps
+
+### 1. Preflight checks
+
+- Verify we are in a git repository
+- Verify we are NOT on `main` or `master` (refuse to merge main into itself)
+- If there are uncommitted changes, warn the user and stop — they should commit or stash first
+
+### 2. Detect the parent branch
+
+Run:
+```
+git reflog show --format='%gs' <current-branch> | grep 'branch: Created from' | head -1
+```
+
+This extracts the reflog entry recorded when the branch was created (e.g. `branch: Created from main`). Parse the branch name from the end of that line.
+
+**Fallback** — if the reflog entry is missing (e.g. branch was fetched, not created locally):
+- Compare merge-base distances to `main` and `master`:
+  ```
+  git merge-base --is-ancestor main HEAD && echo main
+  git merge-base --is-ancestor master HEAD && echo master
+  ```
+- If neither works, ask the user to specify the parent branch manually.
+
+### 3. Confirm with the user
+
+Show:
+- Current branch name
+- Detected parent branch name
+- Summary of commits that will be merged: `git log --oneline <parent>..<current>`
+
+**Ask for explicit confirmation before proceeding.** Do NOT merge without user approval.
+
+### 4. Check out parent and pull latest
+
+```bash
+git checkout <parent>
+git pull
+```
+
+### 5. Merge the current branch
+
+```bash
+git merge <current-branch>
+```
+
+### 6. Report result
+
+- **Success**: Tell the user the merge completed. Show `git log --oneline -5` so they can see the result.
+- **Conflict**: Tell the user there are merge conflicts. Show `git diff --name-only --diff-filter=U` to list conflicted files. Do NOT attempt to resolve conflicts automatically — let the user decide how to handle them.
+
+**Do NOT push. Do NOT delete the feature branch.** Only merge locally. The user can push or clean up when ready.

package/content/commands/onboard.md

@@ -0,0 +1,54 @@
+---
+description: Generate a developer onboarding guide for this project
+argument-hint: [optional: focus area like "backend", "frontend", "api", or "contributing"]
+author: "@markoradak"
+---
+
+# Generate Onboarding Guide
+
+I'll analyze your project and generate a comprehensive onboarding guide for new developers.
+
+> **When to use**: You want to help new team members get up to speed on the project quickly. This is different from `/docs readme` (user-facing documentation) or `/explain` (understanding specific code). This generates a developer-oriented "survival guide" covering setup, architecture, patterns, conventions, and common tasks.
+
+## Current Context
+
+**Working Directory**: !`pwd`
+
+**Project**:
+!`cat package.json 2>/dev/null | head -15 || cat Cargo.toml 2>/dev/null | head -15 || cat pyproject.toml 2>/dev/null | head -15 || cat go.mod 2>/dev/null | head -5`
+
+**Structure**:
+!`ls -la`
+
+**Git Info**:
+!`git log --oneline -5 2>/dev/null; echo "---"; git branch -a 2>/dev/null | head -10`
+
+**Existing Docs**:
+!`ls README* CONTRIBUTING* CLAUDE.md docs/ 2>/dev/null | head -10`
+
+**Dev Scripts**:
+!`cat package.json 2>/dev/null | grep -A 20 '"scripts"' | head -25`
+
+---
+
+## Focus Area
+
+$ARGUMENTS
+
+---
+
+## Launching Onboard Agent
+
+The onboard agent will:
+1. **Deep-scan the project** — Structure, dependencies, patterns, conventions
+2. **Read existing documentation** — README, CONTRIBUTING, CLAUDE.md, inline docs
+3. **Identify key patterns** — How code is organized, named, and tested
+4. **Discover setup requirements** — Env vars, services, tools, config
+5. **Generate the guide** — A comprehensive ONBOARDING.md covering everything a new dev needs
+
+**Workflows**:
+- No argument → Full onboarding guide covering all aspects
+- `backend` / `frontend` / `api` → Focused guide for that area
+- `contributing` → Focus on contribution workflow, PR process, code standards
+
+Use the Task tool to launch the onboard agent (subagent_type="onboard") with any focus area and additional context.

package/content/commands/plan.md

@@ -25,7 +25,7 @@ $ARGUMENTS
 
 ## Generating Plan
 
-Launching the plan agent to analyze our conversation and generate `{{PLANS_DIR}}/PLAN_{NAME}.md`...
+Launching the plan agent to analyze our conversation and generate `{{PLANS_DIR}}/PLAN_{NN}_{NAME}.md`...
 
 The agent will:
 - ✅ Summarize key findings from our discussion
@@ -34,5 +34,6 @@ The agent will:
 - ✅ Break down tasks into actionable steps
 - ✅ Note technical considerations and constraints
 - ✅ List relevant files and references
+- ✅ Copy any reference files (images, videos, mockups) to `{{TASKS_DIR}}/references/` and link them in the plan so implementing agents can consume them
 
 Use the Task tool to launch the plan agent (subagent_type="plan") which will autonomously generate the plan document.

package/content/commands/release.md

@@ -0,0 +1,63 @@
+---
+description: Create a release — version bump, changelog, tag, and publish
+argument-hint: [optional: major | minor | patch | version number | --dry-run]
+author: "@markoradak"
+---
+
+# Release
+
+I'll orchestrate a complete release for your project — detecting existing release scripts and tooling first.
+
+> **When to use**: You're ready to cut a release. This handles version bumping, changelog updates, git tagging, and optionally GitHub Releases or publishing. Use `/changelog` if you only want to generate a changelog without releasing. Use `/commit` for a simple commit without release semantics.
+
+## Current State
+
+**Working Directory**: !`pwd`
+
+**Branch**: !`git branch --show-current 2>/dev/null || echo "Not a git repository"`
+
+**Status**:
+!`git status --short`
+
+**Current Version**:
+!`cat package.json 2>/dev/null | grep '"version"' | head -1 || cat Cargo.toml 2>/dev/null | grep '^version' | head -1 || cat pyproject.toml 2>/dev/null | grep '^version' | head -1 || echo "Could not detect version"`
+
+**Latest Tags**:
+!`git tag --sort=-version:refname 2>/dev/null | head -5 || echo "No tags found"`
+
+**Commits Since Last Tag**:
+!`git log $(git describe --tags --abbrev=0 2>/dev/null)..HEAD --oneline 2>/dev/null | head -15 || git log --oneline -10 2>/dev/null`
+
+**Release Scripts Detected**:
+!`cat package.json 2>/dev/null | grep -E '"(release|version|bump|publish|prepublish|postpublish|preversion|postversion|prepublishOnly)"' || echo "None in package.json"`
+!`ls .release-it.* .changeset/ .versionrc* lerna.json .releaserc* release.config.* 2>/dev/null || echo "No release tool configs found"`
+!`ls scripts/release* scripts/publish* scripts/version* Makefile 2>/dev/null || echo "No release scripts found"`
+
+---
+
+## Release Scope
+
+$ARGUMENTS
+
+---
+
+## Launching Release Agent
+
+The release agent will:
+1. **Detect existing release infrastructure** — scripts in package.json, release-it, changesets, semantic-release, standard-version, Makefile targets, scripts/ directory, CI workflows
+2. **If existing tooling found** — use it, guiding through any interactive steps
+3. **If no existing tooling** — orchestrate the release manually:
+   - Determine version bump from conventional commits (or use the specified version)
+   - Update CHANGELOG.md
+   - Bump version in manifest files
+   - Create git commit and tag
+   - Optionally create a GitHub Release
+4. **Confirm every destructive step** before executing
+
+**Workflows**:
+- No argument → Auto-detect version bump from commits (major/minor/patch)
+- `major` / `minor` / `patch` → Explicit bump type
+- `1.2.3` → Explicit version number
+- `--dry-run` → Show what would happen without making changes
+
+Use the Task tool to launch the release agent (subagent_type="release") with the scope and any additional context.

package/content/commands/research.md

@@ -18,27 +18,27 @@ $ARGUMENTS
 
 Analyze the query to determine the best research agent:
 
-**Use `codebase-research` agent when:**
+**Use `research-codebase` agent when:**
 - Query mentions "in this codebase", "how does X work here", "where is X implemented"
 - Looking for files, components, functions, or code patterns
 - Understanding architecture, structure, or current implementation
 - Keywords: "explore", "find in code", "how does our", "where is", "codebase structure"
 
-**Use `docs-research` agent when:**
+**Use `research-docs` agent when:**
 - Query mentions specific library/framework APIs (React, Next.js, Prisma, tRPC, etc.)
 - Looking for package documentation or how to use a dependency
 - Questions about official API references
 - Keywords: "library docs", "API reference", "how to use [library]", "documentation for"
 - Check package.json first to see if mentioned library is a project dependency
 
-**Use `web-research` agent when:**
+**Use `research-web` agent when:**
 - Query asks for "latest", "best practices", "how to do X"
 - Looking for online tutorials, guides, or examples
 - Researching industry standards or modern approaches
 - No specific library mentioned, or general "how to" questions
 - Keywords: "research online", "best practices", "modern approach", "latest", "tutorial"
 
-**Default to `codebase-research`** if the query is ambiguous and could apply to understanding existing code.
+**Default to `research-codebase`** if the query is ambiguous and could apply to understanding existing code.
 
 ---
 
@@ -46,9 +46,9 @@ Analyze the query to determine the best research agent:
 
 Based on the query above, determine which agent to use and launch it with the Task tool:
 
-- `subagent_type="codebase-research"` for codebase exploration
-- `subagent_type="docs-research"` for library documentation
-- `subagent_type="web-research"` for web searching
+- `subagent_type="research-codebase"` for codebase exploration
+- `subagent_type="research-docs"` for library documentation
+- `subagent_type="research-web"` for web searching
 
 Pass the full query as the prompt to the agent.
 

package/content/commands/showcase.md

@@ -0,0 +1,56 @@
+---
+description: Design an award-winning landing page with animations and micro-interactions
+argument-hint: [product/project name or description]
+author: "@markoradak"
+---
+
+# Showcase — Landing Page Design
+
+I'll design and build a high-end landing page with polished animations, micro-interactions, and visual craft worthy of an Awwwards feature.
+
+## Current Context
+
+**Working Directory**: !`pwd`
+
+**Project Detection**:
+!`ls package.json tsconfig.json next.config.* vite.config.* astro.config.* tailwind.config.* 2>/dev/null || echo "No recognized project files"`
+
+**Existing Pages**:
+!`find . -maxdepth 4 -type f \( -name "page.tsx" -o -name "page.jsx" -o -name "index.tsx" -o -name "index.jsx" -o -name "index.html" \) -not -path "*/node_modules/*" 2>/dev/null | head -10`
+
+**Reference Files** (images/videos provided):
+!`ls {{TASKS_DIR}}/references/ 2>/dev/null | head -10 || echo "No references found"`
+
+---
+
+## Project / Product
+
+$ARGUMENTS
+
+---
+
+## What This Does
+
+The showcase agent will design and build a complete, production-ready landing page with:
+
+- **Hero section** with striking visual impact and entrance animations
+- **Scroll-driven animations** — elements that reveal, parallax, and transform on scroll
+- **Micro-interactions** — hover states, button feedback, cursor effects, toggle animations
+- **Smooth transitions** — page sections that flow into each other seamlessly
+- **Typography craft** — deliberate type hierarchy, spacing, and rhythm
+- **Responsive design** — fluid layouts that feel intentional at every breakpoint
+- **Performance** — optimized animations that don't tank Core Web Vitals
+
+### Style Direction
+
+If reference images/videos were provided, the agent will extract the visual direction from them.
+
+If no references are provided, the agent will ask you to choose a style direction before designing.
+
+### How It Integrates
+
+- In `/autopilot` or `/implement` — if the plan includes a landing page task, the showcase agent is used instead of the generic implement agent for that task
+- In `/parallelize` — landing page work can be a dedicated stream using the showcase agent
+- Standalone — run `/showcase` directly to design a landing page from scratch or redesign an existing one
+
+Use the Task tool to launch the showcase agent (subagent_type="showcase") with the product/project context and any reference files.