axel-setup 0.2.0

package/commands/create-pr.md

@@ -0,0 +1,13 @@
+# Create a Pull Request
+
+- Check that I'm in a branch other than `main`, `staging`, or `prod`. If not, bail and explain.
+- Run `git status` to see all changes
+- If there's unstaged or staged work that hasn't been committed, commit all relevant code first
+  - Follow commit format: `<tipo> (Modelo/Archivo): Mensaje descriptivo`
+  - Max 6 files per commit, grouped by model/functionality
+- Use `gh pr create` to open a PR with:
+  - Title: `<feature_area>: <Title>` (80 chars or less)
+  - Body: TLDR (2 sentences max) + 1-3 bullet points explaining what's changing
+- Always paste the PR link in the response
+- Prepend `GIT_EDITOR=true` to git commands to avoid blocking
+- **NEVER use `--no-verify`**

package/commands/daily.md

@@ -0,0 +1,182 @@
+# Daily — Morning Check-in
+
+Scan rápido de todo lo que pasó desde el último check. Read-only, no escribe en ningún sistema. Diseñado para arrancar el día en ~2 minutos sabiendo qué pasó y qué necesita atención.
+
+## Configuration (edit this section for your team)
+
+Este skill es genérico. Antes de usarlo, edita la sección siguiente con los canales, personas y repositorios de tu equipo. Todo lo marcado como `[OPTIONAL]` puede desactivarse borrando la sección entera si tu equipo no usa ese sistema.
+
+```yaml
+# --- Slack channels to scan (add/remove as needed) ---
+slack_channels:
+  - name: "#incidents"    # id: Cxxxxxxx
+  - name: "#clients"      # id: Cxxxxxxx
+  - name: "#tech-guild"   # id: Cxxxxxxx
+
+# --- Slack DMs to scan (privacy gate applies) ---
+slack_dms:
+  - name: "PM/CEO"        # id: Uxxxxxxx
+  - name: "CS Lead"       # id: Uxxxxxxx
+
+# --- Git repos to scan for PR/commit activity ---
+git_repos:
+  - ~/your-org/api-repo
+  - ~/your-org/frontend-repo
+
+# --- Team member git-email → display-name mapping ---
+team_members:
+  - { email: "you@company.com", name: "You" }
+  - { email: "teammate@company.com", name: "Teammate" }
+
+# --- Optional integrations (delete sections you don't use) ---
+integrations:
+  linear: true            # requires Linear MCP
+  google_calendar: true   # requires Google Calendar MCP
+  gmail: true             # requires Gmail MCP
+  intercom: false         # [OPTIONAL] requires Intercom MCP — client conversations
+  notion: false           # [OPTIONAL] requires Notion MCP
+```
+
+**How to customize:** open this file (`~/.claude/commands/daily.md`) and edit the YAML block above. The rest of the skill reads from it. Any section whose integration is `false` or whose MCP is not connected is skipped gracefully.
+
+## Data sources (all read-only, all in parallel)
+
+Launch all configured sources concurrently. Skip any section whose integration is `false` or whose MCP is not connected.
+
+### Slack (last 24h or since last check, whichever is longer)
+For each channel in `slack_channels`:
+- New messages, threads without reply, threads needing your attention
+- Highlight messages from team members that require action
+
+For each DM in `slack_dms`:
+- Asks pendientes, confirmations, context **work-only** (privacy gate — see Rules below)
+
+### Git (all repos in `git_repos`)
+- `git fetch origin --prune` in each repo
+- PRs merged since last check (`gh pr list --state merged --search "merged:>=DATE"`)
+- PRs opened/updated by anyone (`gh pr list --state open`)
+- New branches pushed
+
+### Linear (if `integrations.linear`)
+- Issues updated since last check
+- New issues created
+- Issues moved to Done (celebrate!)
+- Issues assigned to you still in Todo (nudge)
+
+### Google Calendar (if `integrations.google_calendar`)
+- Today's events with time, title, and meeting link
+- Use `gcal_list_events` for the user's primary calendar, filtered to today
+
+### Gmail (if `integrations.gmail`)
+- Unread or recent emails from the last 24h that are work-relevant
+- Use `gmail_search_messages` with query like `is:unread newer_than:1d`
+- Focus on: emails from clients, from team members, from external services
+- Skip: newsletters, marketing, automated non-actionable notifications
+- For each relevant email: sender, subject, 1-line summary of what it needs
+
+### Intercom `[OPTIONAL]` (if `integrations.intercom`)
+- When a team uses Intercom, it's typically the canonical source for client conversations; internal Slack channels are usually just a mirror of notifications.
+- Last 24h conversations needing attention:
+  - Open + unread
+  - Priority flagged
+  - Conversations with a new customer reply pending a response
+- Tool: `mcp__intercom__search_conversations` with filter `updated_at` last 24h + `state=open`
+- For each relevant conversation: contact name, company, last message, state, 1-line summary
+- **Cross-ref with Slack:** if a conversation also appears forwarded into a Slack client channel, link both (Slack permalink + Intercom URL)
+
+### Notion `[OPTIONAL]` (if `integrations.notion`)
+- Skim relevant pages/databases the team uses as a read-only reference (roadmap, backlog, specs)
+- Never write from `/daily`
+
+## Privacy gate
+DMs pass through a work-vs-personal classifier. Personal content is dropped silently — never logged, quoted, or mentioned. Only work-relevant asks surface.
+
+## Output format
+
+```
+## Buenos días — [fecha] [día de la semana]
+
+### 📅 Agenda de hoy
+- HH:MM — [título] ([link])
+- (sin reuniones hoy ✨)
+
+### 📧 Emails relevantes (últimas 24h)
+- [sender] — [subject] — [acción necesaria o "solo FYI"]
+- (sin emails relevantes pendientes ✨)
+
+### 📬 Intercom — conversations activas   [OPTIONAL section, omit if disabled]
+- [contact — company] — [state] — [acción sugerida o "solo monitoreo"]
+- Cross-ref Slack: [permalink if applicable]
+- (sin conversations que requieran atención ✨)
+
+### 🆕 Qué pasó mientras no estabas
+Bullets cortos por canal/fuente, solo lo que requiere tu atención:
+- [#channel-1]: [resumen o "sin nuevos"]
+- [#channel-2]: [resumen o "sin nuevos"]
+- DM [person]: [resumen work-only o "sin novedades"]
+- Git: [N PRs merged, N PRs opened, branches nuevas relevantes]
+- Linear: [N issues movidas, N nuevas]
+
+### 🔔 Necesita tu respuesta/acción
+Lista priorizada de threads, PRs, asks que esperan algo de ti:
+1. [canal/fuente] — [qué] — [acción sugerida]
+2. ...
+(si no hay nada: "Inbox limpio 🟢")
+
+### 🔴 Stoppers activos
+- [ISSUE-ID] — razón — días frenado
+(si no hay: "Sin stoppers 🟢")
+
+### 🎯 Foco sugerido para hoy
+Top 3 acciones de mayor leverage basadas en lo detectado arriba.
+1. [acción concreta]
+2. [acción concreta]
+3. [acción concreta]
+```
+
+## Phase 2 — Sync systems (after showing the briefing)
+
+After presenting the morning briefing to the user, propose system updates detected during the scan. Wait for user confirmation before executing.
+
+### What to detect and propose:
+
+**Linear updates** (if enabled):
+- Issues that should move to Done based on git evidence (PR merged to main but Linear still says In Progress/In Review)
+- New items detected in Slack channels without a Linear issue yet → propose CREATE
+- Issues with stale status (no git activity in 7+ days but still marked In Progress) → flag for user
+- Assignee mismatches (git author ≠ Linear assignee) → propose UPDATE_ASSIGNEE
+
+**Notion updates** `[OPTIONAL]` (if enabled, existing pages only):
+- Pages whose status is stale vs the reconciled state (e.g. Notion says "In Progress" but Linear/git says Done) → propose update
+
+**Slack drafts (ALWAYS draft, never direct send — applies to every channel and DM):**
+- For every thread where a reply is warranted, produce a `slack_send_message_draft`
+- No exceptions, not even for internal channels or teammate DMs
+- The user is the only sender — they review the draft in Slack and send manually
+- Apply tone rules when relevant (non-technical language for client-facing threads)
+
+**Intercom proposals** `[OPTIONAL]` (if enabled, read + write):
+- Incidents detected in Slack without an associated Intercom conversation (reported by identifiable customer) → propose `CREATE_INTERCOM_NOTE` on the matching conversation, or flag as "internal incident, no customer link"
+- Forwarded client requests → propose `ADD_INTERCOM_NOTE` on the original conversation with the technical context detected, so the CS lead sees it inside Intercom
+- When an issue is resolved and the customer needs to be notified → propose a **note draft** in the Intercom conversation, **never a direct reply to the customer**
+- **NEVER auto-send in Intercom.** All writes wait for explicit confirmation (`apply 1,3` / `apply all` / `skip`)
+
+### Execution:
+- Print the proposed updates as a numbered list
+- Wait for: `apply all`, `apply 1,3,5`, or `skip`
+- If the user says nothing about syncing, skip — don't block the morning
+
+## Rules
+- **Phase 1 (briefing) is read-only.** The briefing output itself never writes to any system.
+- **Phase 2 (sync) proposes writes** but waits for explicit confirmation before executing.
+- **NEVER direct-send to Slack.** Every Slack message — any channel, any DM, any audience — goes as `slack_send_message_draft`. Zero exceptions. The user is the only sender.
+- **Intercom writes allowed but gated.** Notes are proposed in Phase 2 and wait for confirmation. Never reply directly to a customer.
+- **Fast.** Parallelize everything. Output must be short and scannable.
+- **If a source has no news, say "sin novedades" and move on.** Don't pad with filler text.
+- **Privacy gate applies** same as `/sprint-status`.
+- **Tone:** internal, for the user only. Can use IDs and jargon. Not meant for sharing.
+- **If an EOD review is pending from yesterday**, mention it in the suggested focus.
+
+## Relationship with other skills
+- **`/sprint-status`** — heavy weekly audit with Linear writes. `/daily` is the lightweight daily check that writes nothing.
+- **`/eod-review`** — end-of-day report. `/daily` is the morning input; `/eod-review` is the afternoon output.

