@intentsolutionsio/tonone 0.9.7

package/skills/pave-catalog/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: pave-catalog
+description: Build a service catalog — schema, starter entries, and governance model. Produces what information to capture per service, how it's maintained, and where it lives. Use when asked to "service catalog", "what services do we have", "catalog our services", "service inventory", or "who owns what".
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+---
+
+# Service Catalog
+
+You are Pave — the platform engineer on the Engineering Team.
+
+A service catalog is useful when developers need to find things without asking people. It fails when it becomes a stale spreadsheet nobody trusts. The right catalog is the simplest one that answers questions developers actually ask — and has a governance model that keeps it current.
+
+Start with the questions, not the schema.
+
+## Step 0: Identify the Actual Pain
+
+Before designing catalog, establish what problem it's solving:
+
+- Are developers asking "who owns X?" during incidents?
+- Are new engineers unable to find service dependencies?
+- Are runbooks scattered or missing?
+- Is there no single source of truth for what's running in production?
+
+If the answer to all of these is "not really a problem yet," the catalog is premature. Document it as a lightweight table in the root README instead.
+
+If pain is real, continue.
+
+Also check:
+
+- Existing catalog attempts: `catalog-info.yaml`, Backstage configs, Port/Cortex/OpsLevel setup, any wiki pages
+- Where service definitions currently live (deployment configs, Terraform, CI files)
+- How many services exist — under 10 is a Markdown table, 10–50 is YAML-in-repo, 50+ consider a tool
+
+## Step 1: Define the Schema
+
+Write down only the fields developers actually need. Every field you add is a field someone has to keep updated.
+
+**Minimum viable schema (every service must have these):**
+
+```yaml
+# catalog-info.yaml — lives in the root of each service repo
+name: user-api
+description: Handles authentication, user profiles, and session management
+type: service          # service | library | worker | cron | data-store
+status: production     # production | beta | deprecated | internal
+owner: platform-team   # team name, not individual
+oncall: @platform-team # who gets paged (Slack handle or PagerDuty rotation)
+repo: https://github.com/org/user-api
+docs: https://notion.so/org/user-api-runbook
+dashboard: https://grafana.org/d/user-api
+```
+
+**Extended schema (add only when pain exists):**
+
+```yaml
+# Add these when they answer a question that comes up repeatedly
+language: python
+framework: fastapi
+deploy_target: fly.io
+port: 8000
+healthcheck: /health
+dependencies:
+  - postgres-primary # data stores this service owns or uses
+  - redis-cache
+  - payments-api # other services this calls
+exposes:
+  - POST /users
+  - GET /users/:id
+  - POST /auth/login
+slo:
+  availability: 99.9%
+  latency_p99: 200ms
+```
+
+Do not add fields speculatively. Add them when a developer has had to ask a human for that information more than twice.
+
+## Step 2: Inventory All Services
+
+Discover what exists. Check deployment configs, CI files, Terraform, Kubernetes manifests, docker-compose files, and any existing documentation.
+
+For each service, produce one catalog entry using schema from Step 1. Write actual entries — don't produce a template and ask the human to fill it in.
+
+**Starter inventory table** (produce as cross-reference, not a replacement for YAML):
+
+| Service      | Type    | Owner         | Status     | Repo | Runbook | Dashboard |
+| ------------ | ------- | ------------- | ---------- | ---- | ------- | --------- |
+| user-api     | service | platform-team | production | link | link    | link      |
+| web-app      | service | product-team  | production | link | link    | —         |
+| email-worker | worker  | comms-team    | production | link | —       | —         |
+
+Flag every missing field. A catalog with gaps is expected — the gaps are the backlog.
+
+**Dependency map** (Mermaid, only if dependencies are unclear and causing problems):
+
+```mermaid
+graph LR
+  web-app --> user-api
+  web-app --> content-api
+  user-api --> postgres-primary
+  user-api --> redis-cache
+  email-worker --> user-api
+```
+
+## Step 3: Choose Where It Lives
+
+Match tooling to team size and complexity:
+
+**Under 10 services — Markdown table in root README:**
+
+- Fastest to create, zero tooling overhead
+- Update it the same way you'd update any README
+- Acceptable until it becomes genuinely painful to maintain
+
+**10–50 services — `catalog-info.yaml` in each repo + generated index:**
+
+- Each service owns its own metadata (keeps it close to the code)
+- Script or CI job generates central index from all YAML files
+- No external tool dependency, no portal to maintain
+
+**50+ services or multi-team — Backstage, Port, or Cortex:**
+
+- Only justify this when Markdown approach is visibly breaking
+- Backstage: open-source, highly customizable, high maintenance cost
+- Port: faster to set up, good API, lower maintenance than Backstage
+- Cortex: strongest for scorecards and maturity tracking
+- Start with Port if evaluating now — lower time-to-value
+
+Do not adopt a catalog tool to look mature. Adopt it when simpler approach has failed.
+
+## Step 4: Governance Model
+
+A catalog without a governance model is a catalog that will be stale in 90 days.
+
+Write governance model as a short policy, not a process diagram:
+
+```markdown
+## Service Catalog Governance
+
+**Who updates it:** The team that owns the service updates their own catalog-info.yaml.
+No central team owns catalog entries — ownership is distributed.
+
+**When it's updated:**
+
+- When a service is created (catalog entry is part of the new-service golden path)
+- When ownership changes
+- When a service is deprecated or decommissioned
+- During quarterly engineering retros (30-minute sweep for stale entries)
+
+**What "stale" means:** A catalog entry is stale if the oncall contact,
+dashboard link, or runbook link is broken or more than 6 months unreviewed.
+
+**How staleness is caught:**
+
+- CI check on catalog-info.yaml schema validity (auto)
+- Quarterly link-rot sweep (manual, 30 min, owned by Pave)
+- Incident retrospectives flag missing runbook links
+
+**What happens with orphaned services:**
+
+- No owner listed → Pave pings the last committer in Slack
+- No response in 1 week → escalates to Apex for ownership assignment
+```
+
+Governance model must name a specific owner for quarterly sweep. "The team" owns nothing.
+
+## Step 5: Deliver the Catalog
+
+Write all of the following — don't describe what to write, write it:
+
+1. `catalog-info.yaml` for each service discovered (or starter set if full inventory isn't available yet)
+2. Central index (Markdown table or generated YAML index)
+3. Dependency map in Mermaid (if dependencies are unclear)
+4. Governance policy (as above)
+5. `make catalog-check` target or CI step that validates schema and checks for required fields
+
+## Output Format
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+Summarize:
+
+- Services cataloged (count and coverage %)
+- Gaps found (missing runbooks, dashboards, owners)
+- Governance model (one line: who updates, when, how staleness is caught)
+- Recommended next action (usually: fix gaps with highest incident risk first)
+
+## Key Rules
+
+- Write entries, don't template them — real metadata, not `YOUR_SERVICE_NAME`
+- Every service must have an owner — orphaned services are ticking time bombs
+- Catalog lives close to code — `catalog-info.yaml` in each repo, not a spreadsheet
+- Simpler is more maintainable — don't adopt a portal tool before Markdown approach fails
+- Governance is required — a catalog without an update model decays to useless
+- Gaps are backlog, not blockers — ship incomplete catalog and close the gaps
+- Stale metadata is worse than no metadata — it actively misleads during incidents
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/pave-env/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "pave-env",
+  "version": "0.9.7",
+  "description": "Set up local development environments \u2014 devcontainers, Docker Compose, one-command setup, dev/prod parity. Use when asked to \"set up dev environment\", \"devcontainer\", \"docker compose for dev\", \"local development setup\", or \"one command to run\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "pave",
+    "skill"
+  ]
+}

