Repair missing managed skill-reference mirrors (clue 0.24.1 carrier drift)

clue migrate's preview (MIG-003) found five generated skill reference
files missing from .claude/skills/ even though the repo is already on
the newest release (0.24.1) and their .agents/ counterparts exist:
clue-delta/references/intent-model.md, clue-extract/references/
intent-discovery.md and intent-model.md, clue-plan/references/
intent-discovery.md and intent-model.md.

Materialized non-destructively with `clue init .` (100 other files
already present were left untouched). clue init also bootstrapped
docs/vision.md; removed it again since MIG-014 confirms this corpus
deliberately states no vision, and clue validate itself says to delete
a bootstrap vision when the repository isn't stating one.

clue validate passes clean (65 artifacts, no issues).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A6pPpd8gWaqE3w1PWYr4qn

Author: flemming-n-larsen

.claude/skills/clue-delta/references/intent-model.md

@@ -0,0 +1,41 @@
+## Intent model
+
+A corpus carries two threads, and they meet only at the goal.
+
+The **intent thread** says what the product means: `VIS-001` (the vision, at `docs/vision.md`) → goal → optional use case → capability → acceptance criterion → evidence. The **delivery thread** says how that meaning gets built: goal → plan → milestone → change → accepted merge commit. Plan, milestone, and change never join the semantic hierarchy, which is what keeps a change from editing the vision merely because it edited code.
+
+Each artifact answers one question, and none of them answers another's. A **goal** says who wants something and why. A **use case** says what one actor does, end to end, across capabilities. A **capability** says what the system can do. An **acceptance criterion** says what would prove it. A vision that lists goals, a use case that restates criteria, or a capability that argues for its own existence has taken over a neighbour's job — link instead of repeating.
+
+**Both intent artifacts are optional to have.** `clue validate` never requires a vision or a use case, never reports one missing as an issue, and computes no coverage figure over either; absence is not a gap. Run `clue validate --intent` to see what a corpus states.
+
+**Links point down.** A use case names the goal it serves and every capability it crosses; a goal names the vision. A capability never names a use case back, so no edge is written twice and none can drift. Reading it the other way is `clue context <id>`, which names the use cases reaching an artifact by identity and title without following them.
+
+### The vision
+
+One per corpus, roughly one screen, at `docs/vision.md`. It answers what the product or system is, whom it serves, what problem it addresses and what value it intends to create, what is in scope and what is deliberately out, what principles constrain its direction, how success would be recognized, and which assumptions are still uncertain. It is not a roadmap, a backlog, an architecture document, a requirements list, or a marketing statement, and it needs no business case.
+
+Edit it only when the direction itself changes. Restating a new feature there is how a vision becomes a changelog and stops being read.
+
+### When a use case is worth creating
+
+Write one when it changes what a reader understands:
+
+- an actor's journey crosses several capabilities;
+- ordering, interaction, alternatives, or failure recovery carries meaning;
+- the individual criteria are each locally correct and still do not explain the outcome;
+- several actors collaborate through the system;
+- a brownfield system holds important behaviour no single capability explains.
+
+Do not write one when a capability and its criteria already describe the behaviour clearly, when there is no meaningful actor interaction, when it would restate an existing goal or capability, or when the subject is internal implementation behaviour that design, architecture, a constraint, or an IDR owns. Never create one for trivial create-read-update-delete behaviour to satisfy a process, and never let one grow into a design or prescribe interface details that are not themselves accepted intent.
+
+Recommend for or against one, say why, and let the human decide. A use case is created because it earns its place, never because a capability lacks one.
+
+### Its shape
+
+`docs/use-cases/UC-<number>-<slug>.md`, `type: use-case`, links naming the goal and the capabilities it crosses, and four sections: `## Actors`, `## Trigger`, `## Main flow`, `## Outcome`. Add preconditions, alternative and failure flows, and open questions when they carry meaning; leave them out when they do not.
+
+### Marking what is not yet confirmed
+
+Agent-drafted intent is `status: draft` with `provenance: inferred` and a stated `reversal-cost`, and its assumptions and open questions stay visible in the artifact. Promotion is a human act. Never present an inference as a fact, and never resolve a contradiction between sources by picking the convenient reading — record it and ask.
+
+**A full change's acceptance brief states the vision it proceeds under**, or states that the repository has none and that the change proceeds without one. When unresolved meaning would materially change what the system is for, stop and ask rather than deciding it inside an implementation.