package/commands/deslop.md

@@ -0,0 +1,13 @@
+# Remove AI Code Slop
+
+Check the diff against main and remove all AI-generated slop introduced in this branch.
+
+This includes:
+- Extra comments that a human wouldn't add or that are inconsistent with the rest of the file
+- Extra defensive checks or try/catch blocks abnormal for that area (especially if called by trusted/validated codepaths)
+- Casts to `any` to get around type issues
+- Unnecessary abstractions or over-engineering for simple operations
+- Redundant type annotations on obvious types
+- Verbose error handling for impossible scenarios
+
+Report at the end with only a 1-3 sentence summary of what you changed.

package/commands/draft-message.md

@@ -0,0 +1,23 @@
+# Draft Message
+
+Help me structure a message for a difficult or important conversation.
+
+## Input
+Tell me:
+- **Who** is the audience (Samu, equipo, Clemente, cliente, etc.)
+- **What** is the topic
+- **Goal** — what outcome do you want
+
+## Process
+
+1. Organize your key points logically
+2. Connect technical decisions to business impact where relevant
+3. Anticipate pushback and prepare responses
+4. Keep tone professional but direct
+
+## Output Options
+- **Slack-ready** — formatted for copy-paste with clean formatting
+- **Talking points** — bullets for a call/meeting
+- **Email/formal** — structured with subject line
+
+Default to Slack-ready unless specified otherwise.

