SMTM Upgrade — Planning Document

Task file: /mnt/d/FSS/KB/Business/_WorkingOn/Tasks/SMTM-Upgrade.md Date: 2026-04-12 Scope: Planning only — updated after Talbot Response #1; awaiting approval before implementing

Context

SMTM v4.1 is a solid file-based AI task management system. The next leap is:

Making tasks self-describing via frontmatter so AI agents can auto-select the right model, apply appropriate rigor, and route work without Talbot having to specify it every time.
Adding a /task-prep skill that hydrates any task with full context before execution — enabling delegation to any AI (Claude, Cursor, local model) with zero warm-up.
Evolving toward AI agent team support where tasks route themselves to the right tool automatically.

1. Frontmatter Parameter Schema

Every task file gains a frontmatter block. Simple/optional — defaults assumed when absent.

---
title: Task Name
date: YYYY-MM-DD        # creation date (modified date readable from git/filesystem)
model: default          # light | default | high | highest
model-type: auto        # auto | free | local
task-type: code         # code | research | brainstorm | planning | writing | review | ops
risk: low               # low | medium | high | critical
status: ready           # ready | active | blocked | complete
prerequisites: none     # none | TaskName | TaskName, Phase2/TaskName
assignee: claude        # claude | cursor | talbot | tbd
---

Parameter Definitions

Param	Values	Default	Meaning
`date`	YYYY-MM-DD	(when created)	Creation date. Modified date comes from git/filesystem — no separate field needed.
`model`	light / default / high / highest	default	Maps to Haiku / Sonnet / Opus / Opus w/ extended thinking
`model-type`	auto / free / local	auto	`free` = Gemini free tier; `local` = Ollama; `auto` = best available
`task-type`	code / research / brainstorm / planning / writing / review / ops	—	Informs skill behavior (debug mode, research tools, etc.)
`risk`	low / medium / high / critical	low	Governs validation rigor and approval gates
`status`	ready / active / blocked / complete	—	Task lifecycle state; enables Dashboard queries
`prerequisites`	none / TaskName / TaskName, Phase2/TaskName	none	Tasks that must complete first. `none` implies independence (replaces `independent: yes/no` from Task Brief). For project tasks, use `Phase/TaskName` format.
`assignee`	claude / cursor / talbot / tbd	claude	Who executes

Status Lifecycle

(no status)  → task created, not yet prepped
  ready      → /task-prep ran; context complete; waiting for /task-start or agent dispatch
  active     → currently being executed
  blocked    → waiting on prerequisite or external dependency
  complete   → done

/task-prep sets status: ready. /task-start sets status: active. /task-complete sets status: complete. Dashboard query for status: ready = the executable queue.

Risk Level Behavior

Risk	Nickname	Behavior
`low`	Normal ops	Execute autonomously
`medium`	Elevated	Extra validation; flag edge cases in response
`high`	Significant	Run /task-QA before completing; require explicit Talbot sign-off
`critical`	Existential	Two-step: plan first, wait for approval, then execute. Examples: code security, data privacy, financial regulations, AI risk to core services

Note on Defcon framing: “Defcon” was considered but dropped — 4 risk levels map cleanly without military metaphor and are more self-explanatory.

2. `/task-prep` Skill

Purpose: Hydrate any task with 100% of the context needed to execute it — by any AI, in any session, from cold start.

Why it’s foundational: The quality of a task’s context is the single biggest lever on execution quality. /task-prep makes this systematic. Every task that goes through prep can be delegated, forked, or queued for agent execution without re-discovery cost.

Consolidation with Task Brief

The existing Task Brief (Task-Brief-N-[descrip].md) overlaps significantly with /task-prep — it exists only for Complex Project tasks delegated to external agents. Decision: collapse both into /task-prep.

For standalone tasks: /task-prep appends ## Context (Auto-Prepared) to the task file and sets status: ready
For project tasks (assignee ≠ claude, or in a phases/ folder): /task-prep generates/updates a Task-Brief-N-[descrip].md in the correct phase folder using the existing Task Brief format
/write-task-brief skill is deprecated — /task-prep replaces it entirely
The Task Brief FILE FORMAT is preserved; only the creation mechanism changes

What `/task-prep` Does