.claude/skills/clue-extract/references/intent-discovery.md

@@ -0,0 +1,25 @@
+## Intent discovery
+
+Use when a repository has no usable vision. `clue` reports whether one exists and what its provenance is; it never interviews and never infers. Interpretation is yours, and accepting meaning is the human's.
+
+### Greenfield: interview, then summarize
+
+A user may start from one informal sentence — "I want to build a service that helps local running clubs organize weekly runs" — and that is enough to begin.
+
+Ask only questions whose answers would change the vision, the initial goals, the system boundary, or a candidate use case. Ask a few at a time and let each round follow from the last; a fixed questionnaire asked in one block is not this. Do not make the user learn Cliewen's vocabulary to answer — ask about their product, and do the translation yourself. Do not demand complete requirements before anything useful can start.
+
+Across the rounds, find out who the actors are, what outcome each wants, what is inside the boundary and what is deliberately outside it, what would count as succeeding, what constrains the direction, what is being assumed, and which end-to-end interactions matter enough to be use cases. Stop as soon as another question would not change what you would write.
+
+Then summarize what you understood in plain language and ask the user to correct or confirm it. Only after that does any of it become accepted intent. Write the vision, the initial goals, and the use cases you recommend — with your reason for each, and for any you considered and are not recommending.
+
+If the user explicitly asks you to draft from what little they have said, do it. What changes is how much you write, never how honestly you label it: the vision stays `draft` with `provenance: inferred`, every uncertainty appears as a stated assumption or an open question, and nothing you guessed is presented as something they told you.
+
+### Brownfield: read first, then ask what the repository cannot answer
+
+Inspect the repository before asking anything. The README and other documentation, architecture and design material, any existing Cliewen corpus, source and public APIs, tests and acceptance scenarios, command-line help and user interfaces, configuration, package metadata, deployment definitions, existing ADRs, PDRs, and IDRs, the change history available inside the repository, and examples and integration tests.
+
+Then produce a concise draft that cites the repository sources behind each material claim, keeps what you observed separate from what you concluded, and names the contradictions, stale documents, and gaps you found rather than smoothing them over. Ask only what the repository genuinely cannot answer.
+
+**Code demonstrates what a system does; it cannot establish why the product exists or what anyone wants.** Never derive strategic intent from implementation structure. Where sources disagree and the disagreement affects durable meaning, record the conflict and ask for a decision instead of choosing the convenient reading. A partially documented repository is the normal case, and missing documentation is a reason to mark uncertainty, never a reason to invent certainty.
+
+Present the proposed vision and any candidate use cases for correction or acceptance. Recommend a use case only where the existing capabilities genuinely fail to explain an outcome; a brownfield system's behaviour is mostly ordinary, and most of it needs no journey written down.

.claude/skills/clue-extract/references/intent-model.md

