sebastians1999/bean-stack
Bean Stack is Sebastian Schmülling's lean fork of pstack (MIT, Lauren Tan). Concise, verified implementation work, with one code-writing subagent.
Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.
Use for "automate me", "create/update/refresh my -mode skill", "turn/capture my preferences or working style into a skill", or wanting agents to follow how the user works. Drafts or revises a personal -mode skill via create-skill + unslop, optionally pulling fresh evidence from recent transcripts.
Use for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Use why for motivation.
Spawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints.
Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI, config, network, external APIs); trust internal types and keep business logic in pure functions.
Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text.
Apply when debugging. Trace each symptom back to the first place the system went wrong and fix it there. A guard is a fix only when the state it handles is legitimate.
Apply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share. Get the data structures right so downstream code becomes obvious.
Apply when refactoring, evaluating diff size, or tempted to add abstractions, layers, or signal threading. Bias toward deletion and the smallest change that solves the problem.
Apply when reviewing or shaping code that's hard to trace. Count layers between question and answer, and hidden state in the reader's head; collapse one-caller wrappers and shrink mutable scope.
Apply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files.
Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'
Apply after how or why reports how the thing works, and before any code. Stop before any code only when the prompt and the conversation history show the user did not account for what the report found, or that the user has a knowledge gap about it. The report must show that the stated approach cannot work, or that it has a major design flaw.
Apply when sequencing an addition, refactor, or rewrite. Remove dead code, redundant validators, and stub references first, then build on the simpler base.
Apply when you write, change, or keep a test. Assert what the code's users can observe, so that the test fails when that behavior breaks and keeps passing when only the internals change.
Sebastian's agent style for concise, detailed responses, deliberate subagents, unslopped prose, simple code, and verified work. Use for Sebastian, /sebastian-mode, or requests to work in this style.
Configure which model each Bean Stack subagent role uses. Detects your available models and writes an always-applied rule that overrides the defaults. Use for /setup-bean-stack, "configure bean stack models", or changing a subagent's model.
Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away.
Tutor the user through course material with retrieval practice, hints, and visuals. Use for /study, "quiz me", "help me learn", "test me on", or working through an exercise or lecture.
Cut AI tells from any writing.
Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.