source-of-truth-preflight

$npx mdskill add Kastalien-Research/thoughtbox/source-of-truth-preflight

Prevents duplicate abstractions by finding canonical domain models before coding.

  • Solves the problem of building features on the wrong source of truth.
  • Depends on ripgrep (rg) to search for existing domain types and schemas.
  • Identifies canonical models by inventorying existing types and enforcement points.
  • Delivers a preflight report that gates implementation until the source of truth is clear.

SKILL.md

.github/skills/source-of-truth-preflightView on GitHub ↗
---
name: source-of-truth-preflight
description: >
  Use this skill before implementing features, lifecycle changes, runtime
  boundaries, persistence contracts, or architectural work where the codebase
  may already contain canonical domain models. It prevents duplicate
  abstractions, illegal representable states, and plans built on the wrong
  source of truth.
---

# Source Of Truth Preflight

Run this skill before editing code for non-trivial feature work, especially
when the task touches domain models, state machines, runtime providers,
repository contracts, schema migrations, or existing subsystem boundaries.

This is a short gate, not a design ceremony. Produce the report before coding.
If the report cannot identify the canonical model or enforcement points, pause
instead of implementing.

## Trigger Conditions

Use this skill when any of these are true:

- adding or changing lifecycle states
- compiling, parsing, importing, exporting, or graduating a domain object
- adding a repository method, migration, runtime provider, broker, or handler
- introducing a new type whose name overlaps an existing concept
- seeing two or more files define similar domain terms
- after two surprises during a task

## Preflight Steps

### 1. Identify The Unit

State the requested unit in one sentence. Name explicit non-goals.

### 2. Inventory Existing Models

Search before designing. Prefer `rg`:

```bash
rg -n "export (interface|type|class|const) .*<Concept>|<Concept>Schema|type <Concept>|interface <Concept>" src apps .specs .adr docs
rg -n "from ['\"].*<concept>.*['\"]|<Concept>" src apps
```

Record:

- canonical model candidates with file references
- legacy or competing models with file references
- runtime/schema/repository boundaries that already enforce the concept

### 3. Choose The Canonical Source Of Truth

Name the model the implementation will build on. If there are multiple live
models, classify each as one of:

- `canonical`: new work should build here
- `legacy-live`: still used, but not the right extension point
- `adapter-only`: used only to translate between systems
- `control-plane`: metadata/registry state, not the domain object itself
- `test-fixture`: fixture-only, not production semantics

If the choice is not obvious, pause and ask for a decision.

### 4. Illegal-State Pass

List the states that should be impossible. Check whether current types make
them impossible.

Look for:

- flat records with `status` plus many nullable fields
- generic `string` identifiers for different ID classes
- optional fields that are required for only some statuses
- generic `save*` methods that bypass lifecycle transitions
- casts from storage rows into domain records without parsing
- public tool input objects with many optional fields instead of a
  discriminated union

For each illegal state, decide whether to:

- make it impossible in TypeScript,
- reject it at a parser/boundary,
- enforce it in the database/transaction, or
- explicitly defer it with named risk.

### 5. Acceptance-To-Enforcement Map

For each acceptance criterion, name the enforcing artifact:

- type or schema
- parser or compiler
- repository command
- transaction/RPC/migration constraint
- broker/runtime guard
- test

If an acceptance item maps only to prose or a broad test, mark it as weak.

### 6. Reuse Challenge

Before adding a new service/type/schema, answer:

```text
Why does the existing model/engine/repository not own this?
```

Proceed only when the answer is concrete. Good answers include:

- the existing model is legacy-live and this is an adapter
- the new type is a control-plane read model, not a duplicate domain object
- the existing model lacks a boundary parser and this change adds one

Weak answers include:

- it was faster to write a new shape
- the prompt used different names
- tests can catch it later

### 7. Surprise Gate

After two unexpected findings, stop and write:

- what surprised us
- what assumption failed
- whether the current plan is still valid
- the next bounded action

Do not debug process/tooling or migrate workflow systems inside the feature
session unless that is the explicit unit of work.

## Required Report

Produce this before code edits:

```text
Source Of Truth Preflight

Unit:
Non-goals:

Canonical model:
Legacy/competing models:
Control-plane models:
Adapters needed:

Illegal states currently representable:
Acceptance-to-enforcement map:
New types/services proposed:
Reuse decision:

Surprises:
Proceed / pause:
```

Use file references for every model claim.

More from Kastalien-Research/thoughtbox

SkillDescription
assumptionsManage the assumption registry — track, verify, and query assumptions about external dependencies and system behavior. Prevents costly rediscovery of known failures.
capture-learningCapture significant learnings from the current work session. Structures insights for future sessions and updates agent memory.
claude-opus-4-6-prompting>
claude-promptWrite or improve prompts for Claude using Anthropic's official best practices. Creates system prompts, agent prompts, tool descriptions, and MCP resource templates. Pass an existing prompt to improve it, or describe what you need to create one from scratch.
coolify-composeConvert Docker Compose files to Coolify templates. Use when creating Coolify services, converting docker-compose.yml for Coolify deployment, working with SERVICE_URL/SERVICE_PASSWORD magic variables, or troubleshooting Coolify compose errors.
crafting-effective-readmesUse when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
diagramGenerate architecture diagrams for a codebase subsystem or module. Explores source files and produces Mermaid diagrams in docs/.
diataxisStructure, classify, and write documentation using the Diátaxis framework. Use when writing docs, README files, guides, tutorials, how-to guides, API references, or organizing documentation architecture. Also use when asked to improve documentation, restructure docs, decide what type of doc to write, or classify existing content. Covers tutorials, how-to guides, reference, and explanation.
escalateFormat a structured escalation to the human decision-maker (Chief Agentic). Use when hitting an escalation threshold.
frontend-design-principlesCreate polished, intentional frontend interfaces. Use this skill when building any UI — dashboards, admin panels, landing pages, marketing sites, or web applications. Routes to specialized guidance based on context.