hudrazine

agent-memory

Use this skill to read, write, update, search, or organize repo-local Markdown memory notes so project-specific context can be resumed across conversations. Use when the user asks to remember, save, recall, or clean up notes, or when durable project knowledge, restart points, decisions, gotchas, solved problems, or in-progress context should be preserved or checked before related work. Do not use for transient task details, facts that belong in repository docs, or information that is not useful across conversations.

agent-skill-design

Design, review, or refine the behavioral substance of Agent Skills: decide whether a repeated task belongs in a Skill, define its responsibility, invocation and non-invocation conditions, degree of freedom, tool and resource boundaries, failure handling, and evaluation cases. Use when turning workflows or guidance into a Skill design or correcting a Skill that is vague, broad, unsafe, hard to invoke, or difficult to evaluate. Do not use for platform-specific packaging, manifests, file templates, installation, or authoring-spec compliance.

alignment-interview

Interview the user adaptively, using one question or a small dependency-safe round at a time, to externalize and organize their context, resolve decision dependencies, show progress, and confirm shared understanding before acting. Use when the user asks to be interviewed, wants to brain-dump or think something through together, needs to align intent or expectations, wants missing context surfaced, or wants to clarify decisions collaboratively in any domain. Do not use for routine clarification, idea generation alone, immediate execution, factual research, or one-shot critique.

Code & Development Listed

complexity-review

Review implemented code, diffs, or snippets for unjustified maintenance complexity and concrete behavior-preserving simplifications. Use for simplification-focused reviews of needless abstractions, unused API or configuration, redundant dependencies, avoidable state or control flow, duplicated logic, test indirection, or over-engineering. Avoid for implementation planning, general correctness, security, performance, accessibility, module-boundary, or architecture review.

Code & Development Listed

design-deep-modules

Apply the Deep Modules lens to software boundary decisions so callers rely on small, stable contracts while cohesive modules hide meaningful knowledge. Use when a task materially affects what callers must know, which decisions a module owns, dependency direction, public contracts, boundary enforcement, or whether a boundary should be preserved, deepened, merged, split, or delayed. Apply alongside planning, implementation, review, refactoring, or migration guidance when boundary quality is relevant, and as the primary Skill for explicit boundary design or assessment. Avoid for deployment topology alone, general review or local changes with no boundary concern, pure simplification with no boundary concern, visual-only work, or documentation that does not define architecture or public contracts.

project-development-docs

Search, read, create, update, organize, audit, archive, or remove repository-local development documentation under `.dev-docs/`. Use when project architecture, decisions, specifications, product intent, development workflows, testing strategy, operations, security, or other maintainer-facing knowledge may already be documented or must be maintained. Do not use for user-facing documentation, generated API references, transient task notes, agent memory, or facts better owned by code, tests, types, schemas, scripts, configuration, or CI.

right-size-engineering

Calibrate software engineering decisions across macro, meso, and micro perspectives so the result is complete without unsupported structure, detail, or scope. Use when requirements, architecture, design, implementation, migration, or verification may be misaligned; when local and structural approaches compete; when a decision introduces enduring commitments; or when over- or under-engineering is a material risk. Avoid for fully specified mechanical work, unconstrained exploration with no decision to make, or tasks owned by a more specific review method.

Testing & QA Listed

tdd

Apply practical, language-agnostic test-driven development when implementing observable behavior, reproducing and fixing bugs, or changing untested code where executable examples can guide the design. Use a small List → Red → Green → Refactor loop, with regression-first, characterization-first, refactoring, and spike-then-test variants. Do not use strict TDD for visual-only styling, exploratory work before behavior is understood, mechanical migrations, or documentation-only changes unless tests clarify a real contract or risk.

Code & Development Listed

to-tickets

Convert PRDs, plans, specs, conversations, backlog ideas, or existing tracker items into small, verifiable implementation ticket drafts for GitHub, Linear, or file-based workflows. Use when the requested outcome is an implementation-ticket breakdown or approved tickets written or published to a destination; do not use for implementation itself, broad strategy, prioritization, support-ticket handling, or architecture work unless that work is being turned into implementation tickets.