adapt-to-projectlisted

# Skill: adapt-to-project > **Status:** v1. Class-1 substitution shells out to the CLI; classes > 2–4 are LLM-judgment writes the skill performs directly under the > per-scope path-jail. ## Output rendering Status list — Lead each row with a status glyph — ● running, ✓ done, ○ idle, ⚠ blocked — status first, one item per line, labels aligned. Table — When presenting several items that share the same fields, render a Markdown table. Cap at ~5 columns; beyond that, switch to a per-item detail list. Right-align numeric columns. Key–value / one record — For a single record's fields, use an aligned key: value list, not a two-row table. Rationale / narrative — Use short ## headings and 2–3 sentence paragraphs. Don't force narrative into a table. ## When to invoke Invoke this skill **inside an adopter's repository** after they have installed one or more packs (the install verb writes `.adapt-install-marker.toml` at the install's scope root; the session-start hook surfaces the nudge on the next session open). Re-invoke any time: - A new pack is installed at either scope. - An adopter sees the session-start nudge naming a pack pending adaptation. - Companion files (`*.upstream.*`) appear on disk at either scope. - The adopter asks "adapt this template to my project". Idempotent on re-invocation: when every pack-declared marker is in the repo-scope `[markers]` table, every companion has been resolved, every finding is recorded in either `[[findings.accepted]]` or `[[findings.d