Simple Markdown Task Management (SMTM)

Version: 5.9 — Updated 2026-09-23 Status: Active system

Summary

Talbot’s authoritative guide for task, project, and log management across the KB and all AI sessions.

Description

A lightweight, file-based system for managing tasks, projects, and logs in Obsidian. Designed for AI-assisted workflows — each project has a ROADMAP.md (structure), STATUS.md (state), and NEXT-STEPS.md (active conversation), giving any AI session immediate orientation without prior context. When onboarding a new AI tool, point it here.

Future Upgrades

See UPGRADES for possible upgrade ideas

Three Constructs — Task vs Project vs Ongoing Project

SMTM manages three distinct constructs. Mixing them up is the most common mis-filing mistake — check this table before creating anything.

	Task	Project (finite)	Ongoing Project
Ends?	Yes — closes on completion	Yes — archives once all phases are done	No — evergreen, never archived
Where it lives	owning dept’s `Tasks/` folder (or `Core/_WorkingOn/Tasks/` if no single owner)	`_WorkingOn/Projects/[name]/`	its primary work surface — a repo or a KB dept folder. Never `_WorkingOn/Projects/`.
Structure	one `.md` file + frontmatter	`ROADMAP.md` + `STATUS.md` + `NEXT-STEPS.md` + `LESSONS.md` + `UPGRADES.md`	`STATUS.md` + `ROADMAP.md` + `UPGRADES.md` + `LESSONS.md` at the SSOT home, plus one KB portal note
Example	”Fix the PWA manifest bug"	"ai-config Rules Upgrade” (4 phases, closed 2026-07-07)	ai-config, KB-OS, monorepo — the thing tasks and projects work on
Skills	`/task-start`, `/task-continue`, `/task-complete`	`/project-start`, `/project-continue`, `/project-task-complete`	work on it is always a normal dept Task with `project-type: ongoing`; `/project-continue <name>` routes to the active task (v5.9 — see Continuing an Ongoing Project)

How they relate: a finite Project is a bounded initiative that builds or upgrades something — often an Ongoing Project. Once it ships, it closes and archives; the thing it built keeps running as the Ongoing Project. A Task is the unit of work inside either a finite Project’s phase or an Ongoing Project’s maintenance stream.

Full detail below: Tasks → Layer 1: Tasks. Finite Projects → Layer 2: Projects. Ongoing Projects → Ongoing Projects (Third Construct), including the step-by-step workflow for handing work to a dept agent.

The Lifecycle

Two separate lifecycles — Tasks and Projects — share the same principles but different structures.

Task Lifecycle

┌─────────────────────────────────────────────────────────┐
│  HUMAN INITIATES: /task-start [filename]                │
│                                                         │
│  Quick task → add to Tasks/_tmp.md (personal scratch)   │
│  Substantive task → create Tasks/YYYY-MM-DD_Name.md     │
│  + add pointer in Tasks/_active.md                      │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│  AI SESSION                                             │
│                                                         │
│  1. Read Tasks/_active.md  (active task tracker)        │
│  2. Read task file if named (current state)             │
│  3. Execute work                                        │
│  4. Append ## Claude Response to END of task file       │
│     • Summary (checkboxes for completed items)          │
│     • Next Steps for Talbot                             │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│  TALBOT RESPONDS                                        │
│                                                         │
│  Primary: bullet list items indented under each         │
│  Next Steps checkbox                                    │
│    - [ ] Item A                                         │
│      - Talbot's response to A                           │
│  Catch-all: free-form text in ## Talbot Response        │
│                                                         │
│  Next session: /task-continue [filename]                │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
                 [repeat until done]
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│  COMPLETION: /task-complete [filename]                  │
│                                                         │
│  • AI suggests LESSONS.md candidates                    │
│  • CONTINUATION GATE — blocking: name the successor,    │
│    create it, or declare terminal with a reason         │
│  • Purge to keep only what has reference value          │
│  • Option: log to 09_Logs, delete, or keep as reference │
│  • Offer to commit                                      │
│  • Update Tasks/_active.md                              │
└─────────────────────────────────────────────────────────┘

Resuming After a Rate Limit or Crash

TL;DR:

Limit hit → wait for the reset shown, then claude --continue in the same directory (or just send a new message if the terminal’s still open). Status line shows the countdown before it happens.
Fresh session / different machine / /cleared → /task-continue [file] — auto-detects an interrupted task and resumes from its Progress checklist.
Multiple sessions open, can’t tell which is which → the status line’s own first line is always the session identity: [name · id: xxxxxxxx] when named, [id: xxxxxxxx] when not (the id is the always-valid claude --resume handle). Launch named ones with claude -n "<name>" (or /rename <name> mid-session). Note a fresh session shows only the ID line + dir | model until the first API response — normal, not broken.

A session can be cut off mid-task with no warning — a subscription rate limit pauses Claude Code before it gets a chance to write anything. See Core/AI/Claude-Code/Claude-Code.md → Rate Limits & Resuming for the native CC-level fix first: claude --continue / claude --resume restore full conversation history in the same directory and are cheaper/faster than anything below. That same page’s status line update (2026-07-14) shows live rate-limit consumption before it hits, and always shows a session’s name-or-ID so an interrupted task file can be traced back to the right terminal — see Identifying & Naming Running Sessions there. (/session name never existed — corrected 2026-07-14; the real commands are /rename and /resume.)

The mechanism here is for when that’s not enough — a fresh session, a different machine, or a /cleared conversation that no longer has the interrupted history.

While working: for any task expected to run 3+ steps, or long enough to risk a rate-limit window, write/update a **Progress:** checklist inside the task file’s in-progress Claude Response as you go (one checkbox per step, ticked as completed) — not just at the end. This costs nothing when the session finishes normally (the final Summary replaces it) and becomes the resume checkpoint when it doesn’t.
On the next /task-start or /task-continue: if the file ends mid-## Claude Response — no ## Talbot Response follows it, or the placeholder is empty — treat this as an interrupted session, not “waiting on Talbot”:
- Resume from the first unchecked item in the last **Progress:** checklist.
- No Progress checklist present → re-derive actual state from the repo/vault before resuming; don’t blindly redo work that may have already landed.
- Complete the work, then replace the in-progress Claude Response with the final Summary + Next Steps (don’t append a duplicate section).

Reconciling a Follow-up Task Back Into Its Parent

A revision/follow-up task (e.g. X-Revisions.md) can end up fully absorbing everything still open on the task it followed up on (e.g. X.md), leaving two files half-tracking the same thread — a live SSOT violation. When that happens:

Read the parent task’s Next Steps for Talbot across every Claude Response round; identify which are already closed (addressed in the follow-up, or superseded) vs still genuinely open.
Append the still-open items to the follow-up task’s own Next Steps for Talbot as one consolidated list — don’t leave them scattered across per-round sections.
Close the parent via /task-complete, not a manual frontmatter edit — the skill runs the full workflow (LESSONS extraction, disposition decision, _active.md update) that a bare status: complete edit skips entirely.
The parent’s closing note should point at the follow-up file by name as the SSOT for continued work, not just say “done” — a future /task-continue or human re-read needs to know where the thread actually lives now.

Discovered: mBR-Business-Review-and-Plan.md → mBR-Business-Review-Revisions.md reconciliation, 2026-07-15 — closing the parent by hand-editing frontmatter to complete (skipping /task-complete) was caught and reverted before the skill ran properly.

The Continuation Gate — No Task Closes Without a Resolved Successor

The failure this fixes. A task closes, the thread it was part of keeps going, and nothing tracks the next piece. It is silent — no error, no orphan file, nothing on a dashboard. It surfaces days later when a human notices work stopped. Two confirmed incidents, same shape:

sdc-levpro-sdmath-complete closed 2026-08-28. The LevPro port had to continue into the UI, and no task or roadmap line tracked it. Talbot found the gap himself the next day and wrote the successor from scratch.
sdc-sdapp-full-levpro-port reached “dev scope functionally complete” (round 6, 2026-08-30) with no artifact answering what happens after this closes. An instance-level patch (round 7) fixed that one file and would not have applied to any other task — the reason this mechanism exists.

The mechanical cause, confirmed by reading the skills rather than assumed. /task-complete treated the hand-off as conditional prose — “end with the next command if the closed task hands off to another skill… otherwise Next: none”. /task-continue had no successor check at all. /project-task-complete Step 8 (project closure) had the same hole, so promoting flat Tasks into a Layer-2 Project would not have prevented either incident — the Project construct buys a shared state doc, not a successor guarantee.

The mechanism. /task-complete Step 4c fires on every close — unconditional, no grandfathering, _tmp.md excepted — and blocks with AskUserQuestion, never a note (per Core/Processes/Behavioural-Solutions.md: an informational nudge at a decision moment measures ≈0; a forced choice naming a concrete alternative is what moves behaviour). Three resolutions:

Resolution	What the agent does	Frontmatter written
Successor already exists	Verify it on disk via the Tasks-folder glob before pointing at it	`continuation: <filename>`
Successor needed, not written	Create the stub now, routed by dept, carrying the still-open items verbatim; add to `_active.md`	`continuation: <new-filename>`
Terminal	Reason required, and it survives the purge into the closing log — under disposition B the task file is deleted, so the log is the only readable record	`continuation: none — <reason>`

Ongoing-project variant (v5.9). An ongoing project never ends, so “terminal” is the wrong word for closing its last open task. For a task with project-type: ongoing, or with a project: value that is a registry row, option 2 is pre-filled with the next unchecked ROADMAP item, which serves as the one named alternative. Option 3 becomes “leave the project idle”. Its reason is still required, and it is also written into ROADMAP ## Now as Idle by decision, so a quiet project is a recorded choice. See Continuing an Ongoing Project.

The gate rides in the same message as the LESSONS/memory candidate gate when that one has anything to post — closing a task costs one interruption, not two.

Two design points that make it structural rather than declarative:

A named successor must resolve to a file that exists. Incident #1’s continuation existed conceptually; no file existed. A pointer that isn’t verified reproduces the failure with extra steps.
It is asked of Talbot, never self-resolved. Both incidents happened with an agent that would have answered “nothing follows.”