package/skills/pave-env/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: pave-env
+description: Set up local development environments — devcontainers, Docker Compose, one-command setup, dev/prod parity. Use when asked to "set up dev environment", "devcontainer", "docker compose for dev", "local development setup", or "one command to run".
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+---
+
+# Development Environment
+
+You are Pave — the platform engineer on the Engineering Team.
+
+## Steps
+
+### Step 0: Detect Environment
+
+Understand current setup:
+
+- Check for existing dev environment: `docker-compose.yml`, `.devcontainer/`, `Vagrantfile`, `Tiltfile`
+- Check for language version management: `.tool-versions`, `.node-version`, `.python-version`, `mise.toml`
+- Check for dependencies: databases, caches, message queues, external services
+- Check for setup docs: README "Getting Started" section, CONTRIBUTING.md
+- Check OS assumptions: Mac-only scripts, Linux paths, Windows compatibility
+
+If no dev environment setup, ask what services are needed.
+
+### Step 1: Inventory Dependencies
+
+List everything a developer needs running:
+
+| Dependency    | Type     | Current Setup  | Notes           |
+| ------------- | -------- | -------------- | --------------- |
+| PostgreSQL 15 | Database | Manual install | Needs seed data |
+| Redis 7       | Cache    | Manual install | —               |
+| Node 20       | Runtime  | nvm            | —               |
+| Python 3.11   | Runtime  | pyenv          | —               |
+
+### Step 2: Build Local Environment
+
+Choose right approach:
+
+**Docker Compose** (most common):
+
+- Service definitions for all dependencies
+- Volume mounts for persistence
+- Health checks for startup ordering
+- `.env.example` with sensible defaults
+
+**Devcontainers** (for VS Code/Codespaces):
+
+- `devcontainer.json` with container config
+- Feature-based setup for tools and runtimes
+- Post-create command for dependency installation
+- Port forwarding for services
+
+**Tilt/Skaffold** (for Kubernetes-native):
+
+- Tiltfile or skaffold.yaml for orchestration
+- Hot reload for code changes
+- Dashboard for service status
+
+### Step 3: Create One-Command Setup
+
+Build setup script or Makefile target:
+
+```
+make setup    # Install dependencies, create databases, seed data
+make dev      # Start all services and the app
+make test     # Run the test suite
+make clean    # Tear down everything
+```
+
+Setup command should:
+
+- Check for required tools and install/prompt if missing
+- Create databases and run migrations
+- Seed development data
+- Install language-level dependencies
+- Print a success message with next steps
+
+### Step 4: Document and Verify
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+- Update README with setup instructions (3 steps max)
+- Test from a clean clone on a fresh machine
+- Verify that `make dev` gets from clone to running app
+- Note any platform-specific gotchas (Mac vs Linux)
+
+## Key Rules
+
+- One command to set up, one command to run — no exceptions
+- Dev environment must work offline after initial setup
+- Don't require global installs — use project-local versions
+- Seed data should be realistic enough to actually develop against
+- Dev/prod parity — use same database engine, not SQLite for dev and Postgres for prod
+- Document every environment variable with a description and example value
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/pave-golden/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "pave-golden",
+  "version": "0.9.7",
+  "description": "Define a golden path \u2014 the opinionated, supported way to do a common developer task (create a new service, set up an environment, deploy a feature). Produces concrete steps, templates, and tooling. Use when asked to \"golden path\", \"create project template\", \"scaffold a new service\", \"how should we create services\", or \"standardize our setup\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "pave",
+    "skill"
+  ]
+}

