golang-effective
Source-backed Go task router and baseline workflow. Use when Codex is writing, refactoring, debugging, reviewing, or designing Go code and needs to choose the right Effective Go, Google Go Style, or Uber Go Style guidance without loading unnecessary context.
Works with
--- name: golang-effective description: Source-backed Go task router and baseline workflow. Use when Codex is writing, refactoring, debugging, reviewing, or designing Go code and needs to choose the right Effective Go, Google Go Style, or Uber Go Style guidance without loading unnecessary context. license: MIT --- # Golang Effective Use this as the router for broad Go work. ## Workflow 1. Identify the task type from the prompt and touched code. 2. Read `references/routing.md`, then load one primary adjacent skill. 3. Follow that skill's Load Protocol before giving advice or editing code. 4. Load at most two secondary adjacent skills when the task crosses domains. 5. Prefer local repository conventions unless they harm correctness, readability, or testability. 6. When editing Go code, run `gofmt` and the narrowest useful test command. 7. For source-backed grounding, run `scripts/query_chunk_index.py "<query>"` and open only the returned `sources/chunks/...` files. ## Routing - Style/readability/formatting: `go-style-core` - Package names, exported API, comments, receiver names: `go-naming-api-design` - Errors, wrapping, panic/recover, logging: `go-errors-panics` - Unit tests, table tests, helpers, examples, benchmarks: `go-testing` - PR/code review: `go-code-review-checklist` ## Guardrails - Do not load full raw or normalized source docs during ordinary coding tasks. - Do not browse chunk directories manually before trying the chunk index. - Do not treat Effective Go as a complete modern guide for modules or generics. - Do not invent style rules when a repository has a clear local pattern. - Do not optimize Go code without evidence when the task is not performance work. ## Source Priority Read `references/source-priority.md` when guidance conflicts.
More Debugging skills
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
explore-code
lllllllama/rigorpilot-skills
Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant modules, adapt a backbone, add LoRA or adapter layers, replace a head, or stitch together meaningful low-risk migration ideas with rollback-aware records in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline reproduction, conservative debugging, environment setup, verified contribution claims, or default repository analysis.
safe-debug
lllllllama/rigorpilot-skills
Rigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization.
