codex-deck-flow
- Repo stars 8
- License MIT
- Author updated Live
- Author repo codex-deck
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @asfsdsf · MIT
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: codex-deck-flow
description: Use this skill when the user asks for persistent multi-agent coding workflows with task dependen…
category: engineering
runtime: no special runtime
---
# codex-deck-flow output preview
## PART A: Task fit
- Use case: Use this skill when the user asks for persistent multi-agent coding workflows with task dependencies, per-task codex sessions, git worktree isolation, and explicit merge flow backed by one JSON workflow file under ./.codex-deck/. Always use this skill when the user explicitly mentions `$codex-deck-flow` or `codex-deck-flow`..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Mandatory activation contract / Strict task creating mode / Core runtime model” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use this skill when the user asks for persistent multi-agent coding workflows with task dependencies, per-task codex sessions, git worktree isolation, and explicit merge flow backed by one JSON workflow file under ./.codex-deck/. Always use this skill when the user explicitly mentions `$codex-deck-flow` or `codex-deck-flow`.”.
- **02** When the source has headings, the agent prioritizes “Mandatory activation contract / Strict task creating mode / Core runtime model” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Mandatory activation contract / Strict task creating mode / Core runtime model”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: codex-deck-flow
description: Use this skill when the user asks for persistent multi-agent coding workflows with task dependen…
category: engineering
source: asfsdsf/codex-deck
---
# codex-deck-flow
## When to use
- Use this skill when the user asks for persistent multi-agent coding workflows with task dependencies, per-task codex s…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Mandatory activation contract / Strict task creating mode / Core runtime model” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "codex-deck-flow" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Mandatory activation contract / Strict task creating mode / Core runtime model
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Orchestrate Persistent Multi-Agent Workflows
Use this skill to create workflows, inspect workflows, and send control messages to the background codex-deck-flow daemon.
This skill is an operator control client, not the long-running orchestrator. After the daemon has started successfully and a control message has been sent successfully, the skill should stop.
Detailed operational guidance is routed through references/*.md:
- Command sequences and syntax:
references/commands.md - Workflow/task authoring rules:
references/authoring.md - Failure recovery runbooks:
references/runbooks.md - Scheduler vs workflow-task guidance placement:
references/guidance-routing.md - Architecture, contracts, and role prompts:
references/agent-flow-design.md - Scheduler mutation heuristics (scheduler task only):
references/scheduler.md
Mandatory activation contract
- If the user explicitly mentions
$codex-deck-floworcodex-deck-flow, treat that as a strict instruction to use this workflow system. - Do not switch to direct ad-hoc coding as the primary path while that request is active.
- In the first response after activation, say that codex-deck-flow orchestration is active and state the first command you are running.
- If the user gives
project rootplusworkflow IDfor a workflow that the current session has not created, loaded, or already resolved, first runresolve-workflow, then continue withvalidate,reconcile, andstatus. - If the current session already knows the workflow path from
create, a previousresolve-workflow, or earlier inspection in the same chat, reuse that path instead of resolving again. - If the user already gave a workflow path, start with
validate, thenreconcile, thenstatus. - If no workflow exists yet, start with
create, then immediatelyvalidate, thenshoworstatus, and present the authored tasks/prompts for user approval beforetrigger. - If the user explicitly includes
Strict task creating mode, keep the normal create/validate/show flow, but use the strict authoring protocol described below. - Keep merge explicit. Never run
merge --applyunless the user explicitly asked to apply the integration branch into the target branch. - Once
triggerordaemon-sendsucceeds, stop. Do not continue the same skill turn as if it were the orchestrator.
Strict task creating mode
When the user explicitly includes Strict task creating mode, treat that as a workflow-authoring protocol layered on top of the normal codex-deck-flow create flow.
Rules:
- Still run
create, thenvalidate, thenshoworstatusas usual. - The draft workflow JSON already exists after
create; approval still gatestrigger, not draft creation. - If you must ask the user a clarifying question before the workflow is ready, the assistant message must end with exactly:
<codex-deck-flow>Question<codex-deck-flow/>
- When asking the user to approve the authored workflow, the assistant message must end with exactly:
<codex-deck-flow>Request approve:workflow-file-name.json<codex-deck-flow/>
- Replace
workflow-file-name.jsonwith the JSON file name only, for examplefeature-delivery.json. - Use only the file name token after
Request approve:. Do not add brackets or extra wrappers. - Do not put any additional text after the strict tag suffix.
- Once the user approves, exit strict task creating mode and continue with the normal codex-deck-flow flow.
- If the approval message includes workflow data for an already-created draft, reuse that workflow and do not run
createagain. - The approval workflow data may include fields such as
workflowPath,workflowFileName,workflowId,projectRoot, andboundSessionId; treat that as the canonical handoff for reusing the already-authored draft.
Core runtime model
- One workflow = one JSON file under
./.codex-deck/. - The daemon is the orchestration owner and can serve workflows from multiple project roots.
- The skill starts daemon if needed, sends one control message, then stops.
- Worker tasks run in isolated
git worktreedirectories. - Scheduler continuity should use codex-deck-flow non-interactive app-server-backed resume behavior (
scripts/codex_resume_noninteractive.pybehavior model), not rawcodex resume SESSION_IDsemantics in daemon mode.
Use references/agent-flow-design.md for full runtime contracts and role data.
Route by intent
Use this decision route, then follow details in references/commands.md:
- New workflow request:
create->validate->show/status-> user approval ->trigger - Existing workflow by known path:
validate->reconcile->status - Existing workflow by project root + workflow ID when path unknown in current session:
resolve-workflow->validate->reconcile->status - Explicit daemon control message:
daemon-sendorstop-workflow-processes - Merge request:
mergepreview, andmerge --applyonly if explicitly requested
Reference loading boundaries
- Scheduler task only:
references/scheduler.md - Scheduler/workflow-task guidance file rules and routing:
references/guidance-routing.md - Non-scheduler roles should not load scheduler-specific mutation guidance.
References
Canonical references:
references/commands.mdreferences/authoring.mdreferences/runbooks.mdreferences/guidance-routing.mdreferences/agent-flow-design.mdreferences/scheduler.md(scheduler task only)
Implementation scripts:
scripts/workflow.pyscripts/task_runner.pyscripts/daemon.pyscripts/daemon_client.pyscripts/codex_resume_noninteractive.pyscripts/session_state.pyscripts/session_summary.py
Decide Fit First
Design Intent
How To Use It
Boundaries And Review