Cadasto

Idiomatic, leak-free Go concurrency. This skill should be used when the user writes or reviews Go goroutines, channels, `sync`/`atomic`, `context`, `errgroup`, or worker pools — goroutine lifetimes/leaks, context propagation, typed atomics, mutex misuse, or data races. Pair with `go test -race`, `go vet`, and `goleak`. Defers time/concurrency *testing* mechanics to `go-testing` (synctest). Not for non-Go languages.

Modern idiomatic Go (the `modernize` analyzer set). This skill should be used when the user writes, reviews, or modernizes Go and wants current-version idioms — range-over-int, `min`/`max`, `slices`/`maps`, `strings.Cut`, `cmp.Or`, `sync.OnceFunc`, iterators, `slog.LogAttrs`, `new(expr)` (Go 1.26), dropped loop-var copies. Framed so advice equals tooling (`go fix ./...` on Go 1.26, or `golangci-lint --enable-only=modernize`). Errors→`go-errors`, concurrency→`go-concurrency`, tests→`go-testing`. Not for golangci-lint configuration (use `go-linting`) or non-Go languages.

Idiomatic Go testing. This skill should be used when the user writes or reviews Go tests, benchmarks, or fuzz targets — table-driven tests, `t.Parallel`, `testing.B.Loop`, the race detector, goroutine-leak detection, `testing/synctest` for time/concurrency, fuzzing, or golden files. Pair with `go test -race`. Not for non-Go test frameworks; error-wrapping belongs to `go-errors`.

Go coding-standards router and entry point for idiomatic Go (Go 1.26, works with 1.25+; golangci-lint v2). This skill should be used when a Go task spans multiple areas, is unspecified, or the question is which tool or standard applies — it routes each topic to the deterministic tool (gofmt/gofumpt, go vet, go fix / golangci-lint v2 modernize, go test -race), to the gopls-lsp plugin for code intelligence, and then to the focused go-* skill that owns it. For a single, already-identified topic prefer that skill directly (errors → go-errors, concurrency → go-concurrency, testing → go-testing, idioms/modernization → go-idioms, linter config → go-linting, layout → go-layout). Not for non-Go languages or domain/business rules.

One-shot lookup/explanation of a single Go idiom, standard, or tool. This skill should be used when the user runs `/go-explain <topic>` or asks to "explain", "look up", or "what's the modern way to do" a specific Go construct (e.g. error wrapping, `synctest`, `wg.Go`, `min`/`max`, `internal/` layout) — returning the modern form, the enforcing linter, and a cited source. For applying a standard while writing or reviewing code, use the focused go-* skill (`go-errors`, `go-concurrency`, …). Not for non-Go languages.

golangci-lint v2 setup and adoption for Go. This skill should be used when the user configures, upgrades, or debugs Go linting — the `.golangci.yml` file, the golangci-lint v2 schema (the versioned config, the `linters.default` set, the separate formatters section), the `modernize` linter, or stack linters (errorlint, bodyclose, rowserrcheck, sqlclosecheck, noctx, contextcheck). Not for what individual idioms mean (use the `go-idioms` skill) or writing rules by hand.

Idiomatic Go error handling. This skill should be used when the user writes, reviews, or debugs Go error code — wrapping with `%w`, inspecting via `errors.Is`/`errors.As`, sentinel vs typed errors, `errors.Join`, or chasing a silently-swallowed or context-losing error. Pair with the `errorlint` linter (set it up via `go-linting`). Not for panics-as-control-flow or non-Go languages.

Go project layout and package design. This skill should be used when the user structures a Go module or names packages — `internal/`, `cmd/`, start-flat-then-grow, package naming, avoiding `util`/`common` grab-bags, or deciding whether hexagonal/DDD ceremony is warranted. Counters imported Java/C# structure. Not for build tooling or for non-layout idioms (→ `go-idioms`).

This skill should be used when the user asks to "write an AQL query", "optimize an AQL query", "review AQL", or "query openEHR data" — the multi-step authoring/optimization workflow for AQL (Archetype Query Language) over openEHR clinical data. For a one-off explanation of an existing query or a single AQL keyword/operator (no authoring), the `/openehr-explain` command suffices.

This skill should be used when the user asks to "create", "edit", "specialize", "review / remediate", "write the rationale for", or "translate / localise" an openEHR archetype, or to import a CKM archetype into the workspace for reuse. It covers the full author → review (lint → fix → re-lint) → rationale → translate lifecycle. To merely explain an existing archetype with no edits, use `/openehr-explain` instead.

This skill should be used when the user asks to "build a composition", "create a composition", "validate a composition", "convert a composition", or "generate FLAT/STRUCTURED/CANONICAL format". Covers building openEHR compositions in all simplified formats and guiding their validation and format conversion (against a target template; there is no automated validator/converter tool). Also handles quick format explanations and single-payload sketches directly.

