magic-context

Prepare and run a user-confirmed interactive execution or test session for a source file, executable, script, demo, or directory. This skill must be invoked manually: use it only when the user explicitly invokes step-interactive-execution by name or clearly asks for this exact manual workflow. Read the target first without pausing, then switch to a strict step-by-step loop where the agent prints the exact CLI command to run next, waits for confirmation such as "continue", executes only that approved command, and reports the result before proposing the next step.

Manual invocation only. Drive a crashy, hanging, or half-broken system forward along a real production user path using real data. Two subskills: `prepare` to analyze the target and set up `<htt-home>/` with infrastructure dirs (logs, runs, issues); optionally creates `<htt-home>/autotest/` with automatic scripts and interactive guides only when the developer explicitly requests test-case generation. `run` drives testing — with or without autotest artifacts — patching forward through blockers. Run subskill operates in-place by default (stash + test on current branch) or in a disposable snapshot worktree when explicitly requested. Supports automatic and interactive driving. Default when ambiguous: both subskills, in-place, automatic. Not for CI-oriented unit, smoke, or mock-based integration tests.

Programmatically invoke Codex via the `codex` CLI for headless, non-interactive runs using `codex exec`, machine-readable JSONL via `--json`, final-message capture via `-o/--output-last-message`, and multi-turn continuation via `codex exec resume`. Use when you need scriptable Codex automation for repo reviews, issue investigation, implementation planning, or structured one-shot outputs.

Create and resume Codex CLI sessions with a persistent session-name-to-thread_id mapping plus last-used model stored in a workspace-scoped JSON file under system temp. Invoke only when the user explicitly names `$codex-cli-invoke-persist` or otherwise clearly requests this exact skill. Use it for deterministic, session-persistent Codex automation across turns and processes.

Manual invocation only. OpenSpec-specific hack-through-testing workflow targeting production-level end-to-end paths using real data and real user workflows — not CI smoke/unit/integration tests. Three subskills: `propose` to create an OpenSpec change with HTT-ready test cases (automatic scripts and interactive guides) by invoking `openspec-propose` or `openspec-ff-change`, `revise` to update an existing OpenSpec change so its artifacts support hack-through-testing-driven implementation and testing, and `run` to exercise an implemented OpenSpec change through the full hack-through-testing loop (in-place by default, or in a disposable snapshot worktree when requested). Use when the user explicitly asks for `openspec-ext-hack-through-test`, points to `openspec/changes/...` while asking to propose, revise, run, exercise, or prepare work under hack-through-testing principles, or wants OpenSpec work shaped for fast blocker discovery through patch-forward testing.

Review an OpenSpec change (or a single OpenSpec change artifact file) for completeness, coherence, and alignment with existing system design; capture actionable feedback plus open questions; write a review report under the change directory (review/review-YYYYMMDD-HHMMSS.md).

Read an OpenSpec review report critically, evaluate the reviewer's proposals and findings against the current change artifacts and repository context, and write developer-owned final decisions/responses back into the review document. Use when the user explicitly mentions `openspec` or points to a path under `openspec/` while asking to examine a review report carefully, decide open questions, respond to findings, fill `DECISION` blocks, respond to an OpenSpec review file, or record final answers in an OpenSpec review document without yet revising the proposal, design, specs, or tasks.

Manual invocation only; use only when the developer explicitly requests `impl-via-git-worktree` or asks for implementation in a fresh local branch/worktree. Snapshot the current repository state into a new local `feature/topic-slug` or `fix/topic-slug` branch, create a separate git worktree, bridge the ignored local resources that worktree needs, implement and test there, and commit the result without pushing. If the target is an OpenSpec change or a path under `openspec/changes/`, derive the change from that target and, once inside the worktree, use OpenSpec tooling plus `openspec-apply-change` there instead of manually assuming artifact paths.

Prepare for and run user-driven interactive testing of a directory the user points to. Use when the user wants the agent to read what is already there first, be prepared, follow step-by-step test instructions, or honor a constrained edit boundary during testing. Handle generic directories, demo/tutorial directories, and OpenSpec change directories differently; for OpenSpec change directories, use openspec CLI commands to gather context instead of assuming a file layout inside the directory. During interactive testing, do not automatically modify the system under test; report issues first, let the developer decide whether to log them or proceed to a fix, and only modify demo-specific code when a fix is explicitly requested. Do not create extra logs unless the developer asks for issue logging or step logging.

Manual invocation only; use only when the user explicitly requests `create-git-worktree` by exact name. Create a clean git worktree for the current repository and symlink reusable local tool-state directories into it.

A three-part Claude Code setup skill with subskills for installation, skip-login configuration, and custom API-key launcher setup. Use when the user wants Claude Code installed or configured on the current host, with instructions adapted to the actual operating system and runtime environment.

