derive-tests

Étoiles13

Forks1

Mis à jour14 juillet 2026 à 09:29

Use only after the lock (gate 2b) is on record for the slice portion, to derive the fidelity ledger and acceptance scenarios from the locked prototype. Triggers when a portion is newly locked or re-locked. Never use before the lock, and never use it to hand-author prototype-fidelity test cases from prose.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

teklabsdigital

teklabsdigital/x2-method

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	derive-tests
description	Use only after the lock (gate 2b) is on record for the slice portion, to derive the fidelity ledger and acceptance scenarios from the locked prototype. Triggers when a portion is newly locked or re-locked. Never use before the lock, and never use it to hand-author prototype-fidelity test cases from prose.

X2 Derive Tests

Turn the locked portion into its tests. Nothing here is authored from imagination: the locked prototype is the acceptance contract, and the tests are projections of it.

What derives from the lock

The per-slice fidelity ledger (design/ledger/slice-NNN.md): the locked portion's visual atoms, enumerated. The kernel tests it in both directions: every ledger atom renders (exhaustiveness) and nothing renders beyond the ledger (de-fabrication). Until the prototype-to-ledger exporter exists (owed on the claim), the hand-derived ledger is a known second-source risk: derive it at lock time only, from the artifact on disk, never maintain it by hand alongside a moving prototype.
The acceptance scenarios on the e2e floor: the flows the locked portion shows, driven through the real client services against a running server.

The scoping of "no hand-authored test cases"

The ban is precise, per the record's wording fix:

Banned: authoring prototype-fidelity tests ahead of the lock. They derive from it.
Not banned: claim-driven tests: harness scenarios, gate tests, guard tests. These keep the write-it-first, watch-it-fail shape, and they did the most catching in the pilot.

Coverage expectations the exit report will check

Derivation should leave these satisfiable, because slice-exit reports them:

Every public method of every client data service has at least one harness scenario through the real transport, and when the product owns identity, the harness exercises the real sign-in path at least once; minting around auth is setup for other scenarios, never a substitute (INV-10, ruled: the gated harness profile makes this achievable).
A composed-app smoke exists per primary flow: the actual entrypoint, at least one real request (INV-07).
A service method with no surface in the locked portion is a sanctioned UI-unsurfaced state when it is e2e-covered and its boundary is documented (CONF-03). It is never resolved by inventing UI the prototype does not contain; the fidelity tests would fail that fabrication, and they should.

One discipline line

Prove a derived suite can fail: write one assertion wrong, watch it fail, fix it. A suite that cannot fail is not evidence.

Human-turn contract

No gate of its own. A gap between the locked portion and what is derivable is a record-gap question for the human, never an invented criterion.

What this skill must NOT produce

Nothing before the lock is on record.
No criteria the prototype does not show, no edits to the prototype or ledger direction, no implementation code.

implement.

Plus depuis ce dépôt

même dépôt

adopt

teklabsdigital/x2-method

Use when an existing project that was not built with X2 must be migrated to run under it, with documentation sprawl to dissolve, stories to harvest at epic altitude, an as-built design to baseline, and existing enforcement to map and arm. Runs the migration on a dedicated branch with three human gates. Do not use for a new project (that is seed), and do not use it to redesign the product or refactor code beyond what arming the enforcement requires.

2026-07-2813

decompose

teklabsdigital/x2-method

Use after the repo is seeded to run the D-000 five-lens decomposition, record persistent schema decisions, define slice one, and start the deltas file. Also use when a stays-ahead decision (decomposition, schema) must be revisited. Do not use for per-slice implementation decisions; those are D-0xx record-gaps raised during implement.

2026-07-2813

help

teklabsdigital/x2-method

Use when someone asks what an X2 skill does, which skill to run next, how the gates work, or where an artifact lives. A quick in-flight reference; for the method's rationale, read X2.md at the method repo root.

2026-07-2813

seed

teklabsdigital/x2-method

