orchestrate-project-by-stepslisted

Turn a PROJECT (automation / internal tool) request into a fully decomposed, materialized queue of development sub-steps the RIGHT way — the frozen process for projects, the sibling of orchestrate-content-by-steps. Use when the owner wants a private automation ("summarize my YouTube channels to Telegram every morning", "auto-publish on a schedule", "a tool for my own use"), NOT a public content group. You (Hermes / a model) PROPOSE a graph of nodes (task / tools / keys / io / dependsOn); this engine NORMALIZES it, VALIDATES the DAG, GATES on spec completeness, and MATERIALIZES the whole queue to disk — one rich spec step per node plus one coder-handoff step per node — BEFORE any development. It does NOT deploy, does NOT execute a node, does NOT write code: a coding agent builds each node LATER from its step file. The gate is SPEC COMPLETENESS, not a deployment record.
Fractera/Agent-Engineering-Infrastructure · ★ 37 · AI & Automation · score 76

Install: claude install-skill Fractera/Agent-Engineering-Infrastructure

# orchestrate-project-by-steps The **frozen process** for **projects** (automations / internal tools). You give a **proposed node graph**; the engine decomposes it into a materialized queue of development sub-steps and gates each on **spec completeness** — before any code is written. > **READ FIRST — the automation-ontology glossary** > (`CRUD-DOCS/workspace-standards/automation-ontology.md`, step 188-R): every automation is > composed of EXACTLY twelve entities — Automation · Trigger · Hook · Condition · **Action** · > Router · Step | Integration · Channel · State | Run · Record. The graph you propose is a typed > instance of that ontology and the engine VALIDATES it (schema v2, engine ≥0.8). An automation > described outside the ontology is a defect. Note the terminology: **Action is the first-class > entity** (a named outcome = a branch of steps, bound to its hook phrases); a work NODE is a > `step` (the old node kind `"action"` is accepted only as a legacy alias of `step`). This skill is **self-sufficient**: one `.mjs` (or, from D5, one MCP tool), no Hermes required — a lone agent (even a project with only Codex) runs the whole process on its own. ## Why this exists (read once) Content had a frozen process (`orchestrate-content-by-steps`); projects did not. Without deep, materialize-first decomposition a project is "doomed to fail" (owner). From the content engine we take **only the idea** — freeze the process: decompose and write the whole sub-step queue to disk FIR