@jaguilar87/gaia 5.0.0-rc.2

package/dist/gaia-ops/skills/request-approval/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: request-approval
+description: Use when a mutative command was blocked by the hook and you need to request user approval, or when presenting a plan for a T3 operation before executing it
+metadata:
+  user-invocable: false
+  type: technique
+---
+
+# Request Approval
+
+## Overview
+
+This skill does not approve anything -- it teaches the agent how to
+**request** approval when the hook blocks a mutative command. The
+orchestrator and the user own approval; the agent owns the request.
+
+The core rule is **attempt first**: do not pre-ask the user for
+permission. Attempt the T3 command, let the hook block it with an
+`approval_id`, then emit `plan_status: "APPROVAL_REQUEST"` with the
+captured `approval_id` in your `approval_request` object. The hook is
+the authoritative gate; the agent only records what happened.
+
+Asking the user before attempting produces two failure modes: the
+agent approves itself on a speculative plan the hook would have
+rejected anyway, or the agent blocks on a command that would have
+passed without any friction. Both waste a turn.
+
+## Attempt First Flow
+
+```
+Agent plans a T3 command
+        |
+Agent EXECUTES the command (does NOT pre-ask)
+        |
+  +-- hook allows -> command runs -> continue
+  |
+  +-- hook blocks with [T3_BLOCKED] + approval_id
+        |
+Agent emits plan_status: "APPROVAL_REQUEST"
+with approval_id in approval_request
+        |
+Orchestrator presents plan to user
+        |
+User approves -> grant activates -> agent retries
+```
+
+## Approval Request Object
+
+Include an `approval_request` object in your `json:contract` with these 6 fields,
+plus `approval_id` when a hook blocked the command:
+
+```json
+"approval_request": {
+  "operation": "verb + target",
+  "exact_content": "literal command, config, or file change",
+  "scope": "files, resources, environments affected",
+  "risk_level": "LOW | MEDIUM | HIGH | CRITICAL",
+  "rollback": "how to undo if wrong",
+  "verification": "how to confirm success after execution",
+  "approval_id": "hex from hook deny response (when blocked)"
+}
+```
+
+### Risk Levels
+
+| Level | Criteria |
+|-------|----------|
+| LOW | Single resource, non-prod, no dependencies |
+| MEDIUM | Multiple resources, non-prod, some dependencies |
+| HIGH | Production, dependencies, potential downtime |
+| CRITICAL | Irreversible, data loss possible |
+
+## Status to Emit
+
+Always emit `plan_status: "APPROVAL_REQUEST"`. The presence or absence
+of `approval_id` tells the orchestrator which path to take:
+
+- With `approval_id` -- the hook blocked; orchestrator activates the grant
+- Without `approval_id` -- plan-first; orchestrator gates on user consent
+
+The legacy name `REVIEW` is gone from runtime. If a doc still references
+`REVIEW` as a plan_status literal, it is drift scheduled for cleanup.
+
+## Hook Block Flow
+
+When a hook blocks your command the deny response includes an
+`approval_id` -- a one-time hex token tied to exactly this command.
+
+The instinct is to retry. That is the wrong move: each retry generates
+a fresh nonce, the old `approval_id` goes stale, and you enter an
+infinite retry-block loop.
+
+Instead: emit `APPROVAL_REQUEST` with the `approval_id` in your
+`approval_request`, stop, and wait. When the user approves, the grant
+activates and the orchestrator resumes you to retry.
+
+Deny message format:
+```
+[T3_BLOCKED] This command requires user approval.
+Do NOT retry this command. Report APPROVAL_REQUEST with this approval_id in your json:contract.
+approval_id: <hex>
+```
+
+If you lose the `approval_id`, re-attempt the command once for a fresh one.
+
+## Dispatch mode and foreground/background
+
+When a subagent edits `.claude/skills/**`, `.claude/agents/**`, `.claude/commands/**`, briefs, plans, or evidence files, the orchestrator **must pass `mode: acceptEdits`** in the Agent tool dispatch. Without it, CC native intercepts with a permission prompt (foreground) or auto-denies (background).
+
+**The `mode` is NOT inherited.** Each dispatch of the Agent tool is independent. If the orchestrator runs with `acceptEdits`, that does not flow to any subagent it invokes. The mode must be specified explicitly in every dispatch that needs it.
+
+**The `mode` also does NOT survive a SendMessage resume.** If your original dispatch gave you `mode: bypassPermissions` and you emit APPROVAL_REQUEST mid-task, the orchestrator's SendMessage resume runs in `default`. The Gaia grant activates for the exact blocked command, but CC native re-blocks the next Edit/Write/Bash on `.claude/` because the mode is gone. Consequence for the subagent: when the task is a multi-step bundle on protected paths (e.g., mv on `.claude/**` + Edits in `.claude/project-context/**`), execute every step in the SAME turn the dispatch started. If a hook blocks a step, emit BLOCKED and stop -- do NOT emit APPROVAL_REQUEST mid-task expecting to continue after a SendMessage resume. The orchestrator will re-dispatch fresh.
+
+**Foreground vs background is a separate axis.** It governs whether a user-facing interaction (like AskUserQuestion) can display. It does not resolve CC native permission prompts -- those are governed by `mode`.
+
+### Combination table
+
+| Case | mode in dispatch | Session type | Expected behavior |
+|------|-----------------|--------------|-------------------|
+| Subagent edits `skills/` with `acceptEdits` | `acceptEdits` | foreground | Edit passes -- no CC native prompt, user sees agent output |
+| Subagent edits `skills/` with default mode | `default` | foreground | CC native prompts the user for consent each Edit/Write |
+| Subagent edits `skills/` with default mode | `default` | background | CC native auto-denies -- agent gets permission error, edit never happens |
+| Subagent edits `skills/` with `acceptEdits` | `acceptEdits` | background | Edit passes -- `mode` covers CC native; background only blocks AskUserQuestion |
+| Subagent tries to edit `.claude/hooks/` | any | any | Gaia `_is_protected()` blocks regardless of mode; approval flow required |
+| Orchestrator edits `skills/` directly (no subagent) | n/a (own session) | foreground | Passes if parent session has `acceptEdits` or CC auto-accepts |
+
+The foreground/background distinction matters for approval flows: AskUserQuestion only works in foreground. In background, the orchestrator cannot present interactive prompts -- T3 operations that require user consent must be deferred or routed to a foreground session.
+
+For the full `permissionMode` comparison, see `security-tiers/SKILL.md`.
+
+## Anti-Patterns
+
+- **Pre-asking the user before attempting** -- violates attempt first; the hook is the gate, not the agent's guess
+- **Retrying after T3_BLOCKED** -- each retry generates a new nonce, making the previous approval_id stale; this loops forever
+- **Missing fields in approval_request** -- the orchestrator presents these fields directly; missing fields mean the user approves blind
+- **Approval fields in prose only** -- the orchestrator parses the JSON object, not your text; prose-only plans bypass the structured flow
+- **Reusing prior approvals** -- grants are scoped to a specific nonce and command; a prior approval does not cover a new operation
+- **Fabricating the approval_id** -- the hook validates against its nonce store; an invented token will never match
+- **Omitting `mode: acceptEdits` from dispatch** -- subagents dispatched without it will hit CC native prompts on `.claude/` writes; in background, this auto-denies silently
+- **Assuming `mode` survives a SendMessage resume** -- it does not; if the task depends on bypass/acceptEdits, pack all steps in one dispatch turn, or emit BLOCKED and let the orchestrator re-dispatch fresh

