prod-activation-plan

Activation Plan — Standard Structure

This skill creates a phased activation plan using the EvoNexus standard structure that has been battle-tested: a single index file at the top, folders per phase, one file per item with a rich template. Every file declares its owner agent, decisions pending, dependencies, and suggested implementation team. Oracle uses this skill instead of inventing a plan structure.

Always respond in the user's language (default: pt-BR if the workspace is pt-BR).

When to use

• Oracle's Step 6 (implementation plan delivery) — the canonical trigger
• User asks for an "activation plan", "implementation plan", "rollout plan", "plano de ativação"
• Expanding an existing plan with new axes/pillars (extend, don't duplicate)
• Any multi-phase initiative that needs per-item isolation and discussion

What this skill does NOT do

• It does NOT do business discovery — that's Oracle's Step 2
• It does NOT pick features out of thin air — you must already have the phases and items decided (ideally from Compass)
• It does NOT execute the plan — it only creates the structured artifacts
• It does NOT overwrite existing plans without explicit confirmation

Inputs required

Before invoking this skill, you must have:

1. Plan name — short slug (ex: oracle-implementation-plan-expanded)
2. Plan date — YYYY-MM-DD
3. Context — 2-3 lines about the business and the strategy base (e.g., "Evolution API, 7 axes, Cycle 52 as strategy base")
4. Phases — 2-4 phases, each with: name, timeline window, one-line purpose
5. Items per phase — for each item:
   • ID (ex: 1.1, 1.4a, 2.5)
   • Short name (kebab-case slug for filename)
   • Full title
   • Type: [ATIVAR] | [CONSTRUIR NOVO] | [DECIDIR] | [EVOLUIR]
   • Axis/pillar name
   • Brief description (what is it)
   • Concrete steps (3-6 bullets)
   • Agent/skill/routine involved
   • What the user needs to decide/provide
   • Expected impact
   • Dependencies
   • Risks (if any)
   • Suggested agent team for implementation

If you don't have all of this, ask the user or delegate to Compass first to produce the structured plan, then call this skill to materialize it.

Standard structure

workspace/development/plans/
├── [C]{plan-name}-{YYYY-MM-DD}.md       ← INDEX (single entry point)
├── {phase-1-slug}/                       ← e.g., fase-1-quick-wins/
│   ├── [C]1.1-{item-slug}.md
│   ├── [C]1.2-{item-slug}.md
│   └── ...
├── {phase-2-slug}/
│   └── ...
└── {phase-3-slug}/
    └── ...

Step 1 — Create the folder structure

cd workspace/development/plans/
mkdir -p {phase-1-slug} {phase-2-slug} {phase-3-slug}

Phase slug convention: fase-{N}-{purpose-slug}. Examples:

• fase-1-quick-wins
• fase-2-conexoes
• fase-3-ciclo-completo

Use the purpose of the phase, not just the number.

Step 2 — Write the INDEX file

Write [C]{plan-name}-{YYYY-MM-DD}.md at the root of workspace/development/plans/. The index is a pure navigation file — no duplication of item content. Template:

---
author: claude
agent: {invoking-agent}
type: work-plan-index
date: {YYYY-MM-DD}
plan-name: {plan-name}
status: draft
mode: index
---

# {Plan Title} — {Business/Scope}

**Tipo:** índice. Cada item tem arquivo próprio na pasta da respectiva fase. Este arquivo não duplica o detalhamento — aponta pros arquivos-filhos.

**Estratégia-base:** {link to strategy doc, if any}

---

## Contexto

{2-4 lines: what the plan is, which axes it covers, what it connects.}

## Objetivos

- {Objective 1}
- {Objective 2}
- {Objective 3}

## Guardrails

**Must Have**
- {Constraint 1}
- {Constraint 2}

**Must NOT Have**
- {Anti-constraint 1}
- {Anti-constraint 2}

---

## Visão geral das fases

{Phase 1 name} ({timeline}) → {Phase 2 name} ({timeline}) → {Phase 3 name} ({timeline}) {one-line purpose} {one-line purpose} {one-line purpose}

---

## Fase 1 — {Name} ({timeline})

Pasta: [`{phase-1-slug}/`]({phase-1-slug}/)

| # | Item | Tipo |
|---|---|---|
| 1.1 | [{Item title}]({phase-1-slug}/[C]1.1-{item-slug}.md) | [ATIVAR] |
| 1.2 | [{Item title}]({phase-1-slug}/[C]1.2-{item-slug}.md) | [ATIVAR] |
| ... | ... | ... |

---

## Fase 2 — {Name} ({timeline})

Pasta: [`{phase-2-slug}/`]({phase-2-slug}/)

| # | Item | Tipo |
|---|---|---|
| 2.1 | [{Item title}]({phase-2-slug}/[C]2.1-{item-slug}.md) | [ATIVAR] |
| ... | ... | ... |

---

## Fase 3 — {Name} ({timeline})

Pasta: [`{phase-3-slug}/`]({phase-3-slug}/)

| # | Item | Tipo |
|---|---|---|
| 3.1 | [{Item title}]({phase-3-slug}/[C]3.1-{item-slug}.md) | [ATIVAR] |
| ... | ... | ... |

---

## Decisões críticas pendentes

1. **{Decision 1}** (item X.Y) — {what needs to be decided}
2. **{Decision 2}** (item X.Y) — {what needs to be decided}
3. **{Decision 3}** (item X.Y) — {what needs to be decided}

---

## Histórico de mudanças

- **v1 ({date}):** versão inicial.

Rules for the index:

• Never put item bodies in the index — just titles and links
• Always include the "Decisões críticas pendentes" section — it's the fastest path for the user to spot blockers
• Always include the "Histórico de mudanças" section — future-you will thank present-you
• Link every item to its own file using relative paths

Step 3 — Write one file per item

For each item across all phases, write {phase-slug}/[C]{item-id}-{item-slug}.md using this template:

---
author: claude
agent: {invoking-agent}
type: work-plan-item
date: {YYYY-MM-DD}
phase: {1|2|3}
item-id: {1.1, 1.4a, 2.5, etc}
status: pending
---

# {Item ID}. {Full Title}

**Fase:** {phase name}
**Eixo:** {axis/pillar slug — ex: comunidade, cursos, youtube-lives, redes-sociais, github-open-source, discord-bot, forum-linear}
**Tipo:** {[ATIVAR] | [CONSTRUIR NOVO] | [DECIDIR] | [EVOLUIR]}
**Prazo sugerido:** {window inside the phase — ex: "sem 1" or "13-17/abr"}

## O que é

{2-4 lines describing the objective, no fluff.}

## O que fazer

- {Concrete step 1}
- {Concrete step 2}
- {Concrete step 3}
- {Concrete step 4}

## Agente / Skill / Rotina

{Which agents, skills, or routines from the workspace are involved. Example: "@pixel + skill social-content-calendar + new daily routine in scheduler at 18:15"}

## O que o usuário precisa decidir/fornecer

{List of human-input dependencies. If none, write "Nada além da aprovação pra começar."}

## Impacto esperado

{2-3 lines about the concrete gain when this is running.}

## Dependências

{List of items that must be ready first. Example: "1.4a (calibração)" or "nenhuma".}

## Riscos

{Short list, only if relevant. Example: "régua pode errar em repos novos com pouco contexto"}

## Agente sugerido pra implementação

**Time:** {agent chain — e.g., @compass → @apex → @bolt → @oath}

| Fase | Agente | Papel |
|---|---|---|
| 1. Spec | @compass | Plano 3-6 passos |
| 2. Arquitetura | @apex | ADR + design |
| 3. Build | @bolt | Implementação |
| 4. Verify | @oath | Verificação evidence-based |

**Por quê esse time:** {one-line justification specific to this item}

## Status

- [x] Pendente
- [ ] Em progresso
- [ ] Concluído

Rules for item files

• Every section is mandatory, even if brief
• "Agente sugerido pra implementação" MUST be present — use the routing rules below
• If the team has only 1 agent, use the enxuto format:

  ## Agente sugerido pra implementação
  
  **Agente:** @pixel
  
  **Por quê:** item [ATIVAR] direto — skill já existe, só precisa do agente-dono do domínio.
  

• Status checklist always starts with "Pendente" checked
• Never invent features or dependencies — use only what the caller provided

Step 4 — Agent routing rules (for the "Agente sugerido" section)

Use this table to pick the right team per item type. These rules are the canonical EvoNexus routing for activation plans:

Decision pending items always include @oracle somewhere in the chain — the user needs interactive framing before anyone executes.

Step 5 — Report back

After creating all files, report to the user with:

Plano criado. Estrutura:

workspace/development/plans/
├── [C]{plan-name}-{date}.md       ← índice
├── {phase-1}/  ({N} itens)
├── {phase-2}/  ({N} itens)
└── {phase-3}/  ({N} itens)

Total: {X} itens distribuídos em {Y} fases.

Decisões pendentes ({count}):
- {item-id}: {one-line description}
- ...

Próximo passo sugerido: {item to start with, usually a [DECIDIR] that unblocks the rest}

Expanding an existing plan

If a plan with the same plan-name already exists at that location:

1. Never overwrite without asking. Show the user what exists and what would change.
2. If the user confirms expansion, add phases/items rather than replacing. Update the index's "Histórico de mudanças" with a new version entry (v2, v3…) describing what was added/changed.
3. Preserve existing item files — only create new files for new items. If an existing item needs to be modified, edit it in place and note the change in the index history.

Materializing a Compass plan

When Oracle delegates the plan creation to @compass-planner and receives a structured output, do not write the plan yourself — pass Compass's output to this skill, which materializes it in the standard structure. This is the canonical flow:

Oracle (interview) → Compass (plan) → prod-activation-plan (materialize)

Compass produces the content; this skill produces the structure.

Example — minimal invocation

User (to Oracle): "me monta o plano pra ativar comunidade e redes sociais em 6 semanas"

Oracle:
1. Runs Steps 2-5 (business discovery, capability mapping, wow report)
2. Delegates to @compass-planner to produce the structured plan content
3. Invokes prod-activation-plan skill with Compass's output
4. Reports the created structure back to the user with 3 autonomy paths (Step 7)

The user always sees a single, consistent structure — regardless of which agent produced the plan.