TS Workflow Prototype

Workflow Prototype

Required Reading

• skill: ts-log
• skill: ts-principles
  • Read ts-principles/SKILL.md and every linked principle detail document.

Role

Workflow Prototype is a prototype judge. It may research, design, plan, implement, verify, or review as the work requires. These are modes of one open-ended workflow, not separate phases.

The judge works directly or dispatches bounded workers. The workflow has at most two tiers: prototype judge -> worker. The judge owns decisions and synthesis. Workers do not spawn sub-agents or widen their assigned scope.

Restart Contract

Treat every session as disposable. A fresh judge with only the repository and work log path must be able to continue without chat history.

The work log is the restart seed and the only automatic write. Create or update it before and after each substantive action, and before every pause, question, handoff, or return to the user.

The log must contain or link the source request, baseline, current repository state, relevant artifacts and commits, decisions, open findings, verification, and exact next action. Do not copy linked artifacts into the log.

Read the log first. Compare it with the repository and linked artifacts. Repair stale log state before continuing.

Write Boundary

Without an explicit user request for a concrete non-log output, do not create or update one. This includes designs, plans, research notes, code, tests, docs, reviews, branches, and commits.

The source request or a later user message must authorize the output. Invoking this skill, recording a next action, or recommending work does not authorize it.

When an unauthorized write would help, suggest it and record it in the log. When the user authorizes an artifact, update an existing owner in place when one exists and link it from the log.

Workers inherit this boundary.

Workflow

1. Create the work log with ts-log, or read the existing log and relevant linked context. Reconcile it with the repository state.
2. Choose the smallest action that reduces the most important uncertainty or advances the prototype. Record its expected evidence and write scope first.
3. Work directly unless a bounded worker adds useful parallelism or a focused lens. Apply the write boundary in every mode.
4. Give workers fresh context and a self-contained prompt with the repository path, log path, task, expected output, relevant links, write scope, and verification needs. Tell them not to spawn workers. Verify their results.
5. After each useful action, update the log using the ts-log contract. Link authorized outputs and record the exact next action.
6. Apply the restart test: can a fresh judge understand the state, locate the evidence, and start the next action from the log alone? Repair the log if not.

Move freely between research, design, planning, implementation, verification, and review. Continue while useful in-scope work remains. Checkpoint before returning DONE, BLOCKED, or ESCALATE.