working-in-a-clonelisted

# Working inside a clone A control plane orchestrates repos; it is not where their work happens (ADR 0008). The plane deliberately does not know how to build or test any of them — that knowledge lives in each repo. This skill crosses that boundary correctly. ## 1. Know the workspace, and stay inside it ```bash charter workspace current # the active workspace, and how it resolved ``` Clones live at `workspaces/<workspace>/<repo>`. Work in the **active** workspace only. A repo needed by this task that sits in another workspace gets cloned into this one — never reached across. ## 2. Make sure it is cloned ```bash charter clone <repo> # skipped if already present; checks out its real default branch ``` Default branches differ across an org (`main`, `master`, `develop`). `charter clone` reads each repo's actual default branch, so never assume one. ## 3. Adopt the repo's own conventions before editing Read whichever of `CLAUDE.md`, `AGENTS.md`, `README.md` the repo ships, then skim its manifest (`package.json`, `pom.xml`, `pyproject.toml`, `go.mod`) for its real build and test commands. Use those — never commands carried over from a different repo. ## 4. Commit to the repo you are in A clone is its own git repository, so committing there touches *its* history and never the plane's. Push per that repo's workflow. The plane's own tracked files are a separate concern — `charter save` commits and pushes those. ## The boundary that is easy to get wrong Claud