Menu
Mandatory verification protocol after code changes for Go projects. Use after any code modification to ensure quality.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Reviewer persona for authorization models — RBAC, ABAC, ReBAC, and hybrids. Catches the bugs that ship after auth is correct but authz is wrong: missing tenant scoping, IDOR via predictable IDs, role escalation through unchecked write paths, permission caching staleness, transitive-trust loopholes, RBAC/ReBAC drift between policy doc and code. Use when reviewing endpoints that gate access by user/role/relationship, when adding a new role/permission/scope, when changing tenant isolation, or when designing a permission system from scratch. Triggers: RBAC, ABAC, ReBAC, IDOR, tenant isolation, multi-tenant, permission check, role, scope, principal, Zanzibar, OpenFGA, casbin, authz, can_, has_permission, isAuthorized.
Stand up a full c1 dev stack inside a Squire env — process-compose, postgres, envoy, pub-api, pub-auth, be-* services — wired so an external client can drive c1's gRPC surface end to end with TLS + OAuth2 client_credentials. Use when testing a Latchkey or other c1 client against a real (not stubbed) c1 backend, or when reproducing c1 server-side behavior locally. Triggers on: c1 dev env, squire c1 stack, pc/up, dev-util mint-test-client, test against c1, c1 OAuth client_credentials, run c1 integration tests in squire, repro buildkite integration test, TEST_LOCAL_EXEC, api_no_uplift.
c1-specific values for the general squire dispatch protocols defined in squire-env-management. Provides the c1 gate bundle's contents, the task-family table for c1 work, the c1 always-actives, and the list of c1 skills that should NOT be spent on a squire env. Use when about to spawn a squire env to execute c1 work, when writing a brief for a remote c1 agent, or when filing a c1 bead intended for squire dispatch. Triggers: c1 squire dispatch, c1 squire brief, c1 remote work, c1 ephemeral env, c1 fire-and-forget.
Reviewer persona for detecting hand-rolled cryptography. Distinct from `sharp-edges` (which catches footgun APIs) and `key-lifecycle-review` (which covers lifecycle hygiene): this skill catches the class where someone wrote their own MAC, KDF, AEAD, signature scheme, secret-comparison routine, RNG, or password hash. Almost all custom crypto is broken. Use when reviewing any code that does math on bytes, manipulates buffers in a 'crypto-shaped' way, or implements something whose docs reference a named primitive (HMAC, AES-GCM, Argon2, X25519). Triggers: hand-rolled crypto, custom MAC, custom hash, custom KDF, byte XOR, constant-time compare, derived key, password hashing, HKDF, encrypt_then_mac, mac_then_encrypt, AE, AEAD.
Reviewer persona for the full lifecycle of cryptographic keys and high-value secrets: generation, storage, distribution, rotation, revocation, and destruction. Trail of Bits' `zeroize-audit` covers the destruction half; this skill covers the other four phases plus closes the loop with destruction. Use when reviewing key management code, secret stores, KMS integrations, rotation logic, key derivation, RNG usage, or any system that issues, holds, or revokes long-lived credentials. Triggers: key generation, key rotation, KMS, HSM, secret store, vault, key derivation, KDF, master key, DEK, KEK, rotation, revocation, RNG, entropy, random, secrets management.
Reviewer persona for OAuth 2.0 / 2.1 and OpenID Connect flow implementations. Catches the well-documented attack classes that still ship: missing PKCE, wildcard redirect URIs, mishandled refresh tokens, scope creep, mixed flows on a single endpoint, leaking tokens through referrer or logs, JWT signature bypass. Use when reviewing any code that issues, accepts, validates, exchanges, refreshes, revokes, or stores tokens; when designing a new auth integration; when a PR touches /authorize, /token, /userinfo, /jwks, /introspect, /revoke, OIDC discovery, or a third-party identity provider client. Triggers: OAuth, OIDC, JWT, PKCE, redirect_uri, scope, refresh token, access token, id_token, client_credentials, authorization code, implicit, device code, token exchange, identity provider, IdP, SSO.
| name | post-change-verification |
| description | Mandatory verification protocol after code changes for Go projects. Use after any code modification to ensure quality. |
This skill defines the mandatory verification steps that Go agents must perform after modifying code files.
Use this skill ALWAYS when:
Do NOT use when:
After completing code changes, agents MUST execute these steps IN ORDER:
make fmt
# or if Makefile not available:
go fmt ./...
Purpose: Ensure consistent code formatting using Go's official formatter.
make lint
# or if Makefile not available:
golangci-lint run
Purpose: Detect code quality issues, potential bugs, and style violations.
make build
# or if Makefile not available:
go build ./...
Purpose: Verify code compiles without errors. Go's compiler performs type checking.
make test
# or if Makefile not available:
go test ./path/to/modified/...
# or run all tests:
go test ./...
Purpose: Verify code changes do not break existing functionality.
TARGET: All steps must complete with ZERO errors and ZERO warnings.
If any step reports errors or warnings, proceed to Exception Handling.
When verification finds issues, follow this decision tree:
Issue Found During Verification
|
v
Was this issue caused
by current changes?
|
+------+------+
| |
YES NO
| |
v v
Fix it Is it in a file
now you modified?
|
+------+------+
| |
YES NO
| |
v v
Is it a Document and
small fix? report only
(< 10 lines) |
| |
+------+------+ v
| | DONE
YES NO (proceed with
| | task)
v v
Fix it Document,
now report,
recommend
separate task
Scenario 1: You add a new function and the linter reports an unused variable in your new code.
Scenario 2: You modify a file and discover a pre-existing lint warning (3 lines to fix) in a function you touched.
Scenario 3: You modify a file and discover 50+ lines of lint warnings throughout the file.
Scenario 4: Lint reports warnings in a file you did not modify.
Report verification results using this consistent format:
=== POST-CHANGE VERIFICATION ===
Format: [PASSED | FAILED | SKIPPED (reason)]
Lint: [PASSED | FAILED] ([X] errors, [Y] warnings)
Build: [PASSED | FAILED] ([X] errors)
Tests: [PASSED | FAILED] ([X]/[Y] passed)
Pre-existing issues: [NONE | count listed below]
[If issues exist, list them here]
=== [TASK COMPLETE | VERIFICATION FAILED] ===
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: PASSED (0 errors, 0 warnings)
Build: PASSED (0 errors)
Tests: PASSED (24/24)
Pre-existing issues: NONE
=== TASK COMPLETE ===
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: FAILED (0 errors caused by this change)
Build: PASSED (0 errors)
Tests: PASSED (24/24)
Pre-existing issues (not caused by this change):
- internal/legacy/handler.go: Line 45 - exported function without comment
- pkg/utils/strings.go: Lines 78-92 - ineffective assignment
These issues require structural changes beyond the scope of this task.
Recommend creating a separate cleanup task.
=== TASK COMPLETE ===
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: FAILED (2 errors, 1 warning)
Build: FAILED (1 error)
Tests: FAILED (22/24)
Issues to fix:
- cmd/server/main.go: Line 23 - undefined: Config
- internal/service/user.go: Line 45 - unused variable 'temp'
- internal/service/user.go: Line 67 - missing error check
=== VERIFICATION FAILED - FIX ISSUES BEFORE COMPLETING ===
Handle missing or failing commands gracefully:
| Situation | Status | Action |
|---|---|---|
| Command not found | SKIPPED (command not found) | Note and proceed to next step |
| Command timeout (> 5 min) | SKIPPED (timeout) | Note and proceed to next step |
| Execution error | SKIPPED (execution error: [reason]) | Note and proceed to next step |
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: SKIPPED (command not found - golangci-lint not installed)
Build: PASSED (0 errors)
Tests: PASSED (24/24)
Pre-existing issues: NONE
Note: Consider installing golangci-lint for full quality verification.
=== TASK COMPLETE ===
Go projects MUST use Makefile for build operations. Ensure these targets exist:
.PHONY: fmt lint build test
fmt:
go fmt ./...
lint:
golangci-lint run
build:
go build -o ./bin/app ./cmd/app
test:
go test -v ./...
# Combined verification target
verify: fmt lint build test
If Makefile targets are missing, fall back to direct commands but note in output.
make fmt over go fmt ./...Before completing any code-modifying task:
make fmt)