What problem does it solve? Code alone cannot reveal why a repository was built the way it was — who it serves, where its contract boundary lies, or which principles are inviolable. This Skill runs a structured two-phase interview that captures that intent from the maintainer and writes it into cairn/DESIGN.md, so future sessions and contributors can act on documented design rationale instead of guesswork. ## Core Features & Use Cases - Phase 1 — Facts: Batched question rounds elicit intent the code cannot show (audience, contract boundary, platform commitments, API-stability posture), with every option grounded in cited repo evidence and proto-principles banked rather than decided. - Phase 2 — Principles: Formalizes banked candidates plus principles mined from git history and domain constraints, classifying each as IP (inviolable) or GP (guiding) with stress tests against Phase-1 decisions, then writes them to DESIGN.md with stable numbering. - Migration ingestion: Preserved numbered-principles files (e.g. PRINCIPLES.md cited in code) are ingested as candidates with a recorded old-#N to new-id lineage map, without editing the preserved file. - Use Case: After scaffolding a repo with /cairn-init, run the interview to turn a thin DESIGN.md into a documented purpose, contract boundary, and numbered principle set that later milestone planning and reviews can enforce. ## Quick Start Ask the assistant to run a design interview to articulate this repo's purpose, contract boundary, and guiding principles in cairn/DESIGN.md.