rosetta

Use when designing memory or persistent context for an agent — deciding what to persist vs. recompute, how to retrieve only what's relevant, and how to summarize/compact history to fit the context window. Use when an agent forgets, bloats its context, or repeats work.

Interactive installer for Rosetta. Guides users through selecting and installing skills and language-specific rules at user-level or project-level, verifies paths, and optionally optimizes installed files.

Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills, commands, and agents.

Use when building or reviewing an evaluation for an LLM feature — assembling a representative test set, choosing pass criteria (exact match, programmatic checks, rubric, or LLM-as-judge), and catching regressions. Use when asking "how do I know this prompt or model change is better?"

Use when writing or reviewing a prompt for an LLM — making it specific, structured, and testable (clear task, role/context, examples, an explicit output contract, decomposition, room to reason) and avoiding the anti-patterns that make prompts brittle. Provider-agnostic.

Pattern for progressively refining context retrieval to solve the subagent context problem.

Use when creating or structuring a Claude Code plugin for this marketplace — the on-disk layout, the plugin.json manifest fields, the frontmatter for skills/commands/agents, and the authoring rules (no absolute paths, least-privilege tools, one coherent capability).

Use when a secret may have been committed or is about to be. Covers high-signal detection patterns and the correct remediation order — rotate the credential first, then remove it from code and history. Always redact when reporting.

Suggests manual context compaction at logical intervals to preserve context through task phases rather than arbitrary auto-compaction.

Enforces test-driven development with 80%+ coverage — unit, integration, and E2E. Use when writing new features, fixing bugs, or refactoring.

Use when deciding what to test for a change. Covers the test pyramid, risk-based prioritization, boundary and equivalence partitioning, the edge cases worth checking, and — just as important — what not to test.

Comprehensive verification pattern for Claude Code sessions — build, types, lint, tests, security, and diff review.

Use when writing or reviewing a SKILL.md — how to write a description that reliably triggers the skill, structure the body for progressive disclosure, and keep one skill scoped to one capability. Apply whenever a skill isn't firing when it should, or fires when it shouldn't.

Generates or updates RBS-inline type annotations directly in Ruby source files as comments. Triggers when creating, updating, or maintaining inline type signatures for Ruby source files. Use for rbs-inline (# @rbs) comments in .rb files, not sig/*.rbs.

Generates or updates RBS type signatures in separate .rbs files. Triggers when creating, updating, or maintaining type signatures for Ruby source files. Use for sig/**/*.rbs files (Steep/RBS), not inline comments.

Generates or updates Sorbet inline type signatures directly in Ruby source files using sig blocks. Triggers when creating, updating, or maintaining inline type signatures for Ruby source files. Use for sig { } blocks and

Generates or updates Sorbet type signatures in separate .rbi files. Triggers when creating, updating, or maintaining type signatures for Ruby source files. Use for rbi/**/*.rbi shim files without editing source.

Use when writing or updating a CHANGELOG. Applies the Keep a Changelog format — the six change groups (Added, Changed, Deprecated, Removed, Fixed, Security), reverse-chronological version blocks, ISO dates, and an Unreleased section — kept aligned with Semantic Versioning.

Generate or update CHANGELOG.md from git history for a release.

Use to turn a range of commits into polished, human-readable release notes grouped by theme. Delegate when preparing a GitHub release body or an announcement from a tag range, where the audience is users rather than committers.

Use when writing or reviewing Python (3.10+) — modern idioms for typing, data modeling, control flow, and standard-library use, plus the anti-patterns to avoid (mutable default args, bare except, manual index loops, string-built paths).

Use when writing or reviewing Ruby — Enumerable-driven, expression-oriented idioms (blocks, guard clauses, safe navigation, keyword arguments, predicate methods) and the manual loops, nil checks, and temporary variables they replace.

Use when writing or reviewing TypeScript — getting value from the type system (unknown over any, discriminated unions, narrowing, satisfies, readonly) and avoiding the escape hatches (any, unchecked as casts, non-null !) that silently defeat it.

Use when reviewing a plugin for the rosetta catalog or registering it in marketplace.json — the quality bar the validator can't fully check, the required manifest/component fields, and how category metadata works. Apply during contribution review or before merging a new plugin.

Generate or update CHANGELOG.md from git history for a release.

Use when writing or reviewing bash/shell scripts. Covers strict mode, quoting, error handling and cleanup traps, safe command usage, and bash-vs-POSIX portability so scripts fail loudly instead of silently doing the wrong thing.

Use when writing or updating a CHANGELOG. Applies the Keep a Changelog format — the six change groups (Added, Changed, Deprecated, Removed, Fixed, Security), reverse-chronological version blocks, ISO dates, and an Unreleased section — kept aligned with Semantic Versioning.

Use when writing or reviewing a pull request description. Provides a structure (Summary / Changes / Testing / Notes) and tone guidance focused on the reviewer — lead with why, keep it scannable, never pad a small change into a big description.