Ocas Triage

System scheduler and priority queue manager. Determines what gets attention next across all pending work. Use when prioritizing competing tasks, checking que...

Security Scan

The skill's declared purpose (a local scheduler/priority queue) matches its instructions and artifacts: it is an instruction-only component that reads/writes a local .triage directory, emits signals, and injects heartbeat metadata for Mentor handoffs.

Purpose & Capability

Name/description, SKILL.md, README, and references consistently describe a scheduler that maintains a local durable queue and emits signals. There are no unrelated environment variables, binaries, or external endpoints required that would be inconsistent with a local scheduler.

Instruction Scope

The runtime instructions explicitly require writing and appending records under a local .triage directory (queue.jsonl, signals.jsonl, journals, etc.) and expect consumers (Mentor, Dispatch, base agent) to poll or acknowledge signals. This is in-scope for a scheduler, but it does grant the skill the ability to persist scheduling state locally; review whether you are comfortable with the agent process creating and maintaining these files. The SKILL.md does not instruct reading unrelated system files or exfiltrating data.

Install Mechanism

Instruction-only skill with no install spec and no code files — nothing is downloaded or written by an installer. Lowest-risk install posture.

Credentials

No required environment variables, credentials, or config paths beyond the .triage directory. The requested access is proportional to a local scheduler: persistent local storage only.

Persistence & Privilege

The skill persists state to the agent filesystem (.triage/) and creates journal files and logs. It does not request always:true or other elevated privileges and claims not to write outside .triage. Confirm your environment's file-permission model and retention policy for these files before enabling.

Assessment

This skill appears to be what it says: a local task scheduler that stores audit logs and emits pickup signals for consumers. Before installing, confirm you are comfortable with the agent creating and maintaining a .triage directory (queue.jsonl, signals.jsonl, journals, etc.) in the agent environment and that other skills or processes will honor the stated boundaries. Also verify that Mentor/Dispatch integrations in your system follow the described protocols (polling and acknowledgments) and that no external network endpoints are added later. If you have strict storage or retention rules, decide where the .triage directory will live and who can read it; otherwise the skill is internally consistent and proportional to its purpose.

Triage

Triage is the system scheduler. Its only job is to determine what gets attention next. It maintains a durable priority queue, scores work deterministically, emits pickup signals, injects heartbeat cadence into Mentor handoffs, and handles interrupts.

When to use

• Prioritize competing tasks
• Check queue state: "what are you working on", "what's pending"
• Interrupt active work: "stop and do this first"
• Add work to the queue
• Any complex multi-step task that requires Mentor

When not to use

• Project orchestration internals — Mentor owns that
• Message drafting or inbox triage — use Dispatch
• Skill execution requests — route directly to the target skill
• Pattern analysis — use Corvus

Core promise

One active task at a time. Deterministic scoring. Durable queue. Priority-linked heartbeat on every Mentor handoff. Every task logged.

---

Meta commands (bypass queue, execute immediately)

status / what are you working on
stop / cancel that
pause / resume

Meta commands never appear in queue.jsonl.

---

Task model

A task is created for every actionable input. Not created for: thanks, casual conversation, clarification, meta queries.

States: queued → active → completed or cancelled Lateral: blocked (retries exceeded), waiting_external (awaiting response)

Read references/schemas.md for full schema and signal formats.

---

Priority scoring

priority_score = urgency + deadline_proximity + consequence_weight +
                 interruption_intent + quick_completion_bonus + queue_aging
Clamp: 0–100

Read references/scoring_model.md for signal definitions, points, and examples.

---

Mentor handoff with heartbeat injection

When Triage scores a task and determines it requires Mentor (routing_hint: mentor), it must inject a heartbeat_interval into the task_ready signal before emission. This is not optional.

Heartbeat assignment rules

Priority score	Heartbeat interval	Rationale
70–100 (high)	60 seconds	High-stakes work must surface stalls within 1 minute
40–69 (medium)	10 minutes	Sustained work; surface stalls before significant time is lost
0–39 (low)	1–6 hours	Background work; check-in at natural rest points

For low-priority tasks, use 1 hour as the default. Scale toward 6 hours only if the task is explicitly flagged as non-urgent background work with no deadline.

Extended task_ready signal (Mentor handoff)

{
  "signal": "task_ready",
  "task_id": "string",
  "routing_hint": "mentor",
  "priority_score": 75,
  "heartbeat_interval_seconds": 60,
  "heartbeat_rationale": "high priority — stall detection required within 60s",
  "emitted_at": "ISO8601"
}

Mentor reads heartbeat_interval_seconds from the signal and configures its internal heartbeat loop before beginning work. If this field is absent from a Mentor-routed signal, Mentor defaults to 600 seconds (10 min) and logs a missing-heartbeat warning.

---

Task selection and preemption

Selection formula: task_score = priority_score / max(estimated_completion_seconds / 60, 1)

Preemption: if new task priority exceeds active task by > 25 points, checkpoint active task and run higher-priority task first.

Read references/scoring_model.md for full preemption and tie-breaking rules.

---

Stall detection

Stall threshold: 120 seconds of no progress on a non-Mentor task. Retry limit: 3, exponential backoff. On limit exceeded: state → blocked, blocking_reason logged.

For Mentor tasks, stall detection is delegated to Mentor's heartbeat loop (interval set at handoff). Triage does not independently poll Mentor-owned tasks.

---

Queue pickup

Triage writes to .triage/signals.jsonl. Consumers poll this file.

task_ready — emitted when a task becomes active task_completed — emitted on completion or cancellation task_acknowledged — written by consumer to prevent double-pickup

Read references/boundary_contracts.md for consumer pickup protocol.

---

Storage layout

.triage/
  config.json
  queue.jsonl        append-only; state transitions are new records per task_id
  signals.jsonl      task_ready, task_completed, task_acknowledged
  decisions.jsonl    DecisionRecord entries for preemption and scoring
  history.jsonl      completed/cancelled tasks, last 100
  journals/
  reports/

---

Validation rules

• No two tasks simultaneously in active state
• Every Mentor-routed task_ready signal must include heartbeat_interval_seconds
• Meta commands never appear in queue.jsonl
• Preemption always produces a journal entry and DecisionRecord
• waiting_external tasks have non-null blocking_reason
• history.jsonl does not exceed 100 records
• Queue does not exceed 50 tasks

---

Reference files

File	When to read
references/schemas.md	Task, signal, DecisionRecord schemas; heartbeat signal extension
references/scoring_model.md	Full scoring formula, preemption rules, estimation heuristics
references/boundary_contracts.md	Consumer pickup protocol; Mentor, Dispatch, base agent boundaries