@@ -0,0 +1,41 @@
+## Intent model
+
+A corpus carries two threads, and they meet only at the goal.
+
+The **intent thread** says what the product means: `VIS-001` (the vision, at `docs/vision.md`) → goal → optional use case → capability → acceptance criterion → evidence. The **delivery thread** says how that meaning gets built: goal → plan → milestone → change → accepted merge commit. Plan, milestone, and change never join the semantic hierarchy, which is what keeps a change from editing the vision merely because it edited code.
+
+Each artifact answers one question, and none of them answers another's. A **goal** says who wants something and why. A **use case** says what one actor does, end to end, across capabilities. A **capability** says what the system can do. An **acceptance criterion** says what would prove it. A vision that lists goals, a use case that restates criteria, or a capability that argues for its own existence has taken over a neighbour's job — link instead of repeating.
+
+**Both intent artifacts are optional to have.** `clue validate` never requires a vision or a use case, never reports one missing as an issue, and computes no coverage figure over either; absence is not a gap. Run `clue validate --intent` to see what a corpus states.
+
+**Links point down.** A use case names the goal it serves and every capability it crosses; a goal names the vision. A capability never names a use case back, so no edge is written twice and none can drift. Reading it the other way is `clue context <id>`, which names the use cases reaching an artifact by identity and title without following them.
+
+### The vision
+
+One per corpus, roughly one screen, at `docs/vision.md`. It answers what the product or system is, whom it serves, what problem it addresses and what value it intends to create, what is in scope and what is deliberately out, what principles constrain its direction, how success would be recognized, and which assumptions are still uncertain. It is not a roadmap, a backlog, an architecture document, a requirements list, or a marketing statement, and it needs no business case.
+
+Edit it only when the direction itself changes. Restating a new feature there is how a vision becomes a changelog and stops being read.
+
+### When a use case is worth creating
+
+Write one when it changes what a reader understands:
+
+- an actor's journey crosses several capabilities;
+- ordering, interaction, alternatives, or failure recovery carries meaning;
+- the individual criteria are each locally correct and still do not explain the outcome;
+- several actors collaborate through the system;
+- a brownfield system holds important behaviour no single capability explains.
+
+Do not write one when a capability and its criteria already describe the behaviour clearly, when there is no meaningful actor interaction, when it would restate an existing goal or capability, or when the subject is internal implementation behaviour that design, architecture, a constraint, or an IDR owns. Never create one for trivial create-read-update-delete behaviour to satisfy a process, and never let one grow into a design or prescribe interface details that are not themselves accepted intent.
+
+Recommend for or against one, say why, and let the human decide. A use case is created because it earns its place, never because a capability lacks one.
+
+### Its shape
+
+`docs/use-cases/UC-<number>-<slug>.md`, `type: use-case`, links naming the goal and the capabilities it crosses, and four sections: `## Actors`, `## Trigger`, `## Main flow`, `## Outcome`. Add preconditions, alternative and failure flows, and open questions when they carry meaning; leave them out when they do not.
+
+### Marking what is not yet confirmed
+
+Agent-drafted intent is `status: draft` with `provenance: inferred` and a stated `reversal-cost`, and its assumptions and open questions stay visible in the artifact. Promotion is a human act. Never present an inference as a fact, and never resolve a contradiction between sources by picking the convenient reading — record it and ask.
+
+**A full change's acceptance brief states the vision it proceeds under**, or states that the repository has none and that the change proceeds without one. When unresolved meaning would materially change what the system is for, stop and ask rather than deciding it inside an implementation.

.claude/skills/clue-plan/references/intent-discovery.md

@@ -0,0 +1,25 @@
+## Intent discovery
+
+Use when a repository has no usable vision. `clue` reports whether one exists and what its provenance is; it never interviews and never infers. Interpretation is yours, and accepting meaning is the human's.
+
+### Greenfield: interview, then summarize
+
+A user may start from one informal sentence — "I want to build a service that helps local running clubs organize weekly runs" — and that is enough to begin.
+
+Ask only questions whose answers would change the vision, the initial goals, the system boundary, or a candidate use case. Ask a few at a time and let each round follow from the last; a fixed questionnaire asked in one block is not this. Do not make the user learn Cliewen's vocabulary to answer — ask about their product, and do the translation yourself. Do not demand complete requirements before anything useful can start.
+
+Across the rounds, find out who the actors are, what outcome each wants, what is inside the boundary and what is deliberately outside it, what would count as succeeding, what constrains the direction, what is being assumed, and which end-to-end interactions matter enough to be use cases. Stop as soon as another question would not change what you would write.
+
+Then summarize what you understood in plain language and ask the user to correct or confirm it. Only after that does any of it become accepted intent. Write the vision, the initial goals, and the use cases you recommend — with your reason for each, and for any you considered and are not recommending.
+
+If the user explicitly asks you to draft from what little they have said, do it. What changes is how much you write, never how honestly you label it: the vision stays `draft` with `provenance: inferred`, every uncertainty appears as a stated assumption or an open question, and nothing you guessed is presented as something they told you.
+
+### Brownfield: read first, then ask what the repository cannot answer
+
+Inspect the repository before asking anything. The README and other documentation, architecture and design material, any existing Cliewen corpus, source and public APIs, tests and acceptance scenarios, command-line help and user interfaces, configuration, package metadata, deployment definitions, existing ADRs, PDRs, and IDRs, the change history available inside the repository, and examples and integration tests.
+
+Then produce a concise draft that cites the repository sources behind each material claim, keeps what you observed separate from what you concluded, and names the contradictions, stale documents, and gaps you found rather than smoothing them over. Ask only what the repository genuinely cannot answer.
+
+**Code demonstrates what a system does; it cannot establish why the product exists or what anyone wants.** Never derive strategic intent from implementation structure. Where sources disagree and the disagreement affects durable meaning, record the conflict and ask for a decision instead of choosing the convenient reading. A partially documented repository is the normal case, and missing documentation is a reason to mark uncertainty, never a reason to invent certainty.
+
+Present the proposed vision and any candidate use cases for correction or acceptance. Recommend a use case only where the existing capabilities genuinely fail to explain an outcome; a brownfield system's behaviour is mostly ordinary, and most of it needs no journey written down.

