@c4a/context-cli 0.5.29-beta.17 → 0.5.29-beta.18

package/plugin/skills/skill-compile-judge/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: skill-compile-judge
+description: >
+  Packaged skill invoked by `/context:compile`; not a user slash command. Consumes the full compile prepare payload,
+  judges each draft action's source support and relation to listed candidates,
+  and emits a compile.judge-decisions.v1 document for `context reconcile review`.
+tools:
+  - Bash
+---
+
+# skill-compile-judge — judge compile support and relation
+
+Decide whether each prepared compile item is supported by cited raw evidence
+and how it relates to the candidate Sections listed by the CLI. Emit judge
+decisions only; the CLI reviews, applies, and writes every workspace change.
+
+## TL;DR — Non-negotiables
+
+- Input is the full compile prepare payload. Compact summaries are only a pointer; if needed, load the full payload with the `workflow_payload.show_command` from `context compile --draft ... --prepare`.
+- Do not inspect workspace storage directly or run ad-hoc scripts to reconstruct candidates. Use only `items[]`, `evidence[]`, `source_support` diagnostics, `candidates[]`, `previous_decisions[]`, and `judge_handoff`.
+- Output exactly one JSON or YAML document with `schema_version: "compile.judge-decisions.v1"` and `decisions[]`.
+- Keep one decision per prepared `item_id`, preserving prepare order.
+- For support, output `support_verdict: supported | weak | unsupported` plus `support_reason`.
+- For relation, output `relation_verdict: new | duplicate | supersede | conflict | merge_into` plus `relation_reason`.
+- Compare only the candidates listed on that item. Do not perform workspace-wide BM25, grep, or source-file searches.
+- Fill `compared_section_ids` with every visible candidate Section id you inspected and set `compared_count` to the total candidate count inspected across pages. If candidates are paged, continue until `compared_count >= candidate_total` before final output.
+- Escape hatch: when an item has no candidates, `relation_verdict: new` with `compared_section_ids: []` and `compared_count: 0` is valid and expected.
+- For `duplicate`, `supersede`, `conflict`, or `merge_into`, set `target_section_id` to the matched candidate Section id.
+- Same `source_ref` can support different Section kinds only when the semantic role differs. Detect and explain same-source-ref multi-kind cases instead of treating them as automatic duplicates.
+- Weak support is a warning-level verdict, not permission to invent missing facts. Unsupported support should normally pair with `conflict` or a later user question rather than a write decision.
+
+<reference>
+
+## Output Shape
+
+```yaml
+schema_version: "compile.judge-decisions.v1"
+mode: compile
+decisions:
+  - item_id: claim-001
+    support_verdict: supported
+    support_reason: "The cited raw block explicitly states the same invoice handling behavior."
+    relation_verdict: new
+    relation_reason: "No listed candidate covers this claim."
+    compared_section_ids: []
+    compared_count: 0
+```
+
+For a relation against an existing candidate:
+
+```yaml
+schema_version: "compile.judge-decisions.v1"
+mode: compile
+decisions:
+  - item_id: claim-002
+    support_verdict: supported
+    support_reason: "The cited evidence covers the correction."
+    relation_verdict: supersede
+    relation_reason: "section-3 states the older behavior and should be replaced."
+    target_section_id: section-3
+    compared_section_ids: [section-3, section-7]
+    compared_count: 2
+```
+
+## Verdict Meanings
+
+| field | value | Meaning |
+|---|---|---|
+| `support_verdict` | `supported` | Cited raw evidence covers the claim's hard facts. |
+| `support_verdict` | `weak` | The evidence plausibly supports an ordinary summary, but review may ask for confirmation. |
+| `support_verdict` | `unsupported` | The claim adds facts or boundaries not present in cited raw evidence. |
+| `relation_verdict` | `new` | No listed candidate already covers the proposed knowledge. |
+| `relation_verdict` | `duplicate` | A listed candidate already covers the same claim. |
+| `relation_verdict` | `supersede` | A listed candidate is stale or wrong and should be replaced by the new claim. |
+| `relation_verdict` | `conflict` | The prepared claim and candidate disagree and need user resolution. |
+| `relation_verdict` | `merge_into` | The prepared claim should update or refine one listed candidate. |
+
+</reference>
+
+<procedures>
+
+### Step 1 — Load Full Prepare Payload
+
+If the caller gave compact prepare output, use its workflow payload command to
+load the full `prepare` payload. Do not infer missing candidates from memory.
+
+### Step 2 — Judge Support
+
+For each item, read the proposed content and cited evidence. Use
+`source_support` only as a diagnostic hint; final support is your semantic
+verdict from the cited raw evidence.
+
+### Step 3 — Judge Relation
+
+Compare the proposed claim against each listed candidate. Track every
+visible candidate Section id in `compared_section_ids`, and set
+`compared_count` to the total candidate count inspected across pages. If the
+candidate list is empty, emit `new` with an empty compared list and
+`compared_count: 0`.
+
+### Step 4 — Emit Judge Decisions
+
+Return only the `compile.judge-decisions.v1` document. The caller passes it
+directly to `context reconcile review --prepare-digest <digest> --decisions -`.
+
+</procedures>

package/plugin/skills/skill-semantic-reconcile/SKILL.md

@@ -65,7 +65,7 @@ decisions:
     proposed:
       content: "Runtime isolation uses sandboxing to avoid state pollution."
       confidence: confirmed
-      source_ref: "src-2#runtime L12-14@ab12cd34ef56"
+      source_ref: "src-2#runtime L12-14@7a6f4c9d2e10"
     rationale: "The new evidence clarifies the same claim."
 ```
 
@@ -166,7 +166,7 @@ decisions:
     proposed:
       kind: example
       content: "The host app maps remote modules through the runtime config."
-      source_ref: "src-1#example L32-40@ab12cd34ef56"
+      source_ref: "src-1#example L32-40@7a6f4c9d2e10"
 ```
 
 Final executable decisions must not carry `user_confirmation.required: true`.