بنقرة واحدة
session-report
Generate a polished HTML session report based on the current session's work
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Generate a polished HTML session report based on the current session's work
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
| name | session-report |
| description | Generate a polished HTML session report based on the current session's work |
| summary | Generates polished HTML session reports from conversation work |
| disable-model-invocation | true |
Generate a polished, self-contained HTML report based on this session's work. The workflow adapts to what the operator needs rather than forcing a fixed section structure.
Follow these four phases in order. Do not skip phases.
Ask the operator what kind of report they need. Present ONE AskUserQuestion with a single-select of report intents:
| Intent | Description |
|---|---|
| Session Log | Chronological record of what happened — channels read, values observed, tools used. Minimal interpretation. |
| Analysis Report | Technical deep-dive with charts, data tables, and narrative observations about patterns and anomalies. |
| Executive Briefing | High-level summary for management — KPIs, status cards, key observations in non-technical language. |
| (Other) | Operator describes a custom report structure. |
Do NOT ask follow-up questions after this unless the operator response is ambigious.
session_summaryUse the session_summary MCP tool to get a compact inventory of all data context entries and artifacts in the workspace. This tells you exactly what data is available.
Based on the operator's intent and the inventory, draft a report structure. There is no fixed section list — the structure should be driven by what data exists and what the intent calls for.
Guidance (not constraints) on block types that work well:
archiver_downsample to get chart-ready data (never embed raw timeseries).timeline diagram type renders events organized by time periods with grouping, making complex sequences easier to scan than a flat list. Prefer this over the CSS timeline when there are 5+ events or natural phase groupings.stateDiagram-v2 renders state machines with transitions and guards. Only include when actual state changes were observed — never fabricate state models.Keep it proportional: A 10-minute session with 2 channel reads doesn't need 8 sections. A 2-hour investigation with archiver data, plots, and multiple analyses might warrant a rich structure. Match the report's complexity to the session's complexity.
If the structure includes charts and the inventory shows timeseries data, call archiver_downsample for each relevant data context entry now. This gives you chart-ready payloads (labels + datasets) that fit inline.
Spawn a Task subagent to generate the report. Pass it:
session_summary outputarchiver_downsample results (if applicable)The subagent should:
.claude/skills/session-report/reference.md for CSS/JS patternsartifact_save, session_log, archiver_downsample) as neededartifact_saveCRITICAL — Observation-only reporting
This report documents what was observed during the session. It must NEVER generate recommendations, prescriptive advice, or action items.
- ALLOWED: "Beam current was observed at 302.1 mA" / "A downward trend was noted between 14:00–15:00" / "The value exceeded the nominal range"
- FORBIDDEN: "Investigate the corrector magnets" / "Consider adjusting the RF frequency" / "It is recommended to..."
Exception: If the operator explicitly stated an action item during the session (e.g., "I need to check the vacuum pump tomorrow"), it may be included as an attributed quote: "Operator noted: 'Need to check vacuum pump tomorrow'".
<!DOCTYPE html> file — all CSS in <style>, all JS before </body>prefers-color-scheme media queryfadeUp and fadeScale animations with prefers-reduced-motion respectdisplay=swapAfter the subagent returns:
artifact_focus so it appears in the galleryopen <artifact_path>Do NOT:
archiver_downsample for chartsprefers-reduced-motion media query