work
Work: FSM Lifecycle Router (v3)
One entry point for all work. Concurrent FSM with PLANNING and EXECUTION phases. Guard scoring runs constantly (not as a gate). DISCOVER runs interview, memory prefetch, prior art, and search concurrently. Canonical lifecycle artifacts live under .lev/pm/*. The free-form exception is .lev/scratch/.
PLANNING PHASE EXECUTION PHASE
┌───────────────────┐ ┌───────┐ ┌──────────┐ ┌─────────┐ ┌──────┐ ┌─────────┐ ┌──────────┐ ┌──────┐ ┌───────┐
│ DISCOVER │──▶│ ALIGN │──▶│ RESEARCH │──▶│ PROPOSE │──▶│ SPEC │──▶│ EXECUTE │──▶│ VALIDATE │──▶│ EMIT │──▶│ LEARN │
│ (concurrent) │ └───────┘ └──────────┘ └─────────┘ └──────┘ └─────────┘ └──────────┘ └──────┘ └───────┘
│ │ north star deeper code CDO graph BDD + spawn layer-dep close cm outcome
│ ┌──────────────┐ │ ALIGN gate analysis 5-role contracts team/agents strictness files cm reflect
│ │ Interview(fg)│ │ classify C1-C4 map think accept. inline gates update br learning
│ │ PriorArt(bg) │ │ layers DoR compl. proposal criteria cm add status cass index
│ │ Search (bg) │ │ alignment file (learn)
│ └──────────────┘ │ verdict
│ │
│ ╔════════════════╗│ Guard is NOT a step -- it scores 6 categories every turn.
│ ║ GUARD(constant)║│ <=30% -> PASS | 30-60% -> ASK inline | >60% -> interview skill
│ ╚════════════════╝│
└───────────────────┘
On Load: Do This Immediately (Hard Contract)
- Detect tracker backend (
bd > br > td > none). - Resolve active workstream name from user request.
- Open or create active handoff file in
.lev/pm/handoffs/. - Record or confirm the long-term goal, done condition, roadmap, and current execution slice in the handoff.
- Initialize or update entity matrix.
- Initialize or update a tracker only for the current execution slice.
- Append current tick (
Tn) with objective and first evidence.
If step 3 fails, stop implementation work and create the handoff first.
Storage Boundary (Hard Contract)
The handoff is the canonical planning artifact.
Store in the handoff:
- long-term goal
- done condition
- roadmap
- deferred work
- evolving decisions
- open questions
- why the current execution slice exists
Trackers (bd, br, td) are execution-plane only.
Store in the tracker:
- the current execution slice
- active implementation task
- blockers on the current slice
- validation or closeout status
- evidence links
Never store long-term plans, end-state framing, or multi-session roadmaps in tracker title, description, or comments unless the user explicitly asks for duplication.
Before every tracker write, check:
- Is this only about the current execution slice?
- Would this still be valid if the long-term plan changed?
If either answer is "no", write it to the handoff instead.
PM Artifact Map (Hard Contract)
Template-backed lifecycle artifacts map 1:1 to .lev/pm/*:
| Artifact | Path | Template |
|---|---|---|
| Report | .lev/pm/reports/ |
templates/report.md |
| Proposal | .lev/pm/proposals/ |
templates/proposal.md |
| Design | .lev/pm/designs/ |
templates/design.md |
| Spec | .lev/pm/specs/ |
templates/spec.md |
| Plan | .lev/pm/plans/ |
templates/plan.md |
| Handoff | .lev/pm/handoffs/ |
templates/handoff.md |
| Decision | .lev/pm/decisions/ |
templates/decision.md |
| Validation Report | .lev/pm/validation-reports/ |
templates/validation-report.md |
The skill is self-documenting. Do not rely on companion README files for the contract.
Scratch Boundary (Hard Contract)
/.lev/scratch/ is the free-form exception outside the PM lifecycle tree.
Use scratch for:
- early theories
- partial notes
- temporary fragments
- speculative material not yet ready to become a PM artifact
Do not treat .lev/scratch/ as canonical planning state. Promote out of scratch into a PM artifact when the content becomes durable.
Template Loading (Hard Contract)
Always load:
templates/handoff.md
Load as needed:
templates/report.mdtemplates/proposal.mdtemplates/design.mdtemplates/spec.mdtemplates/plan.mdtemplates/decision.mdtemplates/validation-report.md
Template Authoring Rules (Hard Contract)
Every structured PM template must begin with a How To Fill This Out section.
That section must:
- explain the purpose of the template
- explain the purpose of each major section
- include good/bad examples
- explicitly allow uncertainty markers
Allowed uncertainty markers:
[tbd][unknown][theory][maybe: ..., confidence: ##%]
Quick Start
Use $work when you want one entry point for lifecycle-aware work:
work "analyze the current auth system"
work "design the new onboarding flow"
work "write a spec for deterministic callbacks"
work "plan the next implementation slice"
work "create a handoff for this session"
The first move is always:
- open or update the handoff
- capture or refine the goal/done condition/roadmap/current slice
- update the entity matrix
- route into the correct lifecycle behavior
Common Usage Patterns
Pattern 1: Research / Analysis
Use when you need to gather evidence or understand current state.
Examples:
work "analyze the current API architecture"work "research validation-gate patterns"work "scan the codebase for lifecycle drift"
Typical output:
- active handoff updated
- report artifact in
.lev/pm/reports/
Pattern 2: Design / Proposal
Use when you need to shape a solution, compare options, or define an interaction/system direction.
Examples:
work "design the callback routing surface"work "propose a PM-first docs promotion workflow"work "architect the work-mvp boundary"
Typical output:
- active handoff updated
- proposal or design artifact in
.lev/pm/proposals/or.lev/pm/designs/
Pattern 3: Spec
Use when you need an SDLC behavioral contract.
Examples:
work "spec the deterministic execution boundary"work "spec callback lifecycle semantics"
Typical output:
- active handoff updated
- spec artifact in
.lev/pm/specs/
Pattern 4: Plan / Current Execution Slice
Use when you need the concrete slice that is being executed right now.
Examples:
work "plan the bugfix slice for handoff sharding"work "plan the next implementation slice for work-mvp"
Typical output:
- active handoff updated
- plan artifact in
.lev/pm/plans/ - tracker updated only for the current execution slice
Pattern 5: Session Continuity
Use when you need to checkpoint or close a session.
Examples:
work "create a handoff for the work skill pass"work "close this session and capture next steps"
Typical output:
- handoff updated in
.lev/pm/handoffs/ - decisions promoted if warranted
- closeout/validation artifacts updated if the slice is done
Example Lifecycle
User request
-> $work loads/updates handoff
-> goal + done condition + roadmap captured
-> entity matrix updated
-> DISCOVER
-> ALIGN
-> RESEARCH
-> PROPOSE / DESIGN
-> SPEC or PLAN
-> EXECUTE
-> VALIDATE
-> EMIT updated PM artifact
-> LEARN / closeout
Concrete example:
work "research the current callback boundary"->.lev/pm/reports/...work "design the callback routing surface"->.lev/pm/designs/...work "spec the callback execution contract"->.lev/pm/specs/...work "plan the next implementation slice"->.lev/pm/plans/plan-impl-...work "create a handoff"->.lev/pm/handoffs/...
Troubleshooting
"I don't know what stage this is"
Start with:
- active handoff
- current execution slice
- current artifact
- entity matrix state
If still unclear:
- route to DISCOVER and gather more evidence
- do not skip straight to execution
"The tracker is getting roadmap text"
That is a contract violation.
Move long-term framing back into the handoff and keep the tracker scoped to the current execution slice only.
"I have an idea but it's not ready for PM"
Use .lev/scratch/ first.
Promote to a PM artifact only when it becomes durable enough to track through the lifecycle.
"This seems like design, spec, and plan at once"
Separate them:
- design = broad direction
- spec = SDLC behavioral contract
- plan = current execution slice
Canonical Naming (Hard Contract)
Use this filename format for handoffs:
{YYYYMMDD}-{workstream}-{component}-{slug}-session-{N}.md
Examples:
20260301-work-skill-core-reconstruction-session-1.md20260301-sdlc-docs-gates-audit-session-3.md
Rules:
session-1only whenpredecessor: null.- Continue an existing stream with
session-{N+1}. - Do not start a new
session-1for the same active stream unless explicitly requested.
Required Handoff Frontmatter
---
status: active | paused | completed
workstream: <slug>
component: <slug>
slug: <slug>
session: <N>
created_at: YYYY-MM-DD
predecessor: <filename.md | null>
confidence: 0.0-1.0
decisions_start: D<N>
---
Required Handoff Sections
Every active handoff must contain:
You Are HereNext Agent BriefRoadmap To GoalTimeline(tick log)Decisions LogOpen QuestionsEntity MatrixMeta
Required Next Agent Brief Fields
Every Next Agent Brief must state:
Long-Term GoalDone ConditionCurrent Execution SliceWhy This Slice NowOut of Scope This Session
Decision Promotion (Hard Contract)
Decisions stay in the handoff by default.
Promote a decision to .lev/pm/decisions/ only when it is:
- architectural
- reusable across sessions or workstreams
- policy-setting
- likely to be cited outside the originating handoff
Promoted decisions must:
- link back to the source handoff
- preserve the original rationale
- note whether the handoff copy is now superseded by the promoted ADR
Handoff Sharding (Hard Contract)
Update the handoff incrementally during the session. Before sharding, prune or compress irrelevant or resolved checkpoints first.
Shard to session-{N+1} when one or more of these conditions hold after consolidation:
- soft line cap: around 500 lines and unresolved context is still dense
- hard line cap: around 700 lines
- checkpoint pressure: another checkpoint would exceed 15
- entity pressure: more than 5 actively tracked entities
- complexity pressure: more than 3 major lifecycle phases or more than 2 major domain pivots
- depth pressure: entity-map or timeline growth makes recovery harder than a successor shard
Rules:
session-1only whenpredecessor: null- successor shards must link to the predecessor
- the old shard keeps historical breadcrumbs
- the new shard starts with compressed context, current entity state, and active next steps
Roadmap To Goal (Hard Contract)
The handoff must contain a rolling roadmap from current state to the done condition.
Scope
- The roadmap is a projection of remaining work, not a requirement to invent 10 steps.
- Maximum projection is 10 steps.
- If fewer than 10 steps remain, only list the real remaining steps.
- If remaining steps = 0, the work is in a done-candidate state and must enter reflection before close.
Required format
## Roadmap To Goal
**Goal**: <one-sentence end state>
**Done Condition**: <deterministic completion test>
**Remaining Steps**: <0-10>
### Step 1: <current execution slice>
- <1-10 concrete bullets>
- <only this step gets full detail>
- <include validation or exit criteria when useful>
### Steps 2-5 (Optional)
#### Step 2: <next phase>
- <1-3 bullets if needed>
#### Step 3: <next phase>
- <1-3 bullets if needed>
#### Step 4: <next phase>
- <1-3 bullets if needed>
#### Step 5: <next phase>
- <1-3 bullets if needed>
### Steps 6-10 (Optional)
6. <one-line future step>
7. <one-line future step>
8. <one-line future step>
9. <one-line future step>
10. <one-line future step>
Rules
- Only Step 1 may contain detailed execution bullets.
- Steps 2-5 are optional and medium-granularity only.
- Steps 6-10 are optional and one-line only.
- Do not invent filler steps to reach 10.
- Tracker items may only represent
Step 1unless a later step is explicitly pulled forward into the current execution slice. - When Step 1 completes, shift the roadmap forward and rewrite the new Step 1 in detail.
- When the goal or done condition changes, update the roadmap in the handoff before changing tracker scope.
- Later sessions should refine the goal and done condition when they become clearer; do not preserve session-1 wording if the work is now better understood.
Prompt-Stack Integration (Hard Contract)
Prompt-stack sessions are execution-plane tools, not planning artifacts.
When a workstream uses prompt stacks:
- the active handoff remains the planning source of truth
- prompt-stack step output should be recorded under
.lev/pm/reports/ - stack session progress does not replace handoff updates
- prior-art checks, alignment, BDD/spec deltas, and roadmap changes belong to the normal
worklifecycle, not to the stack wrapper
Use the global stack skill as the thin runtime wrapper.
Do not embed Leviathan-specific planning doctrine into prompt-stack wrappers when the same
rules already live here in work.
Task Tracker Adapter (bd | br | td)
The work skill is backend-agnostic for task tracking. Detect which tool is available and route through the adapter. Preference order: bd > br > td.
Detection
# Prefer bd (Go, auto-commit) > br (Rust, non-invasive) > td (Python, lightweight)
command -v bd && TRACKER=bd || { command -v br && TRACKER=br || { command -v td && TRACKER=td || TRACKER=none; }; }
Operation Map
| Operation | bd (preferred) | br (supported) | td (lightweight) |
|---|---|---|---|
| create | bd create --title="..." --type=task |
br create --title="..." --type=task |
td add "..." |
| list | bd list --status=open |
br list --status=open |
td / td -g {group} |
| search | bd search "{kw}" |
br search "{kw}" |
N/A (grep local) |
| show | bd show {id} |
br show {id} |
td {id} |
| update | bd update {id} --status=X |
br update {id} --status=X |
td {id} edit |
| close | bd close {id} |
br close {id} |
td {id} complete |
| deps | bd dep add {p} {c} |
br dep add {p} {c} |
N/A |
| ready | bd ready |
br ready |
N/A |
| sync | bd sync (auto-git) |
br sync --flush-only + manual git |
N/A (local SQLite) |
| epic | bd epic {id} |
br epic {id} |
N/A (use groups: td -g {epic}) |
Behavioral Differences
- bd sync auto-commits and pushes — no manual git needed
- br sync exports JSONL only — you must
git add .beads/ && git commitmanually - td has no sync/deps/ready — degrade gracefully (skip dep gates, no ready filtering)
Degradation Rules
When td is the only backend:
- Skip dependency-based gates (no
depsupport) - Skip
readyfiltering (list all open instead) - Map groups to epics (
td -g {epic-name}) - Search falls back to
td+ grep
When no tracker is available (TRACKER=none):
- Continue without task integration; note in artifact
- Prior art check skips BD/tracker queries
Tracker Write Rules (Hard Contract)
- Tracker title names the current execution slice, not the full program.
- Tracker description describes only what will be executed in this slice.
- Tracker may link to the handoff path for context.
- Tracker must not duplicate long-term roadmap text from the handoff.
- If tracker text starts reading like a roadmap, stop and move that text to the handoff.
Responsibility Boundary
levowns CLI/protocol routing only.workowns lifecycle-stage logic and artifact contracts.lev-builderowns build/migrate execution patterns.
Do not place artifact-format instructions in command shims. Keep format contracts in this skill and its templates.
Entity Lifecycle (7 States + Discarded Branch)
ephemeral → captured → classified → crystallizing → crystallized → manifesting → completed
↓ ↓ ↓ ↓ ↓ ↓ ↓
[scratch] [report] [report] [proposal or [spec or [handoff] [validation /
design] plan] promoted decisions]
↘ discarded
| Stage | Canonical Artifact | Sub-Skills | Keywords |
|---|---|---|---|
| ephemeral | None (brainstorm) | Inline | "explore", "brainstorm", "understand" |
| captured | .lev/pm/reports/ |
lev get, lev-research |
"get", "research", "analyze", "scan", "find", "lookup", "read", "ls" |
| classified | .lev/pm/reports/ + handoff updates |
work ALIGN gate, lev-portable |
"classify", "align", "categorize" |
| crystallizing | .lev/pm/proposals/ or .lev/pm/designs/ |
lev-cdo, lev-learn, thinking-parliament, ux |
"design", "propose", "architect", "learn", "guide me" |
| crystallized | .lev/pm/specs/ or .lev/pm/plans/ |
work, tracker |
"plan", "implement", "specify", "bugfix", "chore" |
| manifesting | .lev/pm/handoffs/ + active PM artifact |
Team coordination, tracker | "working on", "in progress" |
| completed | .lev/pm/validation-reports/ + optional .lev/pm/decisions/ promotion |
work close/reflect |
"done", "finished", "closed" |
| discarded | tombstone link | work guard + validation |
"discard", "drop", "reject" |
.lev/scratch/ is the free-form pre-artifact area. It is not a PM artifact class.
Shortcuts
| Key | Action | Route |
|---|---|---|
(l) |
Start learn interview | learn [context] |
(p) |
Start proposal | work --stage=crystallizing |
(u) |
Show update diff | work --stage=update |
(s) |
Browse skills | skills-db query (inline) |
(d) |
Design/UX hub | ux hub |
Operational Command Constellation
These are agent <-> human operational commands and aliases. Map them to root primitives, not ad-hoc flows.
Canonical source for CLI alias + FSM stage + schema handler mapping:
~/.agents/skills/work/references/command-matrix.md
| Command / Alias | Primitive | Route | Notes |
|---|---|---|---|
work |
lifecycle | work |
DISCOVER -> ALIGN -> route |
plan |
execution slice | work -> PLAN |
Canonical execution artifact under .lev/pm/plans/ |
spec |
sdlc-variant | work -> SPEC |
SDLC behavioral spec under .lev/pm/specs/ |
propose |
proposal | work -> PROPOSE |
CDO graph deliberation |
design |
design | work -> PROPOSE |
Design artifact under .lev/pm/designs/ |
tracker |
execution tracking | tracker (br/bd/td) | Task graph + status |
check |
validation | work VALIDATE |
Alignment, DoR, drift |
go |
execute | work -> EXECUTE |
Start manifesting |
handoff |
continuity | work EMIT |
Canonical checkpoint output |
exit |
session close | work EMIT -> LEARN |
Emit handoff + learn ceremony |
learn |
guided intake | lev-learn via DISCOVER |
Interview loop (foreground track) |
align |
alignment | work -> ALIGN gate |
North star check, drift detection |
workflow |
workflow mgmt | workflow |
List/create/run workflow skills |
skill |
skill ops | skill-builder or skill lookup |
Build/discover/install path |
ask, wiz |
wizard mode | interview via DISCOVER |
Guard >60% routes here automatically |
scan, security |
assurance | work VALIDATE |
Can route to specialist security skills |
daemon, daemons |
runtime ops | lev-core |
Operational status/health |
reflect |
learning | work LEARN |
cm reflect + update closeout artifacts |
External Context Primitive
Use lev get as the root external context-gathering primitive.
Compatibility note: if lev get is not available in the current CLI build, use lev find as a temporary alias.
Aliases that resolve here:
ls,read,search,find,lookup,scan,research,prior art
Progressive depth:
context-> current conversation/workspace statefs-> filesystem and local artifactstracker-> task graph and open work (br/bd/td)artifacts->.lev/pm/*lifecycle artifactsresearch-> external sources
Quick-Keyword Artifact/Action Glossary
| Keyword(s) | Stage | Artifact | Action |
|---|---|---|---|
| "get", "research", "analyze", "scan", "find", "lookup", "read", "ls" | captured | report | DISCOVER -> lev get (or lev-research for deep mode) |
| "align", "north star", "drift", "classify" | classified | report + handoff | ALIGN gate (embedded) |
| "design", "propose", "architect" | crystallizing | proposal or design | PROPOSE -> lev-cdo + ux when relevant |
| "learn", "guide me", "unstuck" | crystallizing | proposal or design | DISCOVER interview track -> PROPOSE |
| "specify" | crystallized | spec | SPEC -> SDLC behavioral contract |
| "plan", "implement", "bugfix", "chore" | crystallized | plan | PLAN -> current execution slice |
| "working on", "in progress", "handoff", "exit" | manifesting | handoff | EXECUTE -> EMIT |
| "done", "finished", "closed" | completed | validation report + optional decisions | EMIT -> LEARN |
| "reflect", "learnings", "retro" | completed (post-close) | handoff/meta | LEARN -> cm reflect + update closeout |
FSM States: PLANNING PHASE
DISCOVER -- Concurrent Context Gathering
DISCOVER is the entry point. It runs four tracks concurrently with a constant guard scoring function. All findings update the active handoff and, when durable enough, a report artifact under .lev/pm/reports/.
/work "{idea}"
│
▼
DISCOVER (concurrent, not sequential)
├── Interview (foreground)
│ └── Ask user questions, rolling bg research per question
├── Memory Prefetch (background)
│ └── cm context + cass search (workspace-first, global fallback)
├── Prior Art (background)
│ └── br search, lev get, cass search, tracker list
├── Search (background)
│ └── Codebase grep, online search, skill discovery
└── Guard (constant -- runs every turn, not a pre-step)
├── Score 6 categories: Objective, Scope, Constraints, Environment,
│ Dependencies, Success Criteria
├── Each scored: MISSING (full weight) | PARTIAL (half) | PRESENT (0)
├── Weights: Objective (20%), Scope (20%), Constraints (15%),
│ Environment (15%), Dependencies (15%), Success Criteria (15%)
│
├── Score <=30% -> PASS (sufficient, advance to ALIGN)
├── Score 30-60% -> ASK (structured questions inline)
└── Score >60% -> route to interview skill (wizard-mode)
Confidence formula:
base_confidence = 1.0 - (guard_score / 100)
layer_modifier: Site/Structure -0.1, Skin/Services +0.0, Space +0.05, Stuff +0.1
think_modifier: agreement >80% +0.1, 50-80% +0.0, <50% -0.1
final = base + layer_modifier + think_modifier
Memory prefetch runs as part of DISCOVER before heavy research fan-out:
| Step | Command | Policy |
|---|---|---|
| Procedural recall | cm context "{kw}" --workspace "$PWD" --limit 3 --history 1 --json |
Workspace-first |
| Episodic recall | cass search "{kw}" --workspace "$PWD" --json --limit 5 --max-content-length 180 |
Workspace-first |
| Global fallback | retry without --workspace only if low-signal workspace hits |
Fail-open |
| Injection budget | summarize to short bullets with provenance links | Keep compact |
Low-signal criteria (default): generic prompt, zero thinking signal, empty/weak workspace hits.
Skill discovery runs as part of the Search background track:
| Priority | Source | Path |
|---|---|---|
| 1 | Project-local skills | .claude/skills/, .agents/skills/ in project |
| 2 | Global canonical skills | ~/.agents/skills/ |
| 3 | Skills DB | ~/.agents/skills-db/ (use ~/.agents/lev-skills.sh discover) |
| 4 | POC skills | ~/lev/workshop/poc/skills/ |
| 5 | Polymath skills | ~/lev/workshop/intake/cc-polymath/skills/ |
Lookup Tool: Use ~/.agents/lev-skills.sh discover "{kw}" as the shared local discovery entrypoint. Use raw grep only for debugging.
Prior art search runs as part of the PriorArt background track:
| Source | Search Method |
|---|---|
| Tracker store | br search "{kw}" ; br list --label-any "{kw}" |
| Tracker tasks | $TRACKER list --status=open | grep -i "{kw}" ; $TRACKER search "{kw}" |
| Codebase & docs | lev get "{kw}" --scope=all --depth=research |
| CASS index | cass search "{kw}" --robot --limit 10 |
| Existing skills | lev get "{kw}" --scope=knowledge --depth=fs --pattern="SKILL.md" |
If substantial prior art found, present findings and ask:
- Review existing work?
- Extend existing work?
- Proceed with new work anyway?
Flexible ordering: Steps have dependency gates, not fixed sequence. If prior art returns empty fast, skip ahead. If interview reveals complexity, loop back. Guard score dropping below 30% unblocks ALIGN regardless of other tracks.
Skip guard when: Explicit file paths provided, multi-turn context established, --no-guard flag, or resuming from saved session.
Output: updated handoff + report artifact with discovery results, guard scores, and skill manifest.
ALIGN -- North Star Alignment
Check project alignment before deeper work. This is an embedded work gate. Use lev-align only for standalone deep-dive audits.
ALIGN:
├── North star exists?
│ ├── YES -> Compare current state to north star
│ │ └── Drift type? (Stale Docs | Product Pivot | Coverage Gap | Status Drift | Path Drift)
│ └── NO -> Deep research codebase -> define north star -> capture in handoff + report
├── Classify layers (lev-portable):
│ ├── Stewart Brand shearing layers: Site | Structure | Skin | Services | Space Plan | Stuff
│ ├── Depth: L0 (overview) -> L1 (structure) -> L2 (details) -> L3 (runtime)
│ └── Persistence: System graph (permanent) vs CDO graph (ephemeral)
└── Output: alignment verdict (aligned | drift | gap)
| Layer | Timescale | Risk | Examples |
|---|---|---|---|
| Site | Decades | High | DB schema, core model |
| Structure | 30-50y | High | Auth, API contracts |
| Skin | 20y | Medium | UI framework, design system |
| Services | 7-15y | Medium | CI/CD, monitoring |
| Space Plan | 3-7y | Lower | Routes, features |
| Stuff | Daily | Lowest | Copy, env vars |
If no alignment data exists, capture project context in the active handoff and a report artifact.
Execution tiers (determined by layer classification):
| Classification | Tier | Pattern |
|---|---|---|
| Stuff + L3 + CDO | Direct | Just do it |
| Space Plan + L2 | Brief | 5-bullet spec -> execute |
| Skin/Services + L1-L2 | Standard | Plan -> execute -> review |
| Structure + L1 | Deliberate | Proposal -> approval -> execute -> review |
| Site + L0-L1 | Formal | Proposal -> approval -> phases -> multi-gate review |
RESEARCH -- Deep Analysis
Deeper investigation informed by DISCOVER results and ALIGN verdict. Runs only when the task warrants it (skipped for Stuff/Space Plan tier).
| Activity | Method | Output |
|---|---|---|
| Code analysis | Read files, trace dependencies | Understanding of current state |
| Content review | Review prior art artifacts | Context for proposal |
| Design review | Architecture patterns, anti-patterns | Alignment assessment |
| C1-C4 mapping | Site/Structure layer analysis | Impact assessment |
| DoR completion | Fill remaining guard categories | Ready for PROPOSE |
Save to: .lev/pm/reports/ and update the active handoff.
Skip when: Guard score <=30% at DISCOVER exit AND layer is Stuff/Space Plan (tier Direct or Brief).
PROPOSE -- Solution Design
Draft a proposal using CDO graph deliberation. Uses 5-role Think (from lev-portable).
PROPOSE:
├── Think deliberation (5 roles, layer-weighted):
│ ├── Advocate, Critic, Systems Thinker, Pragmatist, Wild Card
│ ├── Layer weighting: Site/Structure -> heavy Critic + Systems Thinker
│ │ Stuff -> heavy Pragmatist + Wild Card
│ ├── Devil's advocate trigger when >70% agreement
│ └── Light mode (>=0.80 confidence): Advocate + Critic only
├── Draft proposal or design artifact
├── If ephemeral -> inline response + optional scratch note
├── If prior art exists -> extend, don't duplicate
├── Surface discovered skills:
│ ├── Pull skill manifest from DISCOVER Search track report
│ ├── If design/UX keywords detected -> propose loading `ux` hub
│ ├── Query local skills runtime: ~/.agents/lev-skills.sh discover "{topic}" --json
│ └── Include in dashboard footer (inline, does NOT block FSM)
Save to: .lev/pm/proposals/ or .lev/pm/designs/, plus active handoff updates.
Team structure (determined here, not in a separate PLAN step):
| Complexity | Signals | Strategy | Tool |
|---|---|---|---|
| Simple | Single file, one skill | Direct execution | None |
| Medium | 2-3 files, multiple skills | Parallel subagents | Task tool, 2-4 agents |
| Complex | Multi-file, cross-cutting | Formal team | TeamCreate + Task tool |
SPEC -- Behavioral Specification
Crystallize the proposal or design into a spec or a plan, depending on intent:
spec= SDLC behavioral contract under.lev/pm/specs/plan= current execution slice under.lev/pm/plans/
Use spec when defining target behavior and contracts.
Use plan when defining the current implementation / bugfix / research slice.
Specs must include: BDD scenarios (Given/When/Then), contracts, acceptance criteria, and validation boundaries. Plans must include: goal, done condition, execution steps, dependencies, and validation for the current slice.
PROPOSE Dashboard Footer
Every PROPOSE output ends with a structured footer. This is a display convention (not a gate). The agent renders it as markdown; the user responds with a number or letter shortcut.
---
🔨 **Work:** {stage} | 🎯 {layer} | 📊 Guard: {score}%
**Skills loaded:** {loaded_list}
**Available:** {available_count} more via skills-db
🪄 **Next:**
1. [s] Skills — browse/load from skills-db
2. [r] Research — deepen with lev-research
3. [p] Prior art — review tracker items and PM artifacts
4. Proceed to SPEC
5. All of the above
6. ⬅️ Back to DISCOVER
#### PM Artifact Promotion Path
The live lifecycle stays in `.lev/pm/*`.
Promotion rules:
1. Reports stay in `.lev/pm/reports/` unless later mined into proposals or decisions.
2. Proposals and designs may be promoted to `docs/_inbox/` when ready for manual review.
3. Specs remain operationally canonical in `.lev/pm/specs/` until explicitly promoted.
4. Plans remain operational in `.lev/pm/plans/` and do not promote directly to canonical docs.
5. Decisions may be promoted from the handoff to `.lev/pm/decisions/` when they become durable.
---
### SPEC ALIGNMENT — Hardening Pass Workflow
When `/work` detects a spec-alignment context (handoff with conflicts, hardening pass, spec rewrite request), it enters this sub-workflow instead of the standard PROPOSE→SPEC flow.
SPEC ALIGNMENT LOOP ┌──────────┐ ┌─────────┐ ┌───────────┐ ┌─────────┐ ┌──────────┐ ┌────────────┐ │ ANALYZE │──▶│ CAPTURE │──▶│ INTERVIEW │──▶│ REWRITE │──▶│ PLAN │──▶│ SCHEDULE │ │ (agents) │ │(handoff)│ │ (1-by-1) │ │ (spec) │ │(gaps) │ │ (tracker) │ └──────────┘ └─────────┘ └───────────┘ └─────────┘ └──────────┘ └────────────┘
#### Phase 1: ANALYZE
Launch 1-3 read-only agents per spec cluster to identify:
- spec-vs-reality conflicts
- spec-vs-spec conflicts
- missing sections
- cross-references and open questions
#### Phase 2: CAPTURE
Update the handoff with:
- numbered conflicts
- user direction and decisions
- open questions
- cross-cutting themes
#### Phase 3: INTERVIEW
Present conflicts to the user and log decisions immediately in the handoff.
#### Phase 4: REWRITE
Update specs to describe the TARGET system based on user decisions.
#### Phase 5: PLAN CREATE
For each approved implementation gap, create a plan artifact under `.lev/pm/plans/`:
- `plan-bugfix-*` for behavior mismatches or regressions
- `plan-chore-*` for cleanup or migration slices
- `plan-impl-*` for implementation slices
#### Phase 6: SCHEDULE
Once the plan is approved, create or update the tracker for the current execution slice only.
---
---
#### FlowMind Naming Structure & Config Keys
The `work` skill recognizes specific configuration keys for identifying specs and promoting them:
| Key | Value Pattern | Purpose |
|-----|---------------|---------|
| `naming_structure` | `flowmind` | Enforce `spec-{module}.md` naming |
| `filename_mask` | `core-*-mask` | Regex for validating core filenames |
| `spec_target` | `docs/specs/` | Target directory for promotion |
Example Config (`.lev/config.yaml`):
```yaml
work:
naming_structure: flowmind
filename_mask: "spec-.*\\.md"
spec_target: "docs/specs/"
Shortcut behavior:
- [s] -> ~/.agents/lev-skills.sh discover "{topic}" --json, present results, offer to cat SKILL.md
- [r] -> route to lev-research with current context
- [p] -> br search "{topic}" + cass search "{topic}"
---
## FSM States: EXECUTION PHASE
> **Note:** ROUTE and MANIFESTING are sub-operations within the EXECUTION PHASE, not distinct FSM states. The FSM states are the 7 states (+ discarded branch) in the diagram above. ROUTE selects which skill to invoke; MANIFESTING describes the handoff contract format.
### ROUTE -- Sub-Skill Routing
| Stage | Primary Skill | Secondary Skills | When |
|-------|--------------|------------------|------|
| **ephemeral** | None | `thinking-parliament` | Meta questions only |
| **captured** | `lev get` | `lev-research`, `deep-research` | Progressive context gathering |
| **captured** | `lev-research` | None | Deep research mode |
| **crystallizing** | `lev-learn` | `lev-cdo` | Guided intake when user invokes learn mode |
| **crystallizing** | `lev-cdo` | `thinking-parliament`, `work` alignment gate | Strategic design |
| **crystallizing** | `ux` | `lev-cdo`, `work` template routing | Product/design/UX shaping before spec |
| **crystallized** | `work` | tracker | Template-driven spec or plan authoring |
| **manifesting** | tracker | `work` handoff contract | Task tracking/coordination + handoff emission |
| **completed** | `work` | `cm`, `cass` | Closeout, reflection, and optional decision promotion |
Routing logic:
- `captured` + simple query → `lev get`; deep ambiguity or broad unknowns → `lev-research`
- explicit `learn` intent or underspecified request needing guided intake → `lev-learn` (proposal + handoff)
- `crystallizing` + product/design/UX framing needed → `ux` hub (routes to design-os, pencil, or pipeline)
- `crystallizing` + needs adversarial validation → `thinking-parliament` + `lev-cdo`; else → `lev-cdo`
- `crystallized` → route to the correct PM template (`spec`, `plan`, `design`, `proposal`) and tracker
- `manifesting` → tracker + mandatory handoff contract output
### MANIFESTING -- Handoff Contract (Required)
When emitting `handoff.md`, follow the checkpoint format contract below. This is the canonical handoff schema for continuity.
1. Write `3-15` checkpoints in chronological order.
2. For each checkpoint, use exactly one block type:
- `⚡ CHECKPOINT Progress`
- `📋 Code Context`
- `📋 User feedback / ADR created`
3. Across checkpoints, include:
- files worked on
- files loaded into context
- what was learned and why it matters
4. End with both:
- `System Prompt for Next Agent`
- `Context Confidence Score`
5. File location:
- `.lev/pm/handoffs/{YYYYMMDD}-{workstream}-{component}-{slug}-session-{N}.md`
6. Template source:
- `~/.agents/skills/work/templates/handoff.md`
7. Handoff must include:
- `You Are Here`
- `Next Agent Brief`
- `Roadmap To Goal`
- `Timeline`
- `Decisions Log`
- `Open Questions`
- `Entity Matrix`
- `Meta`
8. Promote non-ephemeral decisions to `.lev/pm/decisions/` when the promotion rule is met.
9. Shard the handoff when the documented sharding signals are hit and pruning no longer restores clarity.
### EXECUTE -- Spawn Workers
Based on PROPOSE and ROUTE outputs:
1. **Direct execution:** Load matched skill inline, execute in current context
2. **Ephemeral subagents:** Spawn via Task tool with skill content injected into prompt
- Each agent gets: task description + inlined skill content + workspace context
- Instruct agents to return manifest of files touched + executive brief
3. **Formal team:** Create team config, spawn via TeamCreate + Task tool
- Assign workstreams with skill-to-agent mapping
- Set dependency ordering between workstreams
#### Inline Learning Capture
During execution, immediately capture learnings that survive context compaction:
| Trigger | Command | Category |
|---------|---------|----------|
| Bug fixed | `cm add "{description}" --category bug --json` | bug |
| Gotcha discovered | `cm add "{description}" --category {cat} --json` | architecture, testing, tooling |
| Performance issue | `cm add "{description}" --category performance --json` | performance |
| Security concern | `cm add "{description}" --category security --json` | security |
Categories: `bug`, `performance`, `architecture`, `testing`, `security`, `workflow`, `tooling`
**Why inline:** Context compaction loses session details. `cm add` persists immediately to the playbook, surviving any compaction event.
### VALIDATE -- Quality Gates
> Full per-gate definitions (layer modulation, confidence routing, failure actions): `./references/gates.md`
#### Gate A: Preflight (before execute)
Must have:
- active handoff
- objective stated
- long-term goal recorded in handoff
- done condition recorded in handoff
- `Roadmap To Goal` present, with Step 1 matching the current execution slice
- at least one evidence reference
If a tracker exists:
- tracker scope matches the execution slice only
Else: block execution.
#### Gate Summary Matrix
| Gate | Transition | Severity | FORMAL Checks | DIRECT Checks | Confidence Skip |
|------|-----------|----------|---------------|---------------|-----------------|
| `gate:discover-align` | DISCOVER -> ALIGN | MANDATORY | 5/5 (strict) | 1/5 | >= 0.90 auto-pass |
| `gate:align-research` | ALIGN -> RESEARCH | CRITICAL | 7/7 | 2/7 | >= 0.90 skip to 3 |
| `gate:research-propose` | RESEARCH -> PROPOSE | MANDATORY | 6/6 | 1/6 | >= 0.90 skip to 1 |
| `gate:propose-spec` | PROPOSE -> SPEC | CRITICAL | 7/7 + human | 1/7 | >= 0.90 skip to 2 |
| `gate:spec-execute` | SPEC -> EXECUTE | CATASTROPHIC | 16/16 + human | 3/16 | Never fully skip |
| `gate:execute-validate` | EXECUTE -> VALIDATE | MANDATORY | 8/8 | 2/8 | >= 0.90 skip to 3 |
| `gate:validate-emit` | VALIDATE -> EMIT | CRITICAL | 10/10 + human | 1/10 | >= 0.90 layer-min |
| `gate:emit-learn` | EMIT -> LEARN | WARNING | 6/6 | 2/6 | >= 0.90 skip to 2 |
#### Confidence Routing Table
| Confidence | Gate Behavior |
|------------|---------------|
| >= 0.90 | Skip INFO + WARNING gates; execute MANDATORY+ only |
| 0.80 - 0.89 | Standard: all gates at their declared severity |
| 0.60 - 0.79 | All gates fire + deliberation mode (Think 5-role) required before PROPOSE |
| < 0.60 | All gates + extended checks + human review required before SPEC |
#### Backtracking Table
| Gate Failure | Backtrack To | Condition |
|-------------|-------------|-----------|
| `gate:discover-align` | DISCOVER | Insufficient context — re-interview or re-search |
| `gate:align-research` | ALIGN or DISCOVER | Misclassification or missing north star |
| `gate:research-propose` | RESEARCH | Insufficient depth — deepen analysis |
| `gate:propose-spec` | PROPOSE or RESEARCH | Think disagreement or alignment drift |
| `gate:spec-execute` | SPEC or PROPOSE | Missing sections or invalid contracts |
| `gate:execute-validate` | EXECUTE | Incomplete work — finish remaining items |
| `gate:validate-emit` | EXECUTE or VALIDATE | Test failures or visual validation failure |
| `gate:emit-learn` | EMIT (retry) | Write failure — never blocks LEARN |
**Max backtrack depth:** 3 consecutive failures at the same gate before escalating to human review.
#### CATASTROPHIC gate:spec-execute (Inlined — Never Skip)
The spec completeness gate has 16 checks and **cannot be degraded or bypassed** by any mechanism (confidence, layer, user override):
| # | Check | Pass Condition |
|---|-------|---------------|
| 1 | Spec file exists | `.lev/pm/specs/` contains the active spec artifact |
| 2 | Executive summary | Present and <= 3 paragraphs |
| 3 | Context defined | Existing state AND target state documented |
| 4 | BDD scenarios | Given/When/Then covering primary flows |
| 5 | Input/Processing/Output | I/P/O triples defined per scenario |
| 6 | Dependencies declared | All external deps with versions/contracts |
| 7 | Integration points | All integration boundaries documented |
| 8 | Breaking changes | Explicitly noted (even if "none") |
| 9 | Recommended skills | Execution skills listed |
| 10 | Team structure | Team + workstreams if complexity > Simple |
| 11 | Unit test cases | Test cases defined |
| 12 | Integration tests | Integration test scenarios |
| 13 | E2E verification | E2E verification command specified |
| 14 | Success criteria | Measurable criteria with acceptance thresholds |
| 15 | BD tasks created | Spec decomposed into BD epics/tasks |
| 16 | Rollback plan | How to undo if execution fails |
**Layer modulation:** FORMAL = all 16 + human sign-off; DIRECT = checks 1, 3, 14 only. See `./references/gates.md` for full per-tier breakdown.
**Failure:** CATASTROPHIC BLOCK. List every failing check with remediation. Return to SPEC. After 3 consecutive failures, escalate to human. Never auto-waive. Never skip. Never degrade severity.
#### Gate C: Validate Before Close
Must have:
- validation evidence recorded
- open blockers listed or resolved
- next action clear, or explicit `done confirmed` from Done Candidate Protocol
- reflection completed if work is in done-candidate state
Else: block close.
### EMIT -- Create or Update PM Artifact
Create or update the stage-appropriate PM artifact and keep the active handoff in sync.
| Stage | Canonical Path | Action |
|-------|----------------|--------|
| captured | `.lev/pm/reports/` | Create or update report |
| crystallizing | `.lev/pm/proposals/` or `.lev/pm/designs/` | Create or update proposal/design |
| crystallized | `.lev/pm/specs/` or `.lev/pm/plans/` | Create or update spec/plan |
| manifesting | `.lev/pm/handoffs/` | Update handoff |
| completed | `.lev/pm/validation-reports/` | Create validation report or closeout evidence |
Always update the active handoff when emitting any PM artifact.
### LEARN -- Session Close Ceremony
Final FSM step. Reflects on the session, records outcomes, updates the handoff, and optionally promotes durable decisions.
**Triggers:** Session end, `/handoff`, `/exit`, explicit `learn` close request.
#### Steps
1. **Record outcomes** for rules used this session:
```bash
cm outcome {success|failure|mixed} {bullet-ids} --session $SESSION --json
-
Add new learnings not captured inline during EXECUTE:
cm add "{learning}" --category {category} --json -
Reflect on session (extract patterns):
cm reflect --days 1 --json --dry-run # Review proposed rules. If good: cm reflect --days 1 --json -
Promote durable decisions from the handoff if needed:
- create ADR-style documents in
.lev/pm/decisions/ - link back to the source handoff
- create ADR-style documents in
-
Index session for future search:
cass index
Skip Conditions
- Ephemeral/brainstorm sessions (no learnings to record)
- Session < 5 minutes (insufficient depth)
- User flag:
--no-learn
Session Close Checklist
- Final handoff update (entity matrix, decisions, ticks, open questions).
- Mark session status (
activeorcompleted). - Record next concrete action in
Next Agent Brief. - If code changed, run applicable validations and record evidence.
- Verify tracker text still describes only the execution slice; move any long-term framing back to the handoff.
Done Candidate Protocol (Hard Contract)
"Done" must be deterministic.
A workstream is not done because implementation appears complete. A workstream is done only when the done condition is satisfied and the reflection pass finds no material gaps.
Trigger
Run this protocol whenever:
Remaining Steps = 0, or- the agent believes the current workstream may be complete
Required reflection
Before marking a handoff completed, the agent must:
- Review the current handoff.
- Review all predecessor handoffs in the same workstream.
- Produce a full status report and alignment check against:
- goal
- done condition
- roadmap
- decisions log
- open questions
- validation evidence
- Record:
- lessons learned
- gaps or misses discovered during reflection
- whether any pattern, command, template, or rule should be promoted into a skill or AGENTS.md
- Decide:
done confirmed, ornot done
If reflection finds gaps
- Do not close the workstream.
- Update the handoff roadmap with the newly discovered remaining steps.
- Re-enter the lifecycle at the appropriate stage.
- Record a tick explaining why the done-candidate failed.
If reflection confirms done
- Mark the handoff
completed. - Record the deterministic evidence that satisfied the done condition.
- Record any skill-promotion or process-promotion recommendations.
Rule
Assume reflection will often find something. The purpose of the done protocol is to reveal misses before close, not to justify closing.
Integration Points
Lev Master Router
| Keywords | Route |
|---|---|
| get, search, find, lookup, read, ls, prior art | lev get |
| plan, design, build, research, analyze | work |
| learn, guide me, unstuck | work (lev-learn mode) |
| ask, wiz, wizard | work (learn/interview mode) |
| align, check, scan, security | work (validation gates) |
| workflow, workflows | workflow (create/list/run only) |
| execute, do it, run | work (routes to execute path; work-mvp is phase 2 execution binding) |
| install, setup, daemon, daemons | lev-core |
Tracker Integration (br/bd/td)
- trackers represent the current execution slice only
- specs and plans may link to tracker items
- prior art checks may query the tracker
- completion closes slice-scoped tracker items only
Team Mode
- Detect
variant.jsonswarmModeEnabled: trueor team keywords - Use template-driven decomposition and explicit subagent routing
- Keep the handoff and entity matrix as the orchestration spine
Error Handling
| Error | Severity | Response |
|---|---|---|
| Confidence < 0.7 | WARN | Prompt user to clarify: research / design / spec / plan / handoff |
| Tracker not available | INFO | Continue without task integration; note in the handoff |
| Template missing | ERROR | Block artifact creation until the correct PM template exists |
| Tracker-plan boundary violated | ERROR | Rewrite tracker to execution-slice scope, record correction in handoff |
| Spec validation fail | CATASTROPHIC | Block manifesting transition; list missing sections |
| Done claimed without reflection | ERROR | Run Done Candidate Protocol, update roadmap if gaps found, block close |
| Skill discovery empty | INFO | Proceed with inline execution; no skill injection |
learn helper missing |
WARN | Run inline interview loop in work; still emit proposal + handoff |
| CM/CASS not available | INFO | Skip LEARN ceremony; note in output |
Configuration
| Env Var | Default | Purpose |
|---|---|---|
LEV_PM_REPORTS |
.lev/pm/reports/ |
Report output dir |
LEV_PM_PROPOSALS |
.lev/pm/proposals/ |
Proposal output dir |
LEV_PM_DESIGNS |
.lev/pm/designs/ |
Design output dir |
LEV_PM_SPECS |
.lev/pm/specs/ |
Spec output dir |
LEV_PM_PLANS |
.lev/pm/plans/ |
Plan output dir |
LEV_PM_HANDOFFS |
.lev/pm/handoffs/ |
Handoff output dir |
LEV_PM_DECISIONS |
.lev/pm/decisions/ |
Decision output dir |
LEV_PM_VALIDATION_REPORTS |
.lev/pm/validation-reports/ |
Validation report output dir |
LEV_SCRATCH |
.lev/scratch/ |
Free-form scratch area |
Stage override: work --stage={ephemeral|captured|crystallizing|crystallized|manifesting}
Principles
- Progressive Disclosure -- Start simple, add complexity as needed
- Fail Gracefully -- Degrade when dependencies missing, don't block
- Validate Early -- Check spec, prior art, alignment before proceeding
- Route, Don't Duplicate -- Delegate to specialists, don't re-implement
- Context-Aware -- Use workspace, artifacts, BD state for decisions
- Specs Drive Tests -- Behavioral specs produce testable contracts
- Teams Scale Work -- Match execution strategy to task complexity
- Learn Continuously -- Capture learnings inline during execution; ceremony at session close
Relates
Master Router
- Lev Master Router (
lev/SKILL.md) -- Routes all lev-* skills and work skill. Parent skill that dispatches to this skill for work requests.
Related Skills
lev-research-- Orchestrated research (DISCOVER + RESEARCH stages)lev-cdo-- Strategic design playbook (PROPOSE stage)lev-learn-- Guided interview intake to proposal (DISCOVER foreground track)lev-align-- Optional standalone drift-audit deep dive (ALIGN defaults to embedded work gate)lev getbackend (lev-findlegacy alias) -- Semantic context gather (DISCOVER background track)br/bd/td-- Task tracking via adapter (SPEC -> EXECUTE)cm-- Collective memory playbook (EXECUTE inline + LEARN ceremony)cass-- Content-addressable session search (DISCOVER + LEARN)
Templates & References
./templates/report.md./templates/proposal.md./templates/design.md./templates/spec.md./templates/plan.md./templates/handoff.md./templates/decision.md./templates/validation-report.md./references/gates.md— Full per-gate definitions (layer modulation, confidence routing, failure actions)
Status: v3.4.0 -- PM-first lifecycle contract, 1:1 .lev/pm template mapping, handoff bootstrap + sharding + decision promotion, plan restored as canonical execution artifact
Technique Map
- Role definition - Clarifies operating scope and prevents ambiguous execution.
- Context enrichment - Captures required inputs before actions.
- Output structuring - Standardizes deliverables for consistent reuse.
- Step-by-step workflow - Reduces errors by making execution order explicit.
- Edge-case handling - Documents safe fallbacks when assumptions fail.
Technique Notes
These techniques improve reliability by making intent, inputs, outputs, and fallback paths explicit. Keep this section concise and additive so existing domain guidance remains primary.
Prompt Architect Overlay
Role Definition
You are the prompt-architect-enhanced specialist for work, responsible for deterministic execution of this skill's guidance while preserving existing workflow and constraints.
Input Contract
- Required: clear user intent and relevant context for this skill.
- Preferred: repository/project constraints, existing artifacts, and success criteria.
- If context is missing, ask focused questions before proceeding.
Output Contract
- Provide structured, actionable outputs aligned to this skill's existing format.
- Include assumptions and next steps when appropriate.
- Preserve compatibility with existing sections and related skills.
Edge Cases & Fallbacks
- If prerequisites are missing, provide a minimal safe path and request missing inputs.
- If scope is ambiguous, narrow to the highest-confidence sub-task.
- If a requested action conflicts with existing constraints, explain and offer compliant alternatives.