atlas-workflow 0.8.2

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-backlog-generator/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: atlas-backlog-generator
+description: Skill `atlas-backlog-generator`. Use somente quando o usuário acionar explicitamente `$atlas-backlog-generator` ou pedir explicitamente para criar, gerar, montar, estruturar ou atualizar um backlog mestre Atlas a partir de uma conversa, prompt, ideia de feature, briefing, PRD macro, lista solta de requisitos, roadmap ou objetivo de produto, usando `BACKLOG_MESTRE_TEMPLATE.md` como template canônico e aplicando fases, sprints, dependências, MoSCoW e esforço x ganho. Não usar por inferência implícita em pedidos genéricos de planejamento, brainstorming, PRD ou implementação.
+---
+
+# Atlas Backlog Generator
+
+Crie backlogs mestres Atlas em PT-BR, ancorados no template canônico, com decomposição gradual em fases e sprints pequenas, priorização MoSCoW, matriz esforço x ganho, dependências explícitas, gates, riscos e próxima sprint executável.
+
+Esta skill é documental: ela cria ou atualiza o `BACKLOG_MESTRE*.md` no projeto consumidor. Ela não implementa código, não gera PRDs de sprint e não substitui `atlas-sprint-prd-generator`.
+
+Acione esta skill apenas por pedido explícito. Se o usuário apenas pedir planejamento, brainstorming, PRD ou execução, não usar esta skill automaticamente.
+
+---
+
+## Entradas aceitas
+
+- Conversa livre, ideia de feature, prompt exploratório ou briefing incompleto.
+- PRD macro, roadmap, lista de requisitos, issue/backlog item ou texto colado pelo usuário.
+- Opcional: nome do projeto/feature, path de saída, fontes canônicas, restrições técnicas, prioridade de negócio e escopo fora do ciclo.
+
+Se faltar informação não bloqueante, gere o backlog com premissas marcadas e registre perguntas/riscos. Pergunte antes de salvar somente quando faltar uma das decisões bloqueantes: resultado final esperado, fronteira de escopo ou plataforma/produto alvo.
+
+---
+
+## Workflow obrigatório
+
+1. **Resolver template canônico:** descubra a raiz do plugin/bundle e leia `packages/templates/BACKLOG_MESTRE_TEMPLATE.md`. Se ausente, aborte com: `Template canônico ausente: BACKLOG_MESTRE_TEMPLATE.md`.
+2. **Entender pedido:** extraia objetivo, usuários, resultado final esperado, fora de escopo, restrições, dependências, riscos, stakeholders e sinais de valor.
+3. **Inspecionar contexto real:** quando houver repo/projeto ativo, busque documentos existentes (`BACKLOG_MESTRE*.md`, `PRD*.md`, `ROADMAP*.md`, specs, OpenAPI, docs de arquitetura) e código que influencie dependências. Não invente contrato técnico.
+4. **Fechar ambiguidade crítica:** se uma decisão bloquear a decomposição segura, faça até 3 perguntas objetivas. Se o usuário não responder e houver caminho razoável, registre a premissa como risco/decisão pendente.
+5. **Preencher o template:** mantenha todas as seções do template e substitua placeholders por conteúdo específico. Não apague seções; use `não aplicável` apenas com justificativa curta.
+6. **Decompor em sprints:** transforme o objetivo em fatias verticais pequenas, cada uma com objetivo único, dependências e PRD futuro (`PRD_S<NN>_<slug>.md`).
+7. **Priorizar:** para cada sprint, preencha MoSCoW, ganho, esforço e prioridade usando a regra da seção 8.3 do template.
+8. **Selecionar próxima sprint:** escolha a primeira sprint executável respeitando dependências, DoR, MoSCoW, esforço x ganho e risco. Registre a justificativa na seção 20.
+9. **Salvar artefato:** grave o backlog no path pedido ou, se não houver path, crie o diretório `.atlas/backlog/` no projeto consumidor e use `.atlas/backlog/BACKLOG_MESTRE_<slug>.md`.
+10. **Validar antes de finalizar:** releia o arquivo salvo e confirme que não restaram placeholders acidentais, exceto campos conscientemente pendentes e marcados.
+
+---
+
+## Regras de decomposição
+
+- Gere sprints como unidades de entrega, não períodos de tempo.
+- Mantenha cada sprint com 6 a 8 tasks no máximo quando o PRD futuro for detalhado; se uma sprint tiver mais de um objetivo, quebre em `S<NN>a/b/c`.
+- Comece com descoberta/contrato quando houver ambiguidade ou integração. Não pule para implementação quando o contrato ainda for desconhecido.
+- Preserve a ordem natural: descoberta → especificação/contrato → backend/infra quando necessário → front/app → hardening → QA → rollout.
+- Use dependências para permitir paralelismo seguro; não transforme fase em fila rígida se duas sprints independentes puderem avançar.
+- Inclua estados de erro, loading, empty, permission, observabilidade, QA e rollout onde aplicável. Esses itens não são “extras”; são parte do produto pronto.
+
+---
+
+## Regras de priorização
+
+- `Must`: obrigatório para resultado final, segurança, compliance, contrato ou desbloqueio.
+- `Should`: importante para qualidade/adoção, mas contornável por um ciclo.
+- `Could`: refinamento ou melhoria desejável que não bloqueia entrega.
+- `Won't now`: fora do ciclo atual; registre para reduzir reabertura de discussão.
+- `P0`: alto ganho com baixo/médio esforço ou Must desbloqueador.
+- `P1`: alto ganho com alto esforço, ou médio ganho com baixo esforço.
+- `P2`: médio ganho/médio esforço, ou baixo ganho/baixo esforço.
+- `P3`: baixo ganho com médio/alto esforço, candidato a adiar.
+
+Se MoSCoW e esforço x ganho conflitarem, MoSCoW vence; uma sprint `Must` de esforço alto deve ser quebrada, não rebaixada silenciosamente.
+
+---
+
+## Qualidade esperada do backlog
+
+O backlog final deve:
+
+- Declarar precedência documental e fontes canônicas.
+- Explicitar resultado esperado e fora do escopo.
+- Ter dependências internas/externas e decisões bloqueantes com dono/status.
+- Ter registro de sprints com MoSCoW, ganho, esforço, prioridade, PRD futuro, dependências, estado e gate.
+- Ter grafo de dependência coerente com a tabela de sprints.
+- Ter catálogo de fases preservado e adaptado apenas quando necessário.
+- Ter riscos, decisões e próxima sprint executável preenchidos.
+- Ser específico o bastante para gerar PRDs de sprint depois com `atlas-sprint-prd-generator`.
+
+---
+
+## Proibições
+
+- Não entregar uma lista genérica de tarefas sem usar o template.
+- Não remover gates, DoR/DoD, riscos, decisões ou trilhas transversais.
+- Não inventar endpoints, tabelas, schemas, fornecedores, métricas ou responsabilidades como fatos. Quando forem hipóteses, marcar como premissa.
+- Não transformar o backlog em plano técnico de implementação. Código, classes e comandos entram no plano/PRD quando apropriado, não no backlog mestre.
+- Não deixar `[...]` ou placeholders óbvios no arquivo final, salvo quando o campo estiver deliberadamente pendente e explicado.

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-backlog-generator/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Atlas Backlog Generator"
+  short_description: "Cria backlog mestre Atlas a partir de ideia, prompt ou conversa."
+  default_prompt: "Crie um backlog mestre Atlas para esta ideia de feature:"

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-direct-execute/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: atlas-direct-execute
+description: Execute a scoped PRD, task, or implementation slice directly using a compact execution contract, PRD obligation tracking, finite task gates, bounded repair, and mandatory cold validation via atlas-task-validator. Use when the user provides a PRD/spec/path or a debated task and wants implementation now without first producing a separate planning artifact. Preserve evidence against acceptance criteria, dependencies, fixtures, and invariants.
+---
+
+# Atlas Direct Execute
+
+## Purpose
+
+Execute directly from a PRD/spec/task while preserving execution quality: explicit scope, obligations, invariants, task order, risks, and validation. Do not write a separate planning artifact unless the user asks.
+
+This is not planless execution. Replace the visible markdown plan with a compact operational contract held in the current turn and passed to validation.
+
+## Use Criteria
+
+Use when all are true:
+
+- User wants implementation, not a planning artifact.
+- Scope is a PRD/spec/path or a debated task with clear boundaries.
+- Work fits one coherent slice or a bounded task sequence.
+- Execution happens in the same chat/context.
+- A compact contract can be materialized into the state file boundary required by `atlas-task-validator`.
+
+Do not use when any are true:
+
+- User asks only for planning, review, explanation, or handoff artifact.
+- Product rules, permissions, backend contract, migrations, security, or data-loss risk are materially ambiguous.
+- The PRD/spec conflicts with code or adjacent docs in a way that blocks implementation.
+
+## Workflow
+
+### 0. Triage
+
+Before implementation, decide one exact path:
+
+- `direct`: proceed with this skill.
+- `blocked`: ask for the missing decision or environment.
+
+Ask at most 1-3 blocking questions only when a reasonable assumption could change product behavior, contract, permissions, persistence, or user-visible outcome. Otherwise state assumptions and proceed.
+
+### 1. Load inputs
+
+Read the user-provided PRD/spec/task and any directly referenced files needed to resolve scope. If the input names repo artifacts, verify those artifacts exist before editing.
+
+Extract only execution-relevant items:
+
+- in scope / out of scope
+- acceptance criteria and required deliverables
+- accepted decisions
+- invariants and "do not change" rules
+- contracts, entities, routes, schemas, wrappers, generated files
+- dependency contracts that must be consumed, bridged, or preserved
+- fixture requirements and scenario language such as "weeks", "profiles", "matrix", "sequence", or "integration"
+- validation requirements
+- regression risks
+- likely files/modules
+
+If the PRD references another PRD or code contract as dependency, inspect enough to confirm the dependency shape and required bridge. Do not satisfy a dependency by creating parallel synthetic contracts unless the PRD explicitly allows it.
+
+### 2. Build Compact Execution Contract
+
+Before editing, write a compact contract in the working response or internal task state. Size follows complexity: terse for simple tasks, denser only where needed to preserve scope, invariants, and validator quality.
+
+Required shape:
+
+```text
+Direct Execute Contract
+- Goal:
+- Boundary:
+- In scope:
+- Out of scope:
+- Obligations:
+- Invariants:
+- Dependency bridges:
+- Fixtures/scenarios:
+- Scenario probes:
+- Risk probes:
+- Task order:
+- Validation:
+- Stop conditions:
+```
+
+Do not expand this into a separate planning artifact. The goal is execution guardrails, not transfer documentation. The contract may be terse in the user-visible response, but it must be concrete enough to materialize into `.atlas/state/<run_id>/<slice>.json` and referenced evidence for `atlas-task-validator`.
+
+Obligations are mandatory. Convert every PRD acceptance criterion and explicit deliverable into one compact row:
+
+```text
+O1 <requirement> -> evidence: <file/test/check>
+```
+
+When the PRD asks for fixtures, profiles, weeks, matrices, bridges/adapters, immutability, determinism, or calendar semantics, name those explicitly in `Obligations`. Do not collapse them into generic "tests cover rules".
+
+Add a closure analysis packet before implementation starts. Keep it compact, but concrete enough that a cold validator can hunt omissions instead of only confirming obvious files:
+
+- `Invariant ledger`: each invariant or "do not change" rule, with expected code evidence.
+- `Scenario probes`: negative, repeated, empty/null, out-of-order, partial failure, stale state, permission, and cleanup scenarios relevant to this slice.
+- `Contract probes`: DTO/entity/schema/route/RPC/generated/localization/import boundaries that could drift.
+- `Risk probes`: each regression risk translated into a specific question the validator must answer from code.
+- `Validation map`: which checks prove which obligations, and which obligations remain only manually evidenced.
+
+If a probe is irrelevant, omit it. Do not write generic probes such as "check edge cases"; name the exact state, actor, field, route, or failure mode.
+
+### 3. Implement by finite tasks
+
+Execute one task at a time. Prefer this order when applicable:
+
+1. contracts/types/domain
+2. dependency bridges/adapters from existing models or contracts
+3. datasource/client boundary
+4. repository/use case/state
+5. UI/route wiring
+6. fixtures/tests/generation/docs required for closure
+
+For each task, keep a tiny task contract:
+
+- objective
+- files likely touched
+- invariants at risk
+- obligations satisfied
+- focused check
+- repair budget
+
+Do not widen scope for opportunistic cleanup.
+
+### 4. Gate each task
+
+Run focused checks appropriate to the diff:
+
+- targeted tests
+- analyzer/typecheck/lint
+- codegen/localization/schema checks when relevant
+- diff scan for scope creep
+- runtime/browser verification when UI changed
+
+If a check fails, classify:
+
+- `fixable`: caused by current diff and repairable inside budget
+- `blocked`: missing env, upstream failure, ambiguous contract, or required decision
+- `pre-existing`: outside slice; report, do not repair unless blocking closure
+
+Repair only current-diff failures. Stop after repeated failure or budget exhaustion.
+
+### 5. Mandatory cold validation
+
+After tasks and local gates pass, write `.atlas/state/<run_id>/<slice>.json` following `packages/templates/STATE_FILE_SCHEMA.md`.
+
+For direct execution, the state file is still the only validator input. Use the user-provided PRD/spec path as `plan_path` when no handoff plan exists, and include direct-contract anchors in `boundary_refs` such as `direct.O1`, `direct.invariant.permissions`, or `direct.risk.partial_failure`.
+
+The state file is the only validator input. Validation is always **sibling**, on every host: this executor **never** dispatches `atlas-task-validator` itself and never validates its own work in the same context. After tasks and local gates pass and the state file is written, this executor **stops mutation** and returns `validator_handoff_required` with the `state_path`. The orchestrator then dispatches `atlas-task-validator` as the next isolated sibling phase, locks it via `atlas_lock_validator`, and — if the verdict is `fail` — dispatches `atlas-findings-repair` (not this executor) before the **2nd and last** validator.
+
+Do not paste the compact contract, diff, obligation ledger, local checks, or closure analysis packet into the state file's handoff. Those belong in the state file and referenced artifacts.
+
+**Finish all local work before the handoff — then stop idle.** Finish every local gate (lint, analyze, tests, `git diff --check`, diff-stat) and write the state file **before** returning the handoff. After returning `validator_handoff_required`, do nothing: no diff hygiene checks, no extra reads, no opportunistic edits, no parallel work. The orchestrator now owns the slice; any mutation here would change what the sibling validator reads and breaks determinism (same failure class as the orchestrator's G9).
+
+The verdict is consumed by the **orchestrator**, not by this executor:
+
+- `pass` / `pass_with_observations`: terminal — the orchestrator closes the slice (observations are reported residuals, never a trigger for another validator dispatch).
+- `fail`: the orchestrator opens `repair_start`, dispatches `atlas-findings-repair`, closes with `repair_run_id`, and runs the **2nd and last** validator. This executor does not re-validate itself and is not reused for the repair retry.
+
+This executor only re-engages if the orchestrator explicitly re-dispatches it for a new slice. It must not "fix" observations and reopen a closed slice; real follow-up from an observation goes to the final report or backlog, not into an extra in-slice change.
+
+If isolated subagents are unavailable in the current environment, do not pretend the slice is validator-closed. Run a local self-check against the same contract, report `validator not run`, and mark residual risk explicitly.
+
+## Stop Conditions
+
+Stop and report instead of improvising when:
+
+- code contradicts the PRD in product behavior, permissions, backend contract, or persistence shape
+- required dependency PRD/contract is missing or unstable
+- implementing would violate explicit out-of-scope
+- deterministic checks cannot run and no equivalent evidence exists
+- repair loops repeat the same failure twice
+- validator cannot receive a valid `.atlas/state/<run_id>/<slice>.json` state path
+- any PRD obligation lacks code/test/check evidence after implementation
+
+## Final Report
+
+Keep final report short:
+
+- changed scope
+- files touched
+- validations run
+- validator verdict/cycles
+- blockers or residual risks
+
+Do not include the full internal contract unless the user asks.

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-direct-execute/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Atlas Direct Execute"
+  short_description: "Direct PRD execution with cold validation"
+  default_prompt: "Use $atlas-direct-execute to implement this PRD or scoped task directly with a compact obligation ledger, focused gates, and validator closure."
+
+policy:
+  allow_implicit_invocation: true

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-findings-repair/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: atlas-findings-repair
+description: Skill `atlas-findings-repair`. Corrige findings P0/P1/P2 retornados por `atlas-task-validator` dentro do boundary já executado, sem reabrir o plano completo. Use quando o orquestrador receber `fail` do validator (topologia sibling, única em todos os hosts) e precisar de um reparo enxuto, bounded e sem reusar `atlas-plan-execute`.
+---
+
+# Atlas Findings Repair
+
+Use esta skill apenas no caminho de recuperação pós-validator. Ela **não** substitui `atlas-plan-execute` nem `atlas-direct-execute`; serve só para corrigir findings bloqueantes já emitidos pelo `atlas-task-validator`.
+
+## Finalidade
+
+Corrigir findings P0/P1/P2 dentro do boundary atual com o menor contexto possível:
+
+- sem replanejar
+- sem carregar skill de execução
+- sem criar novas tasks
+- sem ampliar o escopo
+- sem despachar validator
+
+O orquestrador é dono do ciclo sibling em todos os hosts:
+
+1. executor inicial entrega `state_path`
+2. orquestrador roda `atlas-task-validator`
+3. se `fail`, orquestrador trava o ciclo em `repair_required`
+4. orquestrador chama `atlas_lock_validator(action=repair_start, state_path=...)`
+5. orquestrador despacha `atlas-findings-repair` com o pacote retornado pelo lock
+6. esta skill corrige e devolve `repair_complete`
+7. orquestrador fecha o lock com `repair_run_id`
+8. orquestrador roda o **2º e último** validator
+
+## Entrada obrigatória
+
+Receba do orquestrador:
+
+- `state_path`
+- findings estruturados do validator
+- `validator_attempt`
+- `repair_run_id`
+- `repair_budget: 1`
+
+Leia `atlas_run_state` como fonte primária do estado da run. O `state_path` continua sendo a fronteira canônica da slice.
+
+## Regras duras
+
+1. **Não carregar `atlas-plan-execute` nem `atlas-direct-execute`.**
+2. **Não reabrir o plano inteiro.** Corrija só o que os findings exigem.
+3. **Não aumentar boundary** sem evidência estrita de dependência técnica inevitável.
+4. **Não corrigir observações/P3 por capricho.** O foco é fechamento do `fail`.
+5. **Não despachar validator, review ou qualquer subagente.** O orquestrador faz isso.
+6. **Não iniciar terceiro ciclo.** Esta skill existe só entre validator 1 e validator 2.
+7. **Não trocar o `state_path`.** Atualize o arquivo original em lugar; redirecionar o boundary invalida a correlação do repair.
+
+## Fluxo
+
+### 1. Ler o boundary
+
+Abra o `state_path` e extraia:
+
+- `files_changed`
+- `diff_stat`
+- `plan_path`
+- `boundary_refs`
+
+Leia do plano apenas o mínimo necessário:
+
+- Section 2 — invariantes
+- Section 6 — contratos técnicos
+- Section 8 — checklist
+
+### 2. Ler os findings recebidos
+
+Trabalhe somente com findings de severidade:
+
+- `P0`
+- `P1`
+- `P2`
+
+Se o pacote vier vazio, inconsistente ou sem finding reparável, pare em `blocked`.
+
+### 3. Montar contrato mínimo de reparo
+
+Antes de editar, reduza o trabalho a:
+
+- finding alvo
+- arquivos a tocar
+- invariante em risco
+- check focado
+- budget de reparo
+
+### 4. Corrigir de forma bounded
+
+Permissões:
+
+- corrigir arquivos do boundary
+- tocar arquivo adjacente apenas quando necessário para satisfazer contrato/invariante
+
+Proibições:
+
+- cleanup oportunista
+- refactor largo
+- nova feature
+- mudança fora da causa do finding
+
+### 5. Rodar gates focados
+
+Rode só validações coerentes com o diff:
+
+- teste alvo
+- lint/analyze/typecheck do pacote afetado
+- `git diff --check`
+
+Se o finding persistir por falta de decisão de produto, dependência externa ou widening de escopo, pare em `blocked`.
+
+### 6. Atualizar evidência
+
+Ao terminar:
+
+- atualize o conteúdo do `state_path` original se a evidência do boundary mudou
+- mantenha a mesma slice
+- não invente novo run state paralelo
+
+### 7. Devolver resultado ao orquestrador
+
+Retorne saída curta e estruturada com:
+
+- `status: repair_complete | blocked`
+- `repair_run_id`
+- `state_path`
+- `files_touched`
+- `checks_run`
+- `residual_risk` (se houver)
+
+O orquestrador chamará `atlas_lock_validator(action=repair_complete, repair_run_id=..., state_path=<mesmo path original>)` e só então poderá despachar o validator final.
+Antes disso, ele deve ter aberto o slot com `atlas_lock_validator(action=repair_start, state_path=...)`; `repair_run_id` é obrigatório no fechamento.
+
+## Stop conditions
+
+Pare e reporte `blocked` quando:
+
+- finding exige reabrir decisão fechada
+- finding exige ampliar escopo além da slice
+- mesmo erro repete sem sinal novo
+- correção depende de ambiente ausente
+- pacote de findings não é confiável
+
+## Resultado esperado
+
+Esta skill deve ser menor e mais barata que um executor completo, mas ainda disciplinada. Ela repara findings; ela **não** “continua a execução”.

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-findings-repair/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Atlas Findings Repair"
+  short_description: "Repair-only post-validator fixer for bounded findings"
+  default_prompt: "Use $atlas-findings-repair to fix the blocking validator findings inside the current slice boundary without reloading the full executor."
+
+policy:
+  allow_implicit_invocation: true

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-plan-execute/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: atlas-plan-execute
+description: Executa planos produzidos por `atlas-plan-handoff` task-a-task com gates finitos e self-repair local pré-handoff (lint/tests/diff — máximo 2 passes por task). Ao concluir todas as tasks da slice, escreve o state file, para toda mutação e retorna `validator_handoff_required` ao orquestrador para validação fria sibling via `atlas-task-validator`. O orquestrador consome o veredito e decide sobre repair ou fechamento — este executor nunca valida o próprio trabalho nem processa resultado do validador. Use quando o cliente precisar implementar um plano sem derivar dos invariantes.
+---
+
+# Atlas Plan Execute
+
+Use this skill to turn a `atlas-plan-handoff` artifact into a controlled execution loop.
+
+Prefer finite, stage-based execution over continuous self-critique. The goal is to finish the task with high confidence, not to keep polishing indefinitely.
+
+---
+
+## Execution Model
+
+Operate as a bounded state machine:
+`ready` → `implementing` → `gating` → `repairing` (self-repair LOCAL, gates pré-handoff) → `task_done` → `validator_handoff_required` (or `blocked`).
+
+`repairing` cobre exclusivamente falhas de gates locais (lint, analyze, tests, diff-check) introduzidas pelo diff corrente — máximo 2 passes por task. O executor não entra em `repairing` pós-validação; qualquer repair pós-veredito é de responsabilidade do orquestrador via `atlas-findings-repair`. Após `task_done` para todas as tasks da slice, o executor escreve o state file e transita para `validator_handoff_required` — não existe `slice_validating` nem `slice_done` no escopo deste executor.
+
+## State persistence
+
+Use `atlas_run_state` as the primary source of run state. Do not read or write run ledger files directly. If the MCP is unavailable, report the gate as unprovable and abort instead of continuing with a silent file fallback.
+
+## Plan path resolution
+
+Resolve plan paths in this order:
+
+1. `.atlas/plans/`
+2. `.cursor/plans/` with a deprecation warning
+3. `.codex/plans/` with a deprecation warning
+
+New or rewritten plan artifacts must use `.atlas/plans/`.
+
+## Host adapter
+
+This skill is host-agnostic. To resolve any host-specific verb (subagent dispatch, native todo tool, plan paths), call the MCP tool `atlas_capabilities` first and use the returned descriptor. Canonical reference: `packages/orchestrator/references/host-adapters.md`. Do not hardcode a host name in reasoning — read it from the descriptor.
+
+## Native todo mirror
+
+When entering `implementing` for the first time in a slice, mirror the plan tasks into the native todo surface named by `atlas_capabilities.todo_tool` (e.g. `TodoWrite` on Claude Code, `tasks` on Codex App). If `todo_tool` is `null`, proceed without a mirror — do not invent a tool.
+
+The plan is the SSoT. Map `ready` to `pending`, `implementing`/`gating` to `in_progress`, and `task_done` to `completed`. If todo state diverges, sync from the plan to todo, never from todo back to the plan. Do not create parallel todos that are not derived from plan task IDs.
+
+## Review gate
+
+`atlas-slice-review` is dispatched only when `--review` is present in the user command or executor arguments. Without `--review`, the orchestrator closes the slice upon receiving `pass` or `pass_with_observations` from the validator — this executor is not involved in that decision and never observes the validator verdict directly.
+
+## Entrada via modo `execute` (PRD D1/D13)
+
+Esta skill aceita entrada pelo modo `execute` do orquestrador: um `PLAN_*.md` pronto de pipeline curta, apontado diretamente e já reverificado na entrada (`atlas_verify_artifact` + TC) pelo orquestrador. **A entrada `execute` é o mesmo executor, com as mesmas garantias** — o contrato não muda: o state file (`.atlas/state/<run_id>/<slice>.json`) permanece **obrigatório** e o `atlas-task-validator` (validador frio, só `state_path`) permanece **obrigatório** antes do relatório final. Não há caminho de execução sem state file nem sem validador, em nenhum modo de entrada.
+
+---
+
+## Required Workflow
+
+### 1. Load the plan as an execution contract
+Read the `atlas-plan-handoff` artifact. Extract at minimum:
+* **Execution metadata**: Prefix, mode, and validator options.
+* **Executive translation and PRD links** (from Section 1 — include path to PRD; cite `PRD §3` D* IDs, do not paste the full D* table).
+* **Execution invariants** (from Section 2).
+* **Current state at sprint opening** (from Section 4 — not Section 2).
+* **Pitfalls** (from Section 3).
+* **All execution tasks TNN** (from Section 5).
+* **Technical contracts** (from Section 6).
+* **Slices of execution** (from Section 7).
+* **Checklist for the validator** (from Section 8).
+
+Treat headings as semantic. If the plan uses equivalent wording but carries the same contract, continue. If the plan is missing the substance, stop and report. 
+The old Gate of Readiness (§15) and Handoff Prompt (§16) are **no longer required** in the compact template.
+If optional Section 9 (open questions / real blockers — **not** PRD §7 Apêndice/Referências) has active blocking items, stop execution and request clarification.
+
+When Section 8 checklist is thin, read **PRD §4–6** from the PRD path in the plan header for business acceptance.
+
+### 2. Create a task-scoped execution contract
+Before editing code, write a short task contract for the current task only (objective, files, invariants, local checks, and repair budget).
+
+### 3. Implement in the smallest coherent slice
+Do not implement the entire feature before validating anything. Prefer one task at a time. Follow closed decisions from the plan.
+
+### 4. Run a focused quality gate after each task slice
+Run only the checks that are relevant to the current diff and task risks (linter, analyze of the affected package, or tests).
+
+### 5. Repair only what the current diff introduced
+If the gate fails, classify the outcome as `fixable` (maximum 2 repair passes per task) or `blocked`.
+
+### 6. Enforce hard stop conditions
+Stop repair and move to `blocked` when budget is exhausted, the same failure repeats twice, or the fix requires reopening closed plan decisions.
+
+### 7. Close the task with evidence
+Mark a task complete and move to the next. Once all tasks are `completed`, write the state file and transition to `validator_handoff_required`.
+
+### 8. Write the state file and hand off to the orchestrator
+After all tasks in the current slice are complete, write the state file boundary. The cold validation runs as an isolated **sibling** dispatched by the orchestrator — never by this executor (see below).
+
+#### State file boundary
+
+Create `.atlas/state/<run_id>/<slice>.json` following `packages/templates/STATE_FILE_SCHEMA.md`:
+
+```json
+{
+  "run_id": "<run_id>",
+  "slice": "<slice id>",
+  "tasks": ["T01"],
+  "files_changed": ["relative/path.ext"],
+  "diff_stat": "N files, +X -Y",
+  "plan_path": ".atlas/plans/<id>.plan.md",
+  "boundary_refs": ["§2.I1", "§6.1", "§8"],
+  "executed_at": "ISO8601",
+  "executor_skill": "atlas-plan-execute"
+}
+```
+
+Validation is always **sibling**, on every host. The validator is registered as a real subagent on every host, but this executor **never** dispatches it and never validates its own work. After tasks and local gates pass and the state file is written, this executor **stops mutation** and returns `validator_handoff_required` with the `state_path`. The orchestrator dispatches `atlas-task-validator` as the next isolated sibling phase, locks it via `atlas_lock_validator`, and — if the verdict is `fail` — dispatches `atlas-findings-repair` (not this executor) before the **2nd and last** validator.
+
+The only handoff input is `state_path`. Do not paste the contract, diff, or task list inline. The validator reads everything it needs from the state file and the plan it points to. (`atlas_capabilities` is the runtime source of truth for the dispatch mechanism the orchestrator uses — see `references/host-adapters.md`.)
+
+**Finish all local work before the handoff — then stop idle.** Finish every local gate (lint, analyze, tests, `git diff --check`, diff-stat) and write the state file **before** returning the handoff. After returning `validator_handoff_required`, the executor must not mutate anything: the orchestrator now owns the slice, and any mutation here would change what the sibling validator reads and breaks determinism (same failure class as the orchestrator's G9).
+
+### 9. The orchestrator consumes the verdict
+This executor does not parse the validator output — the **orchestrator** does, deciding only from `verdict`:
+
+- `pass` / `pass_with_observations`: terminal — close the slice. Observations and `boundary_violations` returned alongside a non-`fail` verdict are reported residuals, never a trigger for another validator dispatch.
+- `fail`: the orchestrator opens `repair_start`, dispatches `atlas-findings-repair`, closes with `repair_run_id`, then runs the **2nd and last** validator (max 2 cycles total). This executor is not reused for the retry.
+
+Never decide by substring matching prose. Once the slice is closed, do not edit code, tests, or boundary files just to satisfy an observation; that reopens the slice and forces an avoidable re-validation. Real follow-up from an observation goes to the final report or a backlog item, not into an extra in-slice change.
+
+### 10. Report final outcome
+At the end of execution, report completed tasks, validations run, validator outcome, and any residual gaps.

package/plugins/atlas-workflow-orchestrator/packages/skills/atlas-plan-execute/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Atlas Plan Execute"
+  short_description: "Bounded plan execution with gates (atlas-plan-execute)"
+  default_prompt: "Use $atlas-plan-execute to execute this handoff plan task by task with explicit invariants, focused validation, bounded self-repair, and clear stop conditions."
+
+policy:
+  allow_implicit_invocation: true