SkillsAdd

phira-ai/phira · Archived

phira-env-contract

Procedural checklist to infer and state the repo's effective runtime environment and dependency policy.

First seen Jun 20, 2026

Installation

$ npx skills add phira-ai/phira --skill phira-env-contract
View on skills.sh ↗ GitHub repository ↗

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

phira-impl-vs-claim-audit Same source
phira-ai/phira

Procedure to audit alignment between a document's claims (e.g., algorithm description) and the …

1 installs
phira-baseline-parity Same source
phira-ai/phira

Checklist for proving baseline behavior is unchanged (or changes are intentional) via controlle…

1 installs
phira-archive-pointers Same source
phira-ai/phira

Pointer semantics for "since last record" and detected-change bookkeeping.

1 installs
summarise-paper Same author
phira-ai/phi-skills

Use when tasks involve reading and summarising an academic paper from either a PDF file or an a…

106 installs

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

review-contract Similar name
anthropics/knowledge-work-plugins

Review a contract against your organization's negotiation playbook — flag deviations, generate …

3.2K installs
contract-review Similar name
anthropics/knowledge-work-plugins

Lightweight NDA, MSA, and vendor contract review for SMBs without legal on staff. Reads contrac…

2.2K installs
prisma-next-contract Similar name
prisma/prisma-next

Edit the Prisma Next data contract — add models, fields, relations, indexes, enums, value objec…

1.3K installs
planetscale-change-gates-and-approval-contract Similar name
planetscale/skills

Enforce explicit approval gates for any PlanetScale, database, repository, credential, network,…

13 installs
typed-service-contracts Similar name
google-labs-code/design.md

Architecture standard for building robust, type-safe TypeScript services using the "Spec and Ha…

13 installs
doca-structured-tools-contract Similar name
nvidia/skills

Use this skill whenever another DOCA skill says "prefer the structured tool per doca-structured…

119 installs

Also in this package

Other skills from phira-ai/phira.

npx skills add phira-ai/phira
phira-impl-vs-claim-audit 1 phira-baseline-parity 1 phira-archive-pointers 1

Browse all from phira-ai/phira

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 10
License LICENSE
Default branch main
Open issues 2
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,425 B
  • docs SUMMARY.md 129 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Use this skill whenever you are about to implement code that could be sensitive to Python/library versions, GPU/CPU availability, or dependency policy.

Goal: produce an explicit "environment contract" that constrains implementation choices and makes later failures reproducible.

Output (copy/paste into your response)

Provide this block near the top of your implementation report:

Environment contract
- Python: <version or "unknown">
- Platform: <os/arch or "unknown">
- Key deps: <package>=<version> (only those that matter)
- Dependency policy: <"no new deps" | "deps allowed" | "unknown">
- Hardware: <"cpu" | "gpu" | "unknown"> (only if relevant)
- Provenance: <how you inferred this>

Checklist (do in order)

  1. Prefer repo artifacts over assumptions
  • Look for: pyproject.toml, requirements.txt, poetry.lock, uv.lock, Pipfile.lock, environment.yml, conda.yml, Dockerfile, docker-compose.yml, Makefile, noxfile.py, tox.ini, .python-version, .tool-versions, setup.cfg, setup.py.
  • Look for CI: .github/workflows/, ci/.
  • Look for runtime docs: README*, docs/**.
  1. Infer Python version
  • If .python-version / .tool-versions exists: trust it.
  • Else if CI pins Python: trust CI.
  • Else if Dockerfile pins Python: trust Docker.
  • Else: report as unknown and constrain implementation to broadly compatible code.
  1. Identify the smallest set of "key deps"
  • Only list packages that affect your change (e.g., torch, jax, transformers, numpy, pydantic, hydra, lightning, accelerate, datasets).
  • Prefer pinned lockfiles over loose requirements.
  1. Determine dependency policy
  • If the task explicitly allows new deps: set deps allowed.
  • Else default to no new deps.
  • If you truly cannot infer: mark unknown and stop to ask phira only if it changes the implementation approach.
  1. Record provenance
  • Cite exactly which artifacts/commands you used (e.g., "from .github/workflows/ci.yml", "from pyproject.toml", "ran python --version in this env").

Guardrails

  • If environment constraints are unknown and materially affect correctness, ask phira one targeted question that requests only the missing constraint(s).
  • Do not upgrade/bump dependencies by default.