Go Coder

Name: Go Coder
Author: Dankosik

ASecurity

Use to implement an authorized Go change with accepted behavior and source ownership, including focused tests and cleanup.

7 stars

0 votes

0 copies

0 views

Added 9/24/2026

developmentgotestingapidocumentation

Works with

api

Security Analysis

A100/100

Pro scans all 6 files and shows the line behind each finding

Scanned 9/24/2026

$npx -y skills add Dankosik/go-service-template-rest --skill go-coder --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Go Coder?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/dankosik-go-coder/badge)](https://www.skillsdirectory.com/skills/dankosik-go-coder)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro

Files

SKILL.md

---
name: go-coder
description: "Use to implement an authorized Go change with accepted behavior and source ownership, including focused tests and cleanup."
metadata:
  invocation: model
  kind: method
---

# Go Coder

Implementation starts at the **earliest valid owner** and ends at the accepted
observable behavior.

`criterion -> earliest owner -> canonical path -> far-side observer -> falsifier -> cleanup -> proof`

Before editing, bind accepted criteria to current owners, observables, and
focused proof. Collapse criteria with one cause into the same edit and proof;
do not leave a layer stub that needs still-missing sibling work.

Extend the existing policy path instead of creating a parallel path. Inspect
the far side of every touched boundary: callers, generated/manual authority,
error identity, lifecycle, and cleanup. A new helper or abstraction must carry
a current constraint, variation, or dependency direction; otherwise keep the
behavior local.

When a library or SDK choice depends on API behavior or availability, establish
the resolved dependency or provider API version and check the relevant official
documentation. Reuse verified evidence while that version and contract remain
unchanged. An upgrade needs a task-relevant reason and compatibility assessment;
a newer documentation example alone is not a reason to change dependencies.

Before freeze, delete or inline each new helper, layer, or configuration seam
whose removal preserves accepted behavior and current
[Engineering](../../../AGENTS.md#engineering) constraints.

Reuse adequate coverage; when adding a test, state why it rejects missing or
wrong behavior. Choose cases and
assertions from accepted behavior as you write code; no approved test plan is
needed. Consult `go-test-strategy` only for a non-obvious testing
choice within this task. Reopen product decisions only if expected behavior is
unresolved; repairing a test or fixture stays with the executor.

Implementation is complete when each criterion has a causal edit or grounded
no-change disposition and its test/proof implementation, no superseded path,
and no unresolved implementation choice. The active workflow owns validation
timing and task completion.
Load one matching [implementation reference](references/index.md) only when its
pressure changes the method.

Attribution

Dankosik

View source See grades on GitHub More from Dankosik →

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: go-coder description: "Use to implement an authorized Go change with accepted behavior and source ownership, including focused tests and cleanup." metadata: invocation: model kind: method --- # Go Coder Implementation starts at the **earliest valid owner** and ends at the accepted observable behavior. `criterion -> earliest owner -> canonical path -> far-side observer -> falsifier -> cleanup -> proof` Before editing, bind accepted criteria to current owners, observables, and focused proof. Collapse criteria with one cause into the same edit and proof; do not leave a layer stub that needs still-missing sibling work. Extend the existing policy path instead of creating a parallel path. Inspect the far side of every touched boundary: callers, generated/manual authority, error identity, lifecycle, and cleanup. A new helper or abstraction must carry a current constraint, variation, or dependency direction; otherwise keep the behavior local. When a library or SDK choice depends on API behavior or availability, establish the resolved dependency or provider API version and check the relevant official documentation. Reuse verified evidence while that version and contract remain unchanged. An upgrade needs a task-relevant reason and compatibility assessment; a newer documentation example alone is not a reason to change dependencies. Before freeze, delete or inline each new helper, layer, or configuration seam whose removal preserves accepted behavior and current [Engineering](../../../AGENTS.md#engineering) constraints. Reuse adequate coverage; when adding a test, state why it rejects missing or wrong behavior. Choose cases and assertions from accepted behavior as you write code; no approved test plan is needed. Consult `go-test-strategy` only for a non-obvious testing choice within this task. Reopen product decisions only if expected behavior is unresolved; repairing a test or fixture stays with the executor. Implementation is complete when each criterion has a causal edit or grounded no-change disposition and its test/proof implementation, no superseded path, and no unresolved implementation choice. The active workflow owns validation timing and task completion. Load one matching [implementation reference](references/index.md) only when its pressure changes the method.