prod-activation-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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).

此技能使用经实战验证的EvoNexus标准结构创建分阶段激活计划：顶部设单个索引文件，按阶段创建文件夹，每个事项对应一个包含丰富模板的文件。每个文件会声明其负责Agent、待决策事项、依赖项和建议的实施团队。Oracle使用此技能而非自行设计计划结构。

始终以用户的语言回复（默认：若工作区为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

Oracle的第6步（实施计划交付）——标准触发条件
用户请求“激活计划”“实施计划”“推广计划”“plano de ativação”
扩展现有计划的新维度/支柱（扩展而非重复）
任何需要按事项隔离和讨论的多阶段举措

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

不进行业务探索——这是Oracle的第2步内容
不会凭空生成功能——你必须已确定阶段和事项（理想情况来自Compass）
不执行计划——仅创建结构化工件
未经明确确认不会覆盖现有计划

Inputs required

所需输入

Before invoking this skill, you must have:

Plan name — short slug (ex:
```
oracle-implementation-plan-expanded
```
)
Plan date —
```
YYYY-MM-DD
```
Context — 2-3 lines about the business and the strategy base (e.g., "Evolution API, 7 axes, Cycle 52 as strategy base")
Phases — 2-4 phases, each with: name, timeline window, one-line purpose
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.

调用此技能前，你必须准备好：

计划名称——简短标识（示例：
```
oracle-implementation-plan-expanded
```
）
计划日期——格式为
```
YYYY-MM-DD
```
背景信息——2-3行关于业务和战略基础的描述（例如：“Evolution API，7个维度，以Cycle 52为战略基础”）
阶段——2-4个阶段，每个阶段包含：名称、时间窗口、一行描述的目标
各阶段的事项——每个事项需包含：
- ID（示例：
```
1.1
```
  、
```
1.4a
```
  、
```
2.5
```
  ）
- 短名称（用于文件名的短横线命名格式）
- 完整标题
- 类型：
```
[ATIVAR]
```
  |
```
[CONSTRUIR NOVO]
```
  |
```
[DECIDIR]
```
  |
```
[EVOLUIR]
```
- 维度/支柱名称
- 简要描述（事项内容）
- 具体步骤（3-6个项目符号）
- 涉及的Agent/技能/常规流程
- 用户需要决策/提供的内容
- 预期影响
- 依赖项
- 风险（如有）
- 建议的实施Agent团队

若未准备好以上所有内容，请先询问用户或委托Compass生成结构化计划，再调用此技能将其落地。

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}/
    └── ...

workspace/development/plans/
├── [C]{plan-name}-{YYYY-MM-DD}.md       ← 索引文件（唯一入口）
├── {phase-1-slug}/                       ← 示例：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

步骤1——创建文件夹结构

bash

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.

bash

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

阶段标识命名规范：

fase-{N}-{purpose-slug}

。示例：

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

使用阶段目标命名，而非仅用数字。

Step 2 — Write the INDEX file

步骤2——编写索引文件

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:

markdown

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

在

workspace/development/plans/

根目录下创建

[C]{plan-name}-{YYYY-MM-DD}.md

文件。索引文件是纯导航文件——不重复事项内容。模板如下：

markdown

---
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.}

{2-4行：计划内容、覆盖维度、关联对象}

Objetivos

目标

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

{目标1}
{目标2}
{目标3}

Guardrails

约束规则

Must Have

{Constraint 1}
{Constraint 2}

Must NOT Have

{Anti-constraint 1}
{Anti-constraint 2}

必须包含

{约束1}
{约束2}

禁止包含

{反向约束1}
{反向约束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}

{阶段1名称}（{时间线}）     →    {阶段2名称}（{时间线}）     →    {阶段3名称}（{时间线}）
{一行描述的目标}                    {一行描述的目标}                    {一行描述的目标}

Fase 1 — {Name} ({timeline})

阶段1 — {名称}（{时间线}）

Pasta:

{phase-1-slug}/

#	Item	Tipo
1.1	{Item title}	[ATIVAR]
1.2	{Item title}	[ATIVAR]
...	...	...

文件夹：

{phase-1-slug}/

