You just cloned a repo you have never seen, whether from a new job or an inherited project, and you need to be productive today. This workflow gets the project running locally and captures the fix in a verified SETUP.md, decodes an opaque build system, pinpoints exactly where your first change goes, and traces a real user action end to end so the code stops feeling like a black box. It is language and build-system agnostic, so the same four commands work whether the repo is Go, Rust, TypeScript, or a polyglot monorepo.
Start by getting the repo to actually run. dev-env-bootstrap detects the toolchain, installs dependencies, and diagnoses the broken or undocumented setup steps the README skipped: the missing runtime version, the unset environment variable, the service that has to be running first. It works through them until the app builds and starts, then records the exact working sequence in a verified SETUP.md so the process is reproducible.
Unfamiliar build tooling is where onboarding stalls. build-explain reads the Make, Bazel, Gradle, Nx, or Turborepo configuration and explains what each target does, how the targets depend on one another, and which commands actually build, test, lint, and run the project. Point it at a single target to learn exactly what happens when you invoke it.
Describe your first task in plain language and locate-change maps it to the exact files, functions, and layers you need to touch. Instead of grepping blindly across an unfamiliar tree, you get a scoped list of where the behavior lives and what each site is responsible for.
Pick a real user action and trace-flow follows it through the codebase: from the entry point, through the routes, services, and data access it touches, to the response that comes back. Seeing the full path turns the files you located into a working mental model of how the system actually behaves.
Run /dev-env-bootstrap before anything else, even if the README claims setup is trivial. It diagnoses the missing runtime version, the unset environment variable, and the service dependency the README forgot, then writes a verified SETUP.md so the next new hire does not lose a day to the same problems.
When /build-explain lists the targets, find out which one your CI actually runs. The command your team ships with is often not the one in the README, and knowing the real build, test, and lint targets is what keeps your first pull request green.
Give /locate-change the task in the words from your ticket, not in code terms. Describing the behavior you want to change lets it map the feature to the exact files, and running /trace-flow on that same feature afterward confirms you found the right entry point before you touch anything.