Search Results for "j5ik2o" | AgentCC

refactoring-packages

Analyze the package/module structure of an existing codebase and perform refactoring. Detect and resolve circular dependencies, split god modules, separate responsibilities, and create and execute migration plans. Triggered by requests to improve the structure of existing code such as "Organize this dependency", "Resolve circular dependencies", "Split this module", or "Refactor this". If design guidance is needed, refer to the package-design skill.

parse-dont-validate

Code review and design assistance based on the "Parse, don't validate" principle. It converts validate patterns (check and discard results) into parse patterns (keep validation results as types), encouraging designs that enforce invariants via the type system. Used when validation functions need improvement during code review, new implementation, or refactoring. Target languages: Rust, Haskell, TypeScript, Scala, Java, Go, Python. Triggers: activated by type-safety related requests such as "improve validation", "I want guarantees via types", "fix shotgun parsing", "prevent invalid states with types", or "reduce Maybe".

reviewing-skills

Review Claude Code skills according to official best practices. Use this for reviewing SKILL.md files, checking skill quality, validating skill structure, and proposing improvements when necessary. Triggers: skill review requests such as "Review this skill", "Check skill quality", "Validate SKILL.md", "Improve this skill", etc.

first-class-collection

Supports the design and implementation of the first-class collection pattern. Guides the design of dedicated classes that wrap collections, the aggregation of domain logic, and ensuring immutability. Use when collection operation logic is scattered during code review, new implementation, or refactoring. Target languages: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust. Triggers: collection-design related requests such as “want to wrap a collection”, “aggregate list logic”, “first-class collection”, “collection operations are scattered”, “convert List<Order> to an Orders class”.

creating-rules

Creates Claude Code rules (.claude/rules/*.md) as modular Markdown files with YAML frontmatter and path-specific scoping. Use this when creating project rules, coding standards, or conditional guidelines for specific file types.

custom-linter-creator

A skill to create custom lint rules by leveraging each programming language's existing linter ecosystem. This is a linter intended for AI agents rather than humans: error messages are designed to act as fix-instruction prompts for an AI. Create custom rules in the lints/ directory using the standard per-language methods (e.g., Rust (dylint), TypeScript/JavaScript (ESLint), Python (pylint), Go (golangci-lint)). Use cases: (1) when you want to force project-specific coding rules on an AI, (2) when you want lint rules that output AI-readable fix instructions on violation, (3) when you want to enforce naming conventions, structural patterns, or consistency rules via AI-driven linting. Triggers: "create a linter rule", "add a lint rule", "enforce this pattern", "AI linter", "custom lint", "code rules", "naming rule", "structure rule".

domain-model-first

A guide to domain-model-centered development. It explains a method for designing and implementing domain models test-first and developing in the order: in-memory repository → use cases → infrastructure. Triggers: activated by development-process-related requests such as "want to start from the domain model", "DDD with TDD", "how to build an in-memory repository", "how to test use cases", "how to progress DDD development", etc.

Clean Architecture

Design and review assistance for projects adopting Clean Architecture. Based on a four-layer structure (domain layer, use case layer, interface adapter layer, infrastructure layer). In particular, it applies the principle that the infrastructure layer should be limited to cross-cutting concerns (logging, configuration management), while persistence and RPC belong in the interface adapter layer. Trigger: only activated when Clean Architecture is explicitly specified (for example, phrases like "with Clean Architecture", "according to Clean Architecture", "Clean Architecture review"). It will not activate for general requests such as "design review" or "architecture consultation."

domain-building-blocks

A design guide for DDD building blocks (value objects, entities, aggregates, domain services). Used when domain modeling, designing entities, deciding aggregate boundaries, or implementing value objects. Triggers: domain-modeling related requests such as “I want to create a value object,” “aggregate design,” “how to write domain services,” “difference between entity and value object,” or “I want to implement this in DDD.”

skill-installer

Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private repos).

aggregate-design

Performs code reviews and design assistance based on DDD aggregate design rules. Used for designing new aggregates, reviewing existing aggregates, and during refactoring. Triggered by aggregate-design–related requests such as: 'I want to design an aggregate', 'Review an aggregate', 'Implement an Aggregate', 'Decide aggregate boundaries', 'Implement with DDD', etc.

skill-creator

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.

DDD module pattern

Domain-layer packaging guidance based on DDD module patterns. Detects technology-driven packaging (entities/, value-objects/, services/, repositories/, etc.) and prompts migration to domain-terminology-based packaging. Guides module names in the domain layer so they become part of the ubiquitous language. Triggers: activated by domain-module-related requests such as “domain layer package structure”, “DDD module design”, “want to fix technology-driven packaging”, “want to stop using an entities/ folder”, “domain package review”, and similar.

repository-placement

A guide on where to place repository interfaces. Explains why, in Clean Architecture, repository interfaces should be located in the use-case layer rather than the domain layer. Emphasizes preventing coupling between domain models and repositories and enforcing design intent through structure. Triggers: activated by repository-placement related requests such as 'where to put the repository', 'repository interface placement', 'repository in domain layer', 'repository in Clean Architecture', etc.

Package design

Guidelines for redesigning a messy codebase into a clear package/module structure. Targets include (1) reorganizing tangled code, (2) splitting a single huge module, (3) reviewing package boundaries, and (4) designing module hierarchies for new projects. Triggered by structure-improvement requests such as "want to review package structure", "module dependencies are complex", "want to tidy file layout", or "resolve circular dependencies".

breach-encapsulation-naming

Naming-convention skill to prevent misuse of getters. When a getter is required in a domain model (persistence, JSON conversion, etc.), prepend the `breachEncapsulationOf` prefix to make explicit that encapsulation is being breached. This helps prevent violations of the Tell Don't Ask principle and suppresses unintended use of getters. Use during code reviews, new implementations, and refactorings when getter design decisions are needed. Target languages: Java, Kotlin, Scala, TypeScript, Python, Go, Rust. Triggers: requests related to getter naming such as getter naming convention, getter that breaks encapsulation, getter for persistence, `breachEncapsulation`, or 'I want to create a getter but avoid abuse'.

tell-dont-ask (Tell, Don't Ask)

Code review and design assistance based on the “Tell, Don't Ask” principle. Converts patterns that query an object's state and make decisions externally into patterns that command the object to act directly. Strengthens encapsulation and consolidates responsibility in the object that owns the data. Used during code reviews, new implementations, or refactorings when getters are overused or Feature Envy needs to be addressed. Target languages: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust. Triggers: OOP-design requests such as “reduce getters”, “improve encapsulation”, “fix Feature Envy”, “assign responsibility to the object”, or “Law of Demeter”.

error-handling

A skill that applies error-handling best practices. It helps design errors based on recoverability, adopt Either/Result types, and correctly classify domain errors versus system errors. Used when improving error-handling patterns during code reviews, new implementations, or refactoring. Target languages: Go, Rust, Scala, Java, TypeScript, JavaScript, Python. Triggers: 'Improve error handling', 'I want to use a Result type', 'Review exception design', 'Design recoverable errors'.