"The PASIV device enables shared dreaming."
In Inception, the PASIV (Portable Automated Somnacin IntraVenous) device connects the team, enabling them to enter dreams together and extract what matters most. This tool does the same for your codebase - connecting your team of AI agents to extract working, tested, reviewed implementations from the seeds of ideas.
Solo dev workflow: specs → issues → TDD implementation → review → merge.
Every extraction needs a team. PASIV connects them:
| Role | What They Do | In PASIV |
|---|---|---|
| Dreamer | Explores possibilities, refines the vision | /brainstorm - Socratic design refinement |
| Extractor | Leads the operation, pulls value from the target | /kick - orchestrates the full flow |
| Architect | Designs the dream levels | /backlog - structures specs into issues |
| Forger | Transforms and adapts | /issue, /parent - shapes ideas into trackable work |
| Point Man | Handles the details | task-ops, git-ops, project-ops - the helpers |
| Chemist | Enables deep dreaming | TDD, verification, systematic debugging - the methodology |
| Fischer | Carries context between dreams | /handoff - structured session memory |
# Add the marketplace
/plugin marketplace add inceptyon-labs/PASIV
# Install the plugin
/plugin install pasiv@pasivPrefer a UI? Use TARS - a visual plugin manager for Claude Code:
- Browse and install plugins from a curated library
- Automatic update notifications
- Easy enable/disable without uninstalling
# Initialize PASIV in your project (interactive setup)
/pasiv init
# Refine a vague idea into a design
/brainstorm
# Stress-test an existing half-baked plan
/brainstorm rough-idea.md
# Parse a design/spec into issues
/backlog design.md
# Start working on an issue (full extraction)
/kick 42
# Work on the highest priority task
/kick next
# Save session context before ending
/handoff"You need the simplest version of the idea."
Run /pasiv init to configure PASIV for your project. The interactive wizard:
- Chooses your task backend — GitHub Issues, Beans, or local markdown
- Configures project board (GitHub) or hooks (Beans)
- Sets workflow toggles — plan approval, TDD, review, verification, plus opt-in extras (UI verify, smoke command, coordinator model, token report, auto-reflect)
- Creates project directories —
docs/handoffs/,docs/designs/,docs/scans/ - Writes
.pasiv.yml— your backend + workflow configuration - Appends PASIV rules to
CLAUDE.md— session start behavior, rules, directory map - Configures a design system (frontend projects) — discovers an existing doc, creates a starter from your codebase's tokens, or records the path you point it at
Already configured? Re-running /pasiv init offers Update mode: it asks only about settings missing from your current .pasiv.yml (new features since your last init) and patches them in — custom keys like model_routing and review.profiles are untouched.
PASIV supports pluggable task backends. Choose the one that fits your workflow:
| Backend | Best For | Storage | Dependencies |
|---|---|---|---|
| GitHub Issues | Team collaboration, CI integration | GitHub API | gh CLI |
| Beans | Solo devs, agent-native, version-controlled | .beans/ flat files |
beans CLI |
| Local Markdown | Zero dependencies, simple projects | docs/tasks/ files |
None |
No .pasiv.yml defaults to Local Markdown (zero-dependency). GitHub and Beans are opt-in via /pasiv init or .pasiv.yml.
| Level | Type | Scope | Example |
|---|---|---|---|
| Epic | Strategic | Multiple features, weeks/months | "User Authentication System" |
| Feature | Tactical | Single capability, days/week | "OAuth Login" |
| Task | Execution | Single work item, hours | "Create OAuth callback endpoint" |
| Command | Creates | Description |
|---|---|---|
/pasiv init |
Config | Interactive setup wizard |
/brainstorm |
Design doc | Socratic dialogue to refine ideas |
/brainstorm doc.md |
Design doc | Stress-test existing document |
/issue |
Task | Create single work item |
/parent |
Feature → Tasks | Create feature with task sub-issues |
/backlog |
Epic → Feature → Task | Parse spec into full hierarchy |
/kick 42 |
- | Full implementation flow for a specific task |
/kick next |
- | Work on highest priority ready task |
/handoff |
Handoff doc | Save session context for next session |
/reflect |
Memory / feedback | Persist durable facts, corrections, and reusable workflows from the session |
/review [profile] |
- | Review the diff at a depth — quick/standard/fast/deep/codex |
Standalone utilities live in the separate pasiv-extras plugin (/plugin install pasiv-extras@pasiv) so they don't load into every session: /repo-scan (security vetting), /repo-ready (first-push prep), /app-store-ready (submission validator + ASO), /de-vibe (strip AI tells), /nano-banana (image generation), /design-pipeline (PRD → finished UI design workflow).
"An idea is like a virus. Resilient. Highly contagious."
Choose your entry point based on what you have:
| You have... | Start with | Flow |
|---|---|---|
| Vague idea | /brainstorm |
→ design.md → /backlog → /kick |
| Half-baked plan | /brainstorm doc.md |
→ refined design → /backlog → /kick |
| Clear requirements | /backlog spec.md |
→ issues → /kick |
| Single task | /issue |
→ /kick 42 |
| Existing issue | /kick 42 |
(inline planning) |
| New project | /pasiv init |
→ configured and ready |
| End of session | /handoff |
→ context preserved |
flowchart LR
subgraph Ideation
A[Vague Idea] --> B["#47;brainstorm"]
C[Half-baked Plan] --> B
B --> D[design.md]
end
subgraph Planning
D --> E["#47;backlog"]
F[Clear Spec] --> E
E --> G[Issues]
H[Single Task] --> I["#47;issue"]
I --> G
end
subgraph Execution
G --> J["#47;kick"]
J --> K[Plan & Approve]
K --> L[TDD Implement]
L --> M[Review]
M --> N[Verify]
N --> O[Merge]
end
style B fill:#e1f5fe
style E fill:#fff3e0
style J fill:#e8f5e9
"What's the most resilient parasite? An idea."
Socratic design refinement - turn vague ideas into validated designs before writing code.
/brainstorm # Start from a vague idea
/brainstorm rough-plan.md # Refine existing document
| Phase | What Happens |
|---|---|
| 1. Understand | Read existing doc OR ask "What are you building?" |
| 2. Socratic Dialogue | One question at a time (5-10 questions) |
| 3. Explore Approaches | Present 2-3 options with trade-offs |
| 4. Present Design | 200-300 word chunks, validate each |
| 5. Document | Save to docs/designs/YYYY-MM-DD-feature.md |
| 6. Next Steps | Offer /backlog, /parent, or /issue |
- Clarifying: "Who will use this?" "What triggers this flow?"
- Challenging: "What if this fails?" "How does this scale?"
- Scoping: "Is X in scope?" "Can we defer Y?"
Output: Validated design document ready for /backlog
"You mustn't be afraid to dream a little bigger, darling."
/kick 42 # By issue number (GitHub) or bean ID (Beans)
/kick lensing-gc5o # Beans bean ID
/kick task-001 # Local task ID
/kick next # Highest priority ready task
- Detect backend (read
.pasiv.yml) - Load session handoff (if one exists in
docs/handoffs/) - Fetch task context — one
task-ops get-contextcall returns issue, parent, sub-issues, and sibling context (parent → autonomous flow) - Start baseline tests in the background — planning is read-only, so nothing waits on the suite
- Move to In Progress
- Load design system (if
area:frontendorarea:mobile) - Create plan → select review depth → wait for approval (large surfaces fan out parallel read-only scouts)
- Join the baseline — fix / proceed / cancel if it failed
- Implementation (Opus writes RED tests in-context; a fresh Sonnet implementer subagent does GREEN — keeps the coordinator lean; the next independent task's RED gets written while the current implementer runs, and fully independent tasks can run in parallel worktrees)
- Run tests (systematic debugging if failures)
- Code review (review profile, based on selection)
- Verification gate (checks run concurrently; Haiku fixes simple issues, escalates complex to Opus)
- Check off acceptance criteria
- Write handoff (if parent issue with remaining tasks)
- Merge to main, move to Done, close task — plus opt-in per-model token report and auto-reflect
During plan approval, select a review profile with smart recommendations based on size and security:
| Profile | Passes | When Recommended |
|---|---|---|
quick |
Sonnet | size:XS/size:S, trivial |
standard |
Opus → Codex | most changes (default) |
fast |
Opus ∥ Codex (concurrent) | same reviewer diversity, one round of wall-clock — no cascade |
deep |
Opus → Codex → Opus | size:L/size:XL, security-critical — final pass re-checks cumulative fixes |
Configurable in .pasiv.yml. See docs/reference/review-profiles.md.
"The dreamer can always remember the genesis of the idea."
PASIV enforces split-model TDD — the stronger model writes the spec, the cheaper model writes the code:
RED (Opus) → GREEN (Sonnet) → REFACTOR (Sonnet) → COMMIT → repeat
| Phase | Model | Why |
|---|---|---|
| RED (write test) | Opus | Tests ARE the specification. Stronger model writes better specs. |
| GREEN (write code) | Sonnet | Code is constrained by the test. Cheaper model follows the spec. |
| REFACTOR | Sonnet | Clean up while tests stay green. |
This is enforced by context isolation: the execute coordinator (Opus) writes the RED tests in-context, then dispatches a fresh Sonnet implementer subagent for GREEN/REFACTOR/COMMIT. The noisy edit-test-iterate loop runs in the subagent's window, so the coordinator stays lean (standard 200k) and the Sonnet workers stay on subscription.
Every dispatch carries an explicit contract — goal, in-bounds files (anything else returns BLOCKED instead of expanding scope), done-condition, and a ≤15-line report format. Failures climb an escalation ladder: one same-tier retry only when context was missing, then one tier up with both failure reports attached so the next model never rediscovers dead ends. Never a third attempt at the same tier, never a silent step down.
"Every dream has a foundation."
Before touching code, PASIV establishes a clean baseline — in the background:
- The suite starts when
/kickbegins and runs while planning happens (planning is read-only) - The result is joined after plan approval, before implementation
- If tests pass: continue. If tests fail: ask how to proceed (fix first, proceed anyway, or cancel)
This ensures you're not blamed for pre-existing failures, without paying the suite's wall-clock up front.
Before merge, fresh evidence is required. All applicable checks run concurrently first (wall-clock = slowest check, not the sum); anything that fails is then fixed serially with smart escalation:
Haiku handles:
- Running all checks (tests, build, lint, typecheck)
- Simple fixes (syntax errors, missing imports, lint auto-fixes)
- Max 2 simple fix attempts per check
Escalates to Opus when:
- Simple fixes don't work after 2 attempts
- Logic errors detected
- Complex debugging needed
The gate loops until all checks pass — no "should work" claims.
| Check | How It Works |
|---|---|
| Tests | Haiku runs → tries simple fixes → escalates to Opus if needed |
| Build | Same strategy - simple first, escalate if complex |
| Lint | Haiku auto-fixes (usually works) |
| TypeCheck | Simple types first, escalate if complex |
| Smoke | Opt-in: runs verify.command from .pasiv.yml if configured |
UI verification (opt-in): with workflow.ui_verify: true, frontend/mobile tasks get driven in the running app — launch, exercise the change, screenshot — before the gate. Enable per project in /pasiv init.
"Downwards is the only way forwards."
Nothing in the flow waits when it doesn't have to:
| Stage | What runs in parallel |
|---|---|
| Baseline | Test suite runs in the background while you plan; joined before code |
| Context fetch | Issue + parent + sub-issues + sibling context — one fork, not four |
| Planning | Large surfaces fan out parallel read-only scout subagents |
| Implementation | RED for the next independent task is written while the current implementer runs GREEN; fully independent tasks dispatch concurrently in isolated worktrees |
| Verification | Tests, build, lint, typecheck, smoke all run concurrently — wall-clock is the slowest check, not the sum |
| Review | fast profile runs both reviewers concurrently on the same diff |
The rules: read-only work fans out; anything that writes is serialized — never two writers on one file. Parallelism is the optimization, not the baseline: uncertain overlap means serial.
"We need to go deeper."
Reviews always happen at the Task level — Epics and Features are containers.
/kick on |
Behavior |
|---|---|
| Task | Implement → Review → Merge |
| Feature | For each Task: Implement → Review → Merge |
| Epic | For each Feature → For each Task: Implement → Review → Merge |
When you /kick an Epic:
Epic: User Authentication System
├── Feature: Email/Password Login
│ ├── Create user table → quick (size:XS, area:db)
│ ├── Create auth endpoint → deep (size:M) [security]
│ └── Create login form → standard (size:M, area:frontend)
│
└── Feature: OAuth Login
├── Add OAuth config → standard (size:S) [security]
└── Add OAuth callback → deep (size:M) [security]
Total: 5 Tasks across 2 Features
Approve and start autonomous run? [Yes/Customize/Cancel]
- Approve once, walk away — implements all Tasks autonomously
- Stops only on error — asks how to proceed
- Auto-closes Features when all their Tasks complete
- Auto-closes Epic when all Features complete
- Writes handoffs between tasks to preserve context
Task priority order:
area:db→area:infra→area:backend→area:frontend- Within same area:
priority:high→priority:medium→priority:low
When tests fail, root cause analysis is enforced:
- Investigate — Read full error, find root cause
- Hypothesize — Form specific theory
- Test — Make ONE minimal change
- Verify — Run tests again
Three Strikes Rule: After 3 failed fix attempts, stop and reassess.
"An idea is like a virus. Resilient. Highly contagious. And even the smallest seed of an idea can grow."
PASIV preserves session context through structured handoff files, inspired by the Claude Context OS pattern.
/handoff # Write handoff before ending session
| Trigger | What Happens |
|---|---|
You run /handoff |
Write session state to docs/handoffs/ |
| Context compaction | PreCompact hook reminds you to write handoff |
| Parent issue mid-flow | /kick auto-writes handoff between tasks |
| Next session start | /kick loads latest handoff, archives it |
- What was done (completed work)
- Exact numbers and metrics
- Decisions made (with rationale and alternatives considered)
- Open questions (UNCLEAR, ASSUMED, MISSING)
- Files changed and why
- What NOT to re-read
- Next steps and files to load
Handoffs live at docs/handoffs/handoff-YYYY-MM-DD-{topic}.md and are archived to docs/handoffs/archive/ after loading.
"You're asking me for inception."
Standalone utilities ship as a separate plugin so the core workflow stays lean — their descriptions aren't loaded into sessions that don't need them:
/plugin install pasiv-extras@pasiv| Skill | What it does |
|---|---|
/repo-scan |
Multi-ecosystem security vetting — CVEs, malware patterns, obfuscated code, secrets; PASS/CAUTION/FAIL report in docs/scans/ |
/repo-ready |
Prep for first GitHub push — README, LICENSE, community files, secret scan |
/app-store-ready |
Apple App Store submission validator + ASO/keyword optimizer |
/de-vibe |
Strip AI tells — de-slop docs, drop restate-comments, scrub trailers |
/nano-banana |
Image generation via Google Gemini (icons, logos, graphics) |
/design-pipeline |
Guided end-to-end design workflow — PRD/spec → brief → visual options → design system → build → anti-slop gate |
Enable/disable per project or on demand — the core pasiv plugin never depends on them.
Reviews run as profiles — an ordered chain of passes resolved by the review skill:
| Profile | Passes | When |
|---|---|---|
none |
— | skip |
quick |
Sonnet | trivial |
standard |
Opus → Codex | most changes (default) |
fast |
Opus ∥ Codex (concurrent) | speed over the second look — findings merged, fixed once |
deep |
Opus → Codex → Opus | security-critical / large — final pass re-checks cumulative fixes |
Passes are cascading (each sees prior fixes; fast trades this for wall-clock) and host-aware — a Claude subagent or the Codex MCP under Claude Code; claude -p (Claude-as-reviewer) or native under a Codex host. Configurable in .pasiv.yml. Standalone: /review [profile]. Full rule, schema, and adapters: docs/reference/review-profiles.md.
When /kick processes an issue labeled area:frontend or area:mobile, it loads your project's design system so implementation references established tokens (spacing, colors, typography) and patterns (buttons, cards, forms) instead of inventing new ones.
Resolution order:
.pasiv.ymldesign.system: <path>— points at any markdown doc- Common locations:
docs/design-system.md,design-system.md,DESIGN.md,.interface-design/system.md
Setup: /pasiv init (frontend = yes) discovers an existing doc and records its path — or offers to create a starter docs/design-system.md with token values pulled from your codebase (Tailwind theme, CSS variables, theme files), or lets you point to a path.
The interface-design plugin is supported as an optional provider — if installed, its init/audit commands are offered — but PASIV no longer requires it. See docs/reference/design-system.md.
/pasiv init writes two things to your project:
Task backend configuration:
# GitHub
task_backend: github
github:
project_board: true
# Beans
task_backend: beans
beans:
path: .beans
prefix: beans-
# Local (default)
task_backend: local
local:
path: docs/tasksWorkflow toggles and opt-in extras (written by /pasiv init, all extras default off):
workflow:
plan_approval: true
tdd: true
review: true
verification: true
ui_verify: false # opt-in: drive the app + screenshot for UI tasks before merge
auto_reflect: false # opt-in: run /reflect at finish when the task hit escalations,
# corrections, or review blockers — clean runs skip it
verify:
command: "npm run smoke" # optional: extra gate command, must exit 0
metrics:
tokens: true # opt-in: per-model token summary at finish,
# history appended to docs/metrics/tokens.jsonl
models:
coordinator: <frontier-model> # opt-in: a stronger model (when your plan has one)
# for frontier escalations + built-in review passes
design:
system: docs/design-system.md # opt-in: loaded for area:frontend / area:mobile tasksOperational behavior appended to your project's CLAUDE.md:
- Session Start — Load latest handoff, state understanding before starting
- Rules — Use PASIV skills, write state to disk, TDD enforced, verification gate
- Where Things Live — Directory map for handoffs, designs, plans, scans
This keeps PASIV context per-project. Projects without the PASIV section in CLAUDE.md are unaffected.
"I bought the airline."
The flow runs on Opus as a lean coordinator that dispatches Sonnet subagents for the heavy work; helper operations run on Haiku in forked contexts:
| Skill | Model | Operations |
|---|---|---|
kick |
Opus | orchestrator/router — setup + sequence the flow |
plan |
Opus | plan + native tasks (writing-plans rigor, ladder, gap check) |
execute |
Opus (coord) | writes RED in-context; dispatches a Sonnet implementer subagent for GREEN |
review |
Opus (coord) | per-pass reviewer-subagent / codex dispatch by profile |
finish |
Opus | completion summary, handoff, merge, close |
git-ops |
Haiku | branch, commit, push, merge |
task-ops |
Haiku | route to backend (issue-ops, beans-ops, local-ops) |
issue-ops |
Haiku | GitHub issue CRUD |
beans-ops |
Haiku | Beans flat-file CRUD |
local-ops |
Haiku | Local markdown CRUD |
project-ops |
Haiku | GitHub Project board operations |
test-runner |
Haiku | run tests, parse results, report |
handoff-ops |
Haiku | read/archive handoff files |
verification |
Haiku → Opus | simple fixes (Haiku), complex debugging (Opus) |
Split-model TDD: the execute coordinator (Opus) writes RED tests; a fresh Sonnet implementer subagent does GREEN in an isolated context — so the whole session stays in standard 200k.
Optional tier routing: plan tags tasks mechanical/standard/frontier; map them to per-host models in .pasiv.yml model_routing (e.g. mechanical → Haiku) and execute picks the cheapest-capable model per task. Dormant by default. See docs/reference/model-optimization.md.
Optional coordinator override: when your plan exposes a frontier model above Opus, models.coordinator routes frontier-tier escalations and the built-in review passes to it — delete the key when the model goes away and everything reverts.
Smart escalation: Verification starts with Haiku for simple fixes, escalates to Opus only when needed. Implementer failures climb the model ladder with their failure evidence attached.
Token accounting (opt-in): metrics.tokens: true prints a per-model in/out/cache summary at finish and appends history to docs/metrics/tokens.jsonl — parsed deterministically from session transcripts, zero model tokens spent.
| Category | Labels |
|---|---|
| Priority | priority:high, priority:medium, priority:low |
| Size | size:XS (<1h), size:S (1-4h), size:M (4-8h), size:L (8-16h), size:XL (16+h) |
| Area | area:frontend, area:backend, area:infra, area:db |
Note: Issue types (Epic, Feature, Task) use GitHub's native --type flag (GitHub backend) or the type field (Beans/local backends).
Issues are automatically added to a GitHub Project board (when using the GitHub backend).
- Auto-creates project named after your repo (on first
/issue,/parent, or/backlog) - Prompts if other projects exist (choose existing or create new)
- Status updates: Issues move to In Progress/Done automatically
- Prioritization:
/backlogoutputs suggested implementation order
gh auth refresh -s project| Backend | Requirements |
|---|---|
| All | Claude Code with plugin support |
| GitHub | gh CLI, jq |
| Beans | beans CLI (npm install -g @beans-lang/cli), jq |
| Local | None |
| Codex reviews | Codex CLI |
rm -rf ~/.claude/plugins/cache
claude plugin update PASIVhooks/
├── hooks.json # PreCompact hook config
└── pre-compact.sh # Reminds to write handoff before compaction
scripts/
├── init.sh # Project initializer (called by /pasiv init)
└── token-report.sh # Per-model token summary + history (called by finish)
skills/
├── pasiv-init/SKILL.md # /pasiv init (setup wizard)
├── brainstorm/SKILL.md # /brainstorm (Dreamer)
├── issue/SKILL.md # /issue (Forger)
├── parent/SKILL.md # /parent (Forger)
├── backlog/SKILL.md # /backlog (Architect)
│
│ # /kick flow — thin router + on-demand step-skills (Extractor)
├── kick/SKILL.md # orchestrator/router (Opus)
├── plan/SKILL.md # plan + native tasks (Opus)
├── execute/SKILL.md # RED in-context → Sonnet implementer subagent for GREEN (Opus coord)
├── review/SKILL.md # /review — profile-driven, host-aware (Opus coord)
├── finish/SKILL.md # merge / handoff / close (Opus)
│
├── handoff/SKILL.md # /handoff (Fischer)
├── handoff-ops/SKILL.md # Handoff file management (Haiku)
├── reflect/SKILL.md # /reflect (persist learnings to memory/skills)
│
├── using-pasiv/SKILL.md # Skill awareness guide
├── verification/SKILL.md # Verification gate (Haiku → Opus)
├── systematic-debugging/SKILL.md # Debug methodology (Opus)
│
├── task-ops/SKILL.md # Backend router (Haiku)
├── issue-ops/SKILL.md # GitHub backend (Haiku)
├── beans-ops/SKILL.md # Beans backend (Haiku)
├── local-ops/SKILL.md # Local markdown backend (Haiku)
├── git-ops/SKILL.md # Git operations (Haiku)
├── project-ops/SKILL.md # GitHub Project operations (Haiku)
└── test-runner/SKILL.md # Test execution (Haiku)
extras/ # pasiv-extras plugin — ad hoc utilities
├── .claude-plugin/plugin.json
└── skills/
├── repo-scan/ # /repo-scan (security vetting)
├── repo-ready/ # /repo-ready (first-push prep)
├── app-store-ready/ # /app-store-ready (submission + ASO)
├── de-vibe/ # /de-vibe (strip AI tells)
├── nano-banana/ # /nano-banana (image generation)
└── design-pipeline/ # /design-pipeline (PRD → finished UI)
docs/
├── reference/ # On-demand reference docs (loaded by skills)
│ ├── review-profiles.md
│ ├── design-system.md
│ ├── labels.md
│ ├── github-projects.md
│ └── model-optimization.md
├── designs/ # Design documents from /brainstorm
└── scans/ # Security scan reports
- Development methodology (TDD cycle, verification gates, systematic debugging) and brainstorming flow inspired by superpowers
- Subagent-driven execution, native-task, and model-tier routing patterns inspired by the Claude Code fork pcvelz/superpowers
- The
grill-meinterview pattern (recommend-an-answer, codebase-first) and handoff refinements (reference-don't-duplicate, suggested-skills) inspired by mattpocock/skills by @mattpocock - Over-engineering "ladder" (YAGNI, stdlib/native-first, no unrequested abstractions) for planning and implementation inspired by ponytail by @DietrichGebert
- Session handoff pattern and per-project CLAUDE.md structure inspired by Claude Context OS
- Beans flat-file task backend powered by beans by @hmans
- Design system integration powered by interface-design by @Dammyjay93
- Name and lore inspired by Christopher Nolan's Inception (2010)
"Do you want to take a leap of faith? Or become an old man, filled with regret, waiting to die alone?"
Connect to PASIV.
/kick next