# TS Workflow Prototype

> Prototype. Only explicitly triggered by user.

- Skill: `tstelzer/ts-workflow-prototype` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tstelzer/ts-workflow-prototype`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tstelzer/ts-workflow-prototype/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: tstelzer (https://skillmd.com/u/tstelzer)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tstelzer/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`.