---
name: teamoften-app-dev-pm
description: Use when planning, routing, reviewing, shipping, verifying, archiving, or releasing TeamOfTen app-development work through the kanban flow; applies to Coach PM decisions and Player execution/audit/ship roles, including Backlog, TruthGate, plan, execute, syntax and semantic review, dev/TOT-DEV verification, dev-to-main release, and archive discipline.
---

# TeamOfTen App-Dev PM

Use this skill when deciding or following the kanban path for TeamOfTen
app-development work. Keep it procedural: pick the right stage path, preserve
the contract, and leave an auditable handoff at each boundary.

## Stage Defaults

- **Backlog always.** New top-level work starts in Backlog so Coach can triage
  priority, scope, assignee, and trajectory deliberately.
- **TruthGate normally.** Promote ordinary work through TruthGate before
  plan/execute. Use emergency overrides only for true emergencies, minor
  non-content-bearing fixes, or explicit human-approved exceptions. Record the
  override reason narrowly.
- **Plan often for complex work.** Use `plan` for unclear scope,
  cross-component changes, risky behavior, multi-step migrations, UI flows,
  release/branch work, or anything needing a contract. For simple corrective
  bugs, Coach may route directly to execute with a sharp note.
- **Break complexity into Backlog tasks immediately.** If a plan reveals
  separable pieces, create follow-on Backlog tasks instead of hiding a project
  inside one task.
- **Execute in the worker worktree.** Executors work only in their slot
  worktree, against the assigned plan/contract and Coach wake note. Do not edit
  `.project/`, push directly to `dev`, or mutate unrelated files.
- **Syntax review normally required.** Formal review checks the diff against
  the contract/spec/wake note, protocol rules, tests, race conditions, and
  regression risk. A syntax FAIL returns to execute; the auditor reports, Coach
  decides the next wake.
- **Semantic review for complex or high-risk work.** Use semantic/truth/wiki
  review when domain fit, product intent, protected truth, Compass/wiki context,
  user-facing meaning, or release risk matters. A semantic FAIL returns to
  execute; Coach composes the rework brief.
- **Ship always to `dev`.** Ship-stage work merges the audited Player branch to
  integration branch `dev` through the approved ship path/tooling. Never ship
  directly to `main`.
- **Verify `dev` and TOT-DEV.** After ship, verify with the right mix of tests,
  health checks, Playwright/UI smoke tests, logs, deploy status, and human
  intervention when judgment or credentials are needed. Batch dev verification
  when several compatible changes land close together.
- **Release `dev` to `main` explicitly.** Production release is a deliberate
  Coach/human decision after dev/TOT-DEV is healthy and the moment is quiet. Do
  not promote each change automatically.
- **Archive deliberately.** Archive only after the stage result is understood,
  release/verification status is clear, and the summary tells the human what
  landed or why it stopped.

## Coach Checklist

1. Put new app-dev work in Backlog and define the initial trajectory with one
   assignee for the first active stage.
2. Run TruthGate unless the situation qualifies for a narrow emergency
   override.
3. Use plan when the executor needs a contract; split discovered subprojects
   into new Backlog tasks.
4. Assign execute with a wake note that names the task contract, expected
   files/behavior, tests, and completion tool.
5. Send most code changes through syntax audit; add semantic audit for
   complex/high-risk work and name the semantic focus.
6. On audit FAIL, read the report and prior delivery, then re-wake execute with
   a specific rework note.
7. Ship only to `dev`, verify locally and on TOT-DEV as appropriate, batch
   compatible verification, and reserve `dev` -> `main` for explicit release
   decisions.
8. Archive with a concise user-facing summary once the outcome is settled.

## Player Checklist

- Start by reading the Coach wake, assignment, and relevant plan/contract.
- Do work only in your slot worktree and report through the role-appropriate
  `coord_*` completion tool.
- Preserve the plan unless Coach changes it; if scope expands, report the
  split/backlog need instead of silently broadening the task.
- For audits, judge against the assigned focus: syntax against the contract and
  diff; semantic against truth, wiki, Compass/project intent, and user-facing
  meaning.
- For ship/verify roles, do only the assigned stage and report pending deploys,
  test gaps, or human-needed checks explicitly.