oh-my-slop

Use when the user wants a high-stakes decision debated by independent perspectives and synthesized into a verdict — five advisors (Contrarian, First Principles, Expansionist, Outsider, Executor) answer independently, peer-review anonymously, then a chairman synthesizes. Triggers on: "council this", "convene the council", "run a council on", "rerun the council", "I want the council to debate this", "five independent perspectives", "have advisors weigh in and peer-review each other".

Use when the user wants a plan, proposal, or conclusion adversarially challenged in one pass — auto-picks the strongest critique mode (socratic, dialectic, pre-mortem, red-team, evidence audit) and delivers the 3–5 strongest challenges plus a synthesis. Triggers on: "court-jester this", "poke holes in this plan", "red-team this design", "run a pre-mortem", "argue the other side", "does the evidence actually support this conclusion", "challenge this proposal".

Use when interacting with a Gitea instance or its `tea` CLI — listing or filing issues, managing pull requests, labels, milestones, releases, repos, or calling the Gitea REST API. Triggers on: "tea" CLI commands, "Gitea", "tea issues", "tea pr", "tea api", blocked-by/issue dependencies, "file this on the tracker", or a repo whose remote points at a Gitea host. Excludes GitHub's `gh` CLI.

Use when documentation must stay truthful as software changes — writing or revising a spec, ADR, runbook, or API/config reference, splitting user-facing docs by purpose, or reconciling documentation drift. Triggers on: "write a spec", "ADR", "runbook", "which docs must change", "documentation drift", "missing acceptance criteria", "spec interview", "update the API reference".

Use when the project's domain model is being changed — terms pinned down, design decisions landing, vocabulary conflicting — or when another skill needs to maintain the domain model while decisions land. Triggers on: "pin down the terminology", "ubiquitous language", "record this decision", "add it to the glossary", "domain model".

Interactive QA session: the user reports bugs or issues conversationally, the agent clarifies, explores the codebase in the background for domain language, and files durable, user-focused issues on the project tracker. Triggers on: "QA session", "let's do QA", "file an issue for this", "report a bug", "log these bugs", "bug triage", or when the user describes problems they want captured as tracker issues rather than fixed immediately.

Use when a git merge or rebase is stopped mid-way with conflicting files. Triggers on: "merge conflict", "rebase conflict", "CONFLICT (content)", "fix these conflicts", "continue the rebase".

Configure the current project for the workflow skills — issue tracker bindings, triage label vocabulary, and domain doc layout. Run once per repo before first use of wayfinder, to-tickets, to-spec, triage, qa, or two-axis-review.

Turn the current conversation into a spec (PRD) — problem statement, user stories, implementation and testing decisions — and publish it to the project issue tracker. No interview, just synthesis of what has already been discussed. Triggers on: "to-spec", "turn this into a spec", "write this up as a PRD", "capture this conversation as a spec", "publish the spec".

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets — vertical slices, each declaring its blocking edges — published to the project tracker or one local file per ticket.

Move issues and external PRs through a state machine of triage roles — categorise, verify the claim, grill if needed, and write durable agent-ready briefs — maintaining an .out-of-scope/ knowledge base of rejected requests.

Use when the user wants the changes since a fixed point reviewed against the repo's coding standards, against the originating spec, or both. Triggers on: "review since X", "review this branch", "review the PR against the spec", "does this match the ticket", "standards check", "two-axis review".

Chart a chunk of work too big for one agent session as a shared map of decision tickets on the issue tracker, then resolve them one per session until the way to the destination is clear.

Use when reimplementing a codebase from scratch from a behavioral spec without copying the original's code — a legal-safe reimplementation, a messy legacy rewrite, or a two-agent spec-then-build process. Triggers on: "cleanroom rewrite", "clean room reimplementation", "spec-driven rewrite", "behavior-preserving rewrite", "rewrite from scratch without copying", "legal reimplement".