#	事项	类型
1.1	{事项标题}	[ATIVAR]
1.2	{事项标题}	[ATIVAR]
...	...	...

Fase 2 — {Name} ({timeline})

阶段2 — {名称}（{时间线}）

Pasta:

{phase-2-slug}/

#	Item	Tipo
2.1	{Item title}	[ATIVAR]
...	...	...

文件夹：

{phase-2-slug}/

#	事项	类型
2.1	{事项标题}	[ATIVAR]
...	...	...

Fase 3 — {Name} ({timeline})

阶段3 — {名称}（{时间线}）

Pasta:

{phase-3-slug}/

#	Item	Tipo
3.1	{Item title}	[ATIVAR]
...	...	...

文件夹：

{phase-3-slug}/

#	事项	类型
3.1	{事项标题}	[ATIVAR]
...	...	...

Decisões críticas pendentes

关键待决策事项

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

{决策1}（事项X.Y）—— {需决策内容}
{决策2}（事项X.Y）—— {需决策内容}
{决策3}（事项X.Y）—— {需决策内容}

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

v1（{日期}）： 初始版本。


**索引文件规则：**
- 切勿在索引文件中写入事项正文——仅包含标题和链接
- 必须包含“关键待决策事项”部分——这是用户快速识别障碍的捷径
- 必须包含“变更历史”部分——未来的你会感谢现在的自己
- 使用相对路径将每个事项链接到其独立文件

Step 3 — Write one file per item

步骤3——为每个事项编写独立文件

For each item across all phases, write

{phase-slug}/[C]{item-id}-{item-slug}.md

using this template:

markdown

---
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
---

针对所有阶段的每个事项，使用以下模板创建

{phase-slug}/[C]{item-id}-{item-slug}.md

文件：

markdown

---
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}

{事项ID}. {完整标题}

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"}

阶段： {阶段名称} 维度： {维度/支柱标识——示例：comunidade, cursos, youtube-lives, redes-sociais, github-open-source, discord-bot, forum-linear} 类型： {[ATIVAR] | [CONSTRUIR NOVO] | [DECIDIR] | [EVOLUIR]} 建议期限： {阶段内的时间窗口——示例："sem 1"或"13-17/abr"}

O que é

事项说明

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

{2-4行描述目标，简洁无冗余}

O que fazer

执行步骤

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

{具体步骤1}
{具体步骤2}
{具体步骤3}
{具体步骤4}

Agente / Skill / Rotina

涉及的Agent/技能/常规流程

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

{工作区中涉及的Agent、技能或常规流程。示例："@pixel + skill social-content-calendar + 调度器中新增每日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.}

{2-3行描述事项运行后的具体收益}

Dependências

依赖项

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

{需先完成的事项列表。示例："1.4a（校准）"或"无"}

Riscos

风险

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

{简短列表，仅在相关时填写。示例："规则可能在上下文不足的新仓库中出错"}

Agente sugerido pra implementação

建议的实施Agent团队

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}

团队： {Agent链——示例：@compass → @apex → @bolt → @oath}

阶段	Agent	角色
1. 需求规格	@compass	制定3-6步计划
2. 架构设计	@apex	ADR + 设计
3. 构建	@bolt	实施
4. 验证	@oath	基于证据的验证

选择此团队的原因： {针对该事项的一行理由}

Status

状态

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:

markdown

## 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

所有部分为必填项，即使内容简短
必须包含“建议的实施Agent团队”部分——使用以下路由规则

若团队仅含1个Agent，使用简化格式：

markdown

## 建议的实施Agent团队

**Agent：** @pixel

**原因：** 直接为[ATIVAR]类型事项——技能已存在，仅需领域负责Agent。

状态检查表始终默认勾选“待处理”
切勿凭空生成功能或依赖项——仅使用调用者提供的内容

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

步骤4——Agent路由规则（用于“建议的Agent团队”部分）

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

