Skills, prompts and deliverables

Three reusable things

A pipeline stage is assembled from three reusable entities, each stored and edited independently of the pipeline itself:

Prompts

A prompt is a first-class record — a title and a body — stored in ~/.tde/prompts.db. A pipeline stage can reference one by id instead of carrying inline text, in which case the prompt's body becomes the source of truth and the pipeline stores only the reference.

That indirection is the point: one prompt can back the same stage across several pipelines, and editing it once changes every stage that points at it. The Prompts panel shows a Used by: line naming those pipelines, or — not used by any pipeline.

On every boot TDE seeds a prompt per stage that does not already reference one, idempotently and without overwriting an existing title. Default-pipeline stages get bare names (Context, Build, Review, …); preset pipelines get <Pipeline name> · <Stage name>, for example GStack · Product Plan · Review.

Skills

A skill is a versioned playbook written as a SKILL.md file — YAML frontmatter followed by markdown instructions. TDE's copy is the source of truth, kept at ~/.tde/skills/<name>/SKILL.md; a small SQLite index next to it stores only which agents each skill is enabled for.

---
name: tde-graph
description: Explore a Rust codebase structurally with tde graph — who calls a
function, what breaks if it changes, and which tests to run.
tags: [rust, refactor, tests]
source: scratch
---

## When to use this
…

name and description are required — a file missing either is rejected as bad frontmatter. tags accepts either a bracketed list or a bare comma list. source records where the skill came from: scratch, url:<u> or repo:<r>.

Synced to all four CLIs

The reason skills exist as a TDE concept at all: each agent CLI has its own, incompatible convention for extension instructions. TDE writes one skill into all four:

Managed blocks are delimited by <!-- TDE SKILLS START --> and <!-- TDE SKILLS END -->, and splicing preserves whatever prose you wrote around them. Disabling a skill strips the block only. In the Claude directory, TDE removes only directories carrying its own .tde-managed marker — skills you installed yourself are never touched.

Enablement is a matrix: each skill is independently on or off per agent. The skill form renders Enabled for: with one toggle per agent, and a card's meta line reads Used by: 3 agents · Source: repo.

Getting skills

• + New — author one in place.
• + Import — paste a SKILL.md and TDE parses the frontmatter.
• Store — installing a skill from the Store picks the shallowest SKILL.md in the repository, writes its support files alongside, refuses to overwrite a differently-sourced local skill of the same name, and then enables and syncs it for all four agents.
• Auto-Skills — stack-detected suggestions from the bundled registry.

Shipped skills

These are bundled and provisioned automatically. They are the agent-facing documentation for TDE's own surfaces — an agent that has them does not need to guess how to drive a TDE app:

Deliverables

A deliverable spec turns a stage's output from prose into a validated structure. Attach one to a stage and two things happen: the agent's prompt gains a deliverable protocol, and its answer is parsed and checked before the task may advance.

The protocol asks the agent to end its response with a YAML block introduced by a DELIVERABLE: line, listing every field with its type and whether it is required, and states plainly: do not emit NEXT: advance until the block satisfies all required fields. The YAML may be plain or wrapped in a fenced yaml/yml code block; the fence is presentation, not part of the payload.

A spec declares fields of type string, text, string_list, checklist, enum, bool or ref_list; where the result is persisted (board, repo or both, with a path template supporting {task_id}, {title_slug} and {board_key}); and whether validation blocks advancement.

The thirteen built-in specs

RFC, ADR, PRD and Research Brief persist to the repository as well as the board — docs/rfc/<task>-<slug>.yaml, docs/adr/…, docs/prd/…, docs/research/<task>-research.md — so the artifact lives with the code, not only in TDE.

Built-in specs cannot be deleted, and creating a spec with a builtin: id rewrites it to a custom: one. Specs can be exported and imported as YAML. Validated payloads are stored on the task, keyed by stage id, and become PRIOR STAGE DELIVERABLES: in every later stage's context — which is how a PRD written in one stage reaches the implementation stage intact.