Use when designing or restructuring a module and reaching for the shared deep-module vocabulary — interface, seam, depth, adapter, leverage, locality — to decide where a boundary goes, whether an abstraction earns its keep, or how to make a module testable through its interface. Also when another skill needs these terms. Triggers on: "deep module", "where should this seam go", "is this abstraction worth it", "make this testable", "module interface", "reduce coupling".

Use when integrating, customizing, or debugging django-allauth: signup/login flows, email verification, password reset, social login and provider setup, MFA, user sessions, headless/API auth, or allauth acting as identity provider. Triggers on: "allauth", "SocialApp", "social login", "OAuth provider", "email verification", "MFA", "headless auth", "account adapter".

Use whenever creating, modifying, or fixing any code in a Django project — a project with manage.py present or django in pyproject.toml/requirements.txt. Applies to every change in such a project, whether or not the change looks Django-specific. This is the discipline skill — for framework pattern lookups, use django instead.

Use when working with Django code — looking up ORM, view, template, form, admin, auth, settings, testing, or async patterns, or debugging Django-specific behavior. Triggers on: "Django", "manage.py", "models.py", "ORM", "migration", "template tag", "Django admin", or any file inside a Django project layout. This is the reference skill — the mandatory workflow checklist lives in django-discipline.

Use whenever creating or modifying Dockerfiles, compose files, or deployment configs — any change to how a project builds or runs in containers. This is the discipline skill — for Docker behavior lookups and troubleshooting, use docker instead.

Use when working out how Docker behaves or why it is failing — `docker build` / `docker compose` errors, daemon connectivity, networking, storage, or registry auth — or when reviewing or fixing a Dockerfile or compose.yaml, including one only described in prose. Triggers on: "docker build", "docker compose", "Cannot connect to the Docker daemon", "bind mount", "container DNS", "registry auth", "BuildKit", "review this Dockerfile". Excludes Kubernetes and Helm; authoring rules live in docker-discipline.

Use when building, securing, or fixing REST APIs with Django REST Framework (anything importing rest_framework). Triggers on: "DRF", "serializer", "ViewSet", "APIView", "router", "permission classes", "throttling", "pagination". Not for pure Django ORM/template/form/admin work — use django for those.

Use when about to write or review code whose identifiers, comments, or docstrings are in a non-English language, or when the user is writing to you in one. Keeps all code identifiers, comments, and docstrings English regardless of the user's language. Triggers on: non-English identifiers (nazwa_użytkownika, licznik), non-English comments, a user request written in another language, mixed-language code.

Use when building, configuring, or debugging a FullCalendar instance — views, event sources, callbacks, drag-and-drop, or render hooks. Triggers on: "FullCalendar", "event calendar", "dayGrid"/"timeGrid", "events show on the wrong day" (exclusive end dates), "calendar not rendering", "dateClick or drag-drop not working" (missing interaction plugin), a JSON event feed, or wiring a calendar into an HTMX-driven app.

Use when running any git operation — committing, pushing, branching, merging, rebasing — or when a command could touch uncommitted or untracked work. Enforces conventional-commit messages, a commit per execution wave, and hard guards on destructive commands. Triggers on: git clean, git reset --hard, force push, rebasing a published branch, rm on user files, deleting untracked files.

Use when the user wants a plan, decision, or idea sharpened through questioning before acting on it, or when another skill needs the interview primitive. Triggers on: "grill me", "grill this plan", "stress-test this design with questions", "interview me about this".

Use when adding, reviewing, or debugging HTMX behavior — hx-* attributes, swap strategies, partial page updates, or the SSE/WebSocket extensions. Triggers on: "HTMX", "hx-get"/"hx-post"/"hx-swap"/"hx-target", "partial reload", "nothing happens when I click" (silent swap failure), "SSE", "WebSockets", or when templates being edited contain hx-* attributes.