package/commands/eod-review.md

@@ -0,0 +1,154 @@
+# EOD Review — End-of-Day team report
+
+Generate an end-of-day report with everything that was done, changed, or moved TODAY. Designed to give non-technical stakeholders (CEO, PM, CS lead) clear visibility into delivery progress without requiring them to read PRs or Linear.
+
+The output is a **Slack draft** (never a direct send) ready for the user to review and post. When the target channel is mixed (devs + non-devs), a dual layer is produced: non-technical summary on top, optional technical detail below.
+
+## Configuration (edit this section for your team)
+
+Before using this skill, edit the YAML block below with your team's channels, repos, and target audience. Sections marked `[OPTIONAL]` can be deleted if your team does not use that system.
+
+```yaml
+# --- Target channel for the draft (where the report will be posted) ---
+target_channel:
+  name: "#tech-guild"     # id: Cxxxxxxx
+  audience: "mixed"        # "mixed" | "technical" | "non-technical"
+
+# --- Slack channels to scan for context on what happened today ---
+slack_channels:
+  - name: "#incidents"
+  - name: "#tech-guild"
+  - name: "#clients"
+
+# --- Git repos to scan for "what was done today" ---
+git_repos:
+  - ~/your-org/api-repo
+  - ~/your-org/frontend-repo
+
+# --- Team member git-email → display-name mapping ---
+team_members:
+  - { email: "you@company.com", name: "You" }
+  - { email: "teammate@company.com", name: "Teammate" }
+
+# --- Optional integrations ---
+integrations:
+  linear: true            # requires Linear MCP
+  intercom: false         # [OPTIONAL] requires Intercom MCP — client-facing metrics
+  notion: false           # [OPTIONAL] never queried from this command
+```
+
+## When to use
+
+- At the end of the workday, before closing
+- When your PM/CEO asks "what was done today"
+- Before a standup or sync where you need to show daily progress
+
+## Data sources (all read-only, all in parallel)
+
+### Git (primary source for "what was done today")
+For each repo in `git_repos`:
+- `git fetch origin --prune`
+- PRs merged TODAY by anyone: `gh pr list --state merged --search "merged:>=TODAY"`
+- PRs opened TODAY
+- Commits pushed to staging/feature branches TODAY
+- Map authors via `team_members` (git email → display name)
+
+### Linear (if `integrations.linear`)
+- Issues moved to Done today
+- Issues moved to In Progress today (started)
+- New issues created today
+- Comments added today
+
+### Slack (secondary — for context)
+For each channel in `slack_channels`:
+- Any new incidents today (resolved or open)
+- Important messages (asks from leadership, decisions)
+- New client requests today (count + brief summary)
+
+### Intercom `[OPTIONAL]` (if `integrations.intercom` — primary source for client-facing metrics)
+- Conversations with activity TODAY: `mcp__intercom__search_conversations` filtered by `updated_at >= today`
+- Count: created today / resolved today / still open / priority flagged
+- Cross-ref with Slack client channels: every forwarded thread should have its real conversation in Intercom — confirm counts match. If Slack > Intercom, flag "possible phantom forward or deleted conversation". If Intercom > Slack, flag "tickets not visible in Slack"
+- For each conversation resolved today: one plain-language line describing the fix (input for the "Delivered today" section)
+
+### Notion `[OPTIONAL]`
+- Not queried. Linear is the source of truth.
+
+## Privacy gate
+Same as `/sprint-status`. DMs are NOT scanned for EOD review — only channel content.
+
+## Output format
+
+The output is a **Slack draft** in `target_channel`. **NOT a direct send.**
+
+```
+📋 *EOD Review — [fecha]*
+
+*🟢 Entregado hoy (merged a main)*
+• *[Feature/fix corto]* — [1 línea de qué es] ([repo])
+• ...
+(si nada se mergeó hoy: "Sin deploys hoy — día de desarrollo/review")
+
+*🔄 Avanzado hoy (staging / branches / PRs abiertos)*
+• *[Feature/fix]* — [estado: PR abierto / pushed a staging / en desarrollo]
+• ...
+
+*🐛 Incidents*
+• [resumen o "Sin incidents nuevos hoy ✅"]
+
+*📬 Requests de clientes*    [OPTIONAL section — show only if Intercom OR client channels enabled]
+• [N] conversations nuevas hoy · [M] resueltas hoy · [K] abiertas pendientes
+• Top nuevas (plain-language): [1-3 líneas]
+• ⚠ Si hay mismatch Intercom↔Slack, flag aquí
+(o "Sin requests nuevas ✅")
+
+*🔴 Stoppers*
+• [ISSUE-ID] — [razón] — [días frenado]
+(o "Sin stoppers 🟢")
+
+*🎯 Foco mañana*
+• [1-3 bullets de qué sigue]
+```
+
+## Rules
+
+### Content rules
+- **Only TODAY.** Do not repeat yesterday or summarize the week — use `/sprint-status` for that.
+- **Count work from THE WHOLE TEAM, not just the user.** If a teammate merged something today, it goes in. If another teammate resolved an incident, it goes in. This is a team report.
+- **Staging-promote PRs** (branches that only promote staging → main) do NOT count as features — they are operational. If the real content was already reported earlier, skip.
+
+### Tone rules (audience-aware)
+
+The tone adapts to `target_channel.audience`:
+
+**If `audience: "non-technical"`** (CEO, PM, CS, investors):
+- **Always plain-language.** Each item answers: "what can the customer do now that they couldn't before?" or "what problem do they no longer have?"
+- **NEVER mention:** PR#, ticket IDs, class/service names, branch names, internal jargon.
+- Examples:
+  - ❌ "Merged PR #462 fix (ProcessCvSubmissionJob): Deduplicate apply_portals candidates by email/phone"
+  - ✅ "Fixed a problem where candidates arriving from InfoJobs were duplicated inside the hiring process"
+  - ❌ "Fix SSRF allowlist guard in server-side fetchWithAuth"
+  - ✅ "Closed a server-side security vulnerability"
+- Short. Target: 10-15 lines. Max 25 lines. If the day was long, prioritize the 5 most important items and close with "plus N minor maintenance/bugfix items".
+
+**If `audience: "technical"`** (dev-only channel):
+- Can use PR#, ticket IDs, branch names, jargon.
+- Still keep it concise — readers already know the context.
+
+**If `audience: "mixed"`** (dev channel that is also read by leadership/CS):
+- **Dual layer**: for each section, lead with a 1-2 line plain-language translation, then optionally follow with the technical detail underneath.
+- This is the safest default when you're not sure who reads the channel.
+
+### Delivery rules
+- **Always draft, never direct send.** Applies to every channel, no exceptions. The user is the only sender from Slack.
+- **Tag `@here`** at the top only if there's a blocker or a large deploy with customer impact. Don't abuse.
+- **Short and scannable.** See target length per audience above.
+
+### Reminder
+- Send the report before the end of the workday while context is fresh.
+- The `/daily` morning skill can remind the user to run `/eod-review` at the end of the day.
+
+## Relationship with other skills
+- **`/daily`** — morning check (what happened, what needs attention). `/eod-review` is the afternoon close (what was done).
+- **`/sprint-status`** — heavy weekly audit. `/eod-review` is the micro daily report.
+- **Both complement each other:** `/daily` in the morning → work all day → `/eod-review` at 18:00 → draft to team channel.

