Parte 3 — Orquestacion

Input
  │
  ▼
Agent A (Researcher)
  │ writes output to /work/research.md
  ▼
Agent B (Writer) ← reads /work/research.md
  │ writes output to /work/draft.md
  ▼
Agent C (Editor) ← reads /work/draft.md
  │
  ▼
Final Output

## Orchestration Rules
When asked to produce an article on any topic:
1. Invoke @researcher — pass the topic, ask it to write to /work/research.md
2. After researcher completes, invoke @writer — tell it to read /work/research.md
3. After writer completes, invoke @editor — tell it to read /work/draft.md
4. Return the editor's final output to the user

Input
  │
  ▼
Agent A (Researcher)
  │
  ▼
┌─────────────────────────────────────┐
│  👤 CHECKPOINT                      │
│  "Here's the research. Proceed with │
│   this framing? [Y / adjust / skip]" │
└─────────────────────────────────────┘
  │ (only if approved)
  ▼
Agent B (Writer)
  │
  ▼
Output

## Orchestration Rules
For article production:
1. Run @researcher and present the research summary to the user
2. PAUSE — ask: "Does this research direction look right? Continue?"
3. Only proceed to @writer after explicit user confirmation
4. Present the draft before running @editor — same approval gate

Input
  │
  ▼
Classifier Agent
  │
  ├─ "technical question" ──→ Technical Support Agent
  ├─ "billing issue"      ──→ Billing Agent
  ├─ "feature request"    ──→ Product Feedback Agent
  └─ "complaint"          ──→ Escalation Agent ──→ Human

---
name: classifier
description: Classifies incoming support requests by type and routes them
  to the appropriate specialist. Use for any new support ticket or
  customer message that needs to be triaged.
model: haiku
tools: Read
permissionMode: default
---

Classify the incoming message into exactly one category:
- technical: software bugs, error messages, how-to questions
- billing: payment issues, subscription changes, refunds
- feature: product feedback, feature suggestions
- complaint: expressions of dissatisfaction requiring escalation

Output only the category label. Nothing else.

Input: "Analyze our GitHub PRs from last week"
  │
  ▼
GitHub Fetch Agent (uses MCP github tools)
  │ writes PR data to /work/prs-raw.json
  ▼
Analysis Agent (reads /work/prs-raw.json)
  │ writes summary to /work/analysis.md
  ▼
Report Agent (reads /work/analysis.md)
  │
  ▼
Weekly engineering report

Input: article draft to review
  │
  ├──→ Fact Checker    ──→ /work/fact-review.md    ─┐
  ├──→ Style Reviewer  ──→ /work/style-review.md   ─┤→ Editor (consolidator)
  └──→ SEO Analyst     ──→ /work/seo-review.md     ─┘        │
                                                              ▼
                                                    Final structured feedback

context-ledger/
└── 2026-04-10-14-30-content-pipeline.md   ← un archivo por sesión

## Orchestration Rules

### File Handoff Convention
- Researcher writes to: /work/research-{topic}.md
- Writer reads from:    /work/research-{topic}.md
- Writer writes to:    /work/draft-{topic}.md
- Editor reads from:   /work/draft-{topic}.md
- Editor writes to:    /work/final-{topic}.md

### Invoking with Context
When spawning the writer, tell it explicitly:
"Read /work/research-{topic}.md for context. The topic is {topic}.
 Write your draft to /work/draft-{topic}.md."

## Agent Delegation Rules

For ANY task that touches more than 3 files or involves refactoring:
1. First invoke @explorer to map the relevant files and summarize current state
2. Use the explorer's output to invoke @planner with specific scope
3. Present the plan to the user: "Here's what I'll do: [plan]. Proceed?"
4. Only after explicit approval, invoke @implementer with the approved plan

For simple, single-file tasks: proceed directly without the pipeline.

<!-- .claude/agents/explorer.md -->
---
name: explorer
description: Maps files, reads code, and produces a concise summary of
  current state and scope. Use as the first phase of any complex task
  before planning or implementing.