This skill should be used when the user mentions openEHR concepts (archetypes, templates, AQL, ADL, CKM, RM types, compositions, OPT, terminology bindings, clinical modeling) outside of a specific command context. Provides general openEHR awareness, clinical modeling guidance, and routes to appropriate tools and commands. Not for focused tasks owned by a dedicated skill — archetype authoring/linting, template authoring, composition building, AQL, or demographic modeling — route those to the matching skill; this skill is the awareness and routing layer.

This skill should be used when the user asks to "create a template", "design a template", "constrain archetypes into a template", "review a template", or "work with OET/OPT files". Covers creating openEHR templates, constraining archetypes, reviewing designs, and OET/OPT authoring. Use `/ckm-search` to find existing CKM templates and `/openehr-explain` to explain one; this skill is for authoring and constraining new OET designs.

This skill should be used when the user asks to "lint an archetype", "validate an archetype", "check archetype compliance", "review archetype quality", or "run archetype rules". Applies 22 normative lint rules with ERROR/WARNING/INFO severity. Supports STRICT and PERMISSIVE modes. Reports violations only — it does not modify files; to lint *and* remediate, use the `archetype-authoring` skill. Auto-invoked on lint/validate intent, and also directly invocable as `/archetype-lint <file or id> [strict]`.

This skill should be used when the user asks to "design a demographic model", "model a person/organisation/role", "design party relationships", "plan identity structures", or "work with demographic archetypes". Covers designing openEHR demographic models using the PARTY hierarchy, roles, capabilities, relationships, and identity patterns. For clinical EHR archetypes (OBSERVATION/EVALUATION/etc.) use `archetype-authoring`; this skill owns the demographic PARTY model.

This skill should be used when the user asks to "close out the plan", "archive the plan", "mark the requirement shipped", or "this feature is done — close it out". The SDD close-out — confirms the document-side Definition of Done (spec status, index, traceability), flips the plan to done and `git mv`s it to `plans/archive/` inside the implementing PR, and updates AGENTS.md tables if user-facing. Not for merging / PR / branch cleanup (superpowers finishing-a-development-branch); not for running tests (superpowers verification-before-completion) or the drift check (sdd-trace).

This skill should be used when the user asks to "run the SDD review", "review this PR/change for spec conformance", "dispatch the reviewers and post findings to the PR", or "spec-aware code review before merge". Opt-in orchestration — dispatches the installed generic code reviewers plus the SDD traceability auditor and spec-conformance reviewer, consolidates the findings, and (optionally) posts them to the PR. It sequences and adds the SDD lens; it does not replace generic review. Not for authoring (sdd-specify), the in-session drift-only scan (sdd-trace), or whether the tests pass (superpowers verification-before-completion).

This skill should be used when the user mentions spec-driven development concepts outside a specific artefact action — "what is SDD", "explain spec-driven development", "how does this repo's spec workflow work", "where does the spec fit with planning/building", or vocabulary like normative, RFC-2119, traceability, drift, ADR, requirement-vs-spec. Provides SDD awareness, explains the methodology, routes intent to the right skill, and maps how SDD complements the superpowers engineering loop. Not for performing an artefact action — use the specific sdd-* skill.

This skill should be used when the user asks to "set up SDD", "initialize spec-driven development", "scaffold the docs tree", "add SDD structure to this repo", or "create the requirements/specifications layout". Creates the SDD docs/ tree, document templates, the .sdd.yaml descriptor, AGENTS.md, and the process docs — idempotently. Not for authoring a requirement, spec, or decision in an already-scaffolded repo (use sdd-specify).

This skill should be used when the user asks to "add a requirement / capability", "write or extend a spec", "make this behaviour normative (RFC-2119)", "record an ADR / architectural decision", or "resolve a STRAND". The SDD definition layer — authors the `REQ`, the canonical RFC-2119 `SPEC §`, and the `ADR`, assigning identifiers and wiring traceability. Not for exploring/design (superpowers brainstorming first); not for planning or building (superpowers writing-plans / executing-plans); a traceability audit (sdd-trace); or a one-line edit to an existing spec § (open the file directly).

This skill should be used when the user asks to "show traceability for REQ-X", "assemble context for REQ-X", "what implements/tests this requirement", "are there orphan requirements", or wants a quick in-session drift / spec-check scan. Read-only — assembles the one-shot context bundle for a REQ and reports drift/orphans in-session (the spec-check analogue). Not for generic tests/build verification (superpowers verification-before-completion); not for authoring (sdd-specify), close-out (sdd-archive), or a heavy whole-repo / pre-release audit (sdd-traceability-auditor agent).