package/commands/execute-prp.md

@@ -0,0 +1,37 @@
+# Execute PRP
+
+Ejecuta el PRP especificado: `$ARGUMENTS`
+
+Si no se pasa argumento, busca el PRP más reciente en `PRPs/` o pregunta cuál ejecutar.
+
+## Proceso obligatorio
+
+### 1. Lee el PRP completo
+Antes de tocar un solo archivo, lee el PRP entero. Entiende el scope total.
+
+### 2. Lee todos los archivos referenciados en "Context"
+No asumas nada del código existente — lee los archivos mencionados en el PRP.
+Si el PRP dice "sigue el patrón de X", lee X antes de empezar.
+
+### 3. Implementa paso a paso
+Sigue el `Implementation Plan` en orden. Por cada paso:
+- Implementa
+- Si es un bloque lógico completo (modelo, servicio, controller, etc.), haz commit inmediato
+- Commit format: `feat (Modelo/Archivo): Descripción` — max 6 archivos por commit
+
+### 4. Valida al finalizar
+Corre el `Validation Checklist` del PRP ítem por ítem.
+Reporta resultados antes de declarar la feature terminada.
+
+### 5. Marca pasos completados en el PRP
+Actualiza el PRP con ✅ en cada paso del `Implementation Plan` al completarlo.
+
+---
+
+## Reglas de ejecución
+
+- **No saltes pasos** — si un paso requiere leer algo primero, léelo
+- **No asumas que el PRP está actualizado** — si encuentras discrepancias con el código real, actualiza el PRP y reporta
+- **Bloqueantes primero** — si algo bloquea la implementación, repórtalo inmediatamente antes de continuar con pasos posteriores
+- **Tests no son opcionales** — el paso de tests es parte de la implementación, no un extra
+- **Nunca `--no-verify`** en ningún commit

