Menü
Write the contract sections of a cnos issue — problem, impact, status truth, source of truth, scope, non-goals, and closure condition.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
The 0th coherence methodology: how coherence methodologies themselves are measured — this one included. Declares what measuring a CM means per axis, the consistency protocol every CM must pass (an instrument that cannot agree with itself is incoherent as an instrument), the mechanical/LLM split for judging a CM's corpus, and the adversarial-CM doctrine: what follows, mathematically, when one methodology demonstrates that another scores lower. Frontmatter is validated by schemas/skill.cue (#CMOfCMs); the declared signal codes and estimate fields are cross-checked against the engine source and the scoring instruction, exactly as for the 1st methodology.
How TSC measures itself. Declares the full self-measurement procedure — the targets, the deterministic (mechanical) work, and the one narrowly scoped cognitive task delegated to an LLM — and is rendered into the `coh self` command and the tsc-self-measure workflow by scripts/render-self-measure.sh. Frontmatter is validated by schemas/skill.cue (#SelfMeasure); the declared signal codes and estimate fields are cross-checked against the engine source and the scoring instruction, so this declaration cannot silently drift from what runs.
Measurement skill declaring a signal code the engine does not compute (negative fixture for the signal-in-engine cross-check).
Measurement skill declaring an estimate field that appears in the instruction's prose but not in its JSON output contract (negative fixture for the estimate-in-contract exact-set check).
Bootstrap an existing repository to operate under CDD — scaffold, version pin, labels, identity, CI, notifications, secrets, and operator registry.
α role in CDD. Implements the selected change, produces the review-ready artifact set, and writes α close-out.
| name | issue/contract |
| description | Write the contract sections of a cnos issue — problem, impact, status truth, source of truth, scope, non-goals, and closure condition. |
| artifact_class | skill |
| kata_surface | embedded |
| governing_question | How does γ write the contract sections of an issue so α can act, β can verify, and γ can close without hidden context? |
| visibility | internal |
| parent | issue |
| triggers | ["issue contract","problem statement","status truth","scope","non-goals"] |
| scope | task-local |
| inputs | ["selected gap","affected surfaces","current implementation status"] |
| outputs | ["problem section (exists / expected / diverges)","impact section","status truth table","source-of-truth table","scope section (in scope / out of scope / deferred / blocked by)","non-goals section","skills to load section","active design constraints section","related artifacts section","implementation guidance section","success / closure condition"] |
A contract section names one truth. It does not argue, qualify, or gesture. Each section answers one question so precisely that α can implement without asking and β can verify without recovering hidden conversation context.
Failure mode: authority drift — docs, implementation, and issue body disagree about what exists, what is required, and what is excluded.
Contract sections:
Problem → Impact establishes why this work matters. Status truth → Source of truth establishes what is real now. Scope + Non-goals establish the execution boundary. Skills + Constraints establish the generation constraints for α. Closure establishes when β's merge and γ's close are justified.
Contract fails through authority drift: two sections disagree about whether something is in scope, or the implementation cites a different canonical source than the issue does.
## Problem
What exists:
What is expected:
Where they diverge:
Keep the problem 3–5 lines. Link to deeper evidence instead of reproducing design discussion.
The package system is inconsistent and needs cleanup.SKILL.md frontmatter has a CTB v0.1 schema in LANGUAGE-SPEC.md, but no CI gate validates the 54 package skill files. Missing fields can drift indefinitely.Answer:
Who or what is affected?
What breaks or drifts?
Why now?
What is blocked if this remains unresolved?
❌ This would be nice to have.
✅ Without this gate, CTB frontmatter conformance depends on reviewer memory. v0.2 promotion inherits unchecked v0.1 drift.
Distinguish shipped reality from expected or draft targets:
| Status | Meaning |
|---|---|
Shipped | Implemented and enforced today |
Current spec | Normative document currently governing conformance |
Draft target | Proposed or draft spec not yet promoted |
Planned | Accepted direction, not implemented |
Not in scope | Explicitly excluded |
Unknown | Not verified yet |
CTB v0.2 draft defines witnessed close-outs. The shipped runtime does not yet enforce them.## Source of truth
| Claim / surface | Canonical source | Status | Notes |
|---|---|---|---|
| CTB v0.1 frontmatter fields | docs/alpha/ctb/LANGUAGE-SPEC.md §2, §11 | current spec | governs current skill frontmatter |
Every load-bearing claim must link to a path, issue, or upstream document. No "the docs say" without a path.
## Scope
In scope:
- ...
Out of scope:
- ...
Deferred:
- ...
Blocked by:
- ...
Rules:
Name what must not appear in ACs or implementation work. Non-goals exist to close the scope leak failure mode.
Name Tier 3 skills only. Tier 1 and Tier 2 are mandatory and not repeated.
## Skills to load
Tier 3:
- cnos.core/skills/design
- eng/tool
Why:
- design: boundary decisions and source-of-truth clarity.
- tool: shell script standards.
Do not list skills as decoration. If a skill changes the issue shape, explain why.
State constraints in plain language.
Follow project conventions.Schema owns field shape/type/enum validation; shell script owns discovery and diagnostics. Do not duplicate schema rules in shell.Link exact paths. If a companion artifact is being drafted in parallel, say how conflicts are resolved.
Related: CTB docs.docs/alpha/ctb/LANGUAGE-SPEC.md §2.1Use for: branch name, git identity, file paths, resolution base, known migration debt.
Do not use to replace a plan when the work requires multi-step execution.
## Implementation guidance
Branch: cycle/324
Identity: alpha <alpha@cdd.cnos>
Notes: ...
State precisely when γ may close:
3.1. State what exists before what is expected. Every problem statement leads with current state, then target, then divergence.
3.2. Status must be explicit. Never describe draft behavior as shipped or planned enforcement as current.
3.3. Source of truth is a path, not a claim. Every load-bearing fact must link to a file or issue.
3.4. Non-goals must not appear in ACs. If a non-goal noun appears in an AC, fix the issue.
3.5. Contradiction resolution is the author's job. When two sections contradict, resolve before filing. α does not choose silently between contradictory interpretations.
You are filing an issue to add a CI gate that validates SKILL.md frontmatter against a CUE schema. The shipped runtime has no frontmatter validation. A draft CTB v0.2 spec proposes a witnessed close-out field.
Write the contract sections:
Shipped, Current spec, and Draft target.