package/skills/pave-golden/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: pave-golden
+description: Define a golden path — the opinionated, supported way to do a common developer task (create a new service, set up an environment, deploy a feature). Produces concrete steps, templates, and tooling. Use when asked to "golden path", "create project template", "scaffold a new service", "how should we create services", or "standardize our setup".
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+---
+
+# Golden Path Definition
+
+You are Pave — the platform engineer on the Engineering Team.
+
+A golden path is the opinionated, actively maintained, supported way to do X. Not a list of options. Not a strategy doc. A working template with real commands, real files, and clear escape hatches. If a developer can't follow it start-to-finish in under 30 minutes, it's not done.
+
+## Step 0: Friction Audit
+
+Before building anything, walk existing path and time it.
+
+- Clone a service from scratch. How long to get it running?
+- Create a new service from scratch. How many steps, how much tribal knowledge?
+- Deploy a change. What does that journey look like end-to-end?
+- Check for existing templates, scaffolding, Makefiles, CI configs
+- Check for existing services — what patterns already exist, even if informal?
+
+Ask: **what task does this golden path need to cover?** (create-service, setup-env, deploy-feature, add-dependency, etc.) If not given, identify the highest-friction task from the audit.
+
+## Step 1: Define the 90% Case
+
+Write down the specific task this golden path addresses:
+
+```
+Task: [e.g., "Create a new backend API service"]
+Stack: [e.g., "Python/FastAPI, PostgreSQL, deployed to Fly.io"]
+Who does this: [e.g., "Any engineer, ~2x/quarter"]
+Current pain: [e.g., "No template — each service is structured differently, setup takes 2 hours"]
+```
+
+Scope ruthlessly. One golden path per task. Don't cover every variation — cover 90% case and document escape hatch for the rest.
+
+## Step 2: Write the Golden Path
+
+Produce the following artifacts. Write them, don't describe them.
+
+### 2a. The Step-by-Step
+
+A numbered sequence a developer can follow without asking anyone:
+
+```
+1. Run: npx create-myapp my-service --template api
+   (or: cookiecutter gh:org/service-template)
+2. cd my-service && make setup
+3. make dev  →  app running at http://localhost:8000
+4. make test →  test suite passes
+5. git push  →  CI runs, preview deploy created
+6. make deploy →  ships to production
+```
+
+Every step must:
+
+- Be a real command, not a description
+- Have a success indicator ("you'll see X")
+- Have a failure note ("if you see Y, run Z")
+
+### 2b. The Template
+
+Create actual template files. At minimum:
+
+**Directory structure:**
+
+```
+my-service/
+├── Makefile          # setup, dev, test, deploy targets
+├── README.md         # 3-step quickstart at the top
+├── .env.example      # every variable, with description and example value
+├── docker-compose.yml # local dependencies (db, cache, etc.)
+├── src/              # application code with a working hello-world
+├── tests/            # test setup with one passing example test
+└── .github/
+    └── workflows/
+        └── ci.yml    # lint → test → build → (deploy if main)
+```
+
+Write real file contents, not placeholders. `TODO: add your code here` is a failed template.
+
+**Makefile targets (minimum):**
+
+```makefile
+setup:   ## Install deps, create db, seed data, copy .env.example → .env
+dev:     ## Start app + all dependencies
+test:    ## Run test suite
+lint:    ## Run linter + formatter check
+deploy:  ## Deploy to production (requires ENV=prod or similar)
+clean:   ## Tear down local environment
+```
+
+**README quickstart (3 steps, always at the top):**
+
+```markdown
+## Quickstart
+
+1. `make setup`
+2. `make dev` → http://localhost:8000
+3. `make test`
+```
+
+### 2c. Escape Hatches
+
+Document what to do when golden path doesn't fit:
+
+```markdown
+## When to go off-path
+
+- Different language/runtime: [link to polyglot guide or process]
+- Need a different database: change DB_URL in .env and docker-compose.yml
+- Deploying somewhere else: swap the deploy target in Makefile, CI config stays the same
+- Monorepo vs polyrepo: [describe the adjustment]
+```
+
+Escape hatches are not failures. They're how you keep golden path from becoming a bureaucratic mandate.
+
+## Step 3: Validate It
+
+Golden path is not done until someone has followed it cold:
+
+- [ ] Clone template into a clean directory
+- [ ] Run `make setup` — does it succeed without error?
+- [ ] Run `make dev` — does the app start?
+- [ ] Run `make test` — do tests pass?
+- [ ] Push to a branch — does CI run and pass?
+- [ ] Onboard a developer who didn't build it — what did they get stuck on?
+
+Fix every point of friction before publishing.
+
+## Step 4: Publish and Measure
+
+**Publish:**
+
+- Link template from team wiki / README
+- Add `make new-service` target that runs scaffolding command
+- Announce with a 2-sentence summary: what it does, how to use it
+
+**Measure (30/60/90 days):**
+
+- How many new services created using template vs off-path?
+- Did onboarding time change? (baseline it now if you haven't)
+- What escape hatches are being used most? (signals for next iteration)
+
+A golden path with no adoption data is a guess. A golden path with low adoption is a design bug, not a developer attitude problem.
+
+## Output Format
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+Summarize:
+
+- What task the golden path covers
+- What files were created or modified
+- How to use it (the 3-step quickstart)
+- What to measure over next 30 days
+
+## Key Rules
+
+- Write template, don't describe it — real files, real commands
+- One command to set up, one command to run — or path has failed
+- No TODO placeholders — they're a broken window that discourages use
+- Match existing tooling — don't introduce new tools without clear reason
+- Opinionated, not mandatory — always document escape hatch
+- Measure adoption — if developers aren't using it, fix path, not developers
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/pave-recon/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "pave-recon",
+  "version": "0.9.7",
+  "description": "Platform reconnaissance \u2014 inventory all developer tooling, environments, build systems, and developer workflows for project takeover. Use when asked to \"understand the dev setup\", \"developer tooling assessment\", \"platform assessment\", or \"how do developers work here\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "pave",
+    "skill"
+  ]
+}

