Playbooks
Opinionated, copy-paste recipes for getting Sebastion AI tuned for your stack — configs, suppression strategy, and worked case studies.
The reference docs tell you what every knob does. The playbooks tell
you which knobs to turn for a given situation, why, and what the
trade-offs are. Each playbook ships a copyable artifact (a
.sebastionai.yml, an AGENTS.md block, a triage workflow) and the
reasoning behind it.
These are opinionated. We have run Sebastion AI on hundreds of repositories — our own and our customers' — and we have seen which configurations age well and which create more noise than they remove. Playbooks are how we share what we have learned without forcing you to read every reference page first.
When to use a playbook vs the reference docs
- Reference docs (
/docs/config,/docs/false-positives-and-learnings) are authoritative on what a key does, what types it takes and what the default is. - Playbooks are opinionated combinations of those keys for a specific stack or scenario. They link back to the reference for the fine print.
If a playbook and the reference disagree, the reference wins. Open an issue and we will fix the playbook.
What is here today
| Playbook | When to read it |
|---|---|
| Next.js configuration | You have a Next.js app or monorepo and want a sensible starting .sebastionai.yml instead of leaving everything at defaults. |
| Suppression strategy | You have noisy findings and you are not sure whether to use disable_rules, AGENTS.md markers, or the @sebastionai ignore chat command. |
| Learnings hygiene | You have been running Sebastion for a few months and want a sustainable workflow for keeping suppressions accurate over time. |
| CWE-502 deserialization | You want a worked example of how a real CWE looks in real code, how Sebastion flags it and how to fix it. Useful for onboarding new engineers to "what good looks like". |
What is not here yet
We are deliberately starting small. The playbooks above are the ones we think will help the most people the soonest. We will add more as patterns become clear and as the product grows new surfaces worth documenting.
If you want a playbook for a specific stack or scenario, tell us at /contact.
The three suppression mechanisms in one diagram
Most "how do I quiet this finding?" questions come down to picking one of these three. The suppression strategy playbook covers each in depth; the short version:
| Mechanism | Where it lives | Scope | Trust |
|---|---|---|---|
disable_rules in .sebastionai.yml | Repo root | Whole repo, every path | Commit it like any other policy |
# sebastion: ignore <rule> in <glob> in AGENTS.md / CLAUDE.md / .cursorrules / .github/copilot-instructions.md | Source file, top-level or per-directory | Path-scoped (top-level matches whole repo; nested matches that directory only) | Read from base branch only — a PR adding a marker has no effect until merged |
@sebastionai ignore on an inline finding comment | The finding comment thread itself | The exact (rule, file) of that finding | Requires write permission; cannot suppress critical or high severity |
The right tool depends on whether you are setting policy
(disable_rules), describing context that should follow the code
(AGENTS.md), or quieting one specific false positive on one specific
line (chat command).