Reads the task file — extracts intent, gaps, referenced files/systems
Clarity check — if objectives or expected outcomes are ambiguous, STOP and ask Talbot for clarification before proceeding. Include: “Which KB sections should I pull in?” as one of the questions if context sources are unclear.
Gap analysis — identifies what context is missing to fully execute
KB access — reads relevant SMTM_System.md, CLAUDE.md, project files, or any referenced docs
Embeds context:
- Standalone task: appends ## Context (Auto-Prepared) section to the task file
- Project task: creates/updates Task-Brief-N-[descrip].md in phase folder
- Context includes: resolved file paths, KB excerpts, dependency list, model recommendation, prerequisite status check
Sets status: ready in frontmatter — signals task is ready for /task-start or agent dispatch
Outputs readiness signal — “Ready to execute” or “Blocked on: [x]“

Clarity Check (Step 2 Detail)

Before pulling in any KB content, /task-prep evaluates:

Are the success criteria measurable? (What does “done” look like?)
Are all referenced files/systems known and resolvable?
Is the task-type clear enough to route correctly?

If any answer is “no” or “unclear”: surface specific questions, pause, wait for Talbot’s answers. Do NOT guess and proceed.

Skill Flow

/task-prep [filename]
  → Read task file + frontmatter
  → Clarity check: are objectives and success criteria clear?
    → If unclear: list specific questions → STOP (wait for Talbot)
  → Extract: intent, task-type, risk, referenced files, prerequisites
  → Resolve prerequisites: are they complete? (check frontmatter status)
  → If prerequisites incomplete: set status: blocked → STOP
  → If multi-KB task: ask which KB sections to include (or read referenced ones)
  → Read/summarize: CLAUDE.md, SMTM_System.md, project STATUS.md (if applicable)
  → For standalone task: append ## Context (Auto-Prepared) to task file
  → For project task: create/update Task-Brief-N-[descrip].md
  → Set status: ready in frontmatter
  → Report: "Ready to execute" with summary of context embedded

3. Agent Team Routing (Forward Design)

This is the bridge to CC Agent Teams / Harness / Paperclip.

Current state

All work goes to the same Claude session. No routing.

Phase 1 (this upgrade): Parameterize

Add frontmatter params to tasks (section 1 above)
Skills read params and adjust behavior (model selection, rigor level)
Manual routing: Talbot sets assignee and launches the right tool

Phase 2 (future): Auto-routing

A routing layer reads model, model-type, assignee and launches the right agent
CC --model flag maps to frontmatter model value:
- light → claude-haiku-4-5-20251001
- default → claude-sonnet-4-6
- high → claude-opus-4-6
- highest → claude-opus-4-6 + extended thinking
model-type: free → Gemini CLI with task’s GEMINI_API_KEY
model-type: local → Ollama CLI call

Phase 3 (future): AI OS layer

Paperclip or equivalent: orchestrator reads _active.md, queues tasks, dispatches to agents
SMTM becomes the task queue; agents become workers
Ralph Loop (already in SMTM_System.md) is the bridge pattern today

4. File/Folder Naming Convention Revision

Current pain

Inconsistent: some tasks have dates (2026-03-14_KB-Folder-Notes.md), some don’t (SMTM-Upgrade.md)
Dates add cognitive load for active tasks (the date is already in the file’s **Date:** field)
Dates ARE useful for logs (chronological ordering)

New Convention

File type	Naming	Example
Task files	`PascalCase.md` (no date)	`SMTM-Upgrade.md`, `SD-App-Planning.md`
Log files	`YYYY-MM-DD_description.md`	`2026-04-12_smtm-upgrade.md`
Project folders	`PascalCase/`	`Projects/SD-App/`
Phase folders	`Phase-N-Name/`	`Phase-1-Foundation/`

Why no dates on tasks: Tasks are alive documents. The creation date is in the frontmatter/body. Date-prefixed task filenames cause drift — once a task extends past its creation day, the prefix feels stale. Dropping it makes names stable and semantic.

Transition: No forced rename of existing files. New tasks use the new convention. Update Tasks-Template.md to reflect this.

5. Dashboard Design

Tool recommendation: Obsidian Bases (no plugin required)

With frontmatter params on all task files, the Tasks folder becomes queryable:

filters:
  - property: status
    condition: is not
    value: complete
groupBy: risk
properties: [model, task-type, assignee, status]
sort: [risk desc]

Kanban view (via Kanban Bases View plugin): Group by status (active / blocked / complete) with drag-and-drop.

Synaptic View: Not recommended at this stage — adds plugin dependency for value that Bases already covers natively.

Dashboard file location

Tasks/DASHBOARD.md — view-only, no data. Like the Project DASHBOARD.md pattern already in SMTM.

6. SMTM_System.md Updates Required

Specific changes needed