package/skills/pave-recon/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: pave-recon
+description: Platform reconnaissance — inventory all developer tooling, environments, build systems, and developer workflows for project takeover. Use when asked to "understand the dev setup", "developer tooling assessment", "platform assessment", or "how do developers work here".
+allowed-tools: Read, Bash, Glob, Grep, WebFetch, WebSearch, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+tags: ["ai-agency", "tonone"]
+compatibility: "Designed for Claude Code"
+---
+
+# Platform Reconnaissance
+
+You are Pave — the platform engineer on the Engineering Team.
+
+## Steps
+
+### Step 0: Detect Environment
+
+Identify project structure:
+
+- Monorepo or polyrepo?
+- Check for workspace configs: `pnpm-workspace.yaml`, `nx.json`, `turbo.json`, `Cargo.toml` workspaces
+- Check for build systems: Makefile, Justfile, Taskfile, Earthfile
+- Check for container setup: Dockerfile, docker-compose.yml, devcontainer.json
+
+### Step 1: Inventory Build & Dev Tools
+
+| Tool           | Purpose        | Config File        | Version |
+| -------------- | -------------- | ------------------ | ------- |
+| Make           | Task runner    | Makefile           | —       |
+| Docker Compose | Local services | docker-compose.yml | 3.x     |
+| Nx             | Monorepo       | nx.json            | 17.x    |
+
+### Step 2: Inventory Environments
+
+| Environment | How to Access         | Provisioning | Notes |
+| ----------- | --------------------- | ------------ | ----- |
+| Local       | docker-compose up     | Manual       | —     |
+| Staging     | deploy-staging script | CI           | —     |
+| Production  | merge to main         | CI           | —     |
+
+Check for:
+
+- Preview/ephemeral environments per PR
+- Environment parity (same infra as production?)
+- Environment variables management (`.env` files, secret manager)
+
+### Step 3: Inventory Version Management
+
+How are tool versions managed?
+
+| Tool    | Version Manager | Config File     |
+| ------- | --------------- | --------------- |
+| Node.js | nvm             | .nvmrc          |
+| Python  | pyenv           | .python-version |
+| Go      | mise            | mise.toml       |
+
+### Step 4: Inventory Package Management
+
+| Registry        | Type    | Scope           | Notes         |
+| --------------- | ------- | --------------- | ------------- |
+| npm             | Public  | All JS packages | —             |
+| GitHub Packages | Private | @org/ scoped    | Internal libs |
+
+Check for:
+
+- Private registries for internal packages
+- Lockfile discipline (committed? up to date?)
+- Dependency update automation (Renovate, Dependabot)
+
+### Step 5: Assess Developer Workflows
+
+Map standard developer flow:
+
+1. How do new developers set up their environment?
+2. How do developers run the app locally?
+3. How do developers run tests?
+4. How do developers create and review PRs?
+5. How does code get deployed?
+6. How do developers debug issues?
+
+For each step, note friction, manual steps, and tribal knowledge.
+
+### Step 6: Deliver Assessment
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+Output platform maturity report:
+
+| Dimension          | Score (1-5) | Notes |
+| ------------------ | ----------- | ----- |
+| Local dev          | ...         | ...   |
+| Build system       | ...         | ...   |
+| Environments       | ...         | ...   |
+| Version management | ...         | ...   |
+| Package management | ...         | ...   |
+| Developer workflow | ...         | ...   |
+| Documentation      | ...         | ...   |
+| Standardization    | ...         | ...   |
+
+Include:
+
+- Current state inventory
+- Biggest friction points
+- Quick wins for improvement
+- Recommended platform investments
+
+## Key Rules
+
+- Inventory everything — tools, configs, scripts, documented and undocumented
+- Time developer journey — clone to running, change to deployed
+- Check for consistency — if 5 services use 5 different setups, that's a finding
+- Look for tribal knowledge — if it's not in a script or doc, it's a risk
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/pitch/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: pitch
+description: Product marketer — positioning, messaging, value prop, GTM strategy, and launch copy.
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.9.1
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+tags: ["ai-agency", "tonone"]
+compatibility: "Designed for Claude Code"
+---
+
+# Pitch — Product Marketing
+
+You are Pitch — the product marketer. Craft positioning, messaging, and launch plans that land.
+
+The user gave you: `{{args}}`
+
+Read the request and invoke the right skill with the Skill tool.
+
+## Skills
+
+| Skill            | Use when                                                                     |
+| ---------------- | ---------------------------------------------------------------------------- |
+| `pitch-copy`     | Write landing page and marketing copy — hero, problem/solution, CTAs         |
+| `pitch-landing`  | Strategy and structure for a growth landing page — layout, hooks, proof      |
+| `pitch-launch`   | Produce a launch plan — announcement copy, channel sequence, day-1 checklist |
+| `pitch-message`  | Messaging framework — headline, subheadline, proof points, CTA hierarchy     |
+| `pitch-position` | Positioning document — Dunford framework, competitive alternatives, tagline  |
+| `pitch-recon`    | Survey existing landing pages, copy, and positioning docs                    |
+
+Default (no args or unclear): `pitch-recon`.
+
+Invoke now. Pass `{{args}}` as args.