argos-harness 0.1.0

package/assets/skills/not-boring-mobile/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: not-boring-mobile
+description: Trigger: Not Boring app, playful/delightful app, juguete, maximalist UI, tactile/skeuomorphic mobile, make it delightful. Visual+interaction direction for delight-first React Native/Expo apps — springs, haptics, sound, bespoke components.
+---
+
+## Activation Contract
+
+Activate when the user wants a React Native/Expo app that feels like a TOY, not a tool — the "Not Boring" (Andy Allen) / Apple-editorial register: maximalist, tactile, animation-led, personality-heavy. This is the VISUAL + INTERACTION layer ONLY; architecture, data, and phase gates come from `app-builder`. Do NOT activate for dense tools, clinical/enterprise, or data-heavy products — those want a restrained register.
+
+## Hard Rules
+
+- Bespoke everything the user touches: NO stock/system components, NO generic shadcn/reusables look. Owned components with custom shape, depth, and motion.
+- Every meaningful interaction gets BOTH a spring (Reanimated `withSpring`, native driver) AND a haptic; primary "toy" interactions also get sound.
+- Spend boldness on ONE signature interaction the app is remembered by; keep everything else coherent, not noisy.
+- Commit to ONE saturated color world (gradients, light, depth) — never tinted neutrals.
+- Respect OS Reduce Motion with a tasteful non-animated fallback; hold 60fps (no layout-animating hot paths, no JS per-frame work).
+- Complement `app-builder`; never redo its architecture, data layer, or phase gates.
+
+## Decision Gates
+
+| Product | Register |
+|---|---|
+| Habit/lifestyle/creative/kids/consumer where delight IS the value | this skill (maximalist) |
+| Tool, clinical, enterprise, dense data, pro workflow | restrained (`app-builder` default) — do NOT use this |
+| Marketing/story surface (editorial, immersive, cinematic) | this skill's editorial mode |
+
+## Execution Steps
+
+1. Confirm the register fits (consumer/delight). If it's a tool, stop and use the restrained register.
+2. Read `references/not-boring-playbook.md` (libraries, spring presets, sound/haptic/depth recipes) BEFORE building UI.
+3. Pick the ONE signature "toy" interaction that embodies the app; prototype it first, on device.
+4. Build bespoke, gesture-reactive components; drive state changes with `withSpring`, not timing curves.
+5. Layer depth (gradients, layered shadows, glass, light) + one committed color world + big expressive type.
+6. Wire haptics + sound via owned `lib/haptics.ts` / `lib/sound.ts` wrappers on every interaction.
+7. Verify on a REAL device (springs/haptics/sound don't read in a simulator); gate on "is it fun to poke?".
+
+## Output Contract
+
+Return: the signature interaction built, the bespoke components created, the color/type/depth system, the haptic+sound wiring, and device-verified evidence it feels like a toy — not just a themed form.
+
+## References
+
+- `references/not-boring-playbook.md` — libraries, spring presets, sound/haptic/depth recipes, and the Not Boring + Apple-editorial principles.

package/assets/skills/not-boring-mobile/references/not-boring-playbook.md

@@ -0,0 +1,65 @@
+# Not Boring Mobile — Playbook
+
+The direction layer for delight-first Expo/RN apps. Read before building UI. Pairs with app-builder (which owns architecture, data, phases).
+
+## The philosophy (Not Boring, Andy Allen)
+
+- **Toy, not tool.** The interface should be fun to poke even with no task. Reward curiosity.
+- **Modern skeuomorphism.** Real depth, material, light — not flat, not literal 2010 skeuo. Surfaces feel touchable.
+- **Motion is the protagonist**, not decoration. Everything reacts to touch; nothing snaps instantly. State changes are physical, not timed.
+- **Personality.** A voice, playful copy, optional character/mascot, surprise & delight, easter eggs. The app has an attitude.
+- **Committed color world.** One saturated palette/gradient system owns the app. No timid neutrals.
+- **Sound design.** Short, tactile sounds paired with haptics make interactions feel physical. Always user-mutable.
+- **Restraint inside maximalism.** One signature "hero toy"; everything else is coherent and disciplined so the hero lands.
+
+## Apple-editorial mode (Today stories)
+
+Full-bleed cinematic imagery, oversized display type, narrative scroll with parallax, generous negative space, one accent. Use for onboarding, marketing, story surfaces. Same craft, calmer motion.
+
+## Libraries (Expo-compatible)
+
+- `react-native-reanimated` (v3/4) — springs, worklets, shared values. Worklets babel plugin is required (v4: `react-native-worklets/plugin`, LAST).
+- `react-native-gesture-handler` — pan/tap/pinch driving animations directly.
+- `expo-haptics` — impact + notification feedback.
+- `expo-audio` (or `expo-av`) — short interaction sounds; preload, keep <300ms.
+- `expo-linear-gradient`, `expo-blur` — gradients + glass.
+- `@shopify/react-native-skia` — advanced visuals: shaders, mesh gradients, custom shapes, glow. Reach for it when gradients/shadows aren't enough.
+- `moti` (optional) — declarative wrapper over Reanimated for quick spring transitions.
+
+## Spring presets (Reanimated `withSpring`)
+
+```ts
+export const springs = {
+  gentle: { damping: 18, stiffness: 140, mass: 1 },   // calm settle
+  bouncy: { damping: 10, stiffness: 180, mass: 0.9 },  // playful overshoot
+  stiff:  { damping: 26, stiffness: 320, mass: 1 },    // snappy, immediate
+};
+```
+
+Drive press/toggle/drag with these, not `withTiming`. Overshoot is the personality.
+
+## Haptics + sound wiring
+
+- `lib/haptics.ts`: map interaction weight → impact (light for taps, medium for commits, heavy/notification for milestones). Wrap in `.catch(()=>{})`.
+- `lib/sound.ts`: owned wrapper; preload sounds once, expose `play(name)`, honor a user mute setting. Never block the interaction on audio.
+- Rule: press = light haptic; success/complete = notification success + a reward sound; drag threshold crossed = tick.
+
+## Depth recipe
+
+Layer, don't flatten: base gradient → surface with layered shadows (a soft wide + a tight dark) → inner light highlight (top edge lighter) → optional blur/glass for overlays. Skia for glow/mesh gradients.
+
+## Performance (non-negotiable)
+
+- Native driver only; keep animation math in worklets.
+- No layout animations on list hot paths; use transform/opacity.
+- Memoize heavy components; virtualize long lists.
+- Skia work off the JS thread; avoid per-frame `setState`.
+- Test on a real device — a simulator hides haptics, sound, and true frame timing.
+
+## Anti-patterns
+
+- Animating everything → fatigue. Choose the moments.
+- System `Alert`/stock inputs in a delight moment → breaks the toy illusion; build bespoke.
+- Shipping without a device haptic/sound pass → the feel is unverified.
+- Tinted-neutral palette → that's the restrained register; this one commits to color.
+- Reusing shadcn/reusables primitives verbatim → they read generic; here every touched surface is bespoke.

package/assets/skills/playwright/SKILL.md

@@ -0,0 +1,315 @@
+---
+name: playwright
+description: Playwright E2E testing patterns. Trigger: When writing E2E tests - Page Objects, selectors, MCP workflow.
+---
+
+## MCP Workflow (MANDATORY If Available)
+
+**⚠️ If you have Playwright MCP tools, ALWAYS use them BEFORE creating any test:**
+
+1. **Navigate** to target page
+2. **Take snapshot** to see page structure and elements
+3. **Interact** with forms/elements to verify exact user flow
+4. **Take screenshots** to document expected states
+5. **Verify page transitions** through complete flow (loading, success, error)
+6. **Document actual selectors** from snapshots (use real refs and labels)
+7. **Only after exploring** create test code with verified selectors
+
+**If MCP NOT available:** Proceed with test creation based on docs and code analysis.
+
+**Why This Matters:**
+- ✅ Precise tests - exact steps needed, no assumptions
+- ✅ Accurate selectors - real DOM structure, not imagined
+- ✅ Real flow validation - verify journey actually works
+- ✅ Avoid over-engineering - minimal tests for what exists
+- ✅ Prevent flaky tests - real exploration = stable tests
+- ❌ Never assume how UI "should" work
+
+## File Structure
+
+```
+tests/
+├── base-page.ts              # Parent class for ALL pages
+├── helpers.ts                # Shared utilities
+└── {page-name}/
+    ├── {page-name}-page.ts   # Page Object Model
+    ├── {page-name}.spec.ts   # ALL tests here (NO separate files!)
+    └── {page-name}.md        # Test documentation
+```
+
+**File Naming:**
+- ✅ `sign-up.spec.ts` (all sign-up tests)
+- ✅ `sign-up-page.ts` (page object)
+- ✅ `sign-up.md` (documentation)
+- ❌ `sign-up-critical-path.spec.ts` (WRONG - no separate files)
+- ❌ `sign-up-validation.spec.ts` (WRONG)
+
+## Selector Priority (REQUIRED)
+
+```typescript
+// 1. BEST - getByRole for interactive elements
+this.submitButton = page.getByRole("button", { name: "Submit" });
+this.navLink = page.getByRole("link", { name: "Dashboard" });
+
+// 2. BEST - getByLabel for form controls
+this.emailInput = page.getByLabel("Email");
+this.passwordInput = page.getByLabel("Password");
+
+// 3. SPARINGLY - getByText for static content only
+this.errorMessage = page.getByText("Invalid credentials");
+this.pageTitle = page.getByText("Welcome");
+
+// 4. LAST RESORT - getByTestId when above fail
+this.customWidget = page.getByTestId("date-picker");
+
+// ❌ AVOID fragile selectors
+this.button = page.locator(".btn-primary");  // NO
+this.input = page.locator("#email");         // NO
+```
+
+## Scope Detection (ASK IF AMBIGUOUS)
+
+| User Says | Action |
+|-----------|--------|
+| "a test", "one test", "new test", "add test" | Create ONE test() in existing spec |
+| "comprehensive tests", "all tests", "test suite", "generate tests" | Create full suite |
+
+**Examples:**
+- "Create a test for user sign-up" → ONE test only
+- "Generate E2E tests for login page" → Full suite
+- "Add a test to verify form validation" → ONE test to existing spec
+
+## Page Object Pattern
+
+```typescript
+import { Page, Locator, expect } from "@playwright/test";
+
+// BasePage - ALL pages extend this
+export class BasePage {
+  constructor(protected page: Page) {}
+
+  async goto(path: string): Promise<void> {
+    await this.page.goto(path);
+    await this.page.waitForLoadState("networkidle");
+  }
+
+  // Common methods go here (see Refactoring Guidelines)
+  async waitForNotification(): Promise<void> {
+    await this.page.waitForSelector('[role="status"]');
+  }
+
+  async verifyNotificationMessage(message: string): Promise<void> {
+    const notification = this.page.locator('[role="status"]');
+    await expect(notification).toContainText(message);
+  }
+}
+
+// Page-specific implementation
+export interface LoginData {
+  email: string;
+  password: string;
+}
+
+export class LoginPage extends BasePage {
+  readonly emailInput: Locator;
+  readonly passwordInput: Locator;
+  readonly submitButton: Locator;
+
+  constructor(page: Page) {
+    super(page);
+    this.emailInput = page.getByLabel("Email");
+    this.passwordInput = page.getByLabel("Password");
+    this.submitButton = page.getByRole("button", { name: "Sign in" });
+  }
+
+  async goto(): Promise<void> {
+    await super.goto("/login");
+  }
+
+  async login(data: LoginData): Promise<void> {
+    await this.emailInput.fill(data.email);
+    await this.passwordInput.fill(data.password);
+    await this.submitButton.click();
+  }
+
+  async verifyCriticalOutcome(): Promise<void> {
+    await expect(this.page).toHaveURL("/dashboard");
+  }
+}
+```
+
+## Page Object Reuse (CRITICAL)
+
+**Always check existing page objects before creating new ones!**
+
+```typescript
+// ✅ GOOD: Reuse existing page objects
+import { SignInPage } from "../sign-in/sign-in-page";
+import { HomePage } from "../home/home-page";
+
+test("User can sign up and login", async ({ page }) => {
+  const signUpPage = new SignUpPage(page);
+  const signInPage = new SignInPage(page);  // REUSE
+  const homePage = new HomePage(page);      // REUSE
+
+  await signUpPage.signUp(userData);
+  await homePage.verifyPageLoaded();  // REUSE method
+  await homePage.signOut();           // REUSE method
+  await signInPage.login(credentials); // REUSE method
+});
+
+// ❌ BAD: Recreating existing functionality
+export class SignUpPage extends BasePage {
+  async logout() { /* ... */ }  // ❌ HomePage already has this
+  async login() { /* ... */ }   // ❌ SignInPage already has this
+}
+```
+
+**Guidelines:**
+- Check `tests/` for existing page objects first
+- Import and reuse existing pages
+- Create page objects only when page doesn't exist
+- If test requires multiple pages, ensure all page objects exist (create if needed)
+
+## Refactoring Guidelines
+
+### Move to `BasePage` when:
+- ✅ Navigation helpers used by multiple pages (`waitForPageLoad()`, `getCurrentUrl()`)
+- ✅ Common UI interactions (notifications, modals, theme toggles)
+- ✅ Verification patterns repeated across pages (`isVisible()`, `waitForVisible()`)
+- ✅ Error handling that applies to all pages
+- ✅ Screenshot utilities for debugging
+
+### Move to `helpers.ts` when:
+- ✅ Test data generation (`generateUniqueEmail()`, `generateTestUser()`)
+- ✅ Setup/teardown utilities (`createTestUser()`, `cleanupTestData()`)
+- ✅ Custom assertions (`expectNotificationToContain()`)
+- ✅ API helpers for test setup (`seedDatabase()`, `resetState()`)
+- ✅ Time utilities (`waitForCondition()`, `retryAction()`)
+
+**Before (BAD):**
+```typescript
+// Repeated in multiple page objects
+export class SignUpPage extends BasePage {
+  async waitForNotification(): Promise<void> {
+    await this.page.waitForSelector('[role="status"]');
+  }
+}
+export class SignInPage extends BasePage {
+  async waitForNotification(): Promise<void> {
+    await this.page.waitForSelector('[role="status"]');  // DUPLICATED!
+  }
+}
+```
+
+**After (GOOD):**
+```typescript
+// BasePage - shared across all pages
+export class BasePage {
+  async waitForNotification(): Promise<void> {
+    await this.page.waitForSelector('[role="status"]');
+  }
+}
+
+// helpers.ts - data generation
+export function generateUniqueEmail(): string {
+  return `test.${Date.now()}@example.com`;
+}
+
+export function generateTestUser() {
+  return {
+    name: "Test User",
+    email: generateUniqueEmail(),
+    password: "TestPassword123!",
+  };
+}
+```
+
+## Test Pattern with Tags
+
+```typescript
+import { test, expect } from "@playwright/test";
+import { LoginPage } from "./login-page";
+
+test.describe("Login", () => {
+  test("User can login successfully",
+    { tag: ["@critical", "@e2e", "@login", "@LOGIN-E2E-001"] },
+    async ({ page }) => {
+      const loginPage = new LoginPage(page);
+
+      await loginPage.goto();
+      await loginPage.login({ email: "user@test.com", password: "pass123" });
+
+      await expect(page).toHaveURL("/dashboard");
+    }
+  );
+});
+```
+
+**Tag Categories:**
+- Priority: `@critical`, `@high`, `@medium`, `@low`
+- Type: `@e2e`
+- Feature: `@signup`, `@signin`, `@dashboard`
+- Test ID: `@SIGNUP-E2E-001`, `@LOGIN-E2E-002`
+
+## Test Documentation Format ({page-name}.md)
+
+```markdown
+### E2E Tests: {Feature Name}
+
+**Suite ID:** `{SUITE-ID}`
+**Feature:** {Feature description}
+
+---
+
+## Test Case: `{TEST-ID}` - {Test case title}
+
+**Priority:** `{critical|high|medium|low}`
+
+**Tags:**
+- type → @e2e
+- feature → @{feature-name}
+
+**Description/Objective:** {Brief description}
+
+**Preconditions:**
+- {Prerequisites for test to run}
+- {Required data or state}
+
+### Flow Steps:
+1. {Step 1}
+2. {Step 2}
+3. {Step 3}
+
+### Expected Result:
+- {Expected outcome 1}
+- {Expected outcome 2}
+
+### Key verification points:
+- {Assertion 1}
+- {Assertion 2}
+
+### Notes:
+- {Additional considerations}
+```
+
+**Documentation Rules:**
+- ❌ NO general test running instructions
+- ❌ NO file structure explanations
+- ❌ NO code examples or tutorials
+- ❌ NO troubleshooting sections
+- ✅ Focus ONLY on specific test case
+- ✅ Keep under 60 lines when possible
+
+## Commands
+
+```bash
+npx playwright test                    # Run all
+npx playwright test --grep "login"     # Filter by name
+npx playwright test --ui               # Interactive UI
+npx playwright test --debug            # Debug mode
+npx playwright test tests/login/       # Run specific folder
+```
+
+## Keywords
+playwright, e2e, testing, page object model, selectors, end-to-end, mcp

package/assets/skills/pr-comments/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: pr-comments
+description: Review, evaluate, fix, and reply to PR comments in Spanish (MX). Trigger: revisar comentarios del PR, responder comentarios, PR comments, or when the user wants to address reviewer feedback.
+---
+
+## When to Use
+
+The user wants to process reviewer comments on a Pull Request: read them, judge if each is correct or if there's a better solution, apply fixes, and reply.
+
+## Required Skills to Load First
+
+Load these BEFORE doing any work:
+
+- `comment-writer` — voice and tone for replies
+- `ponytail` — laziest correct fix for any code change
+- `judgment-day` — when a comment is non-trivial and needs adversarial check before agreeing
+- Language/framework skills relevant to the diff (e.g. `react-19`, `nextjs-15`, `typescript`, `django-drf`, `pytest`)
+
+## Workflow
+
+### 1. Fetch comments
+
+```bash
+gh pr view <PR> --json number,title,headRefName,baseRefName
+gh api repos/{owner}/{repo}/pulls/<PR>/comments    # inline review comments
+gh api repos/{owner}/{repo}/issues/<PR>/comments   # general comments
+```
+
+Group by file/line. Ignore resolved/outdated unless user says otherwise.
+
+### 2. Triage each comment
+
+For every comment decide one of:
+
+- **AGREE** — reviewer is right, apply fix.
+- **BETTER** — reviewer's intent is valid but there's a better solution. Apply the better one, explain why in the reply.
+- **REJECT** — reviewer is wrong or it's a non-issue. Explain why with technical reasoning.
+- **DISCUSS** — needs user input (ambiguous, product decision, out of scope).
+
+Verify before agreeing. Read the code, don't trust the comment blindly. If non-trivial, run `judgment-day` on the proposed fix.
+
+### 3. Apply fixes (ponytail mode)
+
+Use the ponytail ladder: stdlib > native > existing dep > one line > minimum code. No speculative refactors. One commit per logical group of comments.
+
+### 4. Draft replies
+
+Per comment, draft a short reply in **Mexican Spanish (tú)**, neutral and professional. Match `comment-writer` rules:
+
+- Lead with the action: "Listo", "Lo dejé así porque…", "No lo apliqué porque…"
+- 1–3 frases. Sin relleno.
+- Si rechazas, da la razón técnica con evidencia (link a línea, doc, o test).
+- Si propones algo mejor, di qué cambiaste y por qué.
+
+### 5. MANDATORY review gate
+
+Before publishing ANYTHING:
+
+1. Show the user a table:
+   | Comentario | Veredicto | Fix aplicado | Respuesta propuesta |
+2. Show the diff of the fixes.
+3. STOP and ask: "¿Publico estos comentarios y commiteo los fixes, o ajustamos algo?"
+
+Do NOT post comments, push commits, or resolve threads until the user approves.
+
+### 6. Publish
+
+After approval:
+
+- Commit fixes (conventional commits, no AI attribution).
+- Reply per comment: `gh api -X POST repos/{owner}/{repo}/pulls/<PR>/comments/<comment_id>/replies -f body='…'` for inline; `gh pr comment <PR> -b '…'` for general.
+- Resolve threads only if the user said so.
+
+## Reply Examples
+
+AGREE:
+> Listo, lo cambié a `useId` para evitar la colisión en SSR.
+
+BETTER:
+> Buen punto. En vez de memoizar, extraje el cálculo fuera del render — React Compiler ya cubre el resto. Más simple y sin dependencias.
+
+REJECT:
+> No lo aplico: ese branch ya está cubierto por el guard de la línea 42, agregarlo acá duplicaría la validación. Te dejo el test que lo prueba: `auth.spec.ts:88`.
+
+## Anti-patterns
+
+- Aceptar todos los comentarios sin verificar.
+- Respuestas largas explicando lo obvio.
+- Aplicar fixes y publicar sin pasar por el gate de revisión.
+- Mezclar fixes de varios comentarios en un commit gigante sin razón.
+- Usar voseo o slang rioplatense.
+
+_Adapted from a skill originally authored by gentleman-programming._

package/assets/skills/pr-create/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: pr-create
+description: Crea un PR contra la rama destino del repo, delegando título y body a un modelo, con pre-flight bloqueante (gate verde, review aprobado, branch sincronizada) y oficio de commits atómicos y PRs partidos. Trigger: al cerrar el ciclo de una feature tras el APPROVED del reviewer, o al pedir crear/abrir un PR con gh.
+---
+
+# pr-create — crear PR contra la rama destino del repo
+
+## Cuándo usar este skill
+
+Al cierre del ciclo, tras el `APPROVED` del reviewer (Fase 8 de `ticket-intake`). El pre-flight es bloqueante: ningún PR sale con el gate en rojo o sin aprobación (harness activo).
+
+Este skill no conoce de antemano ni la rama base ni la rama destino del PR: léelas del repo antes de actuar. `branchBase` es el punto de fork; `prTarget` es la rama destino del PR; ambas viven en el `argos.config.json` del repo (y resueltas en texto literal en su ficha, el CLAUDE.md delgado que `argos adopt` escribió). Cuando difieren, el PR y su diff van contra `prTarget`.
+
+## Pre-flight (bloqueante — cualquier check falla → ABORT con mensaje claro)
+
+1. **Working tree limpio** o solo cambios del feature: `git status --porcelain`. Si hay cambios uncommitted que NO son del feature, párate y pregunta.
+2. **No estás en una rama protegida**: aborta si la rama actual es `main`, `master`, la `branchBase` o la `prTarget` del repo.
+3. **`gh` autenticado**: `gh auth status`.
+4. **Gate verde en este turno**: el quality gate fast del repo, resuelto desde `qualityGate.fast` en `argos.config.json` o la ficha. Falla → manda al implementer.
+5. **Review APPROVED de esta feature** (harness activo): `.claude/progress/review_<feature>.md` puntual — glob `review_*.md` no vale. Ausente/ambiguo/scope distinto → NO aprobado, manda al reviewer. Si lista archivos, compáralos con `git diff --name-only`: archivos tocados que el review NO cubre → NO aprobado, aborta y devuelve al reviewer (no basta con mencionar la diferencia y seguir). Mantén este chequeo de cobertura en sync con el agente `commit-pr-pilot`.
+6. **Hay commits para el PR**: `git fetch origin <prTarget> --quiet` y `git log origin/<prTarget>..HEAD --oneline`. Vacío → nada que PR-ear.
+7. **Branch sincronizada**: `git log HEAD..origin/<prTarget> --oneline`. Si origin va adelante, rebase y pregunta.
+8. **Arrastre de commits** (solo si `branchBase` ≠ `prTarget`): `git rev-list --count origin/<prTarget>..origin/<branchBase>`. Si es > 0, `branchBase` va adelantado de `prTarget` y el PR arrastra esos commits ajenos: avisa y sugiere `git rebase origin/<prTarget>` antes de abrir.
+
+## Push y redacción
+
+Si la branch no está pusheada: `git push -u origin "$current_branch"`. Si el upstream diverge, **no fuerces push** — pregunta.
+
+Delega title + body a un `Agent` (modelo rápido). Reglas que le impones:
+- **Title**: Conventional Commit (`feat|fix|docs|refactor|test|chore|perf|ci`) con scope de tu dominio, ≤70 chars, español MX, sin emojis ni puntuación final.
+- **Body**: secciones fijas `## Resumen`, `## Cambios`, `## Test plan`, `## Notas` (opcional). Si el trabajo cierra un issue/ticket de GitHub, termina con `Closes #NN`. Tono directo, sin "Generated by Claude".
+- **Contexto al redactor**: branch, `prTarget` resuelto, ticket, `impl_<feature>.md`, `review_<feature>.md`, y el diff REAL del PR — `git log origin/<prTarget>..HEAD --oneline` + `git diff origin/<prTarget>...HEAD --stat`.
+- **Output**: JSON exacto `{"title": "...", "body": "..."}` sin fences.
+
+Valida: `title` ≤70 y Conventional Commit; `body` con Resumen, Cambios y Test plan. Si falla, reintenta (máx. 2).
+
+## Crear el PR
+
+```bash
+gh pr create --base "$pr_target" --title "$title" --body "$body"
+```
+
+Donde `$pr_target` es el valor de `prTarget` leído del `argos.config.json` del repo (o de su ficha) en este turno — nunca un literal fijo en el skill. Captura la URL del output y muéstrasela al usuario.
+
+## Oficio del PR
+
+- **Commits atómicos**: una cosa por commit (`feat(user): add User model`, luego `test(user): ...`), nunca "add user feature" con todo adentro. Un PR de commits atómicos se revisa solo.
+- **PR gigante**: si el diff supera ~400 líneas o mezcla dominios, propone partirlo en PRs lógicos (models → api → ui). Con harness activo, usa el skill `chained-pr`.
+- **Trabajo en progreso**: `gh pr create --draft` — nunca un PR "normal" a medias esperando que nadie lo mergee.
+
+## Reglas duras
+
+- **NUNCA `git push --force`** ni `--no-verify` sin que lo pida el usuario.
+- **Siempre `--base` contra la `prTarget` resuelta del repo.** No la hardcodees ni la asumas de una sesión anterior; si el target del repo cambió, corrígelo en `argos.config.json` (por ejemplo con `argos adopt --refresh` si cambiaron los hechos del repo, o editándolo directo).
+- **Cambios uncommitted ajenos al feature** → párate y pregunta, no los arrastres al PR.
+- **Reviewers/labels**: no los agregues automático salvo que el usuario lo pida.
+
+## Antes de declarar listo
+
+- El pre-flight pasó completo y el title/body validaron.
+- El PR se creó contra la `prTarget` resuelta del repo y su URL quedó mostrada al usuario.
+- Post-PR: `mem_save` de decisiones no obvias, entrada en `history.md`, `current.md` a `state: idle`, y `mem_session_summary`.
+
+Este skill vive una sola vez en el motor global (`~/.claude/skills/`) y trabaja contra cualquier repo con `argos.config.json`: toda referencia a rama base, rama destino o quality gate se resuelve leyendo la config/ficha de ESE repo en este turno, nunca un valor fijado al escribir el skill.

package/assets/skills/promo-video/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: promo-video
+description: Trigger: promo video, promotional video, video promocional, marketing video, app trailer, Remotion, social video. Generate a branded promotional MP4 for an app with Remotion from its real store screenshots and design tokens.
+---
+
+# Promo Video
+
+## Activation Contract
+
+Activate when an app needs a promotional/marketing video (social, web, messaging) generated programmatically with Remotion from its real screenshots and brand system. Also the optional Phase 11 executor of `app-builder`.
+
+## Hard Rules
+
+- The video project lives at `tools/promo/` OUTSIDE npm workspaces, with its own `node_modules` — Remotion's `react-dom` must never hoist next to the app's React (Expo/RN conflict). Never add it to root `workspaces`.
+- The root script must force the directory context: `"promo:render": "cd tools/promo && npx remotion render Promo out/promo.mp4"` — this guarantees the render resolves `tools/promo`'s own dependencies and never the app bundler's React.
+- Brand fidelity is non-negotiable: colors and fonts derive from the app's token file (e.g. `lib/theme.ts`); copy derives from store metadata (`store.config.json`) / product definition — never invent a palette or product claims.
+- Screenshots come from the store screenshot set (`store/screenshots/`) — real app runs, not mockups.
+- On-screen copy in the store listing's locale; code, identifiers, and comments in English.
+- The output is a MARKETING asset. It is NOT an App Store "App Preview" — Apple requires real screen recordings there and `eas metadata` cannot upload video. Always state this distinction when delivering.
+- Renders run in the FOREGROUND of the session that owns them — a background render dies when its (sub)agent session ends.
+- Timeline math: with `TransitionSeries`, total frames = sum(scene durations) − sum(transition overlaps). Tune scene durations to land exactly on the target length.
+
+## Decision Gates
+
+| Situation | Route |
+|---|---|
+| Store screenshots + logo exist | Screenshot-showcase format (default, `assets/promo.template.tsx`) |
+| Motion clips wanted instead of stills | Record simulator via `xcrun simctl io booted recordVideo` during a Maestro flow; embed with `<OffthreadVideo>` — pipeline §7 |
+| Aspect ratio | 1080×1920 vertical (default, social); other ratios only on explicit request |
+| Web app or dashboard promo | Use `promo-video-web` (landscape, browser frame, Playwright captures) — extends the same `tools/promo/` project |
+| Screenshots are horizontal or 4:3 (tablet set) | Never stretch to 9:16 — constrain inside a fixed mobile mockup frame or use a blurred-background fill (same capture scaled up + blur behind) |
+| App Store App Preview requested | Different pipeline (Maestro + simctl + ffmpeg to Apple spec) — out of scope, say so |
+
+## Execution Steps
+
+1. Read `references/pipeline.md`. Inventory inputs: token file, transparent logo PNG, store screenshots (note their pixel aspect), store copy + locale.
+2. Scaffold `tools/promo/` from `assets/` templates; `npm install` inside it; copy logo + screenshots into `public/` (referenced via `staticFile()`).
+3. Map app tokens into `src/theme.ts`; load fonts via `@remotion/google-fonts`. Build scenes on the template: intro lockup → 3–4 feature scenes (device-framed screenshot, watermark word, staggered copy) → store outro. Skip visually boring screenshots (e.g. login).
+4. Audio bed: check for a user-provided `public/audio/bgm.mp3`; if the user explicitly asks you to source one, follow the sourcing protocol in `references/pipeline.md` §4 (license-safe library, brand-vibe search terms, source+license recorded next to the `<Audio>`; never source silently, and state you cannot listen — the pick is by genre/tags). When present, render Remotion's `<Audio src={staticFile('audio/bgm.mp3')}/>` as a SIBLING of the `TransitionSeries` with a volume fade-out over the last second, so the MP4 is social-ready without post-production.
+5. Render in the foreground: `npx remotion render Promo out/promo.mp4`. Add the root `promo:render` script (cd form — Hard Rules); gitignore `tools/promo/out/`.
+6. Verify duration/fps/size (Remotion's bundled ffprobe), spot-check 2+ frames with `npx remotion still`, deliver the MP4.
+
+## Output Contract
+
+Return: MP4 absolute path with duration/fps/size, files created, root script added, frame spot-check result, and the explicit marketing-vs-App-Preview note.
+
+## References
+
+- `references/pipeline.md` — full runbook: setup, brand mapping, scene direction system, timeline math, render/verify, video-clip variant, troubleshooting.
+- `assets/package.template.json` — pinned Remotion deps + `studio`/`render` scripts.
+- `assets/theme.template.ts` — token bridge shape (colors, google-fonts, radial backdrop).
+- `assets/promo.template.tsx` — full scene architecture: TransitionSeries, device frame, watermark, springs, lockup, glow pulse.

package/assets/skills/promo-video/assets/package.template.json

@@ -0,0 +1,22 @@
+{
+  "name": "APP_SLUG-promo",
+  "version": "1.0.0",
+  "private": true,
+  "description": "Remotion promotional video for the APP_NAME app",
+  "scripts": {
+    "studio": "remotion studio",
+    "render": "remotion render Promo out/promo.mp4"
+  },
+  "dependencies": {
+    "@remotion/cli": "4.0.496",
+    "@remotion/google-fonts": "4.0.496",
+    "@remotion/transitions": "4.0.496",
+    "react": "^19.0.0",
+    "react-dom": "^19.0.0",
+    "remotion": "4.0.496"
+  },
+  "devDependencies": {
+    "@types/react": "^19.0.0",
+    "typescript": "^5.6.0"
+  }
+}