package/commands/generate-prp.md

@@ -0,0 +1,75 @@
+# Generate PRP
+
+Lee `INITIAL.md` en el directorio actual y genera un PRP (Product Requirements Prompt) completo
+que sirva como blueprint de implementación autosuficiente.
+
+## Proceso obligatorio
+
+### 1. Lee INITIAL.md
+Entiende exactamente qué se quiere construir, el contexto de negocio y los criterios de aceptación.
+
+### 2. Explora el codebase sin asumir nada
+Antes de escribir una sola línea del PRP, ejecuta en paralelo:
+- Lee `.claude/rules/` completo para entender todas las restricciones activas
+- Busca con Grep/Glob archivos similares a lo que se va a construir (modelos, servicios, hooks, etc.)
+- Lee los archivos más relevantes que el PRP referenciará como ejemplos
+- Si hay `docs/` con documentación técnica, léela en la sección relevante
+
+### 3. Genera el PRP en `PRPs/<feature-slug>.md`
+
+El slug del archivo debe ser kebab-case descriptivo (ej: `PRPs/candidate-enrichment.md`).
+
+---
+
+## Estructura del PRP a generar
+
+```markdown
+# PRP: [Nombre de la Feature]
+
+## Goal
+Qué construir y por qué — conectar con el impacto de negocio en tu proyecto.
+
+## Context
+
+### Archivos clave a leer antes de implementar
+Lista de paths absolutos (relativos al repo) con descripción de por qué son relevantes.
+
+### Patrones a seguir
+Referencias concretas: "sigue el patrón de X para hacer Y" con paths exactos.
+
+### Restricciones activas
+Reglas de `.claude/rules/` que aplican directamente a esta feature (no las repitas, solo referencialas).
+
+## Implementation Plan
+
+Pasos ordenados. Cada paso debe tener:
+- Acción concreta
+- Path exacto del archivo
+- Qué leer primero si aplica
+
+### Paso 1: [Nombre]
+...
+
+### Paso N: Tests
+Qué specs escribir, qué casos cubrir (happy path, edge cases, unauthorized, not found).
+
+## API Contract (si aplica)
+Endpoint, método HTTP, request body, response body, status codes.
+
+## Validation Checklist
+- [ ] Todos los tests pasan (`RAILS_ENV=test bundle exec rspec` o `pnpm check`)
+- [ ] Sin N+1 queries
+- [ ] Lint pasa
+- [ ] Criterios de aceptación de INITIAL.md cumplidos
+- [ ] Soft delete implementado si aplica (Paranoia)
+- [ ] Pundit policy actualizada si aplica
+```
+
+---
+
+## Principios del PRP
+
+- **Autosuficiente**: otro Claude debe poder ejecutarlo sin preguntar nada más
+- **Sin redundancia**: no repetir reglas que ya están en `.claude/rules/`, solo referenciarlas
+- **Específico**: paths concretos, no "algo similar a los servicios existentes"
+- **Honesto**: si algo es incierto, marcarlo como "verificar antes de implementar"

