菜单
Runs software development projects from idea to completion. Use when starting a software project, adding a feature, fixing a bug, or resuming an in-progress build.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Delegates a task to OpenAI Codex running as an interactive session in a herdr pane - uses the user's ChatGPT subscription, visible in herdr, steerable mid-session. Use when delegating work to codex, offloading a task to a GPT model (sol, terra, luna), or running a second opinion from a non-Claude frontier model. Not for Claude Code's own Agent tool or local-LLM delegation (delegating-to-local-llm).
Delegates a task to a local LLM running as a Pi coding-agent session in a herdr pane - the subagent is visible in herdr, can be steered mid-session, and costs no cloud tokens. Use when delegating work to a local model, spawning a Pi subagent, offloading a task to omlx (qwen, gemma), or running agent work offline. Not for Claude Code's own Agent tool or subagents inside Pi.
Loads the rageatc-code-oss operating rules directly from the plugin when the SessionStart hook has not delivered them. Use when the rageatc-code-oss failsafe line appears in session-start hook output, when the plugin's operating rules are absent from context, or when the injected rules look truncated.
Loads the rageatc-core-oss operating rules directly from the plugin when the SessionStart hook has not delivered them. Use when the rageatc-core-oss failsafe line appears in session-start hook output, when the plugin's operating rules are absent from context, or when the injected rules look truncated.
Raises an artefact's signal-to-noise ratio by removing text that earns nothing for its reader — filler, repetition, over-explanation, ornamental phrasing — and relocating conditional detail to references. Use to slim a skill, agent, or document, cut bloat, tighten prose, or shrink a file that has grown too long. Tuned for SKILL.md files.
Creates a design system for software with a UI. Use when a project has a user interface and architecture is confirmed — whether creating from scratch or extracting patterns from existing code.
| name | orchestrating-software-dev |
| description | Runs software development projects from idea to completion. Use when starting a software project, adding a feature, fixing a bug, or resuming an in-progress build. |
The orchestrator's handbook for running software projects with rageatc-code-oss: which tier to select, which agents and skills to invoke at each stage, and how to respond at every decision point. The orchestrator coordinates; agents execute. How agents do their work lives in their preloaded skills and agent definitions — never restated here.
Orchestrator-owned stages. Four stages are executed directly rather than delegated, because the artefact depends on holding the full project picture (or live dialogue with the user) that delegation would lose:
If context window limits bite, session resumption via project files (ORCHESTRATION-PLAN.md, ORCHESTRATION-LOG.md) is the safety net.
Select the tier before invoking any agent; it governs depth at every subsequent stage.
| Tier | Use when |
|---|---|
| Quick | Bug fix, small isolated change, 1-3 files, no new architectural decisions |
| Standard | New feature, moderate complexity — this is the default |
| Thorough | Greenfield project, cross-cutting change, complex system, multiple components |
Signals for Quick: single component, reversible, no new dependencies, scope clear without upstream work. Signals for Thorough: greenfield, new architectural territory, multiple components with shared interfaces, significant non-functional requirements, parallel workstreams. When in doubt, start Standard.
Record the selected tier and justification in the orchestration log before proceeding.
rageatc-code-oss sits downstream of rageatc-core-oss's thinking pipeline; the handoff point is when solutioning determines the solution is a software product.
/shaping (ideating → understanding-the-ask → solutioning) before Stage 1. Output is concept_v1.md with a decision record./shaping only when direction is unclear; skip if the user arrives with a specific, bounded request.Apply the managing-product skill (orchestrator-led dialogue). Pass the workflow tier — it calibrates PRD depth.
Gate: present PRD.md to the human for approval. Do not advance without explicit confirmation; log the approval.
Output: confirmed PRD.md in project root.
Standard and Thorough only. Apply the scaffolding-project skill (orchestrator-led) to create the project file structure. Quick: skip — structure already exists.
Invoke architect-agent. Provide: PRD.md path, output directory, workflow tier; add existing codebase path for brownfield.
Gate: present ARCHITECTURE.md (and any ADRs) for approval. Resolve all open questions flagged by the architect before approving — decomposing an unconfirmed architecture produces misaligned chunks. Log the approval.
Output: confirmed ARCHITECTURE.md; ADRs in docs/decisions/ for Thorough.
Conditional: only when the project has a UI; Standard and Thorough only. After Stage 3, check ARCHITECTURE.md for frontend components, web interface, or UI framework references. If absent, skip and note it in the log. Quick: skip — if system.md already exists, the developer uses it.
Apply the designing-interfaces skill (orchestrator-led, dialogic). Greenfield: full exploration workflow. Brownfield: if .interface-design/system.md exists, confirm it is current; if direction has changed, run the brownfield entry path.
Gate: present .interface-design/system.md for approval before decomposition. Log the approval.
Invoke breakdown-agent. Provide: ARCHITECTURE.md path, project root path, workflow tier; add existing codebase path for brownfield.
Gate: review the proposed ROADMAP.md before the agent writes it — check chunk structure and dependencies. Confirm or request revisions; log the approval.
Output: confirmed ROADMAP.md (structural — chunks, phases, dependencies, file sets).
Standard and Thorough only. Apply the enriching-roadmap skill (orchestrator-led). Provide: ROADMAP.md, ARCHITECTURE.md, PRD.md paths and workflow tier; if .interface-design/system.md exists, provide it too — enrichment derives design-specific acceptance criteria for UI chunks. The enriched roadmap becomes the developer's brief — no separate briefing step.
Gate: present the enriched ROADMAP.md for approval. Log the approval.
Quick: skip — the developer works directly from the chunk description.
Apply the planning-software skill (orchestrator-led). Provide: enriched ROADMAP.md path, workflow tier, project name.
Output: ORCHESTRATION-PLAN.md (the workflow contract) and initialised ORCHESTRATION-LOG.md in project root.
For each chunk in ORCHESTRATION-PLAN.md, in dependency order, run the Per-Chunk Execution Protocol below.
Standard and Thorough only (Quick: skip). When all chunks are complete in ORCHESTRATION-PLAN.md:
reviewer-agent with the whole-project perspective (from reviewing-code). Provide: PRD.md path, project root, all source files. Accept → proceed; Revise → address findings and re-run.user-emulation-agent with the running product. Provide: PRD.md path, running app URL (or CLI command), and system.md path if a design system exists. DONE → mark plan complete; DONE_WITH_CONCERNS → address severity 3-4 findings via developer-agent, then re-run; BLOCKED → check the app is running and accessible, retry.Only when something noteworthy happened. Append observations to the project root LEARNINGS.md per its inclusion criteria — durable insights a future session would act on, with the likely cause noted while it is still known. Codification happens later, when the user runs /codify (rageatc-core-oss).
Skill or agent produces artefact → Critic reviews (optional) → Human approves
Applied after: PRD (Stage 1), architecture (Stage 3), design system (Stage 4, if applicable), roadmap structure (Stage 5), enriched roadmap (Stage 6). If the human requests changes → revise and repeat. Never advance past a gate without explicit approval; log every approval in ORCHESTRATION-LOG.md.
Read ORCHESTRATION-PLAN.md and select the next chunk whose dependencies are met. Provide developer-agent with the chunk section from ROADMAP.md (acceptance criteria, file set), relevant ARCHITECTURE.md section(s), and — Standard/Thorough — a pointer to patterns from earlier chunks if relevant (2-5 lines; coordination, not production).
Apply the using-worktrees skill. Each chunk runs in an isolated git worktree; use the worktree path as the codebase path for all subsequent steps within the chunk.
Invoke developer-agent. Provide: PRD.md path, chunk section from ROADMAP.md, ARCHITECTURE.md path, worktree path; add CLAUDE.md path if present and .interface-design/system.md path for UI chunks. (TDD and verification discipline live in the developer's preloaded skills.)
Respond to the status code the developer reports:
For iterations (2+), provide the previous review path alongside the worktree path; the developer continues in the existing worktree.
Invoke reviewer-agent. Provide: project context, ROADMAP.md chunk section, ARCHITECTURE.md path, worktree path, changed files list (git diff --name-only main in the worktree); for re-reviews, the previous review path.
Select perspectives per the reviewing-code skill's tier defaults, overriding when chunk characteristics warrant it (e.g., security for a Quick auth fix, design-compliance for UI chunks when system.md exists). Tell reviewer-agent which perspective names to apply.
3-iteration cap. If iteration 3 still produces a revise decision, do not invoke developer-agent a fourth time. Escalate to the human with the chunk, the final review, the worktree path, and the unresolved issues. Persistent failure after 3 rounds signals a brief problem, architecture gap, or complexity mismatch — not a developer failure. The human decides: revise the brief, adjust scope, or accept with known issues.
[x])New orchestrator session on an in-progress project:
[~] or [ ] entry in Build Progress[~]), check ORCHESTRATION-LOG.md for the last completed step within itDo not rely on conversation history — project root files are the authoritative record.
Append-only; write immediately after each step, not in batches; log facts, not opinions. ORCHESTRATION-LOG.md is initialised by planning-software (Stage 7) — append only after that point. Entry format:
## Step N: <Step Name>
- **Agent:** <agent-name> (or "orchestrator")
- **Inputs:** <files and skills provided>
- **Sufficient inputs check:** <passed or failed>
- **Task:** <one-line summary>
- **Output:** <file(s) created>
- **Notes:** <errors, decisions, or "none">
Software-specific events to log: tier selection with justification; every gate approval; each chunk's outcome (iteration count, status code, accept/revise); escalations (chunk ID, iteration count, unresolved issues); worktree branch name per chunk; architecture re-entry decisions; BLOCKED diagnoses and resolutions.
If the developer or reviewer discovers a fundamental architecture gap during the build:
Do not patch around architectural problems at the implementation level. Log the re-entry decision with the specific gap identified.
Chunks annotated as parallelisable in ROADMAP.md (non-overlapping file sets) can be dispatched concurrently. Provide each developer-agent with its own worktree. Merge each worktree individually before starting dependent chunks; resolve conflicts before the next phase.