package/dist/gaia-ops/skills/request-approval/examples.md

@@ -0,0 +1,140 @@
+# Approval Request Examples
+
+Reference examples for agents. Read on-demand when building your first plan or when unsure about format.
+
+## Example 1: Terraform Apply (GCP)
+
+```markdown
+## Terraform Apply Plan
+
+### Summary
+- Creating GCP VPC network for production cluster
+- Adds 3 subnetworks across us-east4-a, us-east4-b, us-east4-c
+- No existing resources affected
+
+### Changes Proposed
+
+**Resources to CREATE:**
+- `google_compute_network.prod-network`: VPC in auto-subnet mode disabled
+- `google_compute_subnetwork.prod-subnet-a`: 10.0.1.0/24 in us-east4-a
+- `google_compute_subnetwork.prod-subnet-b`: 10.0.2.0/24 in us-east4-b
+- `google_compute_subnetwork.prod-subnet-c`: 10.0.3.0/24 in us-east4-c
+
+**Resources to MODIFY:** None
+**Resources to DELETE:** None
+
+### Validation Results
+
+**Dry-run status:**
+- `terragrunt plan` - No errors, 4 to add, 0 to change, 0 to destroy
+- `terragrunt hclfmt --check` - No formatting issues
+- `terraform validate` - Success
+
+**Dependencies verified:**
+- GCP project [project-id]: accessible
+- No CIDR conflicts with existing networks
+
+### Risk Assessment
+
+**Risk Level:** MEDIUM
+
+**Potential Risks:**
+1. CIDR overlap with existing VPC networks
+   - Mitigation: Verified no overlaps via `gcloud compute networks list`
+2. Subnet creation timeout
+   - Mitigation: Timeout set to 300s, idempotent -- safe to retry
+
+**Rollback Plan:**
+- If creation fails: `terragrunt destroy --terragrunt-working-dir "/abs/path/to/terraform/vpc"`
+- Recovery time: ~5 minutes
+
+### Execution Steps
+
+When approved, will execute:
+1. `git add [terraform_vpc_path]/`
+2. `git commit -m "feat(infra): add production VPC network"`
+3. `git push origin main`
+4. `terragrunt apply -auto-approve --terragrunt-working-dir "/abs/path/to/terraform/vpc"`
+
+### Verification Criteria
+
+- `gcloud compute networks describe prod-network --project=[project-id]` -> `status: ACTIVE`
+- `gcloud compute networks subnets list --filter="network:prod-network" --project=[project-id]` -> 3 subnets listed
+
+### Files Affected
+
+**Git changes:**
+- Added: `[terraform_vpc_path]/terragrunt.hcl`
+- Added: `[terraform_vpc_path]/main.tf`
+
+## Approval Required
+
+**Approval Code:** `NONCE:<hex from hook block response>`
+**Operation:** terragrunt apply
+**Environment:** prod
+**Risk Level:** MEDIUM
+```
+
+## Example 2: GitOps Deployment
+
+```markdown
+## GitOps Deployment Plan
+
+### Summary
+- Updating graphql-server image to v1.0.180
+- No configuration changes
+- Flux will auto-reconcile in ~1 minute
+
+### Changes Proposed
+
+**HelmRelease to MODIFY:**
+- `graphql-server` in namespace `common`
+  - Image: ghcr.io/vtr/graphql-server:v1.0.176 -> v1.0.180
+  - No other changes
+
+### Validation Results
+
+**Dry-run status:**
+- `kubectl apply --dry-run=client` - Valid manifest
+- YAML syntax check - Passed
+- Image exists in registry - Verified
+
+### Risk Assessment
+
+**Risk Level:** LOW
+
+**Potential Risks:**
+1. New image might have bugs
+   - Mitigation: Tested in dev cluster, all tests passed
+2. Pod restart might cause brief downtime
+   - Mitigation: RollingUpdate strategy, 2 replicas ensure availability
+
+**Rollback Plan:**
+- If deployment fails: `git revert` + `flux reconcile`
+- Recovery time: ~2 minutes
+
+### Execution Steps
+
+When approved, will execute:
+1. `git add gitops/clusters/prod-digital-eks/common/graphql-server.yaml`
+2. `git commit -m "chore(graphql): update to v1.0.180"`
+3. `git push origin main`
+4. Flux auto-reconciles in ~1 minute (or force: `flux reconcile helmrelease graphql-server -n common --timeout=90s`)
+
+### Verification Criteria
+
+- `kubectl get helmrelease graphql-server -n common --request-timeout=30s` -> `READY=True`, revision contains `v1.0.180`
+- `kubectl get pods -n common -l app=graphql-server --request-timeout=30s` -> all pods `Running`
+
+### Files Affected
+
+**Git changes:**
+- Modified: `gitops/clusters/prod-digital-eks/common/graphql-server.yaml`
+
+## Approval Required
+
+**Approval Code:** `NONCE:<hex from hook block response>`
+**Operation:** git push + flux reconcile
+**Environment:** prod
+**Risk Level:** LOW
+```

