Use when the user wants to: design/redesign modules and layers, choose between a library and your own code, understand why a project became a god file, add an abstraction "just in case", evolve a DB schema without data loss, or review architecture. Covers: YAGNI until second need, stdlib-first, modules by change…
Use before designing features, components, new subsystems, or behavior changes. Resolve intent, constraints, interfaces and acceptance before implementation; scale design depth to uncertainty without adding approval gates to authorized work.
Understand "what this N-file change will break": blast radius over the diff, affected execution paths, dead code, rename impact. Use when the code-review-graph MCP is available and a graph exists, or when the user explicitly invokes a graph-based review; otherwise native source search/LSP (find references…
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
Use when designing, redesigning, or reviewing marketplace, seller, operations, finance, logistics, or analytics dashboards: information hierarchy, KPIs, filters, charts, tables, honest data visualization, design tokens, responsive behavior, loading/empty/error states, and post-change UI verification in the running…
Use when the user says: «it doesn't work», «still broken», «hung/stuck», «disappeared after the update», «it used to work», «the metric is zero but the UI is fine» — or when an incident needs to be analyzed, the root cause of a hang found, and whether a process was actually restarted verified. Covers: facts before…
Use when creating or refactoring product UI, landing-page styling, visual direction, shared components, themes, or design tokens, or adapting a supplied design reference. Not for software architecture or static illustrations.
Instructions for a shared developer memory system that stores useful facts, decisions, errors, and project context across conversations. It separates general knowledge from information tied to one project.
Response format rules (not a persona): direct engineering tone, result first, evidence-based, no fluff, no "I would recommend". Code > words. Observation > assumption. Use when writing reports or answers that need the direct evidence-first tone.
Adversarial verification of finished work: re-runs the claimed verifications, diffs what changed, detects false "done" claims, delivers an evidence-based verdict (VERIFIED / VERIFIED WITH CAVEATS / REFUTED). Use after any agent or model claims work is complete — "/fable-judge", "judge this work", "verify what it did".…
Use for an explicit /fable-method request or an uncovered evidence-and-judgment task. Modes: plan, audit, report. Ordinary implementation follows OPS without loading another method.
Git workflow and versioning practices. Use when committing, branching, resolving conflicts, organizing work across multiple parallel streams, cutting a release, choosing a semantic version bump, tagging, or writing a changelog.
Delivers changes incrementally in thin vertical slices. Use when a task touches many files or spans several independently landable capabilities, or when a large change would otherwise land in one unverified step.
Use when the user wants to: pay/buy/subscribe, receive or spend a bonus/promo code/referral, check a balance or limit, get a refund, or when any logic for deducting/crediting/quotas changes — even if the request does not name money explicitly («give me more minutes», «why was I charged twice», «enter a promo code»).…
Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.
Use for coding tasks to deliver the smallest change that fully solves the request without cutting requested behavior: scope first, reuse existing code, stdlib and platform features before new code, root-cause fixes, a check where the logic needs one, and a reply naming what was skipped and any risk. Use when the user…
Use for consequential choices of tools, libraries, standards or production mechanisms. Check existing project constraints first, research unresolved external facts in primary sources, and test unfamiliar mechanisms before integration. No web-search quota for local facts or established repository patterns.
Evidence-first reasoning for non-trivial tasks: define the outcome, inspect authoritative sources, resolve material uncertainty, act within scope and verify. Use when a question needs a reasoned, source-checked answer and no task-specific skill covers it. Scale analysis to consequences rather than fixed step or source…
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation.
Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when personal data or privacy compliance (GDPR, CCPA) is involved.
Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
★not rated 3
changed 2d agoA45 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: