# Stack

> Use when listing, inspecting, running, or managing prompt-stack sessions. Triggers on "stack", "list stacks", "show stack", "init stack", "run stack", "stack status".

- Skill: `lev-os/stack` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lev-os/stack`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lev-os/stack/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: lev-os (https://skillmd.com/u/lev-os)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/lev-os/stack

---


# Stack

Thin launcher for the prompt-stack runtime at
`$HOME/digital/leviathan/plugins/prompt-stack`.

Runtime ownership stays with the plugin. This skill teaches agents how to
call it correctly and present results as a dashboard, not raw JSON.

## Autopilot Rule

When the user says `/stack next`, treat it as an autopilot command, not a checkpoint request.

- Prefer the most recent active session for the current project before initializing a new stack.
- If an active session exists:
  1. run `next` or `status` to confirm the true active step
  2. finish that step
  3. run `record`
  4. immediately follow the CLI response
  5. continue until the stack completes or a real blocker occurs
- Do not stop after each successful step to ask for permission to continue.
- Send short progress updates, but keep the session moving.

Only stop for:
- missing required artifact or context that cannot be inferred from disk
- contradictory session state after re-checking with `status`
- failed `record` that cannot be corrected locally
- a true product decision that is not covered by existing plan/spec/proposal artifacts

## Run Modes

Once launch is approved, do not ask again until completion or blocker.

- `foreground` = current agent/session drives the run in-process through the returned CLI contract
- `background` = detached execution managed by prompt-stack and `lev exec`
- chained runs continue across stacks without stopping
- blockers come from merged runtime + project + invocation policy

## Hard Rules

- Respect the chosen run mode after launch approval.
- Never ask “should I continue?” after go.
- Stack session serialization stays single-writer per session.
- Git checkpoint serialization stays single-writer per repo through `.lev/steering/checkpoint.lock`.
- Use the prompt-stack checkpoint helper, not ad hoc repo-local scripts.

## Checkpoint Mode

Use the canonical prompt-stack helper layer when multiple runs share one repo and need serialized git checkpoints:

```bash
cd $HOME/digital/leviathan

prompt-stack checkpoint-lock status --project-dir <path>
prompt-stack checkpoint-lock acquire --project-dir <path> --owner-tag <tag>
prompt-stack checkpoint-lock release --project-dir <path> --owner-tag <tag>
```

Rules:

- concurrent prompt-stack runs keep runtime state under `.lev/steering/runs/<run-id>/...`
- git checkpointing is serialized through `.lev/steering/checkpoint.lock`
- dirty worktrees are warning-only, not automatic blockers

## Session Serialization

A stack session is single-writer state.

- Never run `next`, `record`, `status`, or `validate` in parallel against the same session.
- Always use this order:
  1. `status` or `next`
  2. do the step work
  3. `record`
  4. `status` or `next` again
  5. repeat
- After any interruption, timeout, or aborted turn, re-run `status` and trust the session file over memory.

## Dashboard Mode (`/stack list`)

When the user says `/stack list`, do NOT dump raw JSON. Instead:

1. Run `cd $HOME/digital/leviathan && bun plugins/prompt-stack/src/cli.ts list`
2. Parse the JSON response
3. Format as a grouped dashboard — one line per stack:

```
━━━ CORE-LEV (9 stacks) ━━━

  handoff              (4 steps)  gather → distill → write → validate
  lev-align            (4 steps)  load north-star → inspect → classify drift → propose action
  plan-align-gates     (5 steps)  governance → refresh plan → align canon → gates → emit proposal
  research-propose-spec(3 steps)  research evidence → proposal synthesis → spec crystallization
  validate-emit-learn  (4 steps)  review artifacts → validate → emit → capture learnings
  work-deepen          (5 steps)  decompose → discover skills → parallel research → review → brief
  work-full-lifecycle  (9 steps)  governance → plan → align → gates → proposal → review → validate → emit → learn
  work-proof-loop      (3 steps)  handoff update → spec delta → validation report
  robot-readme-harden  (3 steps)  robot-mode hardening → cli error tolerance → readme sync

━━━ JEFF (5 stacks) ━━━

  jeff-delivery-loop   (10 steps) primer → ideation → synthesis → premortem → robot → cli → readme → review → e2e → commit
  jeff-ideation-risk   (4 steps)  idea wizard → multi-model synthesis → premortem → readme
  jeff-primer-quality  (4 steps)  deep primer → e2e validator → peer review → bug hunter
  jeff-quality-gauntlet(5 steps)  bug hunter → peer review → e2e → deploy verify → de-slopify
  jeff-robot-launch    (4 steps)  robot-mode → idea wizard → readme → git commit

━━━ SDLC (7 stacks) ━━━

  sdlc-deepen-plan     (3 steps)  decompose → parallel research → synthesize
  sdlc-exec-validate   (3 steps)  implement → fitness functions → route verdict
  sdlc-handoff-close   (4 steps)  verify handoff → extract decisions → approve → process
  sdlc-handoff-rollup  (4 steps)  scan unprocessed → pick one → extract all → process items
  sdlc-hygiene         (4 steps)  scan staleness → check alignment → propose updates → report
  sdlc-plan-to-beads   (5 steps)  extract items → create issues → review pass 1 → pass 2 → pass 3
  sdlc-spec-lifecycle  (5 steps)  validate completeness → check transition → quality gates → route → approve/iterate

━━━ OTHER ━━━

  knowledge-6r         (6 steps)  record → reduce → reflect → reweave → verify → rethink
  drift-detection      (5 steps)  positive drift → negative → undocumented → stale → alignment
  spec-driven-dev      (5 steps)  detect divergence → classify → push/pull → arbitrate → sync
  cass-cm-audit        (6 steps)  health check → memory scan → playbook audit → gap analysis → reindex → report
  research-worker      (3 steps)  orient → research rounds → synthesize
```

4. After the full list, add context-aware suggestions:

```
━━━ SUGGESTED FOR CURRENT CONTEXT ━━━

Based on: {describe what you detected — active handoff, case folder, recent work}

  (1) {stack-id}  — {why this stack fits right now}
  (2) {stack-id}  — {why}
  (3) {stack-id}  — {why}

  (s)how <id>  — Inspect a specific stack
  (r)un <id>   — Init a session immediately
```

Context detection rules:
- `.lev/osint/` exists → suggest `research-worker`, `work-deepen`
- `.lev/pm/handoffs/` has unprocessed handoffs → suggest `sdlc-handoff-rollup`
- Conversation mentions case/legal/research → suggest `jeff-ideation-risk`, `research-propose-spec`
- Recent code changes or implementation work → suggest `jeff-quality-gauntlet`, `sdlc-exec-validate`
- Session ending or handoff requested → suggest `handoff`, `validate-emit-learn`
- First time seeing the stacks → suggest `work-deepen`, `jeff-ideation-risk`, `sdlc-exec-validate`

## Commands

```bash
cd $HOME/digital/leviathan

# List (then format as dashboard above)
bun plugins/prompt-stack/src/cli.ts list

# Inspect (show steps, schemas, no hidden prompts)
bun plugins/prompt-stack/src/cli.ts show <stack-id>

# Init session
bun plugins/prompt-stack/src/cli.ts init --stack <stack-id> --project-dir <path>

# Get active step prompt
bun plugins/prompt-stack/src/cli.ts next --session <id> --project-dir <path>

# Record step output (validates and advances)
bun plugins/prompt-stack/src/cli.ts record --session <id> --step <step-id> --report <path> --project-dir <path>

# Check progress
bun plugins/prompt-stack/src/cli.ts status --session <id> --project-dir <path>

# Validate completed session
bun plugins/prompt-stack/src/cli.ts validate --session <id> --project-dir <path>
```

## Workflow

1. `/stack list` → dashboard with suggestions
2. User picks a stack (by number or name)
3. `init --stack <id>` → creates session
4. `next --session <id>` → reveals active step prompt
5. Agent does the work, writes report matching schema
6. `record --session <id> --step <step-id> --report <path>` → validates + advances
7. Repeat 4-6 until all steps complete
8. `validate --session <id>` → checks lifecycle integrity

For `/stack next`, steps 4-8 are one continuous autopilot loop. Do not pause between them unless blocked.

## Skill Discovery Integration

Before executing the first step of any stack, run `lev-skills <domain>` to surface
relevant skills from the skills-db. The domain is inferred from context:

- Stack family `legal-osint` → `lev-skills legal`
- Stack family `sdlc` → `lev-skills sdlc`
- Stack family `jeff` → skip (jeff prompts are self-contained)
- Active case folder detected → `lev-skills` with case domain keywords
- Unknown → `lev-skills` with the stack's `title` as query

Inject discovered skill names + one-line descriptions into the first step's context.
Workers then know what specialized skills are available during execution.

## Operator Notes

- Always use absolute paths for `--project-dir` and `--report`
- Session state lives in `<project>/.lev/steering/sessions/`
- `record` REJECTS invalid reports — fix and re-submit
- Report format: YAML frontmatter + required sections (varies by stack)
- If part of active `$work` handoff, keep planning there — stack is execution only
- If the stack is being used inside active `$work`, stack state is **not** the only artifact. You must also persist the corresponding disk-backed `work` template artifact:
  - planning / execution slice -> `.lev/pm/plans/plan-*.md`
  - research lane -> `.lev/pm/reports/report-*.md`
  - shaping / architecture lane -> `.lev/pm/designs/*.md`, `.lev/pm/proposals/*.md`, or `.lev/pm/specs/*.md`
- For large or multi-workstream implementation planning, route through `writing-plans` and split independent workstreams into separate plan files. Do not keep one thin coordination plan where the actual execution detail belongs in child plans.
- A good default: stack session for runtime state, `work` artifact for durable repo state, handoff for continuity. All three should agree.
- For subagent orchestration: `plugins/prompt-stack/references/subagent-contract.md`

## References

- CLI: `plugins/prompt-stack/src/cli.ts`
- Catalog: `plugins/prompt-stack/prompts/prompt-stack.prompts.yaml`
- Subagent contract: `plugins/prompt-stack/references/subagent-contract.md`
- FlowMind path (optional): `plugins/prompt-stack/flows/prompt-stack.flow.yaml`