Use when choosing, reviewing, or explaining HTTP response codes — in an API, OpenAPI spec, controller, middleware, or client retry logic. Triggers on: "which status code", "400 vs 422", "401 vs 403", "429 vs 503", "409 vs 412", "201 vs 202 vs 204", "303 vs 307 vs 308", or when a handler's status code looks wrong.

Use when writing, reviewing, or debugging _hyperscript — `_=` / `script=` / `data-script` attributes, `on click` handlers, DOM commands like `toggle`/`put`, `behavior` definitions, or local UI glue around HTMX events. Triggers on: "hyperscript", "_=", "on click", "behavior", "HTMX companion", inline `_=` snippets shown without naming the language, or hyperscript that silently does nothing (parse errors).

Use when the user wants the codebase swept for over-engineering and bloat and a ranked list of what to cut — dead code, reinvented stdlib, single-implementation abstractions, pass-through wrappers, dead flags. Read-only, one-shot report; applies nothing. Triggers on: "audit this codebase", "find bloat", "what can I cut", "trim this down", "YAGNI check", "over-engineering check", "reduce code surface".

Use when building, reviewing, or debugging a PrestaShop 9 module — its structure, hooks, controllers, configuration page, services, persistence, cron, or packaging. Triggers on: "PrestaShop", a module main class or `getContent()`, hook registration (`registerHook`, `hookDisplay*`/`hookAction*`), `config/services.yml` inside a module, a module ZIP that will not install, or a Back Office configuration page that 404s.

Use when a design question is best answered by throwaway code — "does this state model or logic feel right?" (build a runnable terminal app) or "what should this look like?" (several radically different UI variations on one route). Also when another skill needs a cheap concrete artifact to react to. Triggers on: "prototype this", "sanity-check this state machine", "mock up a few versions of this screen", "explore what this UI could look like".

Use when a question needs investigating against primary sources — official docs, specs, source code, first-party APIs — and the findings captured as a cited Markdown file, ideally delegated to a background agent while the user keeps working. Triggers on: "research this", "look into how X works", "gather the docs/API facts on", "check the spec for".

Use when creating or editing SKILL.md files, diagnosing skill-triggering failures, or measuring whether a skill improves agent behavior. Also use before publishing a new or materially changed skill.

Use when building or styling UI with the Tabler HTML/CSS framework — choosing component markup, CSS classes, variants, colors, or layout. Triggers on: "Tabler", component requests like "Tabler card/button/modal/table", color classes (".bg-*", ".text-*-fg"), "Tabler icons", dashboard or page layout with Tabler, or when editing templates that already use Tabler classes.

Use when the user wants a live web search run against their local SearXNG instance — looking something up online, finding current information, or configuring the SearXNG endpoint. Triggers on: "websearch", "search the web", "look this up online", "find online", "searx", "/skill:websearch".

Use when authoring or editing a skill — writing or reviewing a SKILL.md, crafting its description, choosing its invocation mode, or diagnosing why a skill misfires, undertriggers, or bloats. Triggers on: "write a skill", "edit this skill", "skill description", "skill triggering", "trim this skill".

Use when implementation is blocked by unclear construction prerequisites or tangled routine/data shape, or when system knowledge and artifacts are drifting, commitments are expensive to reverse, recurring engineering work or quality decay needs containment, concurrency ownership is unsafe, or estimates and performance claims lack evidence.

Use when an enterprise app's infrastructure decisions are in play — where business logic lives, transaction and identity coordination, application-level (offline) concurrency, session-state placement, or remote/distribution boundaries. Domain modeling defers to domain-driven-design and database isolation/transactions to data-intensive; based on Patterns of Enterprise Application Architecture (Fowler). Triggers on: "Transaction Script vs Domain Model", "Unit of Work", "Identity Map", "optimistic vs pessimistic offline lock", "session-state placement", "Remote Facade", "generic repository everywhere".

Use when summarizing incidents.

Use when helping with logs.