How do I install the Eng Code Guidelines skill?

Run npx skillmds@latest add compozy/eng-code-guidelines in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Eng Code Guidelines safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Eng Code Guidelines?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Eng Code Guidelines free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Eng Code Guidelines?

compozy (@compozy) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Eng Code Guidelines by compozy — Agent Skill

Name: Eng Code Guidelines
Author: compozy

Eng Code Guidelines

Go production discipline for Compozy. Use when writing or editing non-test Go files under cmd or internal, including config, logging, CLI, concurrency, and process-lifecycle paths. Do not use for Go tests; pair it with the narrower schema, contract, cleanup, or network skill when those domains apply.

compozy 5559f98 3 files · 8.8 KB Updated Sep 17, 2026

File contents

Compozy Code Guidelines

Apply repository-specific Go conventions to production files under cmd/ and internal/. Read the relevant sections of references/coding-style.md; for goroutines, shared state, detached execution, subprocesses, shutdown, timers, locks, or channels, also use references/concurrency-patterns.md.

Trace the changed behavior through its applicable error, context, configuration, CLI, logging, type, and resource boundaries. Fix touched violations without expanding into unrelated debt.
Each changed resource, goroutine, process, or mutable shared state has an owner. Use eng-cleanup-failure-paths when multiple fallible acquisitions make partial failure relevant.
Add a companion skill only for a distinct unresolved concern. golang-master supplies deeper language guidance when needed; it is not an automatic prerequisite.
For public behavior/contract changes, update the owning docs/_memory/change-impact.md audit. Cite an existing spec/task/PR audit instead of writing one per skill.

Run the focused owning check and reuse current scoped lint/race evidence. Cross-build and Linux-race parity checks follow the concurrency reference's applicable branches. Root make gate and PR CI policy apply at the enclosing commit/push or PR-delivery stage, not after each edit.

Specific failure cases

A dependency with only string errors may need one typed wrapper at its boundary so downstream code can match error identity.
Reflection in codegen/decoders needs an adjacent reason; lint exceptions retain a justified //nolint: directive.
A reachable production panic needs an explicit error path. For a proven unreachable invariant, prefer panic("invariant: ...") with its explanation over log.Fatal.
For silently ignored CLI flags, check cmd.Flags().Changed(name), the documented resolution chain, and the default-resolution debug log.

---name: eng-code-guidelinesdescription: Go production discipline for Compozy. Use when writing or editing non-test Go files under cmd or internal, including config, logging, CLI, concurrency, and process-lifecycle paths. Do not use for Go tests; pair it with the narrower schema, contract, cleanup, or network skill when those domains apply.---# Compozy Code GuidelinesApply repository-specific Go conventions to production files under `cmd/` and `internal/`. Read the relevant sections of `references/coding-style.md`; for goroutines, shared state, detached execution, subprocesses, shutdown, timers, locks, or channels, also use `references/concurrency-patterns.md`.- Trace the changed behavior through its applicable error, context, configuration, CLI, logging, type, and resource boundaries. Fix touched violations without expanding into unrelated debt.- Each changed resource, goroutine, process, or mutable shared state has an owner. Use `eng-cleanup-failure-paths` when multiple fallible acquisitions make partial failure relevant.- Add a companion skill only for a distinct unresolved concern. `golang-master` supplies deeper language guidance when needed; it is not an automatic prerequisite.- For public behavior/contract changes, update the owning `docs/_memory/change-impact.md` audit. Cite an existing spec/task/PR audit instead of writing one per skill.Run the focused owning check and reuse current scoped lint/race evidence. Cross-build and Linux-race parity checks follow the concurrency reference's applicable branches. Root `make gate` and PR CI policy apply at the enclosing commit/push or PR-delivery stage, not after each edit.## Specific failure cases- A dependency with only string errors may need one typed wrapper at its boundary so downstream code can match error identity.- Reflection in codegen/decoders needs an adjacent reason; lint exceptions retain a justified `//nolint:` directive.- A reachable production panic needs an explicit error path. For a proven unreachable invariant, prefer `panic("invariant: ...")` with its explanation over `log.Fatal`.- For silently ignored CLI flags, check `cmd.Flags().Changed(name)`, the documented resolution chain, and the default-resolution debug log.

Frequently asked questions