Where else it fires. /project-task-complete Step 8 applies the same gate at project closure (phase boundaries are exempt — the next phase is already named in ROADMAP.md/STATUS.md). /task-continue’s creep gate does not enforce it: options 2 (ship reduced scope) and 3 (stop and close) instead require the deferred remainder to be written as a concrete Next Steps checkbox, so the close-time gate has something real to carry forward. There is deliberately no “agent declares scope done” trigger — that is not mechanically detectable, and a gate keyed on the agent noticing it is the advisory version this replaces.

Task vs. Project is not the variable here. The construct question (“should multi-phase work use Layer 2?”) and the continuation question are independent — Layer 2 had the identical hole. Promote to a Project when a single STATUS.md genuinely earns its keep as the SSOT for state across several live threads; don’t promote to fix continuation, because it doesn’t.

Project Lifecycle

┌─────────────────────────────────────────────────────────┐
│  HUMAN INITIATES                                        │
│                                                         │
│  /project-start [name]                                  │
│  → creates Projects/[name]/ROADMAP.md                   │
│  → creates Projects/[name]/STATUS.md                    │
│  → creates Projects/[name]/NEXT-STEPS.md                │
│  → creates Projects/[name]/LESSONS.md                   │
│  → prompts: Simple or Complex?                          │
│    Complex → creates phases/ subfolder                  │
│  + optional SPEC.md, PLAN.md, DESIGN.md                 │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│  TALBOT RESPONDS                                        │
│                                                         │
│  Write direction in NEXT-STEPS.md                       │
│  below the ## Talbot Response heading                   │
│                                                         │
│  /project-continue [name]                               │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│  AI SESSION                                             │
│                                                         │
│  1. Read STATUS.md  (Current Phase block + blockers)    │
│  2. Verify phase names match ROADMAP.md                 │
│  3. Read NEXT-STEPS.md  (latest Talbot Response)        │
│  4. Execute work                                        │
│  5. On finish:                                          │
│     • Tick checkboxes in STATUS.md                      │
│     • Append Claude Response to NEXT-STEPS.md           │
│     • Write YYYY-MM-DD_Description.md → logs/           │
│     • Final message: WSL + Windows paths                │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
                 [repeat until done]
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│  PHASE BOUNDARY: /project-task-complete (REQUIRED)      │
│                                                         │
│  • Archives NEXT-STEPS.md → logs/                       │
│  • Resets NEXT-STEPS.md to phase-start template         │
│  • Moves phase folder → archive/ (Complex projects)     │
│  • Updates STATUS.md Current Phase block                │
│  • Reviews LESSONS.md for promotion candidates          │
│                                                         │
│  Project closure (final phase / Simple project):        │
│  • Marks STATUS.md ✅ Complete                          │
│  • Removes from Tasks/_active.md                        │
│  • Closure log → owning dept's Logs/                    │
│    (Core/<Dept>/Logs/YYYY-MM-DD_[name]-closure.md)      │
└─────────────────────────────────────────────────────────┘

Phase boundary rule: /project-task-complete is required at every phase end — not just end-of-session. Each phase completion archives NEXT-STEPS.md and resets it to the phase-start template so the next phase starts clean.

AI Session Efficiency

The task file is a complete context capsule. Every task file is designed to contain everything an AI session needs to resume: background, current state, prior conversation history, and next steps. No prior session context is required.

Cross-session practice: When resuming a task in a new Claude Code session or after switching tasks, run /clear before /task-continue. This keeps token costs low and prevents irrelevant prior-session context from accumulating. The task file fully reconstructs context on a fresh session.

Mid-session: Do not /clear mid-task. In-flight state (tool outputs, debugging traces, code in progress) is not captured in the task file and will be lost.

Scenario	Action
Resuming from prior day / new session	`/clear` → `/task-continue [file]`
Switching from an unrelated task	`/clear` → `/task-continue [file]`
Session context approaching 50%+	`/clear` → `/task-continue [file]`
Mid-session iteration (same task)	Continue directly — no clear

The /task-continue skill surfaces a relevance advisory when the session contains substantial unrelated content. Talbot decides whether to clear.

Communication Style — Claude Response / Next Steps

Applies to: every ## Claude Response and ### Next Steps for Talbot section written by /task-start, /task-continue, /task-complete, /project-continue, /project-task-complete. Goal: full clarity, then as concise as possible without losing meaning (Talbot, 2026-07-22).

Order = priority. The first checkbox in “Next Steps for Talbot” is the single most important action. No hard cap on list length — a longer list with the right item first beats a short list that buries it.
[x] means the outcome landed, not “I looked into it.” Analysis-only or an unresolved finding stays unchecked with a one-line status. Don’t check a box because the diagnosis is done if the fix isn’t.
Every open question, decision, or unresolved issue Talbot needs to act on must be a “Next Steps” checkbox — never left in Summary prose, and never just narrated as a “flag” in a body section. A question answered inline in the Summary (even with “your call” language) reads as resolved and gets skipped, because Talbot scans Next Steps for what needs him — and an issue that’s only mentioned (“flagging this so it doesn’t get lost”) without becoming a tracked checkbox gets lost anyway, because there’s nothing for him to check off later. If a question or issue from a prior round is still unresolved, re-surface it with full context restated as a checkbox in the current round — don’t make Talbot backtrack through old rounds to recover what the issue even was, and don’t assume a prose mention counts as having tracked it. (Discovered: rate-scanner-upgrade Round 10 — a “flag-for-investigation workflow?” question got answered in Summary prose instead of a checkbox, 2026-07-25. Recurred: Accounting-Dept-Start 2026-07-29 — chequing-statement reconciliation was raised as a prose “don’t build now, flag so it doesn’t get lost” note rather than a checkbox, and was correctly called out as dropped; Talbot: “we want a robust process that does not result in issues being abandoned.”)
Next Steps items requiring Talbot to visit an external site: include the direct URL, not just the institution/site name — he shouldn’t have to search for it himself. (Same Round 10 incident — “confirm KOHO’s deposit insurance” was flagged as needing a direct link.)
Under each Next Steps checkbox, append (no blank line) a placeholder line * (two spaces, asterisk, one trailing space) for Talbot’s inline reply — never a nested checkbox ( - [ ]), which Obsidian renders as a second, separately-tracked unchecked item rather than a plain reply bullet. Talbot types his response directly after that asterisk. This applies to every skill that writes a Next Steps section, not just /task-start — the same placeholder convention must appear consistently in /task-continue, /task-complete, /project-continue, and /project-task-complete output too. (Discovered: task-start.md had this rule but task-continue.md — the far more frequently run skill — did not, so it silently regressed to nested checkboxes across most task-file rounds. Verify each skill file individually when fixing this class of gap; AGENTS.md’s own lesson on this: a batch “fixed” count doesn’t mean every file was actually checked. Accounting-Dept-Start, 2026-07-29.)
- Use *, not -, for the placeholder — and no blank line above it. An empty - placeholder is a bare dash line, which is a CommonMark setext heading underline; with no blank line separating it from the checkbox paragraph above, it silently turns that checkbox text into a heading (confirmed via markdownlint-cli2 MD022, reproduced live in Obsidian, orgchart-util, 2026-08-31). The first fix added a blank line before the placeholder to break that lazy continuation — CommonMark-correct, but Talbot rejected it as unwanted vertical space (create-review-guide-skill round 4, 2026-08-31 — “there is now an extra space… this blank line was not there before, remove it”; the disconnected-bullet mechanism floated at the time was never actually confirmed and should not be treated as established). The actual fix is the marker, not the blank line: - is a valid setext-underline character, * is not — a bare * line can never be misread as a heading underline, so no blank line is needed at all (verified: markdown-it shows - [ ] text\n - \n corrupts to a heading while - [ ] text\n * \n does not, and markdownlint-cli2 raises no MD022 on the * form). Fixed at the source in task-start.md/task-continue.md (superseded the blank-line-only fix from commit 788cbf5) rather than per-file. Rounds 4–6 of that same task kept re-adding the blank line in practice despite the instruction saying to remove it — the instruction being correct doesn’t mean the output matched it; re-read the actual appended text before claiming the fix landed, don’t just trust that the skill file says the right thing.
“Next Steps for Talbot” file references: always the full path (WSL + Windows), no exceptions except the current working folder. This is stricter than file references in Summary prose (see next bullet) — a Next Steps item is something Talbot must act on without re-reading the round, so “obvious from context” is not good enough there: he shouldn’t have to scroll back up to find a filename, let alone its folder. State both /mnt/d/FSS/KB/... and D:\FSS\KB\... for any KB file, the WSL path for any repo file. The one exception is a file already in the folder Talbot is currently working in (e.g. the task file itself). (Discovered: sdc-sdapp-full-levpro-port round 6 — a Next Steps item named a newly-created task by neither filename nor folder, forcing Talbot to go find it himself; Talbot: “I should never have to wonder where a file or task note is,” 2026-08-30.)
Summary-prose file references: bare name if it’s already obvious from context, full path only when ambiguous (first mention this session, or the name collides with another file). Don’t repeat a full path every time once it’s established. This looser rule applies only to prose inside Summary/body sections — Next Steps items follow the stricter rule above regardless of how the file was already mentioned in Summary.
Use headings and bold key phrases to mark what matters most — Talbot skims for the bolded terms first, reads full text second. This is a deliberate part of his own writing style (used in every publication since 1993), not a nice-to-have.
Cut preamble. No “I confirmed that…”, “Investigation shows…”, “Great question” — state the fact or the action directly.
Commit code/KB changes routinely once verified working — don’t wait to be asked, and don’t hold changes uncommitted as a “Next Steps” item. git add/git commit are already pre-approved everywhere per AGENTS.md (2026-07-18) — never push, but a local commit needs no live-chat approval. Treating “commit the changes” as something to defer until explicitly asked is unnecessary friction Talbot does not want. (Discovered: rate-scanner-upgrade Round 10 — Talbot: “There is zero negative from a commit… Always want to reduce friction for me,” 2026-07-25.)

(History: this section was added after a real friction incident — a Comet browser-settings fix was delivered as prose instead of numbered steps, and a step was marked [x] before the actual fix was confirmed working. See Core/Processes/Projects/KB-OS/Tasks/KB-OS-focus-ongoing-project.md rounds 3–6 for the full before/after.)

