Is loadout-system-design safe to install?

SaferSkills independently audited loadout-system-design (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.claude/skills/loadout-system-design/SKILL.md · 1 file

.claude/skills/loadout-system-design/SKILL.md4.2 KB · Markdown

name: loadout-system-design

description: >

Complete system design reference for the Loadout VSCode extension — a GUI panel for

managing Claude Code agents, skills, and commands as swappable equipment loadouts.

Use at the start of ANY implementation task to ensure design consistency. Covers:

two-process architecture (Extension Host Node.js + Angular 21 Webview), postMessage

protocol, data.js filesystem layer, signal-based state services, storage layout, and

non-negotiable coding rules. Invoke when implementing stories, adding features,

reviewing code, making ANY UI/styling change (design tokens, SCSS, components,

animations), or when any system design question arises in Loadout.

Loadout — System Design Reference

What you need	Load
Two-process overview, file map, state flow, build pipeline	references/architecture.md
Extension entry, src/ modules, data.js API, security model	references/extension-host.md
Angular 21, state services, DataSyncService, shared primitives	references/webview-angular.md
Full message catalogue (WebviewMessage + ExtensionMessage types)	references/messaging-protocol.md
Domain types, storage paths, profiles, hash/sync mechanics	references/domain-storage.md
File size limits, CommonJS rules, Angular rules, git, formatting	references/coding-rules.md
Design tokens, color palettes, SCSS mixins, animations, a11y	references/ui-design-system.md

Non-negotiable invariants

These apply everywhere, always — no exceptions.

No VSCode API in webview — never import vscode or use fs/path/os from any file under webview/.
All filesystem mutations go through `data.js` — no ad-hoc fs.writeFileSync in src/ modules.
Every Angular component: standalone: true + ChangeDetectionStrategy.OnPush — no exceptions.
*State in `core/state/.state.ts` signal services only** — components are dumb views; no component-local mutable state for domain data.
Signals for state, RxJS only for the bridge stream — no BehaviorSubject / ReplaySubject for state.
File size cap ~400 lines — split into a new src/ module or Angular subcomponent when approaching this.
Profiles store filenames only — never copy file content into profiles.json.
Icons: `lucide-angular` only — no SVG file imports, no inline <svg>.
CommonJS in extension host — require() / module.exports in all .js root files; update-claude.mjs is the sole ESM exception.
Build `webview-dist/` before committing UI changes — run cd webview && npm run build.

Feature implementation checklist

When adding a new feature end-to-end, follow this order:

Domain — add or extend types in webview/src/app/core/messages.ts (single source of truth for all shared types).
Storage — decide persistence: profiles.json, ui-state.json, or a new data.js function. Update data.js and src/snapshot.js::buildInitialData if InitialData changes.
Extension messages — add the WebviewMessage union variant and/or ExtensionMessage variant to messages.ts; handle the new case in src/message-handler.js.
data.js — implement the filesystem operation (pure I/O, no VSCode API, no side effects beyond fs).
State service — update the relevant core/state/*.state.ts to expose new signals or a setter; update DataSyncService.applyData() if InitialData fields changed.
Component — create a standalone OnPush component or extend an existing feature. Inject the state service; never own domain state locally. Send actions via bridge.send() in methods, not templates.
Validators — if new user-supplied input crosses the bridge, add a guard in src/validators.js and call it in message-handler.js before acting.
Build — run cd webview && npm run build, verify webview-dist/ is updated.
Git — stage specific files by name; conventional commit in imperative mood.

loadout-system-design— agent skill

Is loadout-system-design safe to install?

Loadout — System Design Reference

Quick Navigation

Non-negotiable invariants

Feature implementation checklist

Audit the pieces. Scan the whole. Decide.