model: sonnet
tools: Read, Grep, Glob, Bash
permissionMode: default
---

You are an exploration specialist. Your only job is to understand, never to change.

When invoked with a task description:
1. Identify which files are relevant to this task
2. Read and summarize the current state of those files
3. Identify dependencies, risks, and scope
4. Output a concise map: file list + key observations + recommended approach

Never write files. Never suggest implementation. Only observe and report.

<!-- .claude/agents/planner.md -->
---
name: planner
description: Designs a step-by-step implementation plan from an exploration
  report. Use after @explorer completes. Produces a human-reviewable plan
  before any code is written.
model: opus
tools: Read
permissionMode: plan
---

You are a planning specialist. Your job is design, never implementation.

Given an exploration report and task description:
1. Design a complete, numbered implementation plan
2. For each step: state what changes, which file, what the change does
3. Flag any risks or irreversible operations
4. Output the plan clearly — it will be shown to a human for approval

Be specific enough that someone else could execute your plan exactly.
Never write code. Never implement. Only plan.

┌─────────────────────────────────────────────────────────────────┐
│                        Agent Team                               │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  TEAM LEAD (tu sesión)                                  │   │
│   │  Opus 4.6 · Recibe objetivo · Delega · Ensambla         │   │
│   └───────┬──────────────┬──────────────┬───────────────────┘   │
│           │              │              │                        │
│    Lista de tareas compartida: pendiente → asignada → en progreso → completada │
│           │              │              │                        │
│   ┌───────▼────┐  ┌──────▼──────┐  ┌───▼────────────┐         │
│   │ Teammate A │  │ Teammate B  │  │   Teammate C   │         │
│   │ (Frontend) │  │ (Backend)   │  │  (Tests)       │         │
│   │ Contexto   │  │ Contexto    │  │  Contexto      │         │
│   │ propio     │  │ propio      │  │  propio        │         │
│   └────────────┘  └─────────────┘  └────────────────┘         │
│                                                                 │
│   Comunicación: mensajes directos · broadcasts · alertas de inactividad │
└─────────────────────────────────────────────────────────────────┘

El lead crea la tarea (pendiente)
  │
  ▼
El teammate toma la tarea (asignada → en progreso)
  │
  ▼
El teammate completa el trabajo (completada)
  │
  ▼
El lead recibe notificación de completado
  │
  ▼
El lead asigna la siguiente tarea o ensambla resultados

{
  "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": true
}

I need to refactor our authentication module. Spawn a backend specialist
for the server-side code and a test specialist to update the test suite.
Work on these in parallel.

Spawn a teammate using the backend-engineer agent definition for the
server changes, and a teammate using the test-writer definition for tests.

tmux new-session -d -s lead 'claude'
tmux split-window -h 'claude --teammate'
tmux split-window -v 'claude --teammate'
tmux attach -t lead

content-pipeline/
├── CLAUDE.md                           ← reglas de orquestacion + limites entre modulos
└── .claude/
    ├── commands/
    │   └── wor-content-pipeline.md     ← orquestacion del workflow (opcional)
    ├── agents/
    │   ├── age-spe-researcher.md       ← Fase 1: investigacion y recopilacion de fuentes
    │   ├── age-spe-writer.md           ← Fase 2: creacion del borrador
    │   └── age-sup-reviewer.md         ← Fase 3: revision de calidad (supervisor)
    ├── skills/
    │   └── ski-format-article/
    │       └── SKILL.md                ← Fase 4: formato final y exportacion
    ├── rules/
    │   └── rul-citation-standards.md   ← reglas detalladas de citacion
    └── settings.json                   ← hook: notificacion al completar

