setuplisted

# pm:setup — read the schemas, draft the config The `pm` skills read every value from `pm-conventions.yaml`. This is where that file comes from. **It reads schemas rather than inferring from samples.** A design file has no schema, so `/fig:setup` has to count occurrences and take the dominant value. A document database and an issue tracker both publish theirs — property names, select options, labels, field ids. So this skill queries, and only interviews for what a schema genuinely cannot answer. **What it never does is guess.** A value the schema does not settle is written as `null`, and `null` means that check or that step is skipped. Filling a blank with a plausible value is how a config ends up describing a workspace nobody has. ## When to invoke - Opening these skills on a new workspace, a new company, or a new tracker - The tracker was restructured — fields renamed, a board rebuilt, options changed - `/pm:task-publish` stopped with "this project is not mapped" - You need the board ids for `mirror_extras` and do not want to write GraphQL by hand ## When NOT to invoke - Drafting a task's context table → `/pm:task-draft` - Design file conventions → `/fig:setup`. Separate file, separate config ## Inputs - `record` (optional): the planning-side list — a database url, a repo, or a directory - `mirror` (optional): the engineering tracker — usually `owner/repo` - `out` (optional): where to write. Defaults to `~/.claude/pm-conventions.yaml`; pass `./pm-conventions.yaml`