The Path to Completion Block — v5.8

Next Steps say what to DECIDE. Path to Completion says what to RUN, in order, until the work is actually finished. All six response-writing skills end every ## Claude Response with one — /task-start, /task-continue, /task-complete, /project-start, /project-continue, /project-task-complete — required, every round, no exceptions. It is the LAST section, immediately before ## Talbot Response; above the Next Steps checkboxes it gets buried and defeats itself.

Schema SSOT is /task-continue Step 6b. The other four skills carry a pointer plus the block list, deliberately — restating the schema in five files is how it drifts. Blocks, in order:

Block	Content	Required when
Review it:	Link to `<project>/docs/Review-<Name>.md` + one line on what changed	The round produced anything Talbot can look at. No guide → run `/create-review-guide` that round; a stale guide → update it before linking
Project SSOT:	`STATUS.md` / `ROADMAP.md` links + which one file is authoritative for oversight	The work lands in a project. Link only files verified to exist
Now:	Exactly one copy-paste-ready command, full path	Always
Then, in order:	The next ~4 commands, each with what it unblocks	Always (stop where knowledge stops)
Related open tasks:	Other open tasks in the same thread, bucketed startable now vs blocked on X, ~5 max	Other open tasks exist. Inventory of parallel work, not a menu — sits below `Then` so it can’t compete with `Now`
Blocked on you:	Human-only work — account creation, a Risks review, a decision	Any exists. Never disguised as a command
Done when:	The concrete, checkable condition that ends the thread	Always

Three rules that carry the weight:

Now is exactly one command, never a menu. Per Core/Processes/Behavioural-Solutions.md, a list of options measures ≈0; one named action moves behaviour. A genuine choice goes in Next Steps; Now names the recommendation.
It must cross the task boundary. A route ending at /task-complete leaves “what do I do after it closes?” unanswered — the exact failure this block exists to prevent.
It survives the hand-off. /task-complete Step 4c writes it into the successor rebased (Then / Blocked on you / Done when / Project SSOT carry forward; Now is rewritten to the successor’s own next command), and /task-continue Step 4 reads that inherited block and continues from it. An inherited block nobody consumes is a tombstone; open items surviving while the route dies is the failure that produced this rule.

Three places the block gets destroyed rather than merely omitted — all three now carry the rebase rule:

Boundary	What happens to the file	Rule
Task close → successor	Successor is a different file	`/task-complete` 4c writes `## Inherited from <parent>`; both `/task-start` and `/task-continue` read it
Project phase boundary	`NEXT-STEPS.md` is replaced, not appended	`/project-task-complete` 5 carries the block into the reset template. The continuation gate is closure-only and does not fire here — nothing else catches a loss at a phase boundary
`/task-compact`	Rounds 1..N-1 are summarized away	The final round is copied byte-for-byte (so its block survives); `## Inherited from` must be preserved explicitly, or a summarizer folds it into Background

Which command opens a successor is a check, not an assumption: grep -c '^## Claude Response' <successor> — zero → /task-start, one or more → /task-continue. /task-start refuses a task that already has a Claude Response, so guessing wrong hands Talbot a dead command.

(Discovered: sdc-sdapp-full-levpro-port rounds 16–17 and sdc-sdapp-deploy-miniapp round 3, 2026-09-01. Talbot: “You ALWAYS need to leave very clear concise next steps on how I progress until task completion”; then, on the first live hand-off: the successor pointer said /task-start for a task that already had two rounds, the Path to Completion didn’t survive the transfer at all, spun-out sibling tasks had to be found by scanning the task list by hand, and nothing pointed at the project’s own STATUS.md/ROADMAP.md.)

Task Routing (Dept-Based) — v5.2

SMTM is no longer vault-monolithic. The KB has a department-first structure, so a task is filed in the Tasks/ folder of whichever surface owns the work. Apply this single decision test:

“What is this task about?”

Business-specific dept work → <Biz>/<Dept>/Tasks/ (owned by that dept’s director) — e.g. MBR/Mktg/Tasks/

Cross-business or vault/system work with a clear Core dept → Core/<Dept>/Tasks/ — e.g. Core/Processes/Tasks/, Core/IT/Tasks/, Core/AI/Tasks/

Vault-level, multi-dept, or no single owner → Core/_WorkingOn/Tasks/ (the quarterback’s desk)

ONE master tracker. Keep a single Core/_WorkingOn/Tasks/_active.md for the whole vault, grouped by dept — not per-dept _active.md files. Talbot is still the single quarterback; per-dept trackers are premature until agents run independent loops (YAGNI → Phase 2). The dept: frontmatter field (see Task Frontmatter Parameters) drives the grouping in the tracker and Dashboard.

Why one tracker: business-specific → <Biz>/<Dept>/Tasks/; cross-business system work with a clear Core dept → Core/<Dept>/Tasks/; vault-level/multi-dept → Core/_WorkingOn/Tasks/. The file moves to the owner; the tracker stays central.

Layer 1: Tasks

Where: Tasks/_tmp.md (personal scratch — AI never reads or writes) + Tasks/_active.md (AI-managed active tracker) + the owning surface’s Tasks/ folder (per Task Routing above — a dept Tasks/ folder or Core/_WorkingOn/Tasks/) for named task files needing a spec or feedback loop.

Tasks/_tmp.md — Personal Scratch + Quick AI Tasks

Tasks/_tmp.md serves two purposes:

Personal scratch pad — drafts, notes, quick ideas, anything Talbot wants to jot down
Quick AI tasks — for lightweight tasks that don’t need a named file or log

AI access via /task-start _tmp.md: When _tmp.md is passed explicitly, /task-start runs in _tmp.md mode — finds unchecked tasks or instructions, executes them, appends results and a ## Claude Response section. No _active.md tracking, no /task-complete workflow needed.

Not suitable for: anything complex, high-risk, or requiring a feedback loop. Use a named task file for those.

Tasks/_active.md — Active Task Tracker (AI-Managed)

