gotrino-assistant

Surface code-level debt — TODO/FIXME markers, deprecated APIs, dead code, oversized units, magic numbers. Use when reviewing a module, planning cleanup work, or before a release. Not a linter — observes patterns and assesses impact.

Show available commands and explain how to use the Gotrino assistant.

Document the reasoning behind implementation decisions as markdown files. Creates decision records that future developers can reference.

Analyze mock data and examples for cultural assumptions, understanding what they communicate about who the product is for. Use when reviewing test data, documentation, or seed data.

Analyze code for internationalization issues, understanding the UI context and user impact before flagging problems. Use when reviewing code for global readiness.

Comprehensive inclusion analysis of code, examining language, internationalization, assumptions, and who might be excluded. Thorough review for releases or major features.

Analyze code and documentation for non-inclusive language, understanding context and intent before flagging issues. Use when reviewing code for biased terms, gendered language, or problematic terminology.

Analyze examples and mock data for name diversity, understanding the context and purpose before suggesting changes. Use when reviewing test data, documentation, or seed data.

Identify hidden assumptions about users in code that could exclude or harm. A focused analysis asking "What am I assuming about the person using this?"

Validate a task, gauge its impact, and decide what to do with it

Set up the Gotrino assistant for your project. Detects your stack, captures scope decisions, and creates a config that evolves with your project. Run once to get started, revisit to update decisions.

Run all five debt dimensions (code, doc, test, dep, design) and synthesize a cross-cutting report. Surfaces systemic hotspots — modules with debt in multiple dimensions. Use when planning a tech-health effort or preparing for a major release.

Surface design-level debt — inconsistent patterns (error handling, naming, response shapes), architectural drift from declared principles, duplicated business logic. Use when the codebase feels harder to reason about than it used to.

Surface dependency debt — outdated packages, abandoned/deprecated libs, unused deps, version drift across manifests. Static analysis only (no package manager calls). Use before upgrades, audits, or when planning tech renewal.

Surface test-suite debt — skipped tests, untested public APIs, flaky patterns (retries, sleeps), missing edge cases. Pattern-based static analysis; does not run coverage tools. Use when tests feel unreliable or before a release.

Surface documentation debt — stale READMEs, missing public API docs, broken internal links, undocumented env vars. Use when onboarding gets friction, before a release, or when an API has evolved without matching doc updates.

Analyze system-wide impact of changes before making them. Use before modifying shared utilities, changing APIs, or refactoring core functionality.

Generate culturally diverse names for examples, mock data, and test fixtures. Includes edge-case names that catch bugs.