Add Frontmatter Parameters section — document the schema from section 1 above
Add /task-prep to Useful Skills table — brief description
_tmp.md AI access rule change — currently says “AI never reads or modifies this file.” The current /task-start skill already supports _tmp.md mode where AI reads and writes it. The doc is stale. Update to: “_tmp.md can be used for quick AI tasks via /task-start _tmp.md. Passes in _tmp.md mode: lightweight, no log, AI processes unchecked tasks and appends results.”
File naming convention update — task files: no date prefix. Update file structure diagram.
Dashboard section update — add Bases query examples using frontmatter params.
NEXT-STEPS.md note — document is NOT stale; it’s a core project artifact. No change to concept.
Version bump → v5.0 (frontmatter params are a significant structural change)

7. Skills Upgrade Specs

`/task-start` changes

Context check: If model context appears large (session has prior content), suggest /clear before starting
Research mode: If task-type: research, note that AutoResearch (heavy tokens) is a future upgrade. For now, use the research superpowers skill if deep research is needed.
Risk gate: If risk: critical, force plan mode before executing — no exceptions.

`/task-complete` changes

Add /task-QA pre-check: Before closing, if task-type: code or risk: high+, run /simplify and verify tests pass
Git commit automation: A PostToolUse hook on task-complete writes would be the right pattern, but hook reliability in CC is variable. Better approach: /task-complete always offers a commit with a pre-drafted message. Keep it in the skill, not a hook.

`/task-continue` changes

Debug integration: If last Claude Response contains error markers or task-type: code, automatically invoke /debug thinking mode before continuing.
Stale context warning: If task file hasn’t been updated in >7 days, surface a warning and offer to re-run /task-prep.

New `/task-QA` skill (pre-complete gate)

Run internal tests for low/medium risk
Run /simplify for code tasks
For high/critical: checklist of verification steps before Talbot sign-off
Called by /task-complete automatically based on risk param; also callable standalone

8. Implementation Sequence

This is a planning task — implementation to be approved and sequenced by Talbot. Suggested order:

Phase 1 — Foundation (high leverage, low risk)

Update Tasks-Template.md with frontmatter schema
Add frontmatter to SMTM-Upgrade.md itself (eat our own cooking)
Update naming convention docs; no file renames needed yet

Phase 2 — Core Skills 4. Create /task-prep skill 5. Update /task-start (context check, risk gate) 6. Update /task-complete (QA gate, commit offer) 7. Update /task-continue (debug integration)

Phase 3 — Dashboard 8. Create Tasks/DASHBOARD.md with Bases queries 9. Update SMTM_System.md (v5.0)

Phase 4 — Skills polish (after dog-fooding v5 for a week) 10. Create /task-QA skill 11. Reoptimize all task skills as unit (task says: “when done SMTM upgrade”)

Decisions Confirmed

/task-prep — name confirmed; consolidates /write-task-brief for project tasks
Risk levels: descriptive — low / medium / high / critical confirmed
_tmp.md AI access — rule change confirmed: AI CAN read/write via /task-start _tmp.md
File renaming — grandfather existing dated files; PascalCase going forward only
Tasks-Template.md is stale — “AI/Human Response” → “Claude/Talbot Response” fix included
date param — creation date in frontmatter; modified date from git/filesystem
prerequisites param — none implies independence; format: none | TaskName | Phase2/TaskName
status: ready — added as distinct state set by /task-prep; full lifecycle: (none) → ready → active → blocked → complete
Clarity check in /task-prep — stops and asks for clarification if objectives/outcomes are unclear; asks which KB sections to include
/task-QA — deferred to Phase 4

Remaining Question for Talbot

Approve implementation? Plan updated with your refinements. Confirm which phase(s) to implement first, or flag any remaining changes.

Files to Modify (When Approved)

File	Change
`Tasks/Tasks-Template.md`	Add frontmatter schema
`Tasks/SMTM-Upgrade.md`	Add frontmatter to itself
`~/.claude/commands/task-start.md`	Context check, risk gate
`~/.claude/commands/task-continue.md`	Debug integration, stale warning
`~/.claude/commands/task-complete.md`	QA gate, commit offer
`~/.claude/commands/task-prep.md`	New skill (create) — replaces /write-task-brief
`~/.claude/commands/write-task-brief.md`	Deprecate (redirect to /task-prep)
`~/.claude/commands/task-qa.md`	New skill (create) — Phase 4 only
`Tasks/DASHBOARD.md`	New file (create)
`03_Processes/Simple Markdown Task Management/SMTM_System.md`	v5.0 updates