Run any Skill in Manus with one click

environment-first

Stars89

Forks8

UpdatedJuly 7, 2026 at 13:11

When something that should work doesn't, suspect the environment before rewriting the code — wrong directory, stale build, missing env var, version mismatch, dirty state. Use when a command fails unexpectedly, tests fail that "can't" fail, or behavior contradicts the code you're reading.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

adamentwistle

adamentwistle/fable-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	environment-first
description	When something that should work doesn't, suspect the environment before rewriting the code — wrong directory, stale build, missing env var, version mismatch, dirty state. Use when a command fails unexpectedly, tests fail that "can't" fail, or behavior contradicts the code you're reading.

environment-first

Weaker debugging assumes the code is wrong and starts editing. Often the code is fine and the world is misconfigured — and code edits made while the environment lies will be wrong edits.

When behavior contradicts the source you're reading, you're probably not running that source: stale build artifact, cached bytecode, an installed copy shadowing the checkout, the wrong virtualenv/node_modules, a running server that predates the change. Rebuild/restart before concluding the code is haunted.
Check the boring five first (under a minute, in order): pwd — right directory/repo/branch? git status — unexpected local modifications? runtime version (node -v, python --version) vs what the project expects? env vars/config the code reads — set, and set to what you think? is the dependency install current (lockfile newer than last install)?
"Works on the other machine / in CI" is an environment diff by definition. Diff the versions, env vars, and OS assumptions before diffing the code.
Flaky ≠ mysterious: a test failing intermittently usually means shared state, port collisions, timing, or leftover files from a previous run. Clean state and rerun before blaming the test's logic.
Fix the environment properly, then re-run the original failure — and if the "bug" vanishes, say so honestly: nothing was wrong with the code, and no code change should ship (see honest-report).
If the setup itself was broken, note the fix where the project keeps such things — the next session shouldn't rediscover it.

Heuristic: if the failure message doesn't mention your code's names at all (import errors, command-not-found, connection refused), it's environment until proven otherwise.

More from this repository

same repository

ambiguity-commit

adamentwistle/fable-skills

Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).

2026-07-0789

api-surface-care

adamentwistle/fable-skills

Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.

2026-07-0789

calibrated-recommendation

adamentwistle/fable-skills

When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.

2026-07-0789

codebase-orientation

adamentwistle/fable-skills

Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.

2026-07-0789

concurrency-reasoning

adamentwistle/fable-skills

Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.

2026-07-0789

context-checkpoint

adamentwistle/fable-skills

Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.

2026-07-0789

name	environment-first
description	When something that should work doesn't, suspect the environment before rewriting the code — wrong directory, stale build, missing env var, version mismatch, dirty state. Use when a command fails unexpectedly, tests fail that "can't" fail, or behavior contradicts the code you're reading.

environment-first

Weaker debugging assumes the code is wrong and starts editing. Often the code is fine and the world is misconfigured — and code edits made while the environment lies will be wrong edits.

When behavior contradicts the source you're reading, you're probably not running that source: stale build artifact, cached bytecode, an installed copy shadowing the checkout, the wrong virtualenv/node_modules, a running server that predates the change. Rebuild/restart before concluding the code is haunted.
Check the boring five first (under a minute, in order): pwd — right directory/repo/branch? git status — unexpected local modifications? runtime version (node -v, python --version) vs what the project expects? env vars/config the code reads — set, and set to what you think? is the dependency install current (lockfile newer than last install)?
"Works on the other machine / in CI" is an environment diff by definition. Diff the versions, env vars, and OS assumptions before diffing the code.
Flaky ≠ mysterious: a test failing intermittently usually means shared state, port collisions, timing, or leftover files from a previous run. Clean state and rerun before blaming the test's logic.
Fix the environment properly, then re-run the original failure — and if the "bug" vanishes, say so honestly: nothing was wrong with the code, and no code change should ship (see honest-report).
If the setup itself was broken, note the fix where the project keeps such things — the next session shouldn't rediscover it.

Heuristic: if the failure message doesn't mention your code's names at all (import errors, command-not-found, connection refused), it's environment until proven otherwise.