package/dist/gaia-ops/skills/request-approval/reference.md

@@ -0,0 +1,57 @@
+# Approval Request Plan Template
+
+Use this template when requesting user approval for a T3 operation.
+The fields below map directly to the `approval_request` object in your `json:contract` block.
+
+```markdown
+## Deployment Plan
+
+### Summary (3-5 bullets)
+- What will be changed
+- Why this change is needed
+- What the expected outcome is
+
+### Changes Proposed
+
+**Resources to CREATE:**
+- [Resource]: [Description]
+
+**Resources to MODIFY:**
+- [Resource]: [What changes] (before -> after)
+
+**Resources to DELETE:**
+- [Resource]: [Why deletion]
+
+### Validation Results
+
+**Dry-run status:**
+- `[simulation command]` - [result summary]
+
+**Dependencies verified:**
+- [Dependency]: Available
+
+### approval_request fields
+
+These 6 fields MUST appear in the `approval_request` object of your `json:contract`:
+
+| Field | Example value |
+|-------|---------------|
+| `operation` | `"apply Terraform changes to dev VPC"` |
+| `exact_content` | `"terraform -chdir=/infra/dev apply -auto-approve"` |
+| `scope` | `"infra/dev/vpc.tf, infra/dev/subnets.tf -- dev environment only"` |
+| `risk_level` | `"MEDIUM"` |
+| `rollback` | `"terraform -chdir=/infra/dev apply -target=module.vpc -var='cidr=10.0.0.0/16'"` |
+| `verification` | `"terraform -chdir=/infra/dev output vpc_id -- expect vpc-xxx"` |
+
+When a hook blocked the command (attempt first path), also include:
+| Field | Example value |
+|-------|---------------|
+| `approval_id` | `"a1b2c3d4e5f6..."` (hex from hook deny response) |
+
+### Files Affected
+
+**Git changes:**
+- Modified: [files]
+- Added: [files]
+- Deleted: [files]
+```

