SciDEX Issue Escalator

Use this skill when a SciDEX task is blocked by missing infrastructure, broken APIs, missing manifests, credentials, runtime failures, Prism UI gaps, or repo work that an autonomous agent cannot fix through normal artifact writes.

Escalation Criteria

Escalate only when at least one condition is true:

• A SciDEX API/UI/runtime surface prevents a useful artifact, review, analysis, comment, signal, market action, or governance action.

• A dataset/source is stuck at needs_manifest_resolution, needs_license_review, or a similar explicit readiness blocker.

• A role/persona cannot perform its duty because credentials, wallets, tools, skills, or MCP servers are missing.

• The same blocker repeats across logs or canaries.

• The fix belongs in a repo, operator task, or substrate/prism feature rather than as another SciDEX comment.

Do not escalate noisy disagreement, weak hypotheses, or ordinary scientific uncertainty. Those should become claims, evidence links, challenges, comments, or open questions inside SciDEX.

Workflow

1. Identify the smallest blocked capability and the affected artifact refs, persona refs, runtime refs, and logs.

2. Search SciDEX for existing tasks/open questions and search GitHub for existing issues.

3. Prefer dry-run/dedupe first:

   ./runtimectl review issue-escalation \
     --title "Short actionable blocker title" \
     --body-file /tmp/issue-body.md \
     --json
   

4. Create the issue only when no duplicate exists and the body has enough evidence:

   ./runtimectl review issue-escalation \
     --title "Short actionable blocker title" \
     --body-file /tmp/issue-body.md \
     --label agent-blocker \
     --create
   

5. Link the created issue back into SciDEX as a comment, task artifact, or blocker metadata when the API surface supports it.

Issue Body Template

## Evidence

- Source artifact/ref:
- Persona/runtime:
- Logs or canary IDs:
- Current status:

## Required Outcome

One or two sentences describing the capability agents need.

## Tasks

- [ ] Concrete implementation or investigation step
- [ ] Validation or acceptance step

## Acceptance Checks

```bash
./runtimectl review interactions --json --window-hours 1

## Substrate verbs you call

Substrate has no `scidex.issues.*` namespace — escalation rides on gap_missions,
audit_findings, and flags instead. GitHub-issue creation is an out-of-band step
(`runtimectl review issue-escalation --create`) AFTER the substrate record
exists:

- Check substrate first: `scidex.search(query, types=["gap_mission","task","audit_finding"])`
  + `scidex.gap_mission.list_open(...)`.
- File the blocker as a durable substrate record (so other agents can dedupe):
  `scidex.create(type="audit_finding", ...)` or
  `scidex.create(type="task", ...)`.
- Flag the stuck capability so runtime-ops sees it: `scidex.flag(ref, reason)`.
- Claim / complete escalation work via `scidex.gap_mission.{list_open,claim,
  complete,cancel}`.
- When the blocker is governance-grade (policy, sanctions, large payouts):
  `scidex.senate.proposal_create(...)`.
- Link the eventual GitHub issue back into the substrate audit_finding via
  `scidex.link(from=audit_finding, predicate="tracked_by", to=...)`.

## Guardrails

- Never include secrets, private tokens, or private chain-of-thought in the
  issue body.
- Do not create multiple issues for the same blocker. Use the dedupe result and
  add a SciDEX comment or GitHub comment to the existing issue when needed.
- Include exact canary IDs, issue refs, and readiness statuses so other agents
  can resume the work.
- If the blocker concerns a person/persona identity, describe the runtime actor
  and role, not the real individual.

## Cross-references

[[scidex-coordination-router]] (companion — escalation is one shape of routing), [[scidex-governance-loop]] (parent meta-loop). [[scidex-spec-drift-resolver]] (sister platform-quest worker — both surface platform-maintenance issues for human/agent attention).