dev-environment-facadelisted

# One Entry Point, Zero Ownership Confusion A project's dev workflow deserves one discoverable surface: a thin facade (`make help` tells the whole story) that delegates to real scripts and tools, plus environment files whose ownership is so clear that no target ever needs to rewrite what a human maintains. The facade encodes *which tool with which flags*; procedures live in scripts; generated and hand-edited configuration never share a file. ## When to use Reach for this skill when adding a task runner or Makefile, when designing how tests obtain credentials from a local stack, or when a "just run this one command" developer experience is the goal. Red-flag thoughts — if you catch yourself thinking any of these, STOP: - "I'll put the logic in the Makefile." (Recipes are one-liners; logic lives in scripts.) - "The test target can regenerate the env file while it's at it." (Targets consume; provisioning writes.) - "I'll preserve the user's lines while rewriting the file." (Preservation machinery means the ownership split is missing.) - "The recipe can just `source` the env file." (Shell-sourcing hand-edited files couples correctness to shell syntax; load in-process.) - "The suite skipped, and skipped is green." (A certifying gate that passes on zero executed tests is a hole.) - "Any 200 from the service proves the credential works." (Probe the endpoint — some are auth-blind.) - "The script calls it `up`, so the target is `stack-up`." (Names come from the vocabulary; a borr