new-module

Scaffold new packages and sub-modules in the gokit Go monorepo with correct wiring.

Updated Feb 15, 2026
One-click install
npx skills add https://github.com/kbukum/gokit --skill new-module-kbukum
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: new-module
Source: https://github.com/kbukum/gokit/tree/main/.github/skills/new-module
Command: npx skills add https://github.com/kbukum/gokit --skill new-module-kbukum

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding a new package or module to a multi-module Go monorepo involves error-prone decisions: root module vs sub-module placement, layer dependency rules, go.mod replace directives, workspace registration, and domain mapping. This Skill walks through the canonical gokit procedure so new code lands in the right place without layering violations or pseudo-version breakage. ## Core Features & Use Cases - Placement Decision: Decides between a root-module package and a standalone sub-module based on whether heavy third-party dependencies are involved. - Layer Enforcement: Confirms the new package respects gokit's downward-only dependency direction enforced by depguard, using domains.toml as the domain map. - Sub-module Wiring: Covers go mod init, replace directives back to the root, registration in core.go.work or contrib.go.work, and domains.toml updates. - Use Case: When adding a new Redis cache adapter to gokit, use this Skill to create the sub-module with its own go.mod, wire the replace directive, register it in contrib.go.work and domains.toml, then validate with build, lint, test, and tidy. ## Quick Start Ask the assistant to scaffold a new gokit module for your capability, for example a Kafka messaging adapter, and have it follow the placement, wiring, and validation steps.

Frequently Asked Questions about new-module

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

FAQPage Schema
How do I add a new module to a Go multi-module monorepo?▼

Decide whether the code belongs in the root module or its own sub-module based on dependency weight, then run go mod init, add a replace directive back to the root, register the module in the appropriate go.work file, and update the domain registry before validating with build and test.

When should a Go package become its own sub-module?▼

Create a sub-module only when the package has heavy third-party dependencies such as cloud SDKs, database drivers, or broker clients that consumers should not inherit transitively. Packages using only the standard library and existing gokit code stay in the root module.

How do I wire a replace directive in a nested Go sub-module?▼

In the new sub-module's go.mod, add a replace directive pointing back to the root module, using ../ for direct children or ../../ for nested sub-modules. Then register the module path in the correct workspace file such as core.go.work or contrib.go.work.

What is depguard and how does it enforce layer dependencies?▼

Depguard is a linter configured in .golangci.yml that enforces gokit's downward-only dependency direction across layers from core through transport to infra. A lower layer importing a higher one is a blocker, and transport packages must not import auth packages directly.

Why does my new Go module fail CI after scaffolding?▼

Common causes include missing registration in domains.toml so check-domain gates skip it, a missing replace directive causing pseudo-version resolution, or upward layer imports flagged by depguard. Run build, lint, test, and tidy per module to catch these locally.