.claude/skills/clue-plan/references/intent-model.md

@@ -0,0 +1,41 @@
+## Intent model
+
+A corpus carries two threads, and they meet only at the goal.
+
+The **intent thread** says what the product means: `VIS-001` (the vision, at `docs/vision.md`) → goal → optional use case → capability → acceptance criterion → evidence. The **delivery thread** says how that meaning gets built: goal → plan → milestone → change → accepted merge commit. Plan, milestone, and change never join the semantic hierarchy, which is what keeps a change from editing the vision merely because it edited code.
+
+Each artifact answers one question, and none of them answers another's. A **goal** says who wants something and why. A **use case** says what one actor does, end to end, across capabilities. A **capability** says what the system can do. An **acceptance criterion** says what would prove it. A vision that lists goals, a use case that restates criteria, or a capability that argues for its own existence has taken over a neighbour's job — link instead of repeating.
+
+**Both intent artifacts are optional to have.** `clue validate` never requires a vision or a use case, never reports one missing as an issue, and computes no coverage figure over either; absence is not a gap. Run `clue validate --intent` to see what a corpus states.
+
+**Links point down.** A use case names the goal it serves and every capability it crosses; a goal names the vision. A capability never names a use case back, so no edge is written twice and none can drift. Reading it the other way is `clue context <id>`, which names the use cases reaching an artifact by identity and title without following them.
+
+### The vision
+
+One per corpus, roughly one screen, at `docs/vision.md`. It answers what the product or system is, whom it serves, what problem it addresses and what value it intends to create, what is in scope and what is deliberately out, what principles constrain its direction, how success would be recognized, and which assumptions are still uncertain. It is not a roadmap, a backlog, an architecture document, a requirements list, or a marketing statement, and it needs no business case.
+
+Edit it only when the direction itself changes. Restating a new feature there is how a vision becomes a changelog and stops being read.
+
+### When a use case is worth creating
+
+Write one when it changes what a reader understands:
+
+- an actor's journey crosses several capabilities;
+- ordering, interaction, alternatives, or failure recovery carries meaning;
+- the individual criteria are each locally correct and still do not explain the outcome;
+- several actors collaborate through the system;
+- a brownfield system holds important behaviour no single capability explains.
+
+Do not write one when a capability and its criteria already describe the behaviour clearly, when there is no meaningful actor interaction, when it would restate an existing goal or capability, or when the subject is internal implementation behaviour that design, architecture, a constraint, or an IDR owns. Never create one for trivial create-read-update-delete behaviour to satisfy a process, and never let one grow into a design or prescribe interface details that are not themselves accepted intent.
+
+Recommend for or against one, say why, and let the human decide. A use case is created because it earns its place, never because a capability lacks one.
+
+### Its shape
+
+`docs/use-cases/UC-<number>-<slug>.md`, `type: use-case`, links naming the goal and the capabilities it crosses, and four sections: `## Actors`, `## Trigger`, `## Main flow`, `## Outcome`. Add preconditions, alternative and failure flows, and open questions when they carry meaning; leave them out when they do not.
+
+### Marking what is not yet confirmed
+
+Agent-drafted intent is `status: draft` with `provenance: inferred` and a stated `reversal-cost`, and its assumptions and open questions stay visible in the artifact. Promotion is a human act. Never present an inference as a fact, and never resolve a contradiction between sources by picking the convenient reading — record it and ask.
+
+**A full change's acceptance brief states the vision it proceeds under**, or states that the repository has none and that the change proceeds without one. When unresolved meaning would materially change what the system is for, stop and ask rather than deciding it inside an implementation.