Skip to content
Automation
Skill

/prod-activation-plan

Create a phased activation plan using the EvoNexus standard structure — single index file + folder-per-phase + file-per-item, each item detailed with owner, dependencies, decisions pending, suggested agent team. Use when the user asks for an activation plan, implementation plan,

From plugin
evo-nexus
520193 skills38 agents40 commands9 MCP
Install
$ npx -y skills add evolution-foundation/evo-nexus --skill prod-activation-plan --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/prod-activation-plan

Context preview

The summary Claude sees to decide when to auto-load this skill.

Create a phased activation plan using the EvoNexus standard structure — single index file + folder-per-phase + file-per-item, each item detailed with owner, dependencies, decisions pending, suggested agent team. Use when the user asks for an activation plan, implementation plan,

SKILL.md

prod-activation-plan.SKILL.md
name: prod-activation-plan
description: "Create a phased activation plan using the EvoNexus standard structure — single index file + folder-per-phase + file-per-item, each item detailed with owner, dependencies, decisions pending, suggested agent team. Use when the user asks for an activation plan, implementation plan, rollout plan, or any phased plan for business/engineering initiatives. Also triggered by Oracle's Step 6 (implementation plan delivery) instead of writing an ad-hoc 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: {
Read more
Ships withevo-nexus

The open source operating system for AI-powered businesses

Get the whole plugin

Other skills on evo-nexus.