본문으로 건너뛰기
cccskills
무료GitHub에 공개

go-nolint-audit

Audit Go nolint directives for staleness and lazy justifications. Mechanically verifies each suppression with golangci-lint, then runs adversarial Red/Blue/White debates on the top candidates for removal. Use when inheriting a Go codebase, during periodic cleanup, or when nolint count is growing unchecked.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(2)

  • SKILL.md5.3 KB
  • references/go-nolint-patterns.md3.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

<!-- Copyright 2025-2026 Richard Shade. Licensed under Apache-2.0. --> <!-- SPDX-License-Identifier: Apache-2.0 -->

Go Nolint Audit

Audit //nolint: directives in Go codebases. Finds suppressions that are stale (code changed, lint rule no longer triggers) or lazily justified (the underlying code could be fixed instead of suppressed). Challenges each justification through adversarial debate rather than accepting comments at face value.

Prerequisite check

go version 2>/dev/null && golangci-lint --version 2>/dev/null

If go is not installed, stop and report. If golangci-lint is missing:

Do not proceed without both tools available.

Discover nolint directives

grep -rn '//nolint' --include='*.go' . | grep -v vendor/

Match all variants: //nolint (bare), //nolint:rule, //nolint:rule1,rule2. For each directive, capture:

  • File and line number
  • Suppressed rule(s), or "bare" if no rule specified
  • Justification comment (text after //nolint:rule // if present)
  • Surrounding code context (~5 lines)

Bare //nolint (no rule) suppresses everything — flag for Phase 2 automatically. If zero directives found, report a clean codebase and stop.

Phase 1: Mechanical verification

For each directive with a named rule, test whether the suppression is still needed. Co-enable nolintlint alongside the target rule:

# v2 syntax (preferred):
golangci-lint run --enable-only=<rule>,nolintlint \
  --allow-parallel-runners <file>

# v1 syntax (if v2 unavailable):
golangci-lint run --disable-all --enable=<rule>,nolintlint \
  --allow-parallel-runners <file>

If nolintlint reports the directive as unused, it is stale. This avoids modifying source files. For multi-rule directives (//nolint:rule1,rule2), test each rule separately. Run up to 3 parallel shell commands. Always use --allow-parallel-runners.

If golangci-lint fails for reasons other than the target rule (build errors, missing deps), skip the directive and report as "unable to verify."

Categorize each directive:

  • Stale — rule no longer triggers. Safe to remove.
  • Active — rule still triggers. Moves to Phase 2.

Report stale directives immediately. If all are stale, skip Phase 2. Bare //nolint directives skip Phase 1 — they cannot be verified against a specific rule.

Phase 2: Adversarial debate

Score all discovered directives (not just the Phase 1 sample) on two dimensions (1-5). For large codebases (50+ directives), sample 5-10 across different rules for Phase 1, but score the full list here to find the worst offenders:

  • Fixability — how easy to fix the code instead of suppressing?
    • 5 = trivial (extract function, rename, add constant)
    • 3 = moderate (restructure logic, split function)
    • 1 = architectural change required
  • Justification quality — how convincing is the comment?
    • 5 = no comment, or vague ("complexity is inherent", "needed")
    • 3 = explains situation but not why fixing is worse
    • 1 = specific, compelling reason

Score = Fixability x Justification quality. Consult references/go-nolint-patterns.md for scoring guidance.

Debate the top 3 by score:

  • Red (remove): argues the nolint should be removed and the code fixed. Must propose a concrete diff. Challenges the justification.
  • Blue (keep): argues the nolint is correct. Must add reasoning beyond the existing comment. Points out risks of the proposed fix.
  • White (judge): evaluates on evidence. Decides: remove, keep, or rewrite justification.

Debate rules

  • Red and Blue must cite specific code, not generalities
  • Red must provide a concrete diff, not just "this could be simpler"
  • Blue cannot simply repeat the existing justification
  • White's decision is final

Output format

Phase 1

Stale (safe to remove):
  file.go:42  //nolint:errcheck — rule no longer triggers
  file.go:87  //nolint:mnd — rule no longer triggers

Unable to verify:
  file.go:99  //nolint:gosec — golangci-lint build error

Phase 2

For each debated directive:

#N: file.go:line — //nolint:rule

Current code (with nolint): [5-10 lines of surrounding code]

Justification: "original comment" Lint warning when removed: [exact golangci-lint output]

Red (remove): [argument + concrete diff] Blue (keep): [argument with specific reasoning] White (verdict): REMOVE | KEEP | REWRITE JUSTIFICATION [reasoning]

[If REMOVE: repeat diff for easy application] [If REWRITE: full replacement line with improved justification]

Summary

#File:LineRuleVerdictEffort
1locationruleverdicteffort
2locationruleverdicteffort
3locationruleverdicteffort

Stale: N (remove immediately) | Unable to verify: N

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Prepares Go applications to work effectively with AI coding agents. Use when setting up a new Go project or retrofitting an existing one to ensure: structured JSON logging (slog/Zap/ZeroLog/Logrus), machine-readable command output, thorough golangci-lint configuration, non-interactive CLI design with --yes flags, structured error handling with meaningful exit codes, proper context.Context propagation, graceful shutdown, health check endpoints, and a standardized Makefile. Triggers when a user asks to make their Go app "agent-ready," "AI-friendly," wants to improve agent tooling/observability in a Go project, or needs to audit an existing Go project against agent-readiness best practices.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

dirien/yet-another-agent-harness202026년 5월 31일 업데이트

Use when creating or updating AGENTS.md files, .github/copilot-instructions.md, or other AI agent rule files, onboarding AI agents to a project, standardizing agent documentation, or when anyone mentions AGENTS.md, agent rules, project onboarding, or codebase documentation for AI agents.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

dirien/yet-another-agent-harness202026년 5월 31일 업데이트

Use when designing new high-level system architecture, reviewing existing designs, or making architectural decisions. Invoke to create architecture diagrams, write Architecture Decision Records (ADRs), evaluate technology trade-offs, design component interactions, and plan for scalability. Use for system design, architecture review, microservices structuring, ADR authoring, scalability planning, and infrastructure pattern selection — distinct from code-level design patterns or database-only design tasks.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

dirien/yet-another-agent-harness202026년 5월 31일 업데이트

Use when building CLI tools, implementing argument parsing, or adding interactive prompts. Invoke for parsing flags and subcommands, displaying progress bars and spinners, generating bash/zsh/fish completion scripts, CLI design, shell completions, and cross-platform terminal applications using commander, click, typer, or cobra.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

dirien/yet-another-agent-harness202026년 5월 31일 업데이트

Convert an AWS CloudFormation stack or template to Pulumi. This skill MUST be loaded whenever a user requests migration or conversion of CloudFormation to Pulumi.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

dirien/yet-another-agent-harness202026년 5월 31일 업데이트

Analyzes code diffs and files to identify bugs, security vulnerabilities (SQL injection, XSS, insecure deserialization), code smells, N+1 queries, naming issues, and architectural concerns, then produces a structured review report with prioritized, actionable feedback. Use when reviewing pull requests, conducting code quality audits, identifying refactoring opportunities, or checking for security issues. Invoke for PR reviews, code quality checks, refactoring suggestions, review code, code quality. Complements specialized skills (security-reviewer, test-master) by providing broad-scope review across correctness, performance, maintainability, and test coverage in a single pass.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

dirien/yet-another-agent-harness202026년 5월 31일 업데이트

dirien의 스킬 모두 보기

이 스킬의 문제 신고