spec-charter

Create and amend the spec-axis files this skill owns: spec/charter.md (direction) and spec/system-map.md (system shape). This skill is rerunnable. It ships no helper scripts: inspect the target repo directly and keep every path target-repo-relative, so a run never analyzes its own installation directory by accident. The single Objectives-vs-Behaviors/Hard-Constraints ownership rule lives in references/spec-axis.md.

Execution contract

Mode router

Explicit mode words win. Next, intent: map when the request is about system shape, architecture, runtime boundaries, flows, invariants, or spec/system-map.md; reassess when it is a report-only staleness or spec-health check. Only then file state: create when neither spec/charter.md nor a legacy root CHARTER.md exists, otherwise amend, including the reset path when the user describes a concept change rather than an edit. Capability contracts, component boundaries, or spec/capabilities.md route to spec-grill.

Completion contract

Every run ends by naming the files created or changed, what was refused or parked (a refused harness pointer counts), and one next action in plain language — "create the system map", "ask spec-grill to review candidate boundaries" — never a memorized argument. Done looks like this:

• create: spec/charter.md exists at revision 1, the harness pointer was either in the same confirm or recorded as refused/parked, unresolved assumptions are listed, and a brownfield repo still missing spec/system-map.md has continued into map.
• amend: the accepted diff is applied, last_amended and revision are bumped, and the charter still reads in about five minutes.
• map: the map is evidence-backed with low-level detail demoted, charter and capability changes are routed out, and the run ends with Evidence Read and Evidence Missing.
• reassess: nothing was written, and the report ends with one recommended next action or "no change".