# Cflx Workflow > Legacy compatibility router for Conflux apply, rejecting, cleanup-review, accept, and archive operations. New orchestrator prompts use dedicated cflx-* operation skills. CRITICAL - This skill CANNOT ask questions or request user input. - Skill: `tumf/cflx-workflow` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add tumf/cflx-workflow` - Raw SKILL.md: https://api.skillmd.com/api/skills/tumf/cflx-workflow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: tumf (https://skillmd.com/u/tumf) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tumf/cflx-workflow --- # Conflux Workflow Compatibility Router Use this skill only for legacy prompts that load `cflx-workflow`. New orchestrator prompts load `cflx-apply`, `cflx-rejecting`, `cflx-cleanup-review`, `cflx-accept`, or `cflx-archive` directly; those dedicated skills are the authoritative guidance for new runs. This router is self-contained so legacy prompts do not need another skill or reference file. ## Shared Rules - Never ask questions or wait for user input. - If `openspec/CONSTITUTION.md` exists, read it first and treat it as higher priority than proposal or spec deltas. - Base completion and routing only on repository-verifiable evidence. - Choose exactly one operation from the prompt context and follow only that section. ## Apply Implement the approved change; do not only inspect, summarize, or plan. 1. Read `proposal.md`, optional `design.md`, and the change's task file under `openspec/changes//`. The prompt's `tasks_path` names it: a change entry owns exactly one task artifact, either checkbox `tasks.md` or versioned `tasks.json`. Never create the other filename; two task files in one entry is an ambiguity error that fails closed. 2. Implement each active incomplete task and run its planned verification. 3. Mark a task complete only after its implementation artifact, runtime wiring when applicable, and verification evidence exist — `- [ ]` becomes `- [x]` in `tasks.md`, and a task's `"status"` becomes `"completed"` in `tasks.json`. 4. Update the resolved task file after each completed task, in that file's own format. Internal agent todos are not OpenSpec completion evidence. 5. Finish only when all active tasks are complete or validly moved to narrative Future Work (a non-checkbox section in `tasks.md`, the `narrative` object in `tasks.json`). Unit-test claims require isolated tests using mocks, fakes, or in-memory doubles. Tests using real filesystem, process, VCS, network, database, clock, credentials, or OS state are integration or e2e evidence and cannot satisfy a unit-test task. Recoverable infrastructure failures such as Docker, DNS, registry, credential, port, rate-limit, or pending managed-job failures are non-terminal stalled holds. Record concrete evidence and recovery actions; do not create `REJECTED.md` for these cases. For a terminally invalid change intent, record the blocker in the change's task file — a non-checkbox `## Implementation Blocker #` section in `tasks.md`, or a `narrative.notes` entry carrying the same fields in `tasks.json` — create `REJECTED.md` as a review proposal, and end with an `IMPLEMENTATION_BLOCKER:` payload containing category, evidence location, and required action. ## Rejecting Review Review apply-generated `REJECTED.md` and the matching `Implementation Blocker` evidence. Return exactly one standalone final marker: - `REJECTION_REVIEW: CONFIRM` when evidence proves the change intent is invalid, obsolete, contradictory, or constitution-violating. - `REJECTION_REVIEW: RESUME` when repository-only work can resolve the issue or evidence is insufficient. - `REJECTION_REVIEW: BLOCK` when the intent remains valid but a real external or infrastructure prerequisite creates a non-terminal stalled hold. Do not emit acceptance markers. ## Cleanup Review Clean only apply-generated dirty state before acceptance. 1. Inspect every dirty file with `git status --porcelain`. 2. Keep and stage only intentional handoff files. 3. Never use `git add -A` or `git add .`. 4. Verify the worktree is clean. 5. On success, emit exactly one standalone final line: `CLEANUP_REVIEW: CLEAN`. Do not perform new implementation or emit acceptance/rejection markers. ## Acceptance Acceptance is read-only review. Read the task file named by `tasks_path` — `tasks.md` or versioned `tasks.json` — and do not implement fixes, edit it, or edit the runtime-owned acceptance follow-up state it carries (the `## Current Acceptance Follow-up` section in Markdown, the `acceptance_follow_up` object in JSON). Review the proposal, tasks, spec deltas, implementation diff, planned verification ownership, tests, working-tree cleanliness, and actual commit-path blockers. Every FAIL finding must cite actionable repository evidence such as a file, symbol, or line. Use these outcomes: - `pass`: all requirements and active task claims have repository evidence. - `fail`: repository-only work can resolve the finding. - `continue`: review is incomplete and another acceptance attempt is required. - `gated`: compatibility token for a valid non-terminal stalled hold that repository-only apply work cannot resolve. It is only a stalled hold when accompanied by a structured `blocker` payload; a bare token is a protocol error. The canonical verdict is strict JSON on its own line: - `{"acceptance":"pass"}` - `{"acceptance":"fail","findings":[""]}` - `{"acceptance":"continue"}` - `{"acceptance":"gated","blocker":{"category":"","evidence":[""],"next_action":"","resumable":true}}` Supported blocker categories: `credential`, `external_approval`, `policy`, `external_service`, `pending_verification`, `infrastructure`, `schema_incompatibility`, `human_decision`. Choose one from observed evidence — the runtime never infers a category from prose. A bare `{"acceptance":"gated"}` or plain `ACCEPTANCE: GATED`, an unsupported category, empty evidence, or a missing `next_action`/`resumable` is an acceptance protocol error: the runtime retries acceptance within a fixed budget and then reports a terminal protocol error. Emit `FAIL` or `CONTINUE` instead when you cannot supply all four fields. During compatibility rollout, emit the matching legacy marker as the next and final line: - `ACCEPTANCE: PASS` - `ACCEPTANCE: FAIL` - `ACCEPTANCE: CONTINUE` - `ACCEPTANCE: GATED` `ACCEPTANCE: BLOCKED` is accepted only as legacy input compatibility. Do not wrap verdicts in headings, blockquotes, bullets, emphasis, or code fences, and do not append text to verdict lines. A valid `Implementation Blocker` produces a stalled hold only when repository-only work cannot resolve it and the structured blocker payload is supplied. Recoverable infrastructure failures remain non-terminal stalled holds. Never create `APPLY_BLOCKED` or any other runtime marker under the change directory; the runtime records stalled holds outside the worktree. Missing or ambiguous verification planning, false unit-test claims, dirty worktrees, and missing repository implementation are FAIL findings. ## Archive Archive only after acceptance passes and all active tasks are complete. 1. Verify the change exists and is archive-ready. 2. Run `cflx openspec archive --yes`; use `--skip-specs` only for tooling-only changes. 3. Never create or move archive entries directly with `mkdir`, `mv`, `git mv`, or scripts. A failed CLI archive command is terminal for this operation. 4. Run strict/archive-gate validation as applicable. 5. Review `git diff openspec/specs/` and confirm each canonical spec change matches the delta. 6. Confirm the active change is no longer left unarchived. Do not perform feature implementation during archive.