writing-go

Name: writing-go
Author: alexei-led

5installs5forks

How to install writing-go?

alexei-led/cc-thingz/writing-go

$npx -y skills add alexei-led/cc-thingz --skill writing-go

Installs into the current project.

Summary

Use only for Go modules. Follow the module's target Go version.

Files · 1

View on GitHub

SKILL.md

1	# Go Development
2
3	Use only for Go modules. Follow the module's target Go version.
4
5	## Read First
6
7	Read [principles.md](references/principles.md) before writing, changing, or reviewing Go code. Read conditional references only when the change touches that area.
8
9	## Conditional References
10
11	- [patterns.md](references/patterns.md) — package layout, interfaces, errors, HTTP/service boundaries, concurrency, comments.
12	- [testing.md](references/testing.md) — adding or reshaping Go tests; keep the local test loop fast.
13	- [linting.md](references/linting.md) — changing lint config, lint commands, or slow lint workflows.
14	- [cli.md](references/cli.md) — writing or changing Go CLIs.
15
16	## Comments
17
18	- Use doc comments for exported declarations. Start with the identifier and end with a period.
19	- Comment non-trivial unexported declarations only when their contract is not obvious.
20	- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or tuning decisions.
21	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
22	- Do not comment obvious code or restate names and types.
23	- Keep tests readable without comments; add one only for unobvious fixtures, timing, concurrency, or regression context.
24
25	## Version-Gated APIs
26
27	- Confirm `go.mod`, `toolchain`, CI, and nearby code before using version-specific APIs.
28	- Go 1.25+: use `sync.WaitGroup.Go` when no error propagation is needed.
29	- Use existing `errgroup` for goroutine errors or shared cancellation; add it only when the dependency is justified.
30	- Go 1.25+: use `testing/synctest` for deterministic concurrent tests when available.
31	- Go 1.25+: prefer stdlib `crypto/hpke` and `testing/cryptotest` over third-party code when they fit.
32	- Treat `encoding/json/v2` as experimental unless the project opts into `GOEXPERIMENT=jsonv2`.
33	- Go 1.26+: use `new(expr)` only when clearer than a local variable, composite literal, or address expression.
34	- Go 1.26+: keep recursive type constraints in generic libraries; keep business logic concrete.
35
36	## Verification
37
38	Run focused package tests and lint while editing, then the project-configured build, tests, lint, vet, and formatting checks before final output. Add race or concurrency-specific checks when the change touches goroutines, shared state, timers, or channels.
39
40	If a check is unavailable, state that and run the closest configured gate. If a check fails, quote the failure, diagnose the cause, fix one issue, and rerun the relevant check.
41
42	## Failure Cases
43
44	- No clear Go root: locate `go.mod` before choosing files, commands, or import paths.
45	- Unknown Go target: inspect `go.mod`, `toolchain`, CI, and lockfiles before using version-specific APIs.
46	- New dependency requested: confirm stdlib or existing dependencies cannot meet the requirement.
47	- Broad or risky edit: state the risk and ask before acting. Do not run destructive commands.
48
49	## Final Response
50
51	Include:
52
53	- changed files
54	- checks run and results
55	- checks skipped with reasons
56	- remaining risks or follow-ups

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

writing-go

5installs5forks

View on GitHub

How to install writing-go?

alexei-led/cc-thingz/writing-go

$npx -y skills add alexei-led/cc-thingz --skill writing-go

Installs into the current project.

Summary

Use only for Go modules. Follow the module's target Go version.

Files · 1

View on GitHub

SKILL.md

1	# Go Development
2
3	Use only for Go modules. Follow the module's target Go version.
4
5	## Read First
6
7	Read [principles.md](references/principles.md) before writing, changing, or reviewing Go code. Read conditional references only when the change touches that area.
8
9	## Conditional References
10
11	- [patterns.md](references/patterns.md) — package layout, interfaces, errors, HTTP/service boundaries, concurrency, comments.
12	- [testing.md](references/testing.md) — adding or reshaping Go tests; keep the local test loop fast.
13	- [linting.md](references/linting.md) — changing lint config, lint commands, or slow lint workflows.
14	- [cli.md](references/cli.md) — writing or changing Go CLIs.
15
16	## Comments
17
18	- Use doc comments for exported declarations. Start with the identifier and end with a period.
19	- Comment non-trivial unexported declarations only when their contract is not obvious.
20	- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or tuning decisions.
21	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
22	- Do not comment obvious code or restate names and types.
23	- Keep tests readable without comments; add one only for unobvious fixtures, timing, concurrency, or regression context.
24
25	## Version-Gated APIs
26
27	- Confirm `go.mod`, `toolchain`, CI, and nearby code before using version-specific APIs.
28	- Go 1.25+: use `sync.WaitGroup.Go` when no error propagation is needed.
29	- Use existing `errgroup` for goroutine errors or shared cancellation; add it only when the dependency is justified.
30	- Go 1.25+: use `testing/synctest` for deterministic concurrent tests when available.
31	- Go 1.25+: prefer stdlib `crypto/hpke` and `testing/cryptotest` over third-party code when they fit.
32	- Treat `encoding/json/v2` as experimental unless the project opts into `GOEXPERIMENT=jsonv2`.
33	- Go 1.26+: use `new(expr)` only when clearer than a local variable, composite literal, or address expression.
34	- Go 1.26+: keep recursive type constraints in generic libraries; keep business logic concrete.
35
36	## Verification
37
38	Run focused package tests and lint while editing, then the project-configured build, tests, lint, vet, and formatting checks before final output. Add race or concurrency-specific checks when the change touches goroutines, shared state, timers, or channels.
39
40	If a check is unavailable, state that and run the closest configured gate. If a check fails, quote the failure, diagnose the cause, fix one issue, and rerun the relevant check.
41
42	## Failure Cases
43
44	- No clear Go root: locate `go.mod` before choosing files, commands, or import paths.
45	- Unknown Go target: inspect `go.mod`, `toolchain`, CI, and lockfiles before using version-specific APIs.
46	- New dependency requested: confirm stdlib or existing dependencies cannot meet the requirement.
47	- Broad or risky edit: state the risk and ask before acting. Do not run destructive commands.
48
49	## Final Response
50
51	Include:
52
53	- changed files
54	- checks run and results
55	- checks skipped with reasons
56	- remaining risks or follow-ups

People who liked this also viewed

6 picks

Type