Use immediately after gate 1 (stories approved) to settle which kernel edition the project is built on, create the project repo from it, and make the method durable inside it. Also use when an existing X2 project is missing its CLAUDE.md standing constraints or its turn ledger. Do not use before stories are approved, and never use it to modify the kernel itself.

2026-07-2813

kernel

teklabsdigital/x2-method

Use to change the claims catalog (add, amend, retire a claim, cut a catalog pass), to manage editions (add, retire, recompose), to measure an edition's conformance honestly (plant, prove, audit, lower a row), to clear accumulated decisions with the owner, or to check that the whole kernel is still coherent. Also use when a claim or edition change may have left counts, scope or statements in the documentation stale. Do not use it to seed a project from an edition; that is seed's job.

2026-07-2813

extract

teklabsdigital/x2-method

Use when an X2 project completes (or reaches a major milestone) to run the extraction loop, the quality feedback that folds the project's evidence back into the method. Reads the turn ledger and decision records, computes the metric and the per-decision churn table, distils sanitized candidates, confirmations, and negative-space nominations, and holds everything for a rulings pass. Do not use mid-slice (that is the normal intake flow), and never let raw project material cross into the public method.

2026-07-2013

name	derive-tests
description	Use only after the lock (gate 2b) is on record for the slice portion, to derive the fidelity ledger and acceptance scenarios from the locked prototype. Triggers when a portion is newly locked or re-locked. Never use before the lock, and never use it to hand-author prototype-fidelity test cases from prose.

X2 Derive Tests

Turn the locked portion into its tests. Nothing here is authored from imagination: the locked prototype is the acceptance contract, and the tests are projections of it.

What derives from the lock

The per-slice fidelity ledger (design/ledger/slice-NNN.md): the locked portion's visual atoms, enumerated. The kernel tests it in both directions: every ledger atom renders (exhaustiveness) and nothing renders beyond the ledger (de-fabrication). Until the prototype-to-ledger exporter exists (owed on the claim), the hand-derived ledger is a known second-source risk: derive it at lock time only, from the artifact on disk, never maintain it by hand alongside a moving prototype.
The acceptance scenarios on the e2e floor: the flows the locked portion shows, driven through the real client services against a running server.

The scoping of "no hand-authored test cases"

The ban is precise, per the record's wording fix:

Banned: authoring prototype-fidelity tests ahead of the lock. They derive from it.
Not banned: claim-driven tests: harness scenarios, gate tests, guard tests. These keep the write-it-first, watch-it-fail shape, and they did the most catching in the pilot.

Coverage expectations the exit report will check

Derivation should leave these satisfiable, because slice-exit reports them:

Every public method of every client data service has at least one harness scenario through the real transport, and when the product owns identity, the harness exercises the real sign-in path at least once; minting around auth is setup for other scenarios, never a substitute (INV-10, ruled: the gated harness profile makes this achievable).
A composed-app smoke exists per primary flow: the actual entrypoint, at least one real request (INV-07).
A service method with no surface in the locked portion is a sanctioned UI-unsurfaced state when it is e2e-covered and its boundary is documented (CONF-03). It is never resolved by inventing UI the prototype does not contain; the fidelity tests would fail that fabrication, and they should.

One discipline line

Prove a derived suite can fail: write one assertion wrong, watch it fail, fix it. A suite that cannot fail is not evidence.

Human-turn contract

No gate of its own. A gap between the locked portion and what is derivable is a record-gap question for the human, never an invented criterion.

What this skill must NOT produce

Nothing before the lock is on record.
No criteria the prototype does not show, no edits to the prototype or ledger direction, no implementation code.

implement.

derive-tests

X2 Derive Tests

What derives from the lock

The scoping of "no hand-authored test cases"

Coverage expectations the exit report will check

One discipline line

Human-turn contract

What this skill must NOT produce

Next

X2 Derive Tests

What derives from the lock

The scoping of "no hand-authored test cases"

Coverage expectations the exit report will check

One discipline line

Human-turn contract

What this skill must NOT produce

Next