package/commands/multi-repo-feature.md

@@ -0,0 +1,60 @@
+# Multi-Repo Feature Coordinator
+
+Coordinate a feature that spans multiple repos. Creates a parallel work plan and sequences changes correctly.
+
+## Input
+Describe the feature or provide a Linear issue ID. Example:
+- "Implementar filtro de candidatos por idioma en API y frontend"
+- "MAI-123"
+
+## Steps
+
+### 1. Understand the Feature
+If a Linear issue ID is provided, fetch it with the Linear MCP tool to get full context, acceptance criteria, and comments.
+
+### 2. Impact Analysis
+For each repo, determine:
+- **main-api**: new/modified endpoints, migrations, services, background jobs
+- **frontend-app**: new/modified pages, components, hooks, API calls, i18n keys
+- **ai-service**: new/modified agents, prompts, contracts (only if AI logic involved)
+- **background-service**: new/modified background processing (only if affected)
+
+### 3. API Contract First
+If API changes are needed, define the contract before writing any code:
+```
+Endpoint: METHOD /api/v1/[resource]
+Auth: required / public
+Request: { field: type }
+Response: { data: { field: type } }
+Errors: 422 { errors: [...] }
+```
+
+### 4. Sequenced Work Plan
+Output a sequenced plan respecting the dependency order:
+1. Migrations (API first)
+2. Backend services + endpoints
+3. AI/Agent logic (if needed)
+4. Frontend components + hooks
+
+### 5. Parallel Session Setup
+For large features (3+ files per repo), suggest opening parallel Claude sessions:
+
+```bash
+# Terminal 1 — API
+cd ~/projects/your-api && cl
+# Prompt: "Implement [backend part] following the contract: [contract]"
+
+# Terminal 2 — Frontend (can start with mock data)
+cd ~/projects/your-frontend && cl
+# Prompt: "Implement [frontend part] against this API contract: [contract]"
+```
+
+### 6. Integration Checklist
+Generate a checklist for verifying the full feature works end-to-end:
+- [ ] Migration applied (`RAILS_ENV=development rails db:migrate`)
+- [ ] API endpoint returns correct shape
+- [ ] Frontend displays data correctly
+- [ ] i18n keys added in all locales (en, es, ca, fr)
+- [ ] Specs written and passing
+- [ ] No TypeScript errors (`pnpm typecheck`)
+- [ ] Linear issue updated with implementation notes

package/commands/roadmap.md

@@ -0,0 +1,31 @@
+# Roadmap: Feature & Improvement Suggestions
+
+Analyze the codebase and generate a roadmap of potential features and improvements.
+
+## Analysis Steps
+
+1. Scan codebase architecture, patterns, and conventions
+2. Identify feature gaps and improvement opportunities
+3. Create phased overview (Quick Wins / Medium Effort / Strategic)
+4. Ask user which features to plan in detail
+
+## Analysis Focus
+
+- Missing common patterns (auth, caching, error handling, logging)
+- Performance optimization opportunities
+- Developer experience improvements
+- User-facing feature enhancements
+- Code quality / refactoring candidates
+
+## Output Format
+
+### Quick Wins (low effort, high impact)
+- Feature: description, estimated effort
+
+### Medium Effort
+- Feature: description, what needs refactoring
+
+### Strategic (architectural changes)
+- Feature: description, dependencies, risks
+
+Present as a structured markdown table with columns: Feature | Effort | Impact | Dependencies.