メニュー
Enforces stank-bot scoring invariants when editing scoring_service.py, chain_service.py, or scoring-related settings. Trigger when modifying SP/PP formulas, position bonuses, finish bonus, Team Player, or ScoringConfig.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Browser automation, UX review, frontend debugging, E2E test writing, mock endpoint catalog. Trigger when asked to review UX, debug the dashboard, write E2E tests, take screenshots, or inspect pages. Also trigger when `stank-frontend-patterns` fires and introduces new components/pages/test-ids.
Enforces Alembic migration conventions when creating or editing migrations, models, or running alembic commands. Trigger when touching migrations/versions/, db/models.py, or adding/removing columns.
Conventions for stank-bot's per-guild embed templates (board, record, session-start/end, points, cooldown). Trigger when editing src/stankbot/services/template_engine.py, board_renderer.py, template_store.py, embed_builders.py, default template strings, or dashboard routes that author templates.
Enforces stank-bot's SvelteKit frontend conventions — component hierarchy, store barrel, shared utilities, testing patterns. Trigger when editing any file under src/stankbot/web/frontend/src/ or creating new Svelte/TS modules there.
WebSocket message type constants (frontend MsgType enum vs backend MSG_TYPE_* in ws.py) must stay in sync. Trigger when editing src/stankbot/web/ws.py, src/stankbot/web/frontend/src/lib/ws.ts, or src/stankbot/web/frontend/src/lib/ws.test.ts.
Enforces stank-bot's event-sourcing invariants when writing code that mutates domain state. Trigger when adding/editing any code path that changes player totals, chain state, sessions, records, or achievements — i.e. anything in src/stankbot/services/* or repositories that writes to the DB. Also trigger when writing rebuild/backfill scripts that touch totals.
| name | stank-scoring-math |
| description | Enforces stank-bot scoring invariants when editing scoring_service.py, chain_service.py, or scoring-related settings. Trigger when modifying SP/PP formulas, position bonuses, finish bonus, Team Player, or ScoringConfig. |
SP is always non-negative. No code path may produce a negative SP award. SP represents earned rewards — use PP for penalties.
PP is always non-positive (stored as positive, displayed as negative). PP represents punishment. The pp_awarded field in ChainResult is a positive integer; the display layer negates it.
Break PP formula: pp_break_base + (broken_chain_length × pp_break_per_stank). Both components come from ScoringConfig. The formula is applied in scoring_service.compute_break_penalty().
Position bonus: The Nth valid stank in a chain earns sp_flat + (N - 1). Position 1 (chain starter) gets sp_flat + 0 plus the separate sp_starter_bonus.
Team Player bonus: Awarded when a user contributes to a chain that already has contributions from other users. Amount: sp_team_player_bonus. Checked via chain_unique > 1 at the time of the stank.
Finish bonus: On chain break, retroactively awarded to the last valid stanker who is NOT the chainbreaker. Walks back chain_messages to find the recipient. If the entire chain was built by the breaker alone, no finish bonus is awarded.
ScoringConfig is frozen. It is a @dataclass(frozen=True, slots=True). Never add mutable fields. All values come from guild settings at the time the chain event is processed — they are not stored on the chain itself.
Reaction SP: sp_reaction per first-time (message, user, sticker) tuple. Subsequent reactions by the same user on the same message with the same sticker are no-ops (enforced by reaction_awards unique constraint).
tests/unit/test_scoring_service.py.AGENTS.md section "SP / PP math" and the README scoring table.Keys.* setting so it's admin-configurable from day one.ScoringConfig.