メニュー
Investigate OSPREY tool, agent, or MCP server failures. Use when a tool call returned an error, a subagent failed, or the MCP infrastructure is not responding. NOT for diagnosing accelerator or machine operational issues.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | diagnose |
| description | Investigate OSPREY tool, agent, or MCP server failures. Use when a tool call returned an error, a subagent failed, or the MCP infrastructure is not responding. NOT for diagnosing accelerator or machine operational issues. |
| summary | Investigate OSPREY infrastructure and agent failures |
Systematically investigate an OSPREY infrastructure failure, gather evidence from all available sources, and produce a structured incident report for developer handoff.
Follow these three phases in order. Do not skip phases.
Determine the investigation target. Use $ARGUMENTS if provided, otherwise infer from conversation history.
Establish:
Do NOT ask the user questions in this phase. Use conversation context to fill in the scope. If the scope is ambiguous, state your best understanding and proceed — the report will make any ambiguity visible.
Gather evidence from ALL sources below. Never stop after one source. Empty results from one source are findings, not dead ends.
Review the conversation history for:
error_code, error_class, message fields)Record each piece of evidence with its source (e.g., "conversation turn N" or "tool call to X").
Query the session log in this order:
session_log(list_agents=True) — get the full picture of all agents and their tool/error countssession_log(agent_id="<id>")session_log(errors_only=True, last_n=20)session_log(since="<timestamp>")If session_log returns empty results, this IS evidence. Record it as a finding and note the possible causes:
Do NOT treat empty session_log results as "nothing to see." Document what was queried, that it was empty, and what that absence implies.
session_summary() to get the current workspace inventory (artifacts, agents)data_list() to see all data entriesCross-reference against session_log findings:
Extract concrete details from conversation-visible tool responses:
Produce a structured incident report as a self-contained HTML artifact and save it to the gallery.
Build a single HTML string with inline CSS (no external dependencies). Use this structure:
<!DOCTYPE html>
<html lang="en"><head><meta charset="utf-8">
<title>Diagnostic Report</title>
<style>
* { margin:0; padding:0; box-sizing:border-box; }
body { font-family:-apple-system,system-ui,sans-serif; background:#0f172a; color:#e2e8f0; padding:24px; line-height:1.5; }
.header { border-bottom:2px solid #ef4444; padding-bottom:12px; margin-bottom:24px; }
.header h1 { font-size:1.4rem; color:#f8fafc; }
.header .timestamp { font-size:0.85rem; color:#94a3b8; margin-top:4px; }
.severity { display:inline-block; padding:2px 10px; border-radius:4px; font-weight:600; font-size:0.8rem; text-transform:uppercase; }
.severity-critical { background:#991b1b; color:#fecaca; }
.severity-warning { background:#92400e; color:#fde68a; }
.severity-info { background:#1e3a5f; color:#93c5fd; }
section { margin-bottom:24px; }
section h2 { font-size:1.1rem; color:#f8fafc; border-bottom:1px solid #334155; padding-bottom:6px; margin-bottom:12px; }
.evidence-item { background:#1e293b; border-radius:6px; padding:12px; margin-bottom:8px; border-left:3px solid #3b82f6; }
.evidence-source { font-size:0.75rem; color:#60a5fa; text-transform:uppercase; letter-spacing:0.05em; }
.evidence-finding { margin-top:4px; }
.evidence-significance { margin-top:4px; font-size:0.85rem; color:#94a3b8; font-style:italic; }
.cause-item { background:#1e293b; border-radius:6px; padding:12px; margin-bottom:8px; }
.cause-rank { display:inline-block; width:24px; height:24px; border-radius:50%; background:#3b82f6; color:#fff; text-align:center; line-height:24px; font-size:0.8rem; font-weight:600; margin-right:8px; }
.gap-item { background:#1e293b; border-radius:6px; padding:10px; margin-bottom:6px; border-left:3px solid #f59e0b; }
.next-step { background:#1e293b; border-radius:6px; padding:10px; margin-bottom:6px; border-left:3px solid #22c55e; }
.timeline-event { display:flex; gap:12px; margin-bottom:8px; }
.timeline-time { flex:0 0 100px; font-size:0.8rem; color:#60a5fa; text-align:right; padding-top:2px; }
.timeline-dot { flex:0 0 12px; position:relative; }
.timeline-dot::before { content:''; display:block; width:10px; height:10px; border-radius:50%; background:#3b82f6; margin-top:5px; }
.timeline-dot::after { content:''; position:absolute; top:18px; left:4px; width:2px; height:calc(100% + 4px); background:#334155; }
.timeline-event:last-child .timeline-dot::after { display:none; }
.timeline-desc { flex:1; }
</style></head><body>
<!-- Fill in sections dynamically based on investigation findings -->
</body></html>
Populate the HTML with:
.evidence-item per finding, each with source badge, finding text, and significance..timeline-event entries..gap-item per evidence source that returned empty/inconclusive. Each must say what was queried, that it was empty, and what the absence could mean..cause-item entries. Each must cite supporting evidence numbers. Do NOT speculate beyond what evidence supports..next-step per handoff action for HUMANS (not the agent).Call the artifact_save MCP tool:
artifact_save(
title="Diagnostic Report — <brief failure description>",
description="Infrastructure failure investigation: <1-line summary>",
content=<the HTML string>,
content_type="html",
category="diagnostic_report"
)
Then call artifact_focus(artifact_id=<id from response>) to open the report in the gallery.
After saving, present a brief inline summary: the failure summary and suggested next steps. Don't duplicate the full report — point the user to the gallery artifact for details.
Operate an already-registered Bluesky scan through the shared plan draft and the plan/results panels: stage the complete configuration in one set_draft, let the human review it live in the plan panel, launch it at a pinned revision, and watch the run. Use when asked to run, launch, or start a scan that already exists. NOT for authoring a new plan file (use writing-bluesky-plans first).
Author a new Bluesky plan for the Bluesky MCP server: the plan-file format (PLAN_METADATA/PARAMS/build_plan), the allowlist the validator enforces, and the author -> validate -> run -> contribute workflow. Use when asked to write, draft, or author a new Bluesky plan, or when an existing plan needs editing before re-validation. NOT for operating an already-registered plan (use the operating-bluesky-scans skill).
Interactive interview to create a custom OSPREY build profile for a new accelerator, detector, or beamline application. Use when someone says "interview me", "create a build profile", "set up my agent", "configure my detector", "onboard me", or needs to create an OSPREY project tailored to their specific control system. Also handles migration from existing OSPREY projects (including LangGraph-era projects) — trigger on "migrate my project", "I have an existing project", "upgrade from old OSPREY", "upgrade from langgraph", "legacy migration", "bring my project forward", "convert my project", "extract profile from existing project", "reverse-engineer build profile". Also use for /osprey-build-interview feedback to collect post-use feedback. Also trigger when onboarding a new colleague or when anyone needs help figuring out what their OSPREY agent should look like.
Author a new OSPREY web-terminal panel — a self-contained, themed HTML mini-app the terminal mounts beside the chat. Use whenever someone wants to create, author, add, scaffold, or build an OSPREY panel, a design-system panel, or a standalone themed surface for the web terminal. Produces a token-only panel that passes the panel validator.
Deployment control plane for an OSPREY-based facility profile repository. Owns the deploy lifecycle end-to-end: scaffolds the deploy infrastructure (docker-compose, .gitlab-ci.yml, scripts/deploy.sh, .env.template) from facility-config.yml, drives the GitLab CI/CD container pipeline (push → CI → manual release tag → server deploy), brings containers up on the deploy server with `scripts/deploy.sh`, and runs post-deploy health checks. Modular opt-in support for OLOG/logbook integration, multi-user web terminals, Ollama embeddings, shared-disk mounts, EPICS-driven event dispatcher, ARIEL database, wiki search, custom MCP servers, e2e benchmarks, and EPICS test IOC management. Use this skill whenever the user is asking about deploying, releasing, pushing to GitLab, building containers, modifying docker-compose files, scripts/deploy.sh, .gitlab-ci.yml, the CI pipeline, the container registry, the deploy server, the .env, the facility-config.yml, webhook triggers, the event dispatcher, web terminals, OLOG, Ollama,
OSPREY's design and architecture principles — the rules that define how OSPREY code should be structured, and the anti-pattern each one prevents. Consult before designing, adding, or reviewing any feature (connectors, MCP servers, providers, capabilities, CLI, registry, runtime, config), and when redirecting work that is drifting from these principles. Trigger when the user says "is this the right direction", "does this fit OSPREY", "this feels wrong", "check the design philosophy", or points an agent at how OSPREY code should look. Apply before adding a config knob, a new abstraction, a new subsystem, or anything touching hardware-write safety.