developer-code-organization

Guides Go code organization, file structure, and WASM build-variant conventions for gh-aw.

5.1k|530|Updated Aug 12, 2025
One-click install
npx skills add https://github.com/githubnext/gh-aw --skill developer-code-organization
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: developer-code-organization
Source: https://github.com/githubnext/gh-aw/tree/main/.github/skills/developer-code-organization
Command: npx skills add https://github.com/githubnext/gh-aw --skill developer-code-organization

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Contributors to the gh-aw Go codebase need consistent rules for where new code belongs, when to split large files, how to name helper files, and how to keep the WASM build compiling, and this Skill codifies those conventions.

Core Features & Use Cases

  • File Organization Patterns: Enforces small, functionality-grouped files (100-500 lines) with decision trees for creating or splitting files, illustrated by the frontmatter.go refactoring case study.
  • Helper File and Naming Conventions: Defines when to create helper files, what belongs in them, and which vague names (utils.go, misc.go) to avoid.
  • String Processing and WASM Guidance: Distinguishes sanitize vs normalize functions and documents the _wasm.go stub pattern required to keep GOOS=js GOARCH=wasm builds compiling.
  • Use Case: When adding a new safe output type or AI engine to gh-aw, consult this Skill to decide whether to create create_entity.go or engine_name_engine.go, and whether a WASM stub is required.

Quick Start

Ask the agent to review the gh-aw code organization guidelines before creating a new Go file in pkg/workflow.

Frequently Asked Questions about developer-code-organization

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How should I organize Go files in the gh-aw codebase?

Organize Go files by functionality rather than type, keeping most files between 100 and 500 lines. Create one file per operation, such as create_issue.go or copilot_engine.go, with tests colocated alongside implementation files.

When should I split a large Go file?

Files over 1000 lines should be split, and files over 800 lines should be considered for splitting. Also split when a file has multiple responsibilities or causes frequent merge conflicts, extracting standalone utilities first.

What is the difference between sanitize and normalize functions?

Sanitize functions remove or replace invalid characters to create valid identifiers, file names, or artifact names. Normalize functions standardize format, such as removing file extensions or converting dashes to underscores, assuming input is already valid.

When do I need to add a _wasm.go stub file?

Add a _wasm.go stub whenever you add a function that calls os/exec, reads the real filesystem, or performs network I/O during compilation. Pure data transformations and in-memory operations do not need stubs.

What file names should I avoid for helper files in Go?

Avoid vague names like utils.go, helpers.go, misc.go, and common.go. Use specific domain-focused names such as github_cli.go, mcp_renderer.go, or config_helpers.go that clearly indicate purpose.