tda-prototype-sandbox

Builds disposable prototypes for design questions while keeping them isolated from evidence-bearing result directories.

1|Updated Dec 13, 2025
One-click install
npx skills add https://github.com/ZK-Theory/TDL --skill tda-prototype-sandbox-zk-theory
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tda-prototype-sandbox
Source: https://github.com/ZK-Theory/TDL/tree/main/.agents/skills/tda-prototype-sandbox
Command: npx skills add https://github.com/ZK-Theory/TDL --skill tda-prototype-sandbox-zk-theory

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When exploring a design idea for a CLI, dashboard, visualization, or workflow, it is easy to accidentally contaminate canonical research outputs with unvalidated prototype artifacts. This Skill enforces a strict sandbox discipline so prototypes answer design questions without ever being mistaken for research evidence. ## Core Features & Use Cases - Disposable Prototyping: Sketch CLI designs, figure layouts, dashboards, and task-state machines in scratch or prototype directories. - Evidence Isolation: Enforces the rule that prototypes never write into canonical results trees and are never cited as paper claims. - Promotion Discipline: Defines what a prototype must go through (task brief, contract, tests, provenance) before becoming production code. - Use Case: You want to compare two result-browser layouts before committing to an implementation. Build both as marked exploratory prototypes under a scratch path, record what was learned, then route the winner through the formal task-brief and contract-first workflow. ## Quick Start Ask the agent to prototype a new dashboard layout idea in a disposable scratch directory and record what design question it answers.

Frequently Asked Questions about tda-prototype-sandbox

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prototype a CLI or dashboard design without affecting research results?

Write the prototype under a scratch or prototypes directory, mark every output as exploratory in the filename or header, and record the design question being tested. Never write prototype outputs into canonical results directories.

When should I use a disposable prototype instead of a formal implementation?

Use a prototype when testing a CLI design, figure layout, dashboard idea, or workflow pattern before committing to a brief. Do not use it for producing paper results, running inference for a claim, or modifying validated pipeline code.

Can a prototype output be saved to the results directory for later use?

No. Prototype outputs must never be written into canonical results trees, even with date-stamped filenames. If a prototype finding matters, re-derive it through the provenance-tracked pipeline instead.

How do I promote a successful prototype into production code?

Promotion requires routing through a formal task brief and contract-first test-driven development, adding tests and provenance tracking. Prototype modules must never be imported directly from pipeline code.

What are the limitations of prototype artifacts in a research workflow?

Prototypes are not evidence, not result artifacts, and not paper-citable. They cannot create canonical computations or contract-bearing implementations unless routed through the appropriate tier 1 or tier 2 skills first.