القائمة
Use when the user wants to create a self-hosted, offline-installable Conda channel (mirror) containing a specific subset of packages using Pixi.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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).
| name | pixi-make-offline-channel |
| description | Use when the user wants to create a self-hosted, offline-installable Conda channel (mirror) containing a specific subset of packages using Pixi. |
Use this skill when the user asks to:
This skill guides the user to creating a custom, self-hosted Conda channel (mirror) that contains only a selected subset of packages but includes all transitive dependencies. This ensures the channel is fully installable on offline machines.
The workflow uses Pixi's lockfile (pixi.lock) as the source of truth for dependency resolution and rattler-index for generating channel metadata.
Create a temporary "builder" project to define the package set. This project will not be used for running code, but for resolving the dependency tree.
mkdir my-mirror-builder
cd my-mirror-builder
pixi init
Add the target packages you want to mirror. Also add the necessary build tools (rattler-index and pyyaml) to the environment.
# Target packages to mirror
pixi add pandas scikit-learn pytorch
# Tools required for the mirroring process
pixi add rattler-index pyyaml requests
Use a Python script to parse pixi.lock, extract the exact URLs for all resolved dependencies, and download them into a standard channel structure (e.g., channel/linux-64/).
Key Steps for the Script:
pixi.lock (YAML format).packages.url to output_dir/<platform>/<filename>.Ref: See context/hints/howto-create-self-hosted-conda-subset-repo-with-pixi.md for the complete build_mirror.py script.
After downloading all artifacts, use rattler-index to generate the repodata.json. This turns the directory into a valid Conda channel.
pixi run rattler-index local-channel
The channel is now ready. It can be used via file:// or hosted via HTTP.
Verification:
# Create a test env using ONLY the local channel
conda create -n test-offline -c file://$(pwd)/local-channel pandas --offline --override-channels
linux-64 AND osx-arm64), manually edit pixi.toml to include them (platforms = ["linux-64", "osx-arm64"]) and run pixi lock before running the download script.pixi update the builder project, re-run the download script (it should skip existing files), and re-run rattler-index.pixi-pack instead. This skill is for creating a reusable channel.