Borrowing it
Nothing to install: this file belongs to luisfurquim/wings. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/luisfurquim/wings/main/.claude/skills/sec-supply-chain/SKILL.mdgit clone --depth 1 https://github.com/luisfurquim/wingsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/luisfurquim/wings/sec-supply-chain)<a href="https://agentmods.dev/skills/luisfurquim/wings/sec-supply-chain"><img src="https://agentmods.dev/badge/skills/luisfurquim/wings/sec-supply-chain/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/luisfurquim/wings/sec-supply-chain"><img src="https://agentmods.dev/badge/skills/luisfurquim/wings/sec-supply-chain.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00063 | $0.00978 |
| Opus 5 | $0.00032 | $0.00489 |
| Sonnet 5 | $0.00013 | $0.00196 |
| Haiku 4.5 | $0.00006 | $0.00098 |
Grade A, and why
sec-supply-chain scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Supply Chain & Artifact Integrity
Neither djb nor Apollo had go.mod — but the philosophy transfers directly:
a dependency is trusted code you didn't write and don't review on update.
This skill covers the gap.
Dependencies
- Default answer to a new dep is no. wings has 6 direct requires; that
smallness is a security feature. A candidate dep must beat "we write the
50 lines ourselves" (djb: eliminate trusted code) and be inspected:
go mod graph | grep <dep>for what it drags in, maintenance pulse, whether we need 1% of its API. - Transitive deps are real deps. After any go.mod change run
go mod tidy && go mod graphand skim what appeared.go mod why -m Xanswers "who brought this". Indirect modules you can't explain are a finding. - go.sum is the integrity anchor. Never bypass it (
GOFLAGS=-mod=modin CI,GONOSUMCHECK,GONOSUMDB,GOPRIVATEwildcards). Builds should run-mod=readonly(Go's default) so a build never silently rewrites deps. - Vulnerability scanning: run
go run ./cmd/build vulncheckbefore each release. It runs govulncheck over every module in the repo, twice each: a native call-graph pass (low noise) and aGOOS=jsimports pass — js-only packages are excluded from the native pass by build constraints, so without the second pass the wasm side would never be scanned. Any finding fails the run; fix or explicitly triage before tagging. Implementation:cmd/build/vulncheck.go. - Pin tools by version.
go install [email protected](the Dockerfile already pins viaWINGS_VERSION) — never@latestin anything reproducible. Toolchain updates are deliberate, reviewed events (see project_crypto_update_decision: no auto-upgrade magic in builds).
Artifacts we ship / fetch
- Reproducible builds are a verification tool.
cmd/buildparity (re-running leavesgit status docs/ dist/empty, byte-identical wasm) is effectively a reproducibility check — treat a parity break as a security signal, not an annoyance. Don't add timestamps/nondeterminism to outputs. - SRI on every
<script>we emit (prana_helper.js,wasm_exec.js): maintained by the build, idempotent. New scripts in served HTML must getintegrity=the same way. - Catalog signing (ed25519) is opt-in by key, fail-closed once a key is
set: with
SetCatalogPublicKey, a missing/invalid.sigis a refusal. Backlog: extend enforcement toinflections.json/fmt.json(rule: an optional file that exists must verify; its absence is fine). Any NEW runtime-fetched artifact must join this scheme from day one. - Releases: if a published version is broken/insecure, use
retractin go.mod (done for v0.16.3/0.16.4-alpha) — don't delete tags. - Docker: base images pinned (prefer digest pins for the final stage);
build-time ARG vs runtime env kept separate (
WINGS_DICT_LANGSis a build ARG by design); never bake private keys into images — the live-demo embeds only the public key, the private key + passphrase are demo-only dogfood.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 66 lines · 63 tokens per session scan A cf52355ae0f8
sec-supply-chain is a skill published in the GitHub repository luisfurquim/wings (29 stars, last pushed 1mo ago), licensed MPL-2.0. It adds 63 tokens to every session and 978 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
golang-testing
Go testing best practices including table-driven tests, test helpers, benchmarking, race detection, coverage analysis, and integration testing patterns. Use when writing or improving Go tests.
golang-patterns
Go-specific design patterns and best practices including functional options, small interfaces, dependency injection, concurrency patterns, error handling, and package organization. Use when working with Go code to apply idiomatic Go patterns.
ast-grep
Guide for writing ast-grep rules to perform structural code search and analysis. Use when users need to search codebases using Abstract Syntax Tree (AST) patterns, find specific code structures, or perform complex code queries that go beyond simple text search. This skill should be used when users ask to search for…
golang-testing
Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI…
golang-samber-oops
Structured error handling in Golang with samber/oops — error builders, stack traces, error codes, error context, error wrapping, error attributes, user-facing vs developer messages, panic recovery, and logger integration. Apply when using or adopting samber/oops, or when the codebase already imports…
golang-uber-fx
Golang application framework using uber-go/fx — fx.New, fx.Provide, fx.Invoke, fx.Module, fx.Lifecycle hooks, fx.Annotate (name/group/As), fx.Decorate, fx.Supply, fx.Replace, fx.WithLogger, and signal-aware Run(). Apply when using or adopting uber-go/fx, when the codebase imports go.uber.org/fx, or when wiring…