Menu
Use at the start of a work session to select a task. Simplified for models with lower reasoning capacity.
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
Use when a file or module is too large, responsibilities are tangled, or a cross-cutting redesign is needed
Use when literature notes exist and need citation verification, or before publishing any artifact that cites literature
Use at the end of a work session to embed learnings into conventions. Simplified for models with lower reasoning capacity.
Use at the end of a work session, or when accumulated findings need to be embedded into conventions, skills, or patterns
Use when the Slack bot needs to handle an operational action like launching an experiment, querying status, or processing approvals
Use when a plan, finding, or design needs adversarial review before committing to it
| name | orient-simple |
| description | Use at the start of a work session to select a task. Simplified for models with lower reasoning capacity. |
| complexity | medium |
| model-minimum | fast-model |
Simplified orient skill for Fast Model and similar models. Select a task to work on in <3 turns.
At the start of every autonomous work session, before selecting a task.
Execute these steps in order:
Run git status. If there are uncommitted changes that are project work (not scheduler state files), commit them with a descriptive message. Skip scheduler state files (.scheduler/, *.json in infra).
Read all projects/*/TASKS.md files. For each task, note:
[ ] = open, [x] = done[in-progress: DATE] = someone is working on it, skip[blocked-by: ...] = cannot proceed, skip[approval-needed] = requires human approval, skip[zero-resource] = costs no budget resourcesWhile reading TASKS.md files (Step 2), verify that [requires-opus] tags are applied correctly:
Tag [requires-opus] if ANY true:
If your repo uses routing tags, untagged tasks may default to fleet-eligible. Only apply [requires-opus] when a task genuinely needs Opus-level capability.
If task supply is thin, improve it before proceeding. In repos that enable fleet execution, this also helps maintain fleet-ready task supply.
How to generate (in order):
[blocked-by: ...] tags where the referenced condition is resolved (prerequisite task already completed)[requires-opus] tasks that have >2 independent steps, >3 files, or mix mechanical + judgment work. Split into smaller subtasks. Write subtasks directly to TASKS.md — replace the original task with its subtasks. Do NOT just flag or propose — proposals die with the session.Run /self-audit on <project> for projects that haven't been audited in the last 7 days. To check: run ls projects/*/diagnosis/compliance-audit-*.md 2>/dev/null | xargs -I{} basename {} to list audit files. Extract dates from filenames (pattern: YYYY-MM-DD). Skip projects with audits within 7 days of today.Decomposition is also valuable even when task supply looks healthy.
After generating, report what changed.
Read the first 5 lines of each projects/*/README.md. Look for Priority: field:
high = highest prioritymedium or no field = default prioritylow = lowest priorityFor each high-priority project with ≤2 unblocked tasks:
Done when: from README.md (already loaded from Step 6)Done when condition has a corresponding open task in TASKS.md- [ ] <verb phrase for the gap> [optional routing tag]
Why: Mission gap — no task for "<condition>" (per ADR 0049)
Done when: <condition from project Done when>
This prevents projects from stalling when tasks run out while the mission is incomplete.
For each unblocked open task, score by these criteria (in order):
Multiply: project_priority × task_value + concrete_done_when
Example: high priority project + prevents waste + concrete done-when = 3×3+1 = 10
The task with the highest score is your task.
Edit the TASKS.md file. Find your task. Add [in-progress: YYYY-MM-DD] after the task description.
Output a single line in this format:
Selected: <task description> (project: <name>, priority: <level>, score: <N>)
If you tagged any untagged tasks during Step 3 or decomposed tasks during Step 4, add a line:
Task supply updates: N tasks tagged or re-tagged. D tasks decomposed.
Task with [blocked-by: external: ...]: Skip. This is waiting on external work with uncertain timeline.
All tasks blocked: Check if there are [zero-resource] tasks that might be unblocked. If all tasks are genuinely blocked, end the session with a log entry noting the blockage.
Budget check: If a project has budget.yaml and the task is NOT [zero-resource], compute remaining budget before claiming. If budget exhausted, select a different task or end session.