Create or update OpenSpec change explanation docs that capture developer-facing questions and answers under `openspec/changes/.../explain/`. Use when the user explicitly mentions `openspec` or points to a path under `openspec/` while asking to create, update, document, or maintain a Q&A, FAQ, explain note, or question-and-answer doc for an OpenSpec change based on user questions, implementation notes, review questions, or current chat context.

Programmatically invoke GitHub Copilot CLI via the `copilot` command (headless `-p`, `--silent`, `--stream on|off`, `--resume`/`--continue`) to automate tasks like producing code review notes for specific files/dirs, investigating an issue, or drafting an implementation plan. Use when you need scriptable, non-interactive Copilot runs with optional streaming progress and session continuation.

A three-part Codex CLI setup skill with subskills for installation, skip-login configuration, and custom API-key launcher setup. Use when the user wants Codex CLI installed or configured on the current host, with instructions adapted to the actual operating system and runtime environment.

Test a target (script, demo, pipeline, CLI command, integration) without modifying any source code, then write a structured log of the process, outcomes, anomalies, and issues. Use when the user says "test X and log", "run X and document findings", or "try X without changing code". Default log location is context/logs/TIMESTAMP-task-name/TIMESTAMP.md.

Manual invocation only; use only when the user explicitly requests `openspec-ext-revise-by-decision` by exact name. Revise OpenSpec change artifacts from a review or decision document that contains questions plus `DECISION` blocks, applying chosen decisions from a review file such as `openspec/changes/<change>/review/review-*.md` back into proposal, design, specs, and tasks.

Programmatically invoke Claude Code via the `claude` CLI (headless `-p`, `--output-format json|stream-json`, `--resume`/`--continue`) to automate tasks like producing code review reports for specific files/dirs, investigating an issue, or drafting an implementation plan. Use when you need scriptable, machine-readable output and/or session-persistent multi-turn workflows with Claude Code.

Create and resume Claude Code CLI sessions with a persistent session-name-to-session_id mapping (plus last-used model and reasoning effort) stored in a workspace-scoped JSON file under system temp. Use when the user wants deterministic, session-persistent Claude Code automation across turns and processes.

Initialize and scaffold a new Pixi-managed Python project, or upgrade an existing one. Use when the user explicitly mentions "init", "initialize", or "setup" in conjunction with "pixi". Handles existing projects by prompting for confirmation before merging.

Serve markdown/docs/text notes with MkDocs using a specified work directory as the output folder (scripts/config/site).

Create readable Mermaid diagrams inside Markdown files. Use for flowcharts and sequence diagrams that must render cleanly in common Markdown renderers (e.g., GitHub) without horizontal scrolling. Covers fenced mermaid blocks, init/theme styling, label wrapping with <br/>, and sequenceDiagram layout rules (short IDs, wrapped labels, don’t break identifiers).

Performs initial configuration of a development host with a fixed sequence: setup proxy first, then configure pixi/uv/npm/bun global tooling, and finally configure Claude Code. Use only when explicitly invoked by name for first-time host bootstrap or full re-bootstrap.

Build a VS Code air-gapped "offline kit" for Remote-SSH: desktop VS Code installers/archives for Windows/macOS/Linux, matching VS Code Server+CLI tarballs for headless Linux (commit-aligned), and pinned extension .vsix bundles for both local (client) and remote (server) sides. Use when you need a reproducible offline deployment, or when you want to mirror the VS Code release+extensions currently installed on a host.

Use when the user wants to create a self-hosted, offline-installable Conda channel (mirror) containing a specific subset of packages using Pixi.

Guides the agent to setup a new or existing Pixi environment for compiling C++ and CUDA code. It ensures the correct compilers, toolkits, and CMake configurations are in place for a robust user-space build.

Use when the user says "use pixi to install <some nvidia tool>" (or similar) and wants NVIDIA/CUDA/GPU packages installed via Pixi (no sudo/apt), e.g., CUDA toolkit pieces, cuDNN/NCCL, PyTorch CUDA builds, RAPIDS.

Basic operations for the Conan C++ package manager. Use when the user explicitly asks to 'use conan' for tasks like creating projects, installing dependencies, or building packages, or asks for 'how to' guidance on Conan setup.

Scripted process to build and verify a Pixi-managed project in Docker, then produce a portable WORKDIR/product directory for air-gapped use.

Manual invocation only; use only when the user explicitly requests `explore-dnn-model` by name. Explore how to run a given DNN model checkpoint in the current Python environment by locating weights + upstream source code, resolving dependencies with user confirmation, running reproducible experiments under `tmp/`, and producing reports about I/O contracts, timing, and profiling.

Helper for PeiDocker (`pei-docker-cli`). Trigger ONLY when the user explicitly requests PeiDocker usage OR when working within a PeiDocker-generated project (indicated by `user_config.yml`).

Manual invocation only; use only when the user explicitly requests `make-program-tutorial` by exact name, OR when the user asks to use a skill to create an SDK/API/library tutorial. Create a clear, reproducible, step-by-step tutorial for a specific API/SDK/library (or a set of functions/classes), with runnable examples, expected outputs, and basic troubleshooting.