Tasks/_active.md is the single, vault-wide list of active named task files, maintained by the AI. There is exactly one (Core/_WorkingOn/Tasks/_active.md) — never per-dept copies. As of v5.2 it is grouped by department (## Processes, ## AI, ## IT, …) so the central tracker reflects dept-based routing while staying SSOT. AI reads this at session start to orient itself, and updates it when tasks are started or completed.

Sequentiality (v5.5, 2026-07-27): within each dept section, list order is literal execution order — top entry is next-up for that dept, not just an unordered set. When adding a new task, insert it at the position reflecting when it should actually be worked (usually top, unless something else is more urgent) rather than always appending to the bottom. This is a documented convention only — no new tooling; Talbot and Claude both re-order by cutting/pasting a line when priorities shift. (Adapted from the ICOR “Sequentiality” concept — execution order as an axis separate from priority/timing; see Core/Processes/Projects/KB-OS/Tasks/KB-OS-icor-ideas.md.)

## Processes
- SMTM-v5.2-Ongoing-Projects

## AI
- ai-config-rules-upgrade

## Vault-level (_WorkingOn)
- KB-OS-Architecture

Tasks/ — Individual Task Files

For anything needing a spec, feedback loop, or more than 30 minutes, create a named task file:

_WorkingOn/Tasks/
├── _tmp.md                    ← personal scratch + quick AI tasks (/task-start _tmp.md)
├── _active.md                 ← active task tracker (AI-managed)
├── DASHBOARD.md               ← Obsidian Bases view over task frontmatter (optional)
├── SMTM-Upgrade.md            ← active task (PascalCase, no date prefix)
└── KB-Folder-Notes.md         ← active task

When to create a task file: task > 30 min, needs a spec, or involves human↔AI back-and-forth. When to use _tmp.md: quick personal notes, or lightweight AI tasks via /task-start _tmp.md. File naming: PascalCase.md — no date prefix. Dates belong in the frontmatter date field and in log filenames, not task filenames. Log: For completed tasks — optional. Keep only if it has future reference value. Promote to Project when: task expands beyond one session, needs phases, or requires a persistent STATUS.md.

Creating a New Task File

Preferred method — Obsidian Templater (smart template): In any Tasks/ folder in the vault, right-click → New File. Templater auto-applies the smart SMTM template and prompts:

Task type — Standalone dept task / Ongoing repo-backed / Ongoing KB-native
Focus — urgency (1_now → 5_someday)
Task category — bug / feature / ops / research / planning / writing / review / brainstorm
Risk — low / medium / high / critical

Dept is auto-detected from the folder path. Appropriate frontmatter and body structure fill automatically. Works for any Tasks/ folder in the vault — no per-folder Templater config needed.

Alternative — Command palette: Templater: Open Insert Template Modal → select “SMTM Task — Smart” (adaptive) or “SMTM Task” (bare-bones).

Templates:

Core/Processes/Projects/KB-OS/Templates/SMTM Task — Smart.md — adaptive wizard (preferred; auto-triggered by Templater file regex .*/Tasks/.*)
Core/Processes/Projects/KB-OS/Templates/SMTM Task.md — bare-bones fallback (available as hotkey)

The task file is a single file for the entire lifecycle. Nothing is deleted — the full Claude↔Talbot conversation history stays in the file. New sections are always appended to the END. After each Claude Response, Claude appends ## Talbot Response + --- so Talbot can write the reply directly.

Cycle: Claude appends → Talbot appends → Claude appends → … → /task-complete

Next Steps requiring human action — be explicit. When a Next Steps for Talbot item requires Talbot to do something outside the chat (re-authorize a connector, run a command, provide a credential, click through a UI flow), never state the ask abstractly (“re-authorize X”). Spell out: exactly which system/URL/menu, the concrete steps to get there, and what to do with the result. Assume no prior knowledge of the tool’s auth flow. Discovered: /task-continue asked Talbot to “re-authorize the Gmail connector” with no path to follow — he had no way to act on it (Ideas-Workflow-P4-multi-format-intake.md, 2026-07-18).

Commands for Talbot to paste — file-based, not multi-line inline. Three failure modes recur: (1) a placeholder inside a command (export VAR="your-value-here") gets pasted verbatim instead of replaced — the ask wasn’t unmistakably a template; (2) a multi-line python3 -c "..." or similar inline block gets mangled by terminal paste (each line becomes a new prompt, picking up stray indentation → IndentationError); (3) two separate statements meant to run in sequence (e.g. a PowerShell $var = ... assignment, then a command using $var on the next line) execute out of paste order in the terminal, so the second line runs before the first line’s assignment lands — the visible error (e.g. “argument is null or empty”) looks like a bad command when it’s really a sequencing artifact. Prefer a cat > file << 'EOF' ... EOF heredoc (pastes as one inert block, no shell interpretation until deliberately run), or join dependent statements onto one line with ; so paste order can’t scramble them, over anything requiring mid-command edits or multi-line inline flags. If a real value must be substituted, mark it unmistakably (PASTE_YOUR_VALUE_HERE) and say so as a separate step, not inline in the pasteable block. Discovered: same task file, 2026-07-18 — modes 1–2, both cost a full round-trip before being caught; mode 3 discovered System-Maintenance ongoing project, 2026-07-21 (a Set-ScheduledTask -Action $action / $action = New-ScheduledTaskAction ... pair pasted as two lines executed in reverse order).

Circuit breaker — after ~4 failed fix attempts on the same problem, change axis. See AGENTS.md’s CIRCUIT BREAKER rule (call advisor, try a different tool/protocol, get a second opinion from another model and evaluate it critically, or ship a reduced-scope fallback) — applies to any SMTM task that’s looping on the same kind of failed remediation, not just code bugs.

Skills:

/task-prep [filename] — prepares a task with full context; sets status: ready; use before /task-start for complex or delegated tasks
/task-start [filename] — Claude reads task file, executes it, appends first Claude Response (first session only)
/task-continue [filename] — Claude reads latest Talbot Response and appends new Claude Response
/task-complete [filename] — closes the task: LESSONS.md candidates, Continuation Gate (Step 4c — blocking), purge, log/delete option, commit

Task Frontmatter Parameters

Every task file can include an optional YAML frontmatter block. Defaults apply when fields are omitted — add only what’s useful for the task.

---
title: Task Name
date: YYYY-MM-DD          # creation date (modified date from git/filesystem)
dept:                     # owning department (Processes | AI | IT | Strategy | ...) — drives routing + tracker grouping
project-type:             # ongoing | finite — set when the task belongs to a project (see Ongoing Projects)
model: default            # light | default | high | highest
model-type: auto          # auto | free | local
task-type: planning       # code | research | brainstorm | planning | writing | review | ops
risk: low                 # low | medium | high | critical
status:                   # (blank) | ready | active | blocked | complete
requires_approval:        # true | false — true for A1 work (CONSTITUTION Approvals queue); A0 advisory is inherently gated
prerequisites: none       # none | TaskName | Phase2/TaskName
continuation:             # <successor-filename> | none — <reason> — written at close by /task-complete Step 4c
assignee: claude          # claude | cursor | talbot | tbd
---

Parameter Definitions

Param	Values	Default	Meaning
`date`	YYYY-MM-DD	creation date	Task creation date. Modified date is derivable from git — no separate field needed.
`dept`	Processes / AI / IT / Strategy / Offerings / Mktg / Risks / …	—	Owning department. Drives Task Routing (which `Tasks/` folder) and grouping in `_active.md` + Dashboard. Omit only for genuinely vault-level/no-owner tasks.
`project-type`	ongoing / finite	—	Set when the task belongs to a project. `ongoing` = work on an evergreen Ongoing Project (repo/dept folder, never archived); `finite` = work on a phased Project in `_WorkingOn/Projects/`. See Ongoing Projects.
`model`	light / default / high / highest	default	Maps to Haiku / Sonnet / Opus / Opus+thinking
`model-type`	auto / free / local	auto	`free` = Gemini free tier; `local` = Ollama; `auto` = best available

Model-check gate (implemented in task-start/task-continue, 2026-07-16): if model:/model-type: is set, the skill compares it against the running session’s own model identity and stops before executing on a mismatch — reporting the required model and telling Talbot to relaunch with claude --model <required> (or /model <required>, then re-run). An agent can detect a wrong model but cannot switch itself mid-session, so this is a hard stop, not a warning. For a multi-phase task where each phase’s plan text names its own model recommendation (e.g. “Phase 3: Fable — workflow judgment”), that phase-level recommendation overrides the file-level frontmatter for that phase’s gate check. | task-type | code / research / brainstorm / planning / writing / review / ops | — | Informs skill behavior (debug mode, research tools, risk gates) | | risk | low / medium / high / critical | low | Governs validation rigor and approval requirements | | status | (blank) / ready / active / blocked / complete | — | Task lifecycle state; powers Dashboard queries | | requires_approval | true / false | — | A1 gate. true = output must clear the CONSTITUTION Approvals queue before it lands. A0 advisory tasks are inherently approval-gated, so the field is optional there. | | prerequisites | none / TaskName / Phase2/TaskName | none | Tasks that must complete first. none implies independence. | | continuation | <successor-filename> / none — <reason> | — | Written at close, not at creation — the recorded answer to /task-complete’s Continuation Gate (Step 4c). A named successor must be a file that exists; none requires a reason. Never set this by hand at task-creation time — at start you don’t yet know the successor. See The Continuation Gate. | | assignee | claude / cursor / talbot / tbd | claude | Who executes |

Status Lifecycle

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

Risk Level Behavior

Risk	Behavior
`low`	Execute autonomously
`medium`	Extra validation; flag edge cases in Claude Response
`high`	Talbot sign-off required before closing; `/task-QA` check (Phase 4)
`critical`	Mandatory plan-first gate — no auto-execution. Applies to: code security, data privacy, financial, AI risk to core services

Dashboard

Tasks/DASHBOARD.md contains Obsidian Bases queries that use these frontmatter params to display active tasks, the ready queue, tasks by risk level, and blocked tasks. See the file for query templates.

Layer 2: Projects

Document Responsibilities

Each document has one clear job. Never store content in the wrong place.

Document	Single responsibility	SSoT for
`ROADMAP.md`	Structure — phases + tasks (living TOC)	“What are we building and how is it structured?”
`STATUS.md`	State — what’s done/not done	”Where are we right now?”
`NEXT-STEPS.md`	Communication — Claude/Talbot dialogue	”What are we doing next?”
`LESSONS.md`	Learning — decisions, patterns, significant pivots	”What have we learned and decided?”
`UPGRADES.md`	Ideas — discovered during dev, not yet committed	”What could we improve or add later?”
`DASHBOARD.md`	View — Obsidian presentation layer (optional)	(no data — renders STATUS + task frontmatter)

Hard rules:

STATUS.md contains only state. No decisions, no feedback, no instructions.
NEXT-STEPS.md is the only communication channel. Talbot feedback goes here as a Talbot Response — not in STATUS.md.
Key decisions belong in LESSONS.md (process) or DESIGN.md (technical, dev projects) — not STATUS.md.
UPGRADES.md is a parking lot for ideas discovered during development. Ideas are not committed to phases until promoted to ROADMAP.md ## Future / Backlog.
ROADMAP.md and STATUS.md are always updated atomically — change one, the hook syncs the other.

Simple Project Structure

For most projects — fewer than ~10 tasks, single-phase or loosely phased:

_WorkingOn/Projects/[name]/
├── ROADMAP.md      ← project TOC: flat task list (Simple) or phase hierarchy (Complex)
├── STATUS.md       ← state-only: Current Phase block + phase checkboxes (AI reads first)
├── NEXT-STEPS.md   ← active Claude/Talbot conversation; phase-scoped, resets at phase boundary
├── LESSONS.md      ← process decisions, patterns, significant pivots
├── UPGRADES.md     ← ideas discovered during dev (not committed to phases)
├── SPEC.md         ← optional: what we're building (requirements, stays current)
├── PLAN.md         ← optional: how we'll build it (approach + phases, stays current)
├── logs/           ← dated session logs (YYYY-MM-DD_Description.md)
└── archive/        ← completed reference documents (moved here when no longer active)

Cancelled phases: Move the phase folder directly to archive/ with a note in LESSONS.md explaining why it was cancelled.

Complex Project Structure

For multi-phase projects with substantial work per phase:

_WorkingOn/Projects/[name]/
├── ROADMAP.md      ← phase hierarchy with tasks per phase
├── DASHBOARD.md    ← optional: Obsidian view layer (no data — renders STATUS + task frontmatter)
├── STATUS.md       ← state-only: Current Phase block + phase checkboxes
├── NEXT-STEPS.md   ← phase-scoped conversation; resets at each phase boundary
├── LESSONS.md      ← process decisions, patterns, significant pivots
├── UPGRADES.md     ← ideas discovered during dev (not committed to phases)
├── ARCHITECTURE.md ← dev projects only: system design + tech stack (stable reference)
├── DESIGN.md       ← dev projects only: evolving technical/architectural decisions
├── SPEC.md         ← optional
├── PLAN.md         ← optional
├── phases/
│   ├── Phase-1-[name]/
│   │   ├── Task-1-[descrip].md    ← task spec + delegation brief (run /task-prep to embed context)
│   │   ├── Task-2-[descrip].md
│   │   └── ...
│   └── Phase-2-[name]/
│       └── ...
├── logs/           ← dated session logs
└── archive/        ← completed phases + reference documents

Key principle: NEXT-STEPS.md and STATUS.md are always live. ROADMAP.md is the authoritative source for phase and task names — STATUS.md mirrors those names exactly. SPEC and PLAN are the current version — no date prefix. Logs are historical records — always dated.

NEXT-STEPS.md — The Conversation Container

The central document for all project-level Claude/Talbot dialogue. It is phase-scoped — at each phase boundary, /project-task-complete archives the current NEXT-STEPS.md to logs/ and resets it to the phase-start template. This keeps the conversation focused on the current phase.

AI reads: latest Talbot Response → executes work → appends new Claude Response
Talbot reads: latest Claude Response → Next Steps → writes Talbot Response
Completed cycles are archived to logs/; each phase starts fresh

# [Project Name] — Next Steps

> Entry point for both parties. Use /project-continue to pick up any session.

---

## Claude Response — YYYY-MM-DD
### Summary
- [x] What was done

### Next Steps for Talbot
- [ ] Item 1
  * Talbot's inline response  ← asterisk placeholder, no blank line above it (primary reply method)
- [ ] Item 2
  *

### Path to Completion
<required every round — schema above>

## Talbot Response
See inline responses above.   ← catch-all; leave blank or use for anything not fitting inline

---

Larger projects: Use the Complex structure above. Add design documents (e.g., DESIGN.md, api-design.md) for topics that need dedicated iteration cycles — they follow the same Claude/Talbot response pattern.

Dev projects: Use Superpowers for brainstorm→plan→execute. Implementation plans live in PLAN.md. Technical decisions go in DESIGN.md (not LESSONS.md).

STATUS.md — State-Only Handoff File

Every project has a STATUS.md. AI reads it at session start; updates checkboxes and the Current Phase block at session end. STATUS.md is state-only — it does not hold feedback, key decisions, or notes.

Feedback → goes in NEXT-STEPS.md as a Talbot Response
Key decisions → go in LESSONS.md (process) or DESIGN.md (technical, dev projects)

# [Project Name] — Status

**Last Updated:** YYYY-MM-DD

## Current Phase
**Phase:** 1 — [Phase Name]
**Active tasks:** Task-1-[descrip], Task-2-[descrip]  *(list all tasks currently in flight)*
**Last action:** [Brief description] (YYYY-MM-DD)
**Next:** [Brief description of next task or decision]

---

## Phase 1: Foundation ✅
- [x] Set up project structure
- [x] Define data models

## Phase 2: Core Features 🟡 (Current)
- [x] Authentication flow
- [ ] Calculator logic
- [ ] i18n integration

## Phase 3: Polish ⬜
- [ ] Responsive design
- [ ] Accessibility audit

## Phase 4: Deploy ⬜
- [ ] Staging + production deploy
- [ ] Final log + close

---

## Key Files
[Most important files for this project]

AI session workflow:

Start: read Tasks/_active.md → read STATUS.md (Current Phase block) → verify phase names match ROADMAP.md → read NEXT-STEPS.md
Work through unchecked items in current phase
End: tick completed checkboxes, update Current Phase block, write log to logs/

ROADMAP.md

ROADMAP.md is the project Table of Contents (ToC) — the authoritative source for phase and task names. STATUS.md mirrors these names exactly; only checkboxes are edited by humans or AI. A PostToolUse hook fires on every Edit/Write to ROADMAP.md and syncs descriptions to STATUS.md automatically (see ROADMAP ↔ STATUS Synchronization below).

ROADMAP.md is a living document — update it freely when plans change. Significant pivots should also be noted in LESSONS.md.

Simple Format

# [Project Name] — Roadmap

**Summary:** One sentence — what this project delivers.
**Description:** 2-3 sentences of context, motivation, and scope.
**Type:** Simple

---

## Tasks
- Task-1: [description]
- Task-2: [description]
- Task-3: [description]

## Future Upgrades
- See [UPGRADES](/sdc/ip/projects/strategies-library/upgrades/) for possible upgrade ideas

Complex Format

# [Project Name] — Roadmap

**Summary:** One sentence — what this project delivers when done.
**Description:** 2-3 sentences of context, motivation, and scope.
**Type:** Complex

---

## Phase 1 — Foundation
- Task-1: [description]
- Task-2: [description]

## Phase 2 — Core Features
- Task-1: [description]
- Task-2: [description]
- Task-3: [description]

## Phase 3 — Deploy
- Task-1: [description]
- Task-2: [description]

## Future Upgrades
- See [UPGRADES](/sdc/ip/projects/strategies-library/upgrades/) for possible upgrade ideas

NEXT-STEPS.md Phase-Start Template

When /project-task-complete closes a phase, it archives the current NEXT-STEPS.md to logs/ and resets it to this template:

# [Project Name] — Next Steps

> Entry point for both parties. Use /project-continue to pick up any session.
> **Current phase:** Phase [N] — [Phase Name] | Active tasks: [first task name]

---

## Claude Response — YYYY-MM-DD

### Phase [N] started
- [x] [Previous phase archived to logs/]
- [x] STATUS.md updated — Phase [N] now active

### Next Steps for Talbot
- [ ] [First task or decision for this phase]
  * Talbot responds here  ← asterisk placeholder, no blank line above it

### Path to Completion
<required — carried across the phase boundary REBASED: Project SSOT / Blocked on you /
Done when survive; Now becomes this phase's own first command>

## Talbot Response
See inline responses above.   ← or blank; catch-all only

---

Task File (Project Tasks)

A project task file (Task-N-[descrip].md) is the spec AND the delegation brief for any unit of work in a Complex project phase. It lives in the phase folder and serves as the single file for the task’s full lifecycle.

Filename: Task-N-[descrip].md — N matches the task number in ROADMAP.md
Frontmatter: includes assignee, prerequisites, risk, status, and other params (see Task Frontmatter Parameters above)
Context section: added by /task-prep — embeds resolved file paths, KB excerpts, constraints, and model recommendation
Agent used field: filled in on completion — tracks which model/tool executed the task
Agent Response section: summary appended by the executing agent on completion

Run /task-prep [Task-N-descrip.md] to prepare a project task for delegation. This sets status: ready and embeds all required context. No separate brief file needed.

Note: Task-Brief-N-[descrip].md (the old separate delegation file) is retired as of SMTM v5.0. Task-N-[descrip].md is the single file type — it becomes the brief once prepped.

---
title: Task N — [description]
date: YYYY-MM-DD
task-type: code
risk: low
status: ready
prerequisites: none
assignee: cursor
---

# Task [N]: [description]

**Project:** [name]
**Phase:** [N] — [phase name]
**Agent used:** [filled in on completion — e.g., claude-sonnet-4-6 via Cursor]

---

## Spec
[What needs to be built or done. Success criteria.]

## Reference Files
- `path/to/file` — why this file matters

## Hard Rules
- [Rule 1]

## Deliverables
[Exact outputs: files created/modified, tests that must pass, etc.]

## Completion Signal
[How we know it's done — test output, build success, file exists, etc.]

---

## Context (Auto-Prepared) — YYYY-MM-DD
[Added by /task-prep — resolved paths, KB context, constraints, model recommendation]

---

## Agent Response
[Agent appends summary here on completion — model used, what was done, issues found.]

Ongoing Projects (Third Construct) — v5.2

SMTM has two completion-bound lifecycles — Tasks (single unit) and Projects (phases → archive). Some efforts never complete: the KB itself, tooling, services (KB-OS, ai-config, monorepo, web-deploy, my_backup). Forcing them into the phase-based Project lifecycle is not appropriate or efficient for ongoing maintenance and upgrades.

Definition: an Ongoing Project is an evergreen, maintained effort with no end state — never “complete”, never archived. Distinct from:

a finite Project — phases that archive on completion; lives in _WorkingOn/Projects/.
a Task — a single unit of work.

SSOT by type

An Ongoing Project’s source of truth lives at its primary work surface, exactly once — never duplicated:

Type	SSOT home	KB visibility
Code (repo exists)	the repo — `AGENTS.md` (SSOT context), `STATUS.md`, `CHANGELOG.md`, `LESSONS.md`, `ROADMAP.md`, `UPGRADES.md`, `README.md` (+ thin `CLAUDE.md`/`GEMINI.md` wrappers as used — ai-config carries `GEMINI.md`; its `CLAUDE.md` is the global `~/.claude/CLAUDE.md`)	one portal note at `Core/<Dept>/Projects/<name>.md`, bidirectionally linked with the repo `README.md`
KB-native (no repo, e.g. KB-OS)	the dept `Projects/` folder (e.g. `Core/Processes/Projects/KB-OS/`) — `STATUS.md` + `ROADMAP.md` + `UPGRADES.md` + `LESSONS.md`	the folder note (`DASHBOARD.md`) is the portal

ROADMAP.md (long-term plan) and UPGRADES.md (future-ideas parking lot) live at the primary surface exactly once — in the repo for code projects, in the KB dept folder for KB-native ones. Never both. The portal note always points to wherever they live (CONSTITUTION SSOT #5).

Hard rules

Ongoing Projects are NOT in _WorkingOn/Projects/ — that folder is finite-only. (This retires the monorepo dual-tree.)
A unit of work on an Ongoing Project = a normal SMTM Task, routed to the owning dept’s Tasks/ (per Task Routing), with project-type: ongoing and a pointer to the repo/folder for context. The task closes; the Ongoing Project lives on.
Quick maintenance → handled in-repo or via _tmp.md. No ceremony.
Session logs → the owning dept’s Logs/ folder.

The flow (Talbot’s monorepo vision, realized)

Talbot names the work → task created in <dept>/Tasks/ with dept: + project-type: ongoing + a pointer to the repo’s AGENTS.md (context already exists there) → agent executes → updates repo CHANGELOG.md/STATUS.md + writes a log to the dept Logs/ → reports back via the task’s ## Claude Response.

Minimal structure, full context, clean handoff.

Registry

One lightweight index answers “what Ongoing Projects exist, who owns them, where do they live?” — Core/Processes/Projects/KB-OS/Ongoing-Projects.md. It lists each Ongoing Project with owner dept, type, SSOT home, and portal-note link. Add a row when a new Ongoing Project is stood up (use /setup-ongoing-project).

Continuing an Ongoing Project — v5.9

One command for any project: /project-continue <name>. A finite project continues from its NEXT-STEPS.md. An ongoing project has no NEXT-STEPS.md. Its conversation lives in task files, and its ROADMAP ## Now block records which of them is active.

Where	What it holds	Who writes it
ROADMAP `## Now`	the one active task (a `link` plus its exact command), `No active task.`, or `Idle by decision (date): <reason>. Next unstarted: <item>.`	`/task-complete` Step 7b on every close; `/project-continue` when it creates a task
ROADMAP `## Waiting on Talbot`	deferred CEO decisions, each with what it gates	the agent that defers the decision; Talbot answers in place
STATUS Recently done	a dated line per closed task, linking its log	`/task-complete` Step 7b

Resolution is scripted: project-now [name] (~/utils/project-now/). It reads the registry, the ## Now block and each task file ## Now names. It verifies each task exists and isn’t complete, then prints the command: /task-start for 0 Claude Responses, /task-continue for 1 or more. A stale ## Now falls back to open tasks with a matching project:, in _active.md order, and says so. project-now --check exits non-zero on stale or missing blocks, for audits.
No active task: /project-continue offers the first unchecked ROADMAP item as a forced choice and creates the task. KB-native projects put it in <home>/Tasks/; repo-backed projects put it in the dept’s flat Tasks/. It then starts the task.
Mega projects (monorepo) may list one ## Now line per active sub-project thread. /project-continue asks which one.
DASHBOARD Biggest Rocks for an ongoing project link to its ROADMAP, or to its KB portal for a repo project, since a vault link can’t reach a repo file. Never link a task file, because tasks close.

Worked examples (the pilots): KB-OS (KB-native) lives in Core/Processes/Projects/KB-OS/ with STATUS.md/ROADMAP.md/UPGRADES.md; its folder note DASHBOARD.md is the portal. ai-config (repo) lives in ~/ai-config/ with the full repo set; Core/AI/Projects/ai-config.md is the portal. Both prove the model in practice.

Handing a Task to a Dept Agent — The Realized Workflow

This is the concrete mechanism behind Talbot’s monorepo vision: name the department and the work, dispatch it, get a report back — never touch the code directly.

Step-by-step

Find the owner — check the Ongoing Projects registry (Core/Processes/Projects/KB-OS/Ongoing-Projects.md). Example: monorepo PWA issue → owner is IT.
Create a task file. Where it goes depends on the project’s type (2026-07-07):
- Repo-backed (monorepo, ai-config, web-deploy, my_backup) → Core/<Dept>/Tasks/<task-name>.md (dept-wide, flat) — the project’s real context lives in its repo, not the KB, so the task just points at it.
- KB-native (KB-OS) → Core/<Dept>/Projects/<project-name>/Tasks/<task-name>.md (self-contained inside the project folder) — sits next to STATUS.md/ROADMAP.md for direct context walk-up.
Create the Tasks/ folder if it doesn’t exist yet. Use the standard SMTM task template. Key frontmatter:
```
---
status: ready
task-type: feature | bug | research | ops
risk: low | medium | high
focus: 1_now | 2_today | 3_thisWeek
project: <ongoing-project-name>   # e.g. monorepo
project-type: ongoing
---
```
Describe the work in plain language — what the problem is, what done looks like, any constraints. The agent reads AGENTS.md / README.md from the Ongoing Project’s SSOT for full context; you don’t need to repeat it.
Dispatch — in a Claude Code session:
```
/task-start <task-name>
```
The agent executes autonomously, tests the change, and reports back with results and evidence.
Review and close — if the report looks good, /task-complete <task-name>. If more work is needed, reply in the task file and re-dispatch.

Worked example — monorepo PWA focus pages

“There’s still an issue with the monorepo deploying the focus pages as a PWA.”

Create Core/IT/Tasks/monorepo-pwa-focus-pages.md:

---
status: ready
task-type: bug
risk: medium
focus: 2_today
project: monorepo
project-type: ongoing
---

# monorepo — Fix PWA deployment for Focus pages

## Problem
Focus pages are not deploying correctly as a PWA in the monorepo. [Describe the symptom — what you see, what you expected.]

## Done when
- Focus pages load as a PWA (installable, offline-capable)
- Passes Lighthouse PWA audit
- Deployed to staging/prod and verified

## Context
SSOT: `~/projects/monorepo/` — see AGENTS.md for full project context.
Portal: [Monorepo](/core/it/projects/monorepo/)

Then: /task-start monorepo-pwa-focus-pages — the IT dept agent takes it from there.

Worked example — KB-native project (self-contained)

“I want to fix a broken wikilink in the KB-OS docs.”

Create Core/Processes/Projects/KB-OS/Tasks/kb-os-wikilink-fix.md (inside the project folder, not Core/Processes/Tasks/):

---
status: ready
task-type: bug
risk: low
focus: 3_thisWeek
project: KB-OS
project-type: ongoing
---

# KB-OS — Fix broken wikilink

## Problem
[Describe the symptom.]

## Context
This task lives inside the KB-OS project folder itself — sibling files
(`STATUS.md`, `ROADMAP.md`, `LESSONS.md`) are immediate context; no separate
portal pointer needed since the project *is* the folder.

Then: /task-start kb-os-wikilink-fix from anywhere — /task-start searches every Tasks/ folder in the vault, including ones nested under Projects/<name>/.

Rules

One task per unit of work. Don’t batch unrelated changes into one task.
Dept determines context. The agent reads the project’s AGENTS.md automatically — trust the SSOT, don’t re-describe the whole codebase.
Agent tests before reporting. A task is not done until the agent has verified end-to-end. “It should work” is not a result.
Task closes; project continues. When the task is complete it’s archived. The Ongoing Project entry in the registry never closes.

Sub-projects within Mega Ongoing Projects

When an Ongoing Project grows to host multiple distinct sub-projects — each with its own backlog, deployment target, and independent lifecycle — it becomes a mega project. The Ongoing Project stays registered as one unit; sub-projects are its internal structure, not top-level registry entries.

Threshold test — a folder earns sub-project status when all three apply:

Has (or imminently will have) an independent backlog (2+ distinct work items)
Has its own deployment target (separate URL or artifact)
Is actively developed or concretely planned for active development

Foundation/shared folders (e.g. sites/template/ in the monorepo) don’t qualify — they’re maintained in-service of other sub-projects, not independently.

SSOT pattern:

Each qualifying sub-project folder → STATUS.md (state + backlog for that sub-project only; no repo-wide history)
Root STATUS.md → index table (one-liner per sub-project with state summary + link to STATUS.md)
KB portal → “Sub-projects” table mirroring the index (link to rolling task note)
Sub-STATUS cell format: path when created; _(pending — create on next <site> thread)_ when not yet started; — for foundation-only folders

Task convention:

Tasks stay in the owning dept’s flat Tasks/ (repo-backed rule — unchanged)
Naming: <project>-<subproject>-<descriptor>.md (e.g. monorepo-tscom-rebuild)
One rolling thread note per active sub-project thread — the same note accumulates rounds until a clean milestone
Archive trigger: close with /task-complete when the sub-project reaches stable state with no imminent work; start a fresh thread note when the next phase begins. Mid-thread pivot is OK — start a new note without forcing closure on the old one.

Optional frontmatter:

subproject: ts   # add when task is scoped to a specific sub-project; enables query grouping

Omit for tasks that apply to the parent project overall. See SMTM Task — Smart.md template.

Pilot: monorepo (IT dept) — ts.com sub-project, 2026-07-10.

Layer 3: Logs

Logs are permanent — the record of what happened.

Naming

YYYY-MM-DD_Description.md

No TYPE prefix on completed logs. PLAN and ACTIVE files keep their prefix because they are process states. Completed logs are just date + description.

Examples:

2026-03-10_KB-Structure-Upgrade.md
2026-03-09_i18n-Paraglide-shadcn-Foundation.md

Log File Template

# [Short Title]

**Date:** YYYY-MM-DD
**Project/Task:** [name]
**Status:** ✅ Complete

---

## Summary
[2-3 sentences]

## Done
- Item 1
- Item 2

## Changes
- file1 — what changed
- file2 — what changed

## Results / Metrics
[test results, build output, etc.]

## Next Steps
- [ ] Suggested next step 1
- [ ] Suggested next step 2

## Feedback
<!-- Human fills in after review -->

Log Storage

Log type	Where it lives
Active project logs	`_WorkingOn/Projects/[name]/logs/`
Archived project logs	`09_Logs/Projects/[name]/` (at project closure)
System/config logs	`09_Logs/System/`
Architecture decisions	`09_Logs/Decisions/`
Business snapshots	`09_Logs/Snapshots/`

Communication Standard (Hard Rule for All AI Sessions)

When Claude Code creates any file (plan, log, STATUS.md, etc.), the closing message must include both paths:

📄 File written:
  WSL:     /mnt/d/FSS/KB/Core/_WorkingOn/Projects/monorepo/complete/2026-03-10_Description.md
  Windows: D:\FSS\KB\Core\_WorkingOn\Projects\monorepo\complete\2026-03-10_Description.md

Claude Code plans (generated in ~/.claude/plans/) should also be copied to the KB so they’re visible in Obsidian:

Copy to: D:\FSS\KB\Core\_WorkingOn\Plans\YYYY-MM-DD_PLAN_Description.md

File Naming Quick Reference

File	Prefix	Location
Completed log	(none)	`logs/` or `complete/`
Implementation plan	`PLAN_`	`plans/`
Work in progress	`ACTIVE_`	`active/`
Session handoff	`STATUS.md`	project root
Active task tracker	`_active.md`	`Tasks/`
Personal scratch	`_tmp.md`	`Tasks/`
Task Brief	`Task-Brief-N-[descrip].md`	phase folder or project root

Superpowers Decision Gate

Use Superpowers when ≥2 of these are true:

Architecture is unclear and needs structured refinement before coding
TDD enforcement matters (you tend to skip tests when moving fast)
Project will span multiple days
Multiple components interact in non-obvious ways

Otherwise: go direct with PLAN + STATUS.md.

Dev Projects Workflow

1. /superpowers:brainstorm    → clarify app spec, edge cases, API design
2. /superpowers:write-plan    → generates TASKS.md with TDD-style spec
3. Review TASKS.md            → adjust, approve
4. /superpowers:execute-plan  → builds with test-first approach
5. Session ends               → update STATUS.md, write log to logs/

The generated TASKS.md lives in Projects/[name]/plans/YYYY-MM-DD_PLAN_Superpowers-Spec.md

Non-Dev Projects (Writing, Research)

The same lifecycle applies. “Tasks” become chapter/section checkboxes in STATUS.md:

## Part 1: The Debt Myth ⬜
- [ ] Draft intro section
- [ ] Add case studies
- [ ] Edit + proofread

Useful Skills

Skill	What it does
`/task-prep [file]`	Prepares a task with full context; sets `status: ready`; use before `/task-start` for complex or delegated tasks
`/task-start [file]`	Executes a new task file, appends first Claude Response (first session only); reads frontmatter params
`/task-continue [file]`	Reads latest Talbot Response in task file, appends new Claude Response; warns if context is stale (>7 days)
`/task-complete [file]`	Closes a task: LESSONS.md candidates, purge, log/delete, commit offer; sets `status: complete`
`/project-start [name]`	Creates ROADMAP.md + STATUS.md + NEXT-STEPS.md + LESSONS.md; prompts Simple or Complex; creates `phases/` if Complex
`/project-continue [name]`	Finite: reads Current Phase block first; verifies phase names match ROADMAP.md (flags mismatch); then reads NEXT-STEPS.md tail. Ongoing (v5.9): `project-now` → hands off to the ROADMAP `## Now` task
`/project-task-complete`	Required at every phase boundary; archives NEXT-STEPS.md to logs/; resets to phase-start template; moves phase folder to archive/; updates STATUS.md; reviews LESSONS.md for promotion candidates; for simple project closure: marks ✅, removes from _active.md
`/write-task-brief`	Deprecated — use `/task-prep` instead
`/test-all`	Full test suite at session end

Tasks/_tmp.md vs Tasks/_active.md

Two files serve completely different purposes — never confuse them:

File	Owner	Purpose	AI access
`_tmp.md`	Human	Personal scratch + quick AI tasks	Reads/writes only via `/task-start _tmp.md`; never accessed otherwise
`_active.md`	AI	Active task tracker — list of open task files	Reads at session start; updates on task start/complete

Why the split? _active.md gives Claude a clean, predictable tracking file. _tmp.md is primarily human-owned space — Claude only touches it when explicitly invoked via /task-start _tmp.md.

LESSONS.md — Self-Improving System

Every project has a LESSONS.md. Captures insights that prevent wasted effort in future sessions. For dev projects, technical decisions go in DESIGN.md — LESSONS.md captures process decisions, workflow insights, and pivots.

# Lessons — [Project Name]

## Lessons
- **[Context]:** [What went wrong or surprisingly well] → [What to do differently]
- **[Context]:** [Pattern discovered] → [How to apply it]

## Escalation Candidates
<!-- Mark with [→ global CLAUDE.md] or [→ project CLAUDE.md] -->
- [ ] [Lesson] → [→ global CLAUDE.md]

When to update LESSONS.md:

When something takes significantly longer than expected — capture why
When a pattern emerges across multiple tasks — write it down
At the end of each session (before closing)
During project cleanup (before archiving) — review for CLAUDE.md/AGENTS.md promotion candidates

Escalation workflow:

AI marks a lesson with [→ global CLAUDE.md] or [→ project CLAUDE.md]
Human reviews and approves during next session
AI adds the approved lesson to the appropriate CLAUDE.md
Lesson is cleared from LESSONS.md

UPGRADES.md — Ideas Parking Lot

Every project has a UPGRADES.md. It captures ideas discovered during development or after the project is complete, that are interesting and might be implemented later.

# [Project Name] — Upgrades

> Ideas to consider for future upgrades
> Should maintain in order of most important first

---

## Ideas
- [idea discovered during work]
- [potential improvement spotted]

Linking in Core Project Doc

Add a ## Future Upgrades section at the bottom of ROADMAP.md. This is the standard location for all projects — Simple and Complex. For dev projects with a repo README.md, also add a brief link there.

## Future Upgrades
- See [UPGRADES](/sdc/ip/projects/strategies-library/upgrades/) for possible upgrade ideas

DASHBOARD.md (Optional — Obsidian only)

Not a data source — a view layer over STATUS.md and task brief frontmatter. Only useful in Obsidian with Dataview or Bases. Markdown-only users ignore it.

Task brief frontmatter (Status, Assignee, Phase, Independent) is Obsidian-queryable:

TABLE status, assignee, phase FROM "Projects/[name]/phases"
WHERE contains(file.name, "Task-Brief-")
SORT phase, file.name

Or with Obsidian Bases (newer, no plugin required):

filters:
  - property: status
    condition: is not
    value: complete
groupBy: phase
properties: [status, assignee, independent]

Dev Project Extras

For software/app development projects, two additional documents capture technical context:

File	Purpose
`ARCHITECTURE.md`	System design, tech stack, component boundaries — stable reference
`DESIGN.md`	Evolving technical/architectural decisions (replaces `DESIGN-Decisions.md`)

Responsibility split:

DESIGN.md captures technical decisions about the product (what to build and how)
LESSONS.md captures process decisions and what to do differently (how we work)
They do not overlap

Relationship to CLAUDE.md: ARCHITECTURE.md and DESIGN.md are the human-readable planning layer. At implementation start, their confirmed decisions and hard rules are distilled into the repo’s CLAUDE.md. CLAUDE.md is updated from them — never independently.

ROADMAP ↔ STATUS Synchronization

ROADMAP.md is the authoritative source for phase and task names. STATUS.md mirrors those names exactly — only checkboxes are edited by humans or AI directly.

How sync works:

A Claude Code PostToolUse hook fires on every Edit/Write to ROADMAP.md
The hook reads the updated ROADMAP.md and syncs phase/task descriptions to STATUS.md automatically
Checkboxes in STATUS.md are never touched by the hook — only descriptions are updated
Skills do NOT enforce this sync — the hook handles it unconditionally
/project-continue verifies sync at session start as a sanity check; flags any mismatch for review

What this means in practice:

Edit ROADMAP.md freely — rename phases, reorder tasks, add/remove items
STATUS.md descriptions update automatically; human-managed checkboxes are preserved
If the hook hasn’t run (e.g., manual edits outside Claude Code), /project-continue will flag the drift

Ralph Loop (Overnight Autonomous Work)

Use when:

Well-defined TASKS.md exists with clear success criteria
Batch operations that don’t need interactive decisions
You want to wake up to completed work

claude -p "Read TASKS.md and complete all items" \
  --allowedTools "Edit,Read,Bash,Write,Glob,Grep" \
  --max-iterations 50

Project Archival

When a project is complete or in maintenance mode, move it out of _WorkingOn/Projects/ to its permanent KB home. Only active, in-progress projects stay in _WorkingOn/.

Permanent Homes by Project Type

Type	Permanent Location	Examples
Production apps (SD App, sites)	`06_Intellectual Property/Software/Apps/<name>/`	SD App, sdc.com
Reusable packages / libraries	`06_Intellectual Property/Software/Packages/<name>/`	asset-history, sd-math
Workflow automation scripts	`03_Processes/System Utils/<name>/`	backup scripts, deploy tools

When to Archive

Archive when the project:

Has no open tasks in STATUS.md
Enters “maintenance mode” (cron updates, dependency bumps, minor fixes only)
Has been signed off by Talbot

How to Archive

Confirm STATUS.md shows all phases ✅ complete
Move _WorkingOn/Projects/<name>/ → permanent home (see table above)

Add a ## Maintenance block at the top of STATUS.md:

## Maintenance Mode
**Archived:** YYYY-MM-DD
**Location:** D:\FSS\KB\Business\06_Intellectual Property\Software\...\<name>
**Next action:** [brief description of what would trigger reactivation]

Remove from Tasks/_active.md if listed there
Update any cross-references that pointed to the old _WorkingOn/ path

Reactivation

When a maintained project needs active work again:

Move back to _WorkingOn/Projects/<name>/
Remove the ## Maintenance block from STATUS.md
Add back to Tasks/_active.md
Start with /project-continue <name>

_WorkingOn Quick Reference
AI Dev Workflow
AI Tools
Folder Notes Guide

Version: 5.9 — Updated 2026-09-23 Replaces: SMTM_System.md v5.8 (2026-09-01)

Multi-KB Skill Synchronization

Claude skills (~/.claude/commands/) are global — they apply to all vaults automatically. Updating a skill in one session updates it for both Business KB and MBR KB. No sync script needed.

sync-vaults.sh (at _shared/sync-vaults.sh) handles Obsidian plugin config only
SMTM_System.md lives in the Business vault; MBR’s CLAUDE.md points here as the authoritative reference
When onboarding a new KB vault, add a .claude/CLAUDE.md that references this file

v5.9 Changes (2026-09-23)

Ongoing projects get a project-level entry point. Every ongoing ROADMAP carries a ## Now block naming the one active task and its command, plus a ## Waiting on Talbot section for deferred CEO decisions. The pilot was SDC/IP/Projects/Strategies-Library/ROADMAP.md. Before this, the successor was recorded only in the closed task and in _active.md, so “where do I pick up project X?” had no answer.
/project-continue gains an ongoing branch. With no NEXT-STEPS.md, it resolves the task through the new project-now script and hands off to the real /task-continue or /task-start, so their gates still fire. With no active task, it creates one from the first unchecked ROADMAP item.
/task-complete Step 7b now covers KB-native projects too. It ticks the ROADMAP item, rewrites ## Now, adds a STATUS Recently done line, and verifies the result with project-now. Step 4c’s terminal option becomes “leave the project idle” for ongoing-project tasks, and option 2 is pre-filled with the next ROADMAP item.
/setup-ongoing-project gains ROADMAP/STATUS/UPGRADES templates (they were missing) and a KB-native mode.
Retrofit: ## Now blocks were added to the existing ongoing ROADMAPs, and the DASHBOARD rock links were repointed off task files.
Source: KB-OS-ongoing-project-continuation (design approved in SMART-DEBT-Strategies-Library round 9).

v5.8 Changes (2026-09-01)

The Path to Completion block is now documented in this system doc, not only inside the skills — new section above, schema SSOT stays /task-continue Step 6b. It existed since 2026-09-01 morning but lived entirely in five skill files, so it had no system-level definition to audit against.
Two new required blocks — Project SSOT (STATUS.md/ROADMAP.md, verified to exist, plus which single file is authoritative for oversight) and Related open tasks (every other open task in the same thread, bucketed startable now vs blocked on X, derived from prerequisites: frontmatter, ~5 max, placed below Then, in order so it can never compete with Now).
The block survives the hand-off — /task-complete Step 4c now writes it into the successor rebased (Now rewritten to the successor’s own next command; everything else carried forward) and /task-continue Step 4 reads and continues from it. Previously only the open items transferred; the route died with the parent.
Successor command is checked, not assumed — grep -c '^## Claude Response' <successor>: zero → /task-start, ≥1 → /task-continue. The first live hand-off pointed at /task-start for a task with two rounds, which /task-start’s own NEVER rule refuses.
Schema de-duplicated — task-start.md and project-continue.md restated the full schema and went stale the day it changed; both now carry a pointer plus the block list. /audit-skills Step 5b gains SSOT= and Related= columns to catch the next drift mechanically.
Source: sdc-sdapp-deploy-miniapp round 3 (Talbot’s review of the first live Continuation-Gate hand-off).

Survival audit, same day (round 4 — Talbot: “double-check that this result will survive the next stage in this project, and the next multiphase project”). Six further defects, all of which would have silently undone the above:

/project-start’s NEXT-STEPS template had no Path to Completion and a 1. placeholder — matching neither the old dash nor the current asterisk convention. Every new multiphase project opened with a routeless first round.
/project-task-complete’s phase-reset template used the corrupting - placeholder two lines below its own prose forbidding it, and carried no route. Since a phase boundary replaces NEXT-STEPS.md and the continuation gate is closure-only, the route died at every boundary with nothing to catch it.
/task-start never read ## Inherited from — a stub successor (Step 4c option 2) is opened with /task-start, so the inheritance fix only covered one of its two doors.
/task-compact didn’t protect the inherited section — the final round is copied verbatim so its own block was safe, but a top-of-file inherited block is exactly what a summarizer folds away.
/task-continue’s own Task File Format example used - and omitted the block — inside the file that is the schema SSOT, contradicting its own Step 6b. Agents copy examples, not prose.
The /audit-skills drift check structurally could not see any of it — its dashPH column requires backticks, so it only matched prose discussing the dash form. New badPH column greps bare placeholder lines in fenced templates; project-start added to the loop (five skills → six).
The three destruction points (successor hand-off, phase boundary, compaction) are now tabulated above rather than left implicit.
Checked and clean: /task-prep (appends and replaces only its own ## Context (Auto-Prepared) section — cannot damage an inherited block).

v5.7 Changes (2026-08-31)

The Continuation Gate — no task or project closes without a resolved successor. /task-complete gains a blocking Step 4c (unconditional, _tmp.md excepted): a successor that already exists and is verified on disk, a stub successor created during the close, or a terminal declaration with a required reason — recorded as the new continuation: frontmatter parameter. /project-task-complete Step 8 applies the same gate at project closure (phase boundaries exempt — the next phase is already named in ROADMAP/STATUS). /task-continue’s creep gate now requires options 2 and 3 to record the deferred remainder concretely, so the close-time gate has something real to carry.
Why, and why not a Project retrofit — two documented incidents (sdc-levpro-sdmath-complete closing with nothing tracking the UI port; the LevPro port reaching “dev scope complete” with no successor artifact). project-task-complete.md’s closure step had the identical hole, so promoting the work into a Layer-2 Project would not have prevented either — the missing thing was a close-time check, not a heavier construct.
Header/footer version corrected — both read 5.4 while this changelog already ran to v5.6, ~5 weeks of stale drift.

v5.6 Changes (2026-07-25)

Communication Style: two new rules — (1) every open question/decision for Talbot must be a Next Steps checkbox, never left in Summary prose only; (2) Next Steps items needing him to visit an external site must include the direct URL. Both from the same friction round: a question got buried in prose and a task (“confirm KOHO’s insurance”) lacked a link.
Commit-without-asking made explicit in Communication Style — commits were already pre-approved per AGENTS.md (2026-07-18), but task-file responses had been treating “commit the changes” as a Next Steps item awaiting Talbot’s go-ahead. Talbot: this is unnecessary friction. Skills should commit routinely once work is verified.

v5.5 Changes (2026-07-25)

Talbot Response format switched from numbered list to bullet list — inline responses under a Next Steps checkbox now use - instead of 1.. Obsidian renders a numbered sub-item (1. done) as flat, un-nested text under a completed/struck-through checkbox; a bullet (- ) renders as a proper nested list item. All task-file examples in this doc and the task-start skill’s placeholder-append instruction updated to match.

v5.4 Changes (2026-07-08)

Smart adaptive task template — new SMTM Task — Smart.md replaces the static SMTM Task.md as the auto-triggered Templater template. A wizard (tp.system.suggester) asks task type (Standalone / Ongoing repo-backed / Ongoing KB-native), focus, category, and risk; dept is auto-detected from the folder path. Outputs type-appropriate frontmatter and body structure in one step.
Templater regex trigger — switched from 6 per-folder mappings to a single file regex (.*/Tasks/.*) that auto-covers any current or future Tasks/ folder in the vault. No manual Templater config needed when adding new dept folders.
SMTM_System.md “Creating a New Task File” section updated to describe the wizard workflow and document both templates.

v5.3 Changes (2026-07-07)

Three Constructs overview added near the top — a Task/Project/Ongoing-Project comparison table now sits right after Summary/Description, before the Lifecycle diagrams. Previously the Ongoing Project construct wasn’t introduced until ~600 lines in, despite being one of three first-class constructs. Feedback: Talbot flagged this discoverability gap after closing ai-config-rules-upgrade.
“Handing a Task to a Dept Agent” workflow moved into SMTM_System.md — the full step-by-step (find owner → create task → describe work → dispatch → review/close) plus the worked monorepo-PWA example now lives in the Ongoing Projects section of this doc, the canonical guide. It previously lived only in Core/Processes/Projects/KB-OS/Ongoing-Projects.md, which is meant to be a pure registry — that file now points back here instead of duplicating process content (SSOT fix, not just a relocation).
Additive/reorganizing only — no lifecycle or frontmatter changes.

v5.2 Changes (2026-06-25)

Ongoing Project — third construct — evergreen, maintained efforts with no end state (KB-OS, ai-config, monorepo, web-deploy, my_backup) are now a first-class SMTM construct, distinct from finite Projects and Tasks. SSOT-by-type (repo vs KB dept folder); never in _WorkingOn/Projects/; a unit of work on one = a normal dept-routed task. Live registry: Core/Processes/Projects/KB-OS/Ongoing-Projects.md. Pilots: KB-OS (KB-native) + ai-config (repo).
Dept-based task routing — codified — single decision test for which Tasks/ folder a task belongs in: business-specific → <Biz>/<Dept>/Tasks/; cross-business/system with a clear Core dept → Core/<Dept>/Tasks/; vault-level/multi-dept → Core/_WorkingOn/Tasks/. ONE master tracker (Core/_WorkingOn/Tasks/_active.md), now grouped by dept.
Frontmatter additions — dept: (owning department; drives routing + tracker/Dashboard grouping), project-type: ongoing|finite (which construct the task serves), requires_approval: true|false (A1 Approvals-queue gate per CONSTITUTION).
_active.md — single vault-wide tracker, grouped by department.
Additive only — existing v5.1 Task and Project lifecycles are unchanged.

v5.0 Changes (2026-04-12)

Task frontmatter parameters — every task file can now carry self-describing metadata: date, model, model-type, task-type, risk, status, prerequisites, assignee
Status lifecycle — new ready status set by /task-prep; full flow: (blank) → ready → active → blocked → complete
New /task-prep skill — hydrates any task with full context before execution; stops and asks for clarification if objectives are ambiguous; both interactive and file-based clarification
Task-Brief-N-[descrip].md retired — replaced by Task-N-[descrip].md (a single file that becomes the brief once prepped by /task-prep)
/write-task-brief deprecated — use /task-prep instead
_tmp.md rule change — AI can read/write via /task-start _tmp.md; no longer fully AI-off-limits
File naming convention — task files use PascalCase.md (no date prefix); dates belong in frontmatter and log filenames
Tasks/_DASHBOARD.md — new Obsidian Bases view over task frontmatter; shows active queue, ready tasks, risk groupings, blocked tasks
Skills updated — /task-start reads frontmatter params, checks risk gate, sets status: active; /task-continue warns on stale context; /task-complete sets status: complete
Tasks-Template.md updated — frontmatter schema included; Claude/Talbot response terminology (replaces AI/Human)
Future: /task-QA skill — automated QA gate before task close (Phase 4, pending dog-fooding)

v4.1 Changes (2026-03-31)

Talbot Response format: inline numbered list items under Next Steps checkboxes (primary); ## Talbot Response section is catch-all only
task-continue and project-continue now read from ## Claude Response (not ## Talbot Response) to capture inline responses
Multi-KB skill sync documented: global ~/.claude/commands/ applies to all vaults automatically

v4.0 Changes (2026-03-24)

Added ROADMAP.md as project TOC (living document, two formats: Simple/Complex)
Two-tier project structure: Simple (<~10 tasks) and Complex (multi-phase with phases/ folder)
STATUS.md is now state-only: added “Current Phase” block; removed Key Decisions, Feedback, Notes/Blockers
NEXT-STEPS.md is phase-scoped: resets to template at every phase boundary via project-task-complete
project-task-complete is required at every phase boundary (not just end-of-session)
LESSONS.md review added to all project closures: identify CLAUDE.md/AGENTS.md promotion candidates
Task Brief format added (Task-Brief-N-[descrip].md with Agent used field for model tracking)
New /write-task-brief skill for external agent task brief creation
ROADMAP sync hook: PostToolUse on ROADMAP.md updates STATUS.md descriptions automatically
Added UPGRADES.md: ideas parking lot for discovered-but-uncommitted improvements
Added _DASHBOARD.md: optional Obsidian view layer (Dataview/Bases) over STATUS + task frontmatter
Added Dev Project Extras section: ARCHITECTURE.md + DESIGN.md responsibilities documented
Added Document Responsibilities table (single-responsibility per artifact)
Design spec (SMTM-v4-design.md) folded into this document and archived
Feedback moved from STATUS.md to NEXT-STEPS.md (Talbot Response)
Key Decisions moved from STATUS.md to LESSONS.md (process) or DESIGN.md (technical, dev projects)
LESSONS.md now captures process decisions and pivots (dev projects: DESIGN.md for technical decisions)
_active.md retained unchanged (cross-project task tracker, read at session start)

v3.4 Changes

Added NEXT-STEPS.md as the standard project conversation container (replaces ad-hoc task files for project-level dialogue)
Added archive/ subfolder to project structure for completed reference documents
Added /project-continue skill — mirrors /task-continue at the project level
Updated /project-start to create NEXT-STEPS.md and archive/ by default
Updated Project Lifecycle diagram to show NEXT-STEPS.md-driven cycle
Removed TASKS.md from required project files (use PLAN.md + task files instead)