메뉴
Ensure that aliases are alphabetically ordered within their groups to maintain consistent code style and address Credo readability warnings.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | alphabetically-ordered-aliases |
| description | Ensure that aliases are alphabetically ordered within their groups to maintain consistent code style and address Credo readability warnings. |
Elixir code style conventions prefer that module aliases are alphabetically ordered within their groups. This improves code readability, maintainability, and consistency. Credo checks for this ordering and warns when aliases are not properly alphabetized.
defmodule Explorer.Migrator.HeavyDbIndexOperation.RenameTransactions do
# ❌ BAD: Aliases not alphabetically ordered
alias Explorer.Chain.Cache.BackgroundMigrations
alias Explorer.Migrator.{HeavyDbIndexOperation, MigrationStatus}
alias Explorer.Migrator.HeavyDbIndexOperation.Helper
alias Explorer.Migrator.HeavyDbIndexOperation.DropTransactionsIndex
alias Explorer.Repo
end
# In the above, "Helper" comes after "DropTransactionsIndex"
# alphabetically, but it's listed before it. Correct order should be:
# - DropTransactionsIndex (D < H)
# - Helper (H)
defmodule Explorer.Migrator.HeavyDbIndexOperation.RenameTransactions do
# ✅ GOOD: Aliases properly alphabetically ordered
alias Explorer.Chain.Cache.BackgroundMigrations
alias Explorer.Migrator.{HeavyDbIndexOperation, MigrationStatus}
# Within same group, ordered alphabetically:
# D comes before H comes before R
alias Explorer.Migrator.HeavyDbIndexOperation.DropTransactionsIndex
alias Explorer.Migrator.HeavyDbIndexOperation.Helper
alias Explorer.Repo
end
Aliases are grouped by their module depth and prefix. List all aliases by location:
Group 1: Single-level modules
- alias Explorer.Repo
Group 2: Multi-level modules from same prefix
- alias Explorer.Chain.Cache.BackgroundMigrations
- alias Explorer.Migrator...
Within each group, sort by:
For modules with the same prefix like:
Explorer.Migrator.HeavyDbIndexOperation.CreateTransactions...Explorer.Migrator.HeavyDbIndexOperation.DropTransactions...Explorer.Migrator.HeavyDbIndexOperation.HelperSort by the last component: Create... < Drop... < Helper
Rearrange the alias statements to match the alphabetical order determined in Step 2.
Run Credo to ensure no warnings remain:
mix credo --strict
# ❌ BEFORE
alias Explorer.Migrator.HeavyDbIndexOperation.Helper
alias Explorer.Migrator.HeavyDbIndexOperation.DropTransactionsIndex
# ✅ AFTER
alias Explorer.Migrator.HeavyDbIndexOperation.DropTransactionsIndex
alias Explorer.Migrator.HeavyDbIndexOperation.Helper
# ❌ BEFORE
alias Explorer.Repo
alias Explorer.Chain.Cache.BackgroundMigrations
alias Explorer.Migrator.{HeavyDbIndexOperation, MigrationStatus}
# ✅ AFTER
alias Explorer.Chain.Cache.BackgroundMigrations
alias Explorer.Migrator.{HeavyDbIndexOperation, MigrationStatus}
alias Explorer.Repo
Create, adjust, or inspect OpenAPI declarations for Blockscout API v2 endpoints. Use this skill whenever the user asks to: add an OpenAPI spec to an endpoint that lacks one, update a spec after controller/view changes, audit or fix an existing OpenAPI declaration, or work with open_api_spex annotations in the Blockscout codebase. Also trigger when the user mentions 'swagger', 'openapi', 'open_api_spex', 'API spec', 'API schema', or 'operation macro', or when debugging failures like 'response schema mismatch', 'CastAndValidate rejection', 'json_response validation error', 'Unexpected field', or extra/missing keys in API responses.
Use when refactoring Elixir multi-clause functions, extracting helper functions, or fixing Credo readability warnings caused by placing `defp` helpers between clauses of the same function. Keeps function clauses contiguous and moves helpers below the full clause group.
Ensure every newly introduced environment variable is also added to docker-compose/envs/common-blockscout.env so local Docker setups stay aligned with runtime configuration.
Replace `with` expressions that contain only a single `<-` clause and an `else` branch with a `case` expression. This addresses the Credo warning "with contains only one <- clause and an else branch, consider using case instead" and produces cleaner, more idiomatic Elixir code.
Use when working on Elixir code with Credo predicate naming warnings, boolean helper functions, or renaming functions that start with is_. Prevents violations like: Predicate function names should not start with 'is' and should end in a question mark.
Define module aliases at the top of the file instead of using fully qualified nested module names in function bodies. Improves code readability and maintainability while addressing Credo style warnings.