version: "1.0.0" name: golang-how-to description: "Route a Go engineering task across the available Go skills, explain overlaps, or design reusable project guidance. Use when the user asks which skills to apply, how to sequence a multi-concern workflow, or how to configure durable Go-specific agent instructions." license: MIT

Plan a Go Skill Workflow

This is a planning and routing aid, not a catch-all Go engineering skill. Use it only for an explicit request to select skills, design a reusable Go workflow, or define project guidance.

Understand the request

Inspect only enough project context to distinguish:

• the concrete outcome and affected code or artifact;
• whether the work is implementation, diagnosis, review, modernization, performance, security, documentation, or release engineering;
• frameworks and tools already present in go.mod and repository configuration;
• existing repository instructions and verification commands;
• risk, external side effects, and whether the user asked for a plan or execution.

Do not load every Go skill to discover what might help. Use the available skill catalog descriptions first, then read only the few candidates whose boundaries are relevant.

Select the smallest useful set

Recommend a skill only when it changes decisions beyond ordinary Go competence. Prefer one primary skill; add a second only for a distinct required concern.

For each recommendation, state:

Avoid stacking broad code-style, naming, testing, security, and performance guidance onto every implementation. Specialized audit or hardening workflows apply when requested or when the task genuinely has that objective, not merely because all code could theoretically be reviewed for those qualities.

When two skills overlap, choose the one closest to the user's deliverable. Use a library-specific skill only when that library is already selected or the user is evaluating it. Use a workflow skill for CI, release, migration, or repository-wide operations rather than for a local code edit.

Produce an actionable plan

A useful response includes:

1. the minimal selected workflow;
2. project evidence that led to the selection;
3. verification appropriate to the change;
4. choices that still require the user;
5. explicit exclusions that prevent scope creep.

Separate the proposed workflow from optional execution so the user can see which steps are planning, local verification, or project changes.

Persist guidance only when requested

If the user asks to add reusable project instructions:

• inspect the target host's existing instruction format;
• add the narrowest durable rule supported by the project's needs;
• avoid duplicating a skill catalog or embedding long tutorials;
• do not edit AGENTS.md, CLAUDE.md, editor rules, or other agent configuration unless the user explicitly names configuration as a deliverable;
• preserve instructions for other hosts and unrelated workflows.

Report exactly which configuration was changed and how future requests should trigger it.