package/dist/gaia-ops/skills/schedule-task/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: schedule-task
+description: Reference material for dispatch parameter extraction and prompt templates. The orchestrator's dispatch execution section covers the core principles -- load this skill for detailed templates and examples.
+metadata:
+  user-invocable: false
+  type: reference
+---
+
+# Schedule Task
+
+On-demand reference for parameter extraction, prompt templates, and task
+classification details. The orchestrator's "Dispatch execution" identity
+section covers when and how to dispatch. Load this skill when you need
+the exact templates or extraction patterns.
+
+## Task classification
+
+| Measurable? | Improvable? | Type | Action |
+|-------------|-------------|------|--------|
+| Yes | Yes (iterative) | agentic-loop | Build loop prompt with all params |
+| Yes | No (pass/fail) | simple-task | Build focused prompt, no loop |
+| Creatable | Yes | two-phase | Phase 1: create eval. Phase 2: agentic-loop |
+| No | N/A | manual-review | Warn user, offer alternatives |
+
+## Parameter extraction (agentic-loop only)
+
+Required: `goal`, `eval_command`, `metric`, `direction`, `threshold`
+Optional: `max_iterations` (default 20), `files_in_scope`, `branch` prefix
+
+If any required param is missing -- ASK the user. Do not guess eval commands
+or thresholds. See `reference.md` for extraction examples and confirmation
+patterns.
+
+## Prompt templates
+
+For agentic-loop tasks, use the template in `reference.md`. The prompt MUST
+include the `Carga la skill agentic-loop` header -- this triggers skill
+injection in the agent.
+
+For simple tasks, build a focused objective prompt without the loop header.
+For two-phase tasks, dispatch Phase 1 first (create eval), then Phase 2 (loop).
+
+## Scheduling with CronCreate
+
+When the user wants recurring execution ("cada noche", "cron", "schedule"):
+- Use `CronCreate` with the built prompt
+- One-shot: `recurring=false`
+- Recurring: `recurring=true` -- warn about 7-day limit
+- See `reference.md` for cron expression examples
+
+## Reading loop_status
+
+When an agent returns `loop_status` in its `json:contract`:
+- `"iterating"` -- agent still working, wait
+- `"threshold_reached"` / `"complete"` -- present: baseline -> final in N iterations
+- `"stopped"` -- present what was achieved + why it stopped
+- `"blocked"` -- present blocker, ask user
+
+## Anti-Patterns
+
+- Dispatching a loop without `eval_command` -- the agent cannot measure progress
+- Including loop protocol details in the dispatch prompt -- `agentic-loop` skill handles that
+- Micromanaging the agent's iterations -- dispatch the goal, not the steps
+- Guessing thresholds the user did not provide

package/dist/gaia-ops/skills/schedule-task/reference.md

