メニュー
Local sandboxed compute — Docker or host process. Use for quick / iterative work, MLX/Metal on Apple Silicon, anything that fits within local memory + disk. Free, no approval gate, supports stop.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Create or revise high-quality academic and research presentation slides in Markdown using Marp, following a story-first multi-phase workflow. Use when the user needs conference talk slides, lab or group meeting decks, thesis defense presentations, research seminars, invited talks, mixed-audience or industry research talks, OR wants to create, revise, or edit a talk deck or a specific slide of it (e.g. 'revise slide 7 of my conference talk'). Starts from an audience-facing story spine before slide titles, frameworks, screenshots, or feature lists; then applies Assertion-Evidence and Mayer multimedia principles. For teaching/lecture slides use `teaching-marp-slides`; for written documents use `paper-writing` or `scientific-writing`; for individual figures use `scientific-visualization`.
Create or revise lecture/teaching slides in Markdown using Marp for upper-undergraduate and graduate courses across any academic discipline. Use when the user needs classroom lecture slides, course materials, tutorial slides, or workshop sessions — including a request framed as creating or editing a slides Markdown file (e.g. a '*_slides.md' in a course or week folder) for teaching a class — or wants to revise existing teaching slides. Enforces Cognitive Load Theory, worked-example effect, scaffolding, and retrieval practice principles. Produces both a lecture version and a handout version. For research/conference talks use `academic-marp-slides`; for written documents use `paper-writing` or `scientific-writing`.
Strategically revise an existing CS/AI/Systems conference paper draft for resubmission or submission readiness. Focuses on framing diagnosis, claim crystallization, narrative unification, evidence strengthening, reviewer defense, and venue-aware polish.
Write publication-ready ML/AI/Systems conference papers (NeurIPS, ICML, ICLR, ACL, AAAI, COLM, OSDI, NSDI, ASPLOS, SOSP). Use when the user requests a conference manuscript, needs conference-specific templates/checklists, or format conversion between venues. For journal articles or technical reports, use scientific-writing instead.
Core skill for high-quality research strategy, topic exploration, idea generation, scope/framing critique, contribution assessment, and mentor-style research direction refinement. Use when the user asks whether an idea is worth pursuing, wants brainstormed research directions, needs to pivot, sharpen a paper/proposal scope, evaluate novelty, identify the strongest objection, or turn a vague area into a concrete, testable research plan. Produces a small number of high-bar candidates with premise audits, nearest alternatives, decisive experiments, and kill criteria.
Prompt guidance for the generate_diagram tool — how to describe different scientific diagram types (flowcharts, pathways, architecture, circuits, networks, conceptual) so the tool produces publication-grade output on the first iteration.
| name | compute-local |
| description | Local sandboxed compute — Docker or host process. Use for quick / iterative work, MLX/Metal on Apple Silicon, anything that fits within local memory + disk. Free, no approval gate, supports stop. |
| category | Compute |
| tags | ["compute","local","sandbox"] |
| triggers | ["run script","python","train locally","fine-tune locally","data processing"] |
| license | MIT |
| metadata | {"skill-author":"Research Copilot"} |
Local backend (backend: 'local', toolPrefix: 'local') runs scripts in a sandbox on the user's machine — Docker when available, host process otherwise. No cost, no approval gate, supports stop.
sandbox: 'process').list_compute_backends() to confirm local is registered + available.compute_plan({ backend: 'local', command, task_description, script_path? }) — produces a plan with risk assessment, recommendations, and an experience summary if you've run similar tasks before.local_execute({ plan_id, timeout_minutes? }) — kicks off the run.local_status({ run_id }) or block with local_wait({ run_id, timeout_seconds? }).local_stop({ run_id }).When the planner detects --smoke / --dry-run / --validate flags in the script's argparse/click config, it sets smokeSupported: true and recommends a quick validation run before the full execution. The runner will automatically run the smoke command first; if it fails, the full run is not attempted.
The planner recommends one of:
docker — preferred on Linux with Docker installed; isolates filesystem + network.process — used on Mac (no GPU passthrough in Docker) or when Docker isn't installed.You can override via the sandbox field in backend_data.recommendations when building the plan, but the recommendation is usually correct.
When a run fails, local_status returns a failure field with a code (e.g. OOM_KILLED, MODULE_NOT_FOUND, TIMEOUT) and human-readable message + suggestions. Retry by calling compute_plan + local_execute again with parent_run_id set to the failed run id — this preserves the retry lineage for the experience tracker.
Print structured progress on stdout:
##PROGRESS## {"step": 1, "total": 5, "phase": "loading", "percentage": 20}
The runner extracts these and surfaces them through local_status/local_wait.