Item type	Team	Notes
[ATIVAR] — already exists, just wire it up	Domain owner agent (@pixel, @pulse, @atlas, @mentor, @clawdia, @flux, @dex, @nex, @mako, @aria, @zara, @lex, @nova)	No planning layer — just execute.
[DECIDIR] — research, benchmark, calibration	@oracle (conduct) + @scout (data) or @scroll (web research)	Decision must stay interactive with the user.
[CONSTRUIR NOVO] — small/medium	@compass (plan) → domain-owner agent (execute)	Compass ensures 3-6 actionable steps.
[CONSTRUIR NOVO] — large/critical	@oracle (framing) → @compass (plan) → @apex (ADR) → @bolt (execute) → @oath (verify)	Serious items need consensus before code.
[CONSTRUIR NOVO] — with UI	Add @canvas after @apex	UI/UX needs dedicated designer.
[CONSTRUIR NOVO] — with security impact	Add @vault and @grid	Auth, secrets, auditability.
[EVOLUIR] — refine what's running	@compass direct + domain owner	Already has a baseline.

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

使用下表根据事项类型选择合适的团队。这些规则是EvoNexus激活计划的标准路由规则：

事项类型	团队	说明
[ATIVAR] — 已存在，仅需配置	领域负责Agent (@pixel, @pulse, @atlas, @mentor, @clawdia, @flux, @dex, @nex, @mako, @aria, @zara, @lex, @nova)	无需规划层——直接执行。
[DECIDIR] — 研究、基准测试、校准	@oracle（主导） + @scout（数据）或@scroll（网络调研）	决策需与用户保持互动。
[CONSTRUIR NOVO] — 中小型	@compass（规划）→ 领域负责Agent（执行）	Compass确保生成3-6个可执行步骤。
[CONSTRUIR NOVO] — 大型/关键	@oracle（框架搭建）→ @compass（规划）→ @apex（ADR）→ @bolt（实施）→ @oath（验证）	重要事项需在编码前达成共识。
[CONSTRUIR NOVO] — 含UI	在@apex之后添加@canvas	UI/UX需专属设计师。
[CONSTRUIR NOVO] — 涉及安全影响	添加@vault和@grid	认证、密钥、可审计性。
[EVOLUIR] — 优化现有运行内容	@compass直接对接 + 领域负责Agent	已有基础版本。

待决策事项必须在链中包含**@oracle**——用户需在执行前进行互动式框架搭建。

Step 5 — Report back

步骤5——反馈结果

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}

创建所有文件后，向用户反馈：

计划已创建。结构如下：

workspace/development/plans/
├── [C]{plan-name}-{date}.md       ← 索引文件
├── {phase-1}/  ({N}个事项)
├── {phase-2}/  ({N}个事项)
└── {phase-3}/  ({N}个事项)

总计：{X}个事项分布在{Y}个阶段。

待决策事项（{count}个）：
- {item-id}: {一行描述}
- ...

建议下一步：{启动事项，通常为解除其他事项阻塞的[DECIDIR]类型事项}

Expanding an existing plan

扩展现有计划

If a plan with the same

plan-name

already exists at that location:

Never overwrite without asking. Show the user what exists and what would change.
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.
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.

若同一位置已存在同名

plan-name

的计划：

未经询问切勿覆盖。向用户展示现有内容及拟变更内容。
若用户确认扩展，添加阶段/事项而非替换。在索引文件的“变更历史”中添加新版本条目（
```
v2
```
、
```
v3
```
…）描述新增/变更内容。
保留现有事项文件——仅为新事项创建新文件。若需修改现有事项，直接编辑并在索引历史中记录变更。

Materializing a Compass plan

落地Compass计划

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.

当Oracle将计划创建委托给@compass-planner并收到结构化输出时，请勿自行编写计划——将Compass的输出传递给此技能，由其以标准结构落地。这是标准流程：

Oracle（访谈）→ Compass（制定计划）→ prod-activation-plan（落地）

Compass生成内容；此技能生成结构。

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.

用户（向Oracle）："帮我制定6周内激活社区和社交媒体的计划"

Oracle：
1. 执行步骤2-5（业务探索、能力映射、亮点报告）
2. 委托@compass-planner生成结构化计划内容
3. 使用Compass的输出调用prod-activation-plan技能
4. 向用户反馈创建的结构及3条自主路径（步骤7）

无论哪个Agent生成计划，用户看到的始终是统一一致的结构。