@@ -0,0 +1,233 @@
+# Schedule Task -- Reference
+
+Prompt templates, parameter extraction examples, agent selection guide, and scheduling patterns. Read on-demand when dispatching tasks.
+
+## Prompt Templates
+
+### Agentic Loop
+
+```
+## Agentic Loop Task
+
+Carga la skill agentic-loop y sigue su protocolo.
+
+goal: {goal}
+eval_command: {eval_command}
+metric: {metric}
+direction: {direction}
+threshold: {threshold}
+max_iterations: {max_iterations}
+files_in_scope: {files}
+branch: {branch_prefix}-{date}
+```
+
+The `Carga la skill agentic-loop` line triggers skill injection -- it must appear exactly as written. The agent receives the `agentic-loop` skill which governs the entire iteration protocol. Do not duplicate any loop instructions in this prompt.
+
+### Simple Task
+
+```
+## Task
+
+{goal}
+
+Expected outcome: {what success looks like}
+Files in scope: {files}
+Verification: {how to confirm it worked -- test command, expected output, etc.}
+```
+
+No loop header, no iteration parameters. The agent executes once and verifies.
+
+### Two-Phase
+
+**Phase 1 prompt (create eval):**
+```
+## Create Evaluation Script
+
+Goal: Create a repeatable eval command for measuring {metric}.
+The command must print a line matching: METRIC {metric_name}={number}
+
+Context: {what the metric measures and why}
+Files to evaluate: {files}
+Output: A script or command that can run repeatedly and produce consistent measurements.
+```
+
+**Phase 2 prompt (after Phase 1 completes):**
+Use the agentic-loop template above, with `eval_command` set to whatever Phase 1 produced.
+
+## Parameter Extraction Examples
+
+Natural language contains the parameters -- extract them, do not invent them.
+
+| User says | Extracted parameters |
+|-----------|---------------------|
+| "Mejora los tests hasta que pasen al 95%" | goal: improve test pass rate, metric: pass_rate, direction: higher, threshold: 95, eval_command: ASK |
+| "Reduce el bundle size a menos de 200kb" | goal: reduce bundle size, metric: bundle_size_kb, direction: lower, threshold: 200, eval_command: ASK |
+| "Optimiza el tiempo de respuesta del API" | goal: optimize API response time, metric: response_time_ms, direction: lower, threshold: ASK, eval_command: ASK |
+| "Trabaja en esto hasta que no haya errores de lint" | goal: fix all lint errors, metric: error_count, direction: lower, threshold: 0, eval_command: ASK (likely `npm run lint`) |
+| "Cada noche corre los tests y avísame si fallan" | type: simple-task + schedule, recurring: true, cron: nightly |
+| "Itera sobre el CSS hasta que Lighthouse de 90+" | goal: improve Lighthouse score, metric: performance, direction: higher, threshold: 90, eval_command: ASK |
+
+When `ASK` appears, the parameter must be confirmed with the user before dispatch.
+
+### Confirming missing parameters
+
+Present what you extracted and what is missing:
+
+```
+Entendido -- quieres mejorar el pass rate de tests hasta 95%.
+
+Para armar el loop necesito:
+- eval_command: el comando que corre los tests y reporta el porcentaje
+  (e.g., `pytest tests/ --tb=short 2>&1 | python parse_results.py`)
+- files_in_scope: que archivos puede modificar el agente?
+
+Con eso lanzo el loop.
+```
+
+## Agent Selection Guide
+
+Match by the FILES the agent will modify, not by the topic of conversation.
+
+| If the agent needs to modify... | Route to |
+|---------------------------------|----------|
+| `hooks/`, `modules/`, `adapters/`, `skills/`, `agents/`, `config/surface-routing.json` | gaia-system |
+| `src/`, `lib/`, `tests/`, `package.json`, `Dockerfile`, `.github/workflows/` | developer |
+| Kubernetes manifests, `HelmRelease`, `Kustomization`, Flux configs | gitops-operator |
+| `.tf`, `.hcl`, `terragrunt.hcl`, Terraform modules | terraform-architect |
+| Nothing -- inspect logs, pods, cloud resources | cloud-troubleshooter |
+
+When files span two domains (e.g., app code + K8s manifest), dispatch to both agents in parallel with separate prompts.
+
+## CronCreate Examples
+
+### Nightly test run
+
+```
+CronCreate:
+  schedule: "0 3 * * *"        # 3 AM daily
+  prompt: "Run pytest on /path/to/project and report results. If any tests fail, summarize the failures."
+  recurring: true
+```
+
+### Weekly optimization loop
+
+```
+CronCreate:
+  schedule: "0 2 * * 1"        # 2 AM every Monday
+  prompt: |
+    ## Agentic Loop Task
+
+    Carga la skill agentic-loop y sigue su protocolo.
+
+    goal: Improve test coverage
+    eval_command: pytest --cov=src --cov-report=term | python parse_coverage.py
+    metric: coverage_pct
+    direction: higher
+    threshold: 90
+    max_iterations: 15
+    files_in_scope: src/, tests/
+    branch: improve/coverage-{date}
+  recurring: true
+```
+
+### One-shot scheduled task
+
+```
+CronCreate:
+  schedule: "30 22 * * *"      # Tonight at 10:30 PM
+  prompt: "Run the full integration test suite and create a summary report."
+  recurring: false
+```
+
+### Common cron expressions
+
+| Expression | Meaning |
+|-----------|---------|
+| `0 3 * * *` | Every day at 3 AM |
+| `0 2 * * 1` | Every Monday at 2 AM |
+| `0 */6 * * *` | Every 6 hours |
+| `0 9 * * 1-5` | Weekdays at 9 AM |
+| `0 0 1 * *` | First of each month at midnight |
+
+**7-day limit warning:** Recurring cron jobs have a 7-day maximum lifetime. After 7 days, the schedule expires and must be recreated. Always inform the user of this constraint when setting up recurring tasks.
+
+## Example Conversations
+
+### Agentic loop dispatch
+
+**User:** "Mejora la cobertura de tests hasta 90%"
+
+**Classification:**
+- Measurable? Yes (coverage tools exist)
+- Improvable? Yes (can add tests iteratively)
+- Type: agentic-loop
+
+**Missing params:** eval_command, files_in_scope
+
+**Orchestrator response:**
+"Para lanzar el loop de mejora necesito saber:
+1. El comando que mide cobertura (e.g., `pytest --cov=src`)
+2. Que archivos puede tocar el agente?
+Con eso arranco."
+
+**User:** "pytest --cov=src --cov-report=term, puede tocar src/ y tests/"
+
+**Dispatch:** Agent(developer) with agentic-loop prompt, all params filled.
+
+### Simple task dispatch
+
+**User:** "Corre los tests y dime si pasan"
+
+**Classification:**
+- Measurable? Yes
+- Improvable? No (pass/fail, no iteration)
+- Type: simple-task
+
+**Dispatch:** Agent(developer) with simple-task prompt: "Run the test suite and report results."
+
+### Two-phase dispatch
+
+**User:** "Quiero que el API responda en menos de 200ms pero no tengo benchmarks"
+
+**Classification:**
+- Measurable? Creatable (need to build a benchmark first)
+- Improvable? Yes
+- Type: two-phase
+
+**Phase 1 dispatch:** Agent(developer) -- "Create a benchmark script that measures API response time and outputs METRIC response_time_ms={number}"
+
+**Phase 2 dispatch (after Phase 1):** Agent(developer) with agentic-loop prompt using the eval_command from Phase 1.
+
+### Manual review warning
+
+**User:** "Mejora la UX del dashboard"
+
+**Classification:**
+- Measurable? No (subjective, no automated metric)
+- Type: manual-review
+
+**Orchestrator response:**
+"La UX no se puede medir automaticamente -- un loop no puede evaluar mejoras subjetivas. Alternativas:
+1. Si hay metricas proxy (Lighthouse accessibility, load time), puedo iterar sobre esas
+2. Puedo hacer cambios puntuales y presentartelos para review manual
+3. Si defines criterios especificos (e.g., 'reduce clicks to complete X'), puedo medir eso
+
+Cual prefieres?"
+
+### Scheduled task
+
+**User:** "Cada noche corre los tests y avísame si hay fallos"
+
+**Classification:**
+- Type: simple-task + schedule
+- Recurring: true
+
+**Dispatch:**
+```
+CronCreate:
+  schedule: "0 3 * * *"
+  prompt: "Run pytest on /path/to/project. Report any failures with file, test name, and error message."
+  recurring: true
+```
+
+**Orchestrator confirms:** "Listo -- programado para las 3 AM cada noche. Recuerda que los cron jobs expiran a los 7 dias y hay que renovarlos."