Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.