菜单
Read-only flow-status and next-step router for arch-step, miniarch-step, arch-mini-plan, and lilarch docs. Use when the user asks 'what's next?', wants a checklist, or wants the single best next move without running the workflow. Not for doing the planning or implementation work itself.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Conduct work to verified completion from a finished plan, a partial plan, or a described outcome; the parent is executive architect and cynical reviewer while workers implement, repair, and prove. Outcome or partial-plan intake first runs an executive shaping stage — parallel worker research, a parent trim to the smallest sufficient solution, a lightweight outcome map, one scope approval — and workers never dispatch before observable done-ness and a frozen scope boundary exist. Default execution is the cheap parallel external fleet (Codex gpt-5.6-sol at ultra via agent-delegate, one-word swaps to Kimi, Grok, Cursor, or Claude); native children stay a narrow exception, and Codex usage limits rotate via aim without losing sessions. The `conductor terra` preset keeps its dedicated-worktree, Terra xhigh, three-review, PR-publication, and follow-through path. Not for single bugs, open-ended metric loops, multi-plan epics, plan audits, one delegated task, parent-implemented plans, or read-only opinions.
Run editful Claude, Codex, Cursor Agent, Grok, or Kimi workers as explicit external processes or resumable sessions with exact model/profile resolution and structured receipts. Use when external transport provides a concrete benefit, such as a different provider, a load-bearing exact model/profile, durable exact-session continuation, process isolation, automation, or captured event/final-output artifacts; these are examples, not a closed gate. Route ordinary same-host work directly to the active host's native children when they can satisfy the role. Use exact handles to resume the same external worker. Not for read-only reviews (`fresh-consult`), Codex `-p yolo` reviews, two-model convergence, ordered orchestration, or detached/background delegation.
Monitor and keep alive a long codex goal-mode session that is already running in a tmux pane, until codex's own goal genuinely completes. Watch the pane for usage limits, stalls, or process death; on a real usage limit rotate the aim account (`aim status` then `aim codex use <label>`), then kill, restart, and `codex resume <session-id>` the SAME session, clear the 'Resume paused goal?' menu, and verify it ACTUALLY resumed work on the new account; check on a ~15-min cadence via a background poll, never a tight loop. Use when the user says monitor/babysit/watch/keep-running my codex, keep it going across rate limits, or restart-and-resume it when limited. Not for spawning a worker to do a task (`agent-delegate`), running your own goal-seeking loop (`goal-loop`), a one-off codex review (`codex-review-yolo`), or purging ~/.codex state (`codex-cleanup`).
Implement an existing plan, phase, section, or checklist faster by keeping the plan, audit log, implementation log, proof freshness, and warm plan-backed code review aligned while coding. Use when the user wants plan-backed implementation with less duplicate rereading, fewer repeated checks, compaction-safe progress, native subagent acceleration when available, and continuous review against plan-audit quality doctrine. Not for creating plans, generic code review, external worker swarms, CI policing, deterministic runners, or manually spawning coding-harness executables.
Canonical preflight and operating contract for direct BrowserOS MCP use. Read and apply before the first BrowserOS MCP call whenever an agent will operate tabs, windows, or authenticated pages; upload or download files; capture screenshots; read or mutate web or BrowserOS-managed connector state; recover from BrowserOS errors; or coordinate browser work across agents. It owns non-hidden background operation, foreground-focus discipline, page lifecycle, dispatch-versus-task authorization, target and profile verification, observe-act-verify, timeout recovery, secrets, proof, and cleanup. Use it alongside narrower site skills such as $chatgpt-web, which own the site workflow while this skill owns BrowserOS mechanics. Not for BrowserOS installation or vendor development, generic connectors, or browsing that does not use BrowserOS MCP.
Orchestrate a goal too large for one `$arch-step` plan by decomposing it into approved ordered sub-plans, then running interactive handoffs, same-session `auto-plan` / `auto-implement`, or role-based planner/worker/critic execution. Same-host roles prefer clean native children from durable epic and sub-plan artifacts; the explicit external-harness lane remains available for deliberate provider, exact-model, lifecycle, isolation, automation, or receipt benefits. Use to break up and run a multi-plan epic, continue/resume an epic doc, plan every sub-plan before implementation, or implement an approved epic end to end. Not for a single architecture plan (`$arch-step`), one-pass mini plan (`$arch-mini-plan`), small feature (`$lilarch`), read-only status (`$arch-flow`), or foreign-repo step orchestration (`$stepwise`).
| name | arch-flow |
| description | Read-only flow-status and next-step router for arch-step, miniarch-step, arch-mini-plan, and lilarch docs. Use when the user asks 'what's next?', wants a checklist, or wants the single best next move without running the workflow. Not for doing the planning or implementation work itself. |
Use this skill to inspect an existing arch-style doc and recommend the next move.
Read references/detection.md, references/checklist-rules.md, and references/recommendation-rules.md before building the checklist.
DOC_PATH and WORKLOG_PATH, not memory.arch-step, miniarch-step, or lilarch.arch-step or miniarch-step.arch-step or miniarch-step.DOC_PATH and the derived WORKLOG_PATH.DONE, PENDING, OPTIONAL, or UNKNOWNarch-step for broad full-arch execution until the code audit is cleanminiarch-step for faster full-arch execution or post-mini-plan follow-through until the code audit is cleanarch-docs for full-arch or post-mini-plan docs cleanup after the clean code auditlilarch for lilarch stepsDOC_PATH) as the source of truth.references/detection.md - flow-family detection and artifact sanity checksreferences/checklist-rules.md - evidence-based checklist construction rulesreferences/recommendation-rules.md - exact next-move recommendation rules by doc family