# Conda Project Environment Manager

> Manage and standardize project conda environment usage as an auxiliary utility skill, including env discovery, package availability checks, explicit env selection, and reproducible `conda run -n ...` integration for scripts and workflows.

- Skill: `mr-fang-vlsi/conda-project-environment-manager` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add mr-fang-vlsi/conda-project-environment-manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mr-fang-vlsi/conda-project-environment-manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: Mr-Fang-VLSI (https://skillmd.com/u/mr-fang-vlsi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mr-fang-vlsi/conda-project-environment-manager

---


# Conda Project Environment Manager

Use this skill when the repo needs one stable helper for managing Python/conda environments across scripts, research utilities, and infrastructure workflows.

## When to use

Use this skill when:
1. the project needs to know which `conda` installations and envs are available,
2. a workflow needs a reproducible env choice for scripts such as model fitting, PDF processing, or slide generation,
3. packages are missing from the default shell Python and the project should standardize `conda run -n ...` instead of ad hoc shell state,
4. multiple conda roots (`miniconda`, `anaconda`) coexist and env provenance is becoming confusing,
5. env drift, missing packages, or conflicting Python roots are blocking project work.

## Scope boundary

This skill owns:
- project-level conda env discovery and reporting,
- explicit env-selection guidance for scripts and workflows,
- package-availability checks for target envs,
- environment snapshot artifacts for later maintenance or debugging,
- minimal reproducibility guidance for `conda run -n ...` use in this repo.

It does not own:
- workflow routing or workflow ownership,
- domain experiment conclusions,
- arbitrary package installation policy for unrelated user machines,
- replacing system package managers outside project needs.

## Preferred usage pattern

1. discover conda roots and envs,
2. record package availability in a snapshot artifact,
3. choose one explicit env per workflow/tool family,
4. call scripts through `conda run -n <env> ...` when reproducibility matters,
5. update the snapshot when environments change materially.

## Expected outputs

Typical outputs include:
1. `*.envs.tsv`
2. `*.summary.md`
3. a short recommendation on which env should back which script family
4. maintenance-log or KB refresh only when the environment contract changes materially

## Hard rules

1. Do not rely on accidental shell activation as the default reproducibility mechanism.
2. Prefer explicit `conda run -n <env>` when a script depends on non-system packages.
3. Keep the number of project-preferred envs small; do not create a new env for every one-off task.
4. Record when both `miniconda` and `anaconda` roots coexist so future users do not guess which one is active.

## Operational references

1. Load `references/background-knowledge-links.md` for the current environment topology and project conventions.
2. Load `references/update-mechanism.md` when environment structure or preferred env ownership changes.
3. Use `scripts/common/conda_project_env_report.py` to generate the canonical snapshot before recommending a new env binding.