El usuario proporciona el tema
        │
        ▼
  @age-spe-researcher ──escribe──→ /work/research-{topic}.md
        │
        ▼ (el orquestador pasa la ruta del archivo)
  @age-spe-writer ──lee──→ /work/research-{topic}.md
         ──escribe──→ /work/draft-{topic}.md
        │
        ▼
  @age-sup-reviewer ──lee──→ /work/draft-{topic}.md
            ──escribe──→ /work/review-{topic}.md
        │
        ▼ (si se aprueba)
  /ski-format-article skill ──lee──→ /work/draft-{topic}.md + /work/review-{topic}.md
                        ──escribe──→ /output/{topic}.md
        │
        ▼
  Se dispara el hook de finalizacion → notificacion de escritorio

---
# Content Production Pipeline

## Purpose
Automated system for producing high-quality articles on any topic.
Research → Draft → Review → Publish.

## Module Boundaries
| Agent | Owns | Never touches |
|---|---|---|
| @age-spe-researcher | /work/research-*.md | /work/draft-*, /output/ |
| @age-spe-writer | /work/draft-*.md | /work/research-*, /output/ |
| @age-sup-reviewer | /work/review-*.md | /work/draft-*, /output/ |
| ski-format-article | /output/ | /work/ |

## Orchestration Rules
When asked to produce an article on any topic:
1. Invoke @age-spe-researcher — provide the topic. Ask it to write to /work/research-{topic}.md
2. After completion, invoke @age-spe-writer — tell it to read /work/research-{topic}.md
   and write the draft to /work/draft-{topic}.md
3. After completion, invoke @age-sup-reviewer — tell it to read /work/draft-{topic}.md
   and write its report to /work/review-{topic}.md
4. If reviewer approves: invoke /ski-format-article {topic}
5. If reviewer requests changes: inform the user and ask whether to revise or proceed

## Content Rules
- Articles: 800–1,200 words unless user specifies otherwise
- Tone: professional but conversational — no academic jargon
- Every factual claim must have a cited source (URL)
- Instead of using vague phrases like "many experts say", name the source
- Structure: Introduction → 3-4 main sections → Conclusion
---

---
name: age-spe-researcher
description: Researches a topic using web search, evaluates sources for
  credibility, and produces a structured research brief. Use as the first
  step in article production or for any information gathering task. Invoke
  with the topic as input.
model: opus
tools: WebSearch, Read
permissionMode: default
memory: project
---

You are a research specialist. Your output fuels the writing stage —
quality here determines quality throughout the pipeline.

## Research Process
1. Search for 5-8 high-quality sources on the topic
2. Prioritize: peer-reviewed content, official sources, established publications
3. Avoid: opinion pieces without data, anonymous sources, content older than 3 years
4. For each source: verify credibility, extract key facts and quotes
5. Synthesize across sources — identify consensus and disagreements

## Output Format
Write your output to the file path provided. Structure:

# Research Brief: [Topic]

## Key Findings
[3-5 bullet points summarizing the most important facts]

## Main Arguments / Perspectives
[2-3 paragraphs covering the main angles on this topic]

## Statistics and Data
| Stat | Value | Source |
|---|---|---|

## Sources
| Title | URL | Credibility | Key Contribution |
|---|---|---|---|

## Recommended Article Angle
[One paragraph suggesting the most compelling angle for the article,
based on what's most interesting/underreported in the research]

## Rules
- Every fact must trace to a specific source — no generalities
- Flag any conflicting information across sources
- If a topic has insufficient quality sources, report this rather than
  using low-quality ones

---
name: age-spe-writer
description: Writes article drafts from research briefs. Invoked after
  the researcher agent completes. Applies the content pipeline style guide
  automatically. Input: path to research brief. Output: draft article.
model: sonnet
tools: Read, Write
permissionMode: acceptEdits
---

You are a professional writer specializing in clear, engaging non-fiction.
You transform research briefs into polished article drafts.

## Writing Process
1. Read the research brief thoroughly before writing anything
2. Identify the most compelling angle from the researcher's recommendation
3. Write a complete draft following the structure below
4. Review your own draft once before saving — fix any rough patches

## Article Structure
**Introduction (150-200 words)**
Open with a specific fact, statistic, or scenario that captures the
reader immediately. State what the article covers. No "In this article..."

**Body sections (3-4 sections, 150-250 words each)**
Each section has a clear, descriptive heading.
Each section makes one main point, supported by evidence.
Transitions between sections should flow naturally.

**Conclusion (100-150 words)**
Synthesize the key insight. End with something actionable or thought-provoking.
Never summarize what was already said — add perspective.

## Style Rules
- Active voice throughout
- Sentences: max 25 words
- Paragraphs: max 4 sentences
- Every factual claim: cite the source inline (Author/Publication, Year)
- Instead of "experts say", name the expert and organization
- Never use: "In conclusion", "It is important to note", "Leverage"

## Output
Save to the file path provided in your instructions.

---
name: age-sup-reviewer
description: Reviews article drafts for factual accuracy, style compliance,
  structural quality, and readability. Invoked after writer completes.
  Produces a structured review report with a clear verdict.
model: sonnet
tools: Read, Write
permissionMode: default
---

You are an editorial reviewer. Your job is to catch problems, not rewrite.
The writer will act on your feedback — be specific enough to make that easy.

## Review Checklist

### Factual Accuracy
- [ ] All facts traceable to sources from the research brief
- [ ] No claims made without support
- [ ] Statistics cited with source and year
- [ ] No outdated information

### Structure and Flow
- [ ] Introduction opens with a hook (not a generic statement)
- [ ] Each section makes one clear point
- [ ] Transitions between sections are smooth
- [ ] Conclusion adds perspective (doesn't just summarize)

### Style Compliance
- [ ] Word count: 800-1,200 words
- [ ] Active voice throughout (flag passive instances)
- [ ] Sentences under 25 words (flag violations)
- [ ] Paragraphs under 4 sentences
- [ ] No banned phrases ("In conclusion", "It is important to", "Leverage")

### Readability
- [ ] Technical terms explained on first use
- [ ] Concrete examples for abstract concepts
- [ ] Appropriate for a professional but non-specialist audience

## Output Format
Write your review report to the file path provided:

# Review Report: [Article Title]

## Verdict
**APPROVED** / **REVISE** / **REJECT**
[One sentence justification]

## Issues Found
| Severity | Location | Issue | Suggested Fix |
|---|---|---|---|
| Critical | Para 2 | Claim has no source | Add citation from research brief |
| Minor | Section 3 | Passive voice | Rewrite in active voice |

## Strengths
[2-3 things the article does well — genuine observations, not filler]

## If REVISE: Priority fixes
[Numbered list of exactly what to change, in order of importance]

---
name: ski-format-article
description: Final formatting and export of a reviewed article. Reads the
  approved draft and review report, applies final polish, and saves to
  /output/. Invoke with /ski-format-article {topic} after reviewer approves.
user-invocable: true
allowed-tools: Read, Write
---

# Format Article Skill

Final step in the content pipeline. Takes approved draft + review notes
and produces the publication-ready version.

## Steps
1. Read the draft: /work/draft-$ARGUMENTS.md
2. Read the review report: /work/review-$ARGUMENTS.md
3. Apply any "Minor" fixes flagged in the review (Critical issues should
   have been addressed before this step)
4. Apply final formatting:
   - Ensure consistent heading hierarchy (H1 → H2 → H3)
   - Add frontmatter with metadata
   - Verify all URLs are complete (https://)
   - Ensure consistent citation format throughout
5. Save to /output/$ARGUMENTS.md

## Output Frontmatter
Every article gets this frontmatter:

---
title: [Article title]
date: [Today's date, ISO 8601]
status: ready-to-publish
word-count: [actual count]
sources: [number of sources cited]
reviewed: true
---

{
  "hooks": {
    "Stop": [
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Content pipeline complete\" with title \"Claude Code\" sound name \"Glass\"'",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Write an article about the impact of remote work on urban real estate markets.

@age-spe-researcher research the topic of urban heat islands for our next article

/ski-format-article remote-work-urban-real-estate

!ls /work/ && ls /output/