app-standards

ScotterMonk's avatarfrom ScotterMonk

All modes that write scripts or code follow these app standards for communication, modularization, simplification, naming conventions

⭐12stars🔀0forks📁View on GitHub🕐Updated Jan 2, 2026
[Code Generation]

When & Why to Use This Skill

This Claude skill enforces rigorous professional standards for script and code generation, focusing on modularity, domain-driven naming conventions, and concise communication. It optimizes codebase maintainability by mandating a 450-line limit per file and implementing a 'domain_specific' naming pattern (e.g., user_edit instead of edit_user). Designed for developers seeking clean, scalable, and organized code, it ensures that AI-generated logic remains consistent across Python, JavaScript, and database-heavy projects.

Use Cases

  • Standardizing New Codebases: Automatically applying domain-first naming and modular structures when generating new scripts to ensure long-term scalability.
  • Architectural Refactoring: Systematically breaking down monolithic files into smaller, focused utility modules to adhere to strict line-count limits and improve readability.
  • Naming Convention Alignment: Transforming legacy 'action_subject' patterns into a unified 'subject_action' format to improve code discoverability and logical grouping.
  • Post-Refactoring Verification: Utilizing the built-in checklist to ensure that all imports, calls, and tests are updated after structural changes or symbol renaming.
nameapp-standards
descriptionAll modes that write scripts or code follow these app standards for communication, modularization, simplification, naming conventions

Standards-all-modes instructions

Communication

Be brief; don't echo user requests.

Modularization

Scope: Critical for Python, JS, and logic files.

  • Exception: Do NOT apply this to CSS.

Hard Limit:

  • Enforce a maximum of 450 lines of code per file.
  • Split larger files: Create more files with fewer functions rather than exceeding this limit.

Utility Strategy:

  • Extract logic liberally into utility folders.
  • Naming Convention: Use utils/ or utils_db/.

Naming Conventions: Domain-First

Rationale: Group related code by Domain (Subject) first, then Specific (Action/Qualifier).

Core Pattern

Invert the standard naming order:

  • Bad: {specific}_{domain} (e.g., edit_user)
  • Good: {domain}_{specific} (e.g., user_edit)

Casing Rules:

  • snake_case: Files, functions, variables, DB tables/columns.
  • PascalCase: Classes.

Transformation Examples

| Type | Old Pattern | New Pattern (Target) | Note | | Files | admin_dashboard_utils.py | dashboard_utils_admin.py | Domain is dashboard | | Functions | edit_user | user_edit | Domain is user | | Classes | AdminPerson | PersonAdmin | Better: Use Person w/ type param |

Scope & Restrictions

When to Apply:

  • New Code: Always apply this pattern.
  • Existing Code: Apply only if you are already actively editing the file.

Do NOT rename without explicit approval:

  • Public APIs: HTTP routes, library exports, CLI flags.
  • Database: Tables and columns (requires migration).
  • Standards: __init__.py, setUp(), settings.py (Django).

Refactoring Checklist

If you rename a symbol, you MUST fix all references. Before finishing, verify:

  1. Imports: Updated in all other files?
  2. Calls: Function/Class usage updated everywhere?
  3. Tests: Do tests still pass?
  4. Docs: Updated docstrings/comments?
  5. VS Code: No errors in the Problems panel?