Menú
Use this when the radorch.mjs pipeline envelope returns ok: false, when an agent produces invalid output, or when manual intervention is needed or any other issue occurs during a pipeline execution.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | rad-log-error |
| description | Use this when the radorch.mjs pipeline envelope returns ok: false, when an agent produces invalid output, or when manual intervention is needed or any other issue occurs during a pipeline execution. |
| user-invocable | false |
The Orchestrator invokes this skill when the radorch pipeline signal envelope returns ok: false. This is near-mandatory — whenever the pipeline signals a failure, the error must be logged so there is a persistent, structured record of what went wrong, when, and what (if anything) was done to recover. This skill should also be used when an agent produces invalid output or when manual intervention is needed.
Determine the error log file path: {PROJECT-DIR}/{NAME}-ERROR-LOG.md (e.g., ~/.radorc/projects/MYAPP/MYAPP-ERROR-LOG.md)
If the file does not exist — create it using the bundled template at templates/ERROR-LOG.md, fill the frontmatter fields (project, created, last_updated), then write the first entry as ## Error 1
If the file already exists — read the existing file, read entry_count from frontmatter to determine the next entry number, increment entry_count, update last_updated, and append the new entry section after the last --- horizontal rule
Entry numbering is sequential starting at 1
Append-only rule — never modify or delete existing entries; only append new entries and update frontmatter counters
Each entry appended to the error log must use this exact structure:
## Error {N}: {Brief Symptom Title}
| Field | Value |
|-------|-------|
| **Entry** | {N} |
| **Timestamp** | {ISO-8601} |
| **Pipeline Event** | {event name, e.g. `task_completed`} |
| **Pipeline Action** | {resolved action at failure, or `N/A`} |
| **Severity** | {`critical` | `high` | `medium` | `low`} |
| **Phase** | {phase index or `N/A`} |
| **Task** | {task index or `N/A`} |
### Symptom
{1-3 sentences: observable failure}
### Pipeline Output
```json
{Raw JSON from pipeline engine}
{1-3 sentences, or "Under investigation."}
{Recovery action, or "None — awaiting fix."}
### Entry Field Contract
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| Entry | integer ≥ 1 | Yes | Sequential entry number |
| Timestamp | ISO-8601 string | Yes | When the error occurred |
| Pipeline Event | string | Yes | Event being processed at failure time |
| Pipeline Action | string \| `'N/A'` | Yes | Resolved action at failure, or `'N/A'` if pre-resolution |
| Severity | `'critical'` \| `'high'` \| `'medium'` \| `'low'` | Yes | Per severity classification guide |
| Phase | integer \| `'N/A'` | Yes | Current phase index |
| Task | integer \| `'N/A'` | Yes | Current task index |
| Symptom | markdown text | Yes | Observable failure description (1-3 sentences) |
| Pipeline Output | JSON code block | Yes | Raw `{ ok: false, ... }` envelope from the `radorch pipeline signal` subcommand |
| Root Cause | markdown text | Yes | Diagnosis or "Under investigation." |
| Workaround Applied | markdown text | Yes | Recovery action or "None — awaiting fix." |
## Severity Classification Guide
| Severity | Criteria | Examples |
|----------|----------|---------|
| `critical` | Pipeline cannot proceed; blocks all execution | Unmapped action, validation error, phase initialization failure |
| `high` | Pipeline produces incorrect state but doesn't crash | Wrong action returned, task stuck in wrong status |
| `medium` | Pipeline works around the issue with degraded behavior | Status synonym normalized instead of matching directly |
| `low` | Cosmetic or informational; no pipeline impact | Verbose error message, minor output formatting issue |
## Template
[ERROR-LOG.md](./templates/ERROR-LOG.md)
Use this skill once you are aligned on a project and ready to start. Typically this is invoked directly by the user after /rad-brainstorm has completed and the Requirements doc is approved. It is the reference for how to run the planning pipeline and author the Master Plan.
Drive the release flow locally — context, version reconcile, build, validate, CHANGELOG, commit, sync plugins to the marketplace, and tag/push (which triggers the CI npm publish + GitHub Release), then a post-release dev bump.
Use this skill if you are a main agent, coder agent and have this skill assigned. It is the reference for how to perform source-control operations like creating commits, opening pull requests, and creating or cleaning up worktrees for a project.
Use this skill if you're a main agent orchestrator executing a rad-orchestration project. It is the reference for how to run the pipeline, signal events, execute actions, and manage the overall flow of a project. Typically, you are guided to using this skill when /rad-execute is invoked, but you may read it if you need to refresh your memory due to compaction during an execution.
Rebuild the standard installer and reinstall one harness (claude, copilot-vscode, or copilot-cli) locally — build the rad-orc tarball, stop the UI, uninstall then reinstall the harness, restart the UI. Use to dogfood canonical harness-files/ agent and skill edits into ~/.claude or ~/.copilot.
Use this skill if you are a main agent who is helping to author planning documents (Requirements or Master Plan). This is triggered by the pipeline or by a brainstorm handoff. It is the reference for how to author planning documents in the rad-orc workflow.