compiling-project-guidelines

# Compiling Project Guidelines ## Overview Large C/C++/Go/Java codebases (often ~500 KSLOC, sometimes multi-repo) almost always carry their own design and coding conventions — scattered across `CONTRIBUTING.md`, `.github/instructions/`, architecture docs, PDFs, wiki exports, and tribal knowledge. Project teams will not adopt any workflow skill that quietly violates those conventions. This skill is the **one-time (and on-demand) compiler**: it reads whatever guideline sources a team already has — without asking them to migrate to a new schema or folder convention — and produces a single, predictable, human-readable file that every other skill can cite before it reads, writes, modifies, reviews, or judges project code. **Run this:** - Once, during project setup (`/ult-compile-guidelines`) - Again on demand whenever guideline sources change ("update my compiled guidelines — I added `docs/payments-conventions.md`") For multi-repo projects, run it once per repo — scopes are path globs relative to that repo, so no cross-repo machinery is needed. **Output:** `starter_kit/project_guidelines/COMPILED-GUIDELINES.md` — see [the format spec](#step-6--write-the-compiled-file) below. This is the *only* artifact this skill produces. There is no registry, no schema, no state machine, no decision log file — the compiled file carries its own provenance and its own conflict-resolution history. **`compiled_guidelines` (D20 Phase 2, D21 §16.4):** the output path above is the `compiled_gu...