Claude Skills by ModernNomad-98

Orchestrate a whole-repo security scan and aggregate it into ONE prioritized report — coordinate the static suite (SAST + dependency/SCA + secret + IaC/config scanning), normalize every scanner''s output into one finding schema, and route it. It RUNS and AGGREGATES; it does NOT triage findings (finding TRIAGE is static-analysis-reviewer''s — yield) and NEVER fixes, opens PRs, or changes settings — every action is handed to a human. Tool-agnostic (scanner CATEGORIES, not one vendor''s CLI). Fa...

Prevent an LLM feature from disclosing sensitive information (OWASP LLM02) — audit and design the data-minimization and redaction pipeline so secrets, credentials, PII, and other-tenant data are stripped BEFORE they enter model context, prompts, or logs; assemble context with least-data (only the fields the task needs, not whole records); check the output path for leaks (the model echoing sensitive input, cross-conversation/cache bleed); and confirm provider data-handling posture (retention, ...

Design full-tier validation as named functional shards with resume: a shard map assigning every test/check to exactly one shard, a persisted status file, resume that reruns ONLY unfinished shards after a timeout/infrastructure interruption (passes are kept; real FAILURES are never resumed-away), an "uncategorized" catch-shard that fails until new tests are assigned, and parallel shards funneling into ONE aggregate gate job as the sole required check — so docs-only conditional skips can''t str...

Design guest/public share-link access for a multi-tenant SaaS — a CAPABILITY model where possession of an opaque, high-entropy, expiring, revocable token grants a fixed narrow scope, distinct from member RBAC: token design, ephemeral guest sessions (not memberships), optional password/OTP gating, per-link scope (which resource, which permission), enumeration/abuse defense, and audit. The link must expose exactly the shared resource and never become a hole into the rest of the tenant. Use when...

Plan the safe retirement of a library skill — the lifecycle end. Establishes the trigger (superseded with a coverage diff, absorbed as an extension, evidence-backed disuse, defect), runs the reverse-link sweep (every neighbor description, trigger-eval, catalog/README row, or agent definition naming the skill gets a disposition), then stages the exit — mark (successor named), redirect for a grace window, remove (registration rows moved to a retired record, never silently deleted) — each stage ...

Review ONE library skill''s quality — the judgment layer above scripts/validate-skills.py. Runs the mechanical validator first (structure/lengths/registration/name collisions are its job — never re-checked), judges what it cannot: description trigger-oriented ("use when <situation>") vs merely descriptive; trigger collision with shipped skills, colliders NAMED (the main failure mode across the full shipped skill corpus); duplication better shipped as an EXTENSION (the LLM03/ASI04 pattern); ev...

Design usage instrumentation for a skill library — the evidence layer answering which skills actually FIRE in practice. Covers per-invocation signals (skill name, auto-trigger vs explicit call, coarse task class — never prompt content or user identifiers), wrong-fire/correction signals, never-fires detection over a stated window, evidence tiers (host-recorded vs self-reported), and thresholds turning counts into action (fix a trigger, split, or hand an evidence package to skill-deprecation-pl...

Derive SLOs from user journeys, not infrastructure — inventory the journeys users depend on, select symptom-based SLIs per journey (availability, latency percentiles, correctness, freshness — measured where users experience them, blind spots named), set targets with error budgets in user-meaningful units, design burn-rate alerting where PAGES fire on symptoms/budget burn and causes (CPU, restarts, queue depth) go to tickets, analyze failure modes against the targets, and define the error-budg...

Scope a SOC 2 engagement — an AICPA ATTESTATION (a CPA''s examination of controls against the Trust Services Criteria), NEVER a certification. Decides the system boundary, which TSC categories the report covers (Security baseline plus optional Availability, Processing Integrity, Confidentiality, Privacy — selected by customer commitments, not ambition), and Type 1 (design as of a date) vs Type 2 (plus operating effectiveness over a period), window planning handed to compliance-evidence-collec...

Audit the library''s skills that cite external sources against a known-good source list, and flag every citation older than a stated threshold (N months) — or superseded/broken — for re-verification. The broad currency sweep: inventory external-source citations across all skills (standards editions, external docs/URLs, research, tool versions, prices/limits, dated facts), check each against a known-good list, flag stale/broken/superseded citations with the reason, and prioritize by how load-b...

Resolve conflicts between current user instructions, repo docs, code, tests, PR history, and older chat or memory context before acting on any of them. Use when two sources disagree (a doc says X, the code does Y), when instructions reference repo state that no longer exists, when planning docs overlap or contradict, or when remembered context conflicts with what the repo actually contains. Produces a precedence-ordered reconciliation with cited evidence (file:line) and surfaces every assumpt...

Help a staff+ IC (or one aspiring) choose the highest-leverage SCOPE to work on — not "what task is assigned" but "what should I pick to maximize impact at my level?". Identify the org's important under-owned problems, match them to leverage archetypes (multiplier/unblocking work, direction-setting, hard problems others avoid, critical glue) and the person's strengths, avoid the traps (only-fun-work, only-firefighting, scope too narrow for the level, invisible glue with no attribution, over-r...

MANUAL-ONLY; never auto-invoke. Design the GOVERNED anti-approval-fatigue layer: a documented standing approval for the mechanical delivery loop (push, PR, monitor CI, fix red, pull) within NAMED scope; a phase-advance rule covering only already-named-and-approved phases; a prompt pattern restating the standing approval each session; an explicit opt-out phrase; and a reviewer-block path that suspends the loop. Merge-after-green is templated ONLY as an explicit opt-in deployment-profile choice...

Author the Statement of Applicability — the ISO-mandatory document tying every reference control to a per-control inclusion or exclusion justification through the 6.1.3 risk-treatment process; serves BOTH ISO 27001:2022 (Annex A controls) and ISO 42001:2023 (Annex A control objectives) from one procedure. Rows record include/exclude with a risk-or-obligation trace, implementation status mapped to the compliance-control-foundation catalog, and controlled-document metadata (version, named appro...

Triage SAST / CodeQL / SARIF / linter-security output on first-party code into what actually matters — sort each finding into true-positive, false-positive, duplicate, or accepted-risk, and rank the true positives by reachability, exploitability, asset sensitivity, tenant impact, and business impact. Confirms each true positive against the real code (a scanner hit is a lead, not a verdict), requires an exploit path for high-severity, and outputs a triaged, deduplicated, prioritized remediatio...

Design the INTERNAL event/streaming data backbone between services and stores — topic/stream taxonomy, partitioning and key choice (ordering stated as "per key, unordered across keys"), delivery semantics stated honestly (at-least-once with idempotent consumers; "exactly-once" claims interrogated), consumer groups, retry/dead-letter policy with replay procedure, retention vs compaction, backpressure/lag handling, event-schema compatibility rules, and CDC ingestion from operational stores. Thi...

Design the schema and validation strategy for an LLM''s structured output so downstream code never trusts an unvalidated response — define the output contract (fields, types, enums, ranges, formats), encode it in TYPES where possible so non-compliant output is unrepresentable, and walk every response up the ladder BEFORE use: parse → strict schema → policy/banned-content scan — failures logged as safety evidence and rejected, never silently repaired — plus bounded failure handling and semanti...

Plan and communicate the sunset or deprecation of a PRODUCT feature or public API to the USERS and integrators who depend on it — establish the (already-made) decision's rationale, assess impact (who uses it, what breaks), define the migration path to the replacement, set a timeline with a deprecation window and a firm sunset date, and build the multi-channel escalating communication plan (announcement, in-app, docs, reminder emails; for APIs deprecation/sunset headers + changelog), plus gran...

Design the cross-tenant superadmin OBSERVABILITY/monitoring console for a multi-tenant SaaS — the surface operators use to SEE platform health (signups, DB health, security, cost, incidents): layered panel IA (one health answer first, drill-downs, escalation badges, restraint), the cross-tenant READ-security model (deny-all-RLS platform-admin registry, no self-service grant, three-layer server-side re-check, read-only-by-default with privileged-write-only telemetry, denied-access-as-metric, b...

Review software supply-chain risk with SLSA-style provenance thinking — dependencies (CVEs triaged by reachability, not presence), lockfile integrity/pinning, transitive/typosquat/confusion risk, install and build scripts, CI/CD workflows (untrusted PR triggers, secret exposure, token scopes, unpinned Actions), artifact provenance, and postinstall/hook execution. Extends to the AI/ML (LLM03: models, datasets, fine-tuning adapters) and agentic (ASI04: MCP servers/manifests, tool/skill registri...

Design ongoing black-box PRODUCTION monitoring — scheduled synthetic probes/journeys against the LIVE app and third-party deps from outside: the probe catalog (critical journeys + dependency health + heartbeat/canary), a HARD prod-safety contract (probes never mutate real data, never leak test fixtures, use ring-fenced synthetic accounts, self-clean), synthetic SLIs + alert-on-failure, and result capture/routing to a runbook. Produces the probe catalog, prod-safety contract, synthetic-SLI + a...

Review an LLM feature for system-prompt leakage (OWASP LLM07) on two axes — (1) CONTENTS: the system prompt must contain no secrets, API keys, credentials, connection strings, internal URLs/architecture, or access rules whose disclosure causes harm; and (2) DEPENDENCE: the system must not RELY on the prompt staying secret for security, because prompts are extractable and are NOT a security control. Enforcement of authz, filtering, and limits must be deterministic and live OUTSIDE the model. P...

Drive an unknown-cause bug to its root cause through the fixed sequence reproduce → reduce → isolate → fix one thing → verify → prevent, with evidence at every step and no shotgun fixes. Use when something fails and the cause is not yet known — an intermittent failure, a regression since a release, wrong output with no obvious source, an error only in one environment. Ranks hypotheses and proves or disproves them instead of guessing; changes exactly one thing per fix attempt; never calls a sy...

Implement behavior test-first with a strict red-green-refactor loop — write the failing test, run it, CONFIRM it fails for the intended reason (not a typo, import error, or wrong assertion), implement the minimal change to pass, and refactor only once green. Reports the exact commands run and their real output at every step. Use when the user asks for TDD or "tests first", when adding new behavior with a clear testable contract, when fixing a bug that should get a regression test proving the ...

Write a TECHNICAL SPEC / design doc for a non-trivial engineering effort — broader than an ADR: problem/context, goals and non-goals, the proposed technical design (architecture, data model, APIs, components and how they interact), alternatives considered, cross-cutting concerns (security, privacy, performance, observability, migration/rollout, testing), risks and open questions, and a review/sign-off path. A tech spec covers the WHOLE design of a change (often several decisions); an ADR reco...

Review an existing multi-tenant system or design for cross-tenant leakage across EVERY surface — identity, data, API, storage, logs, analytics, support tooling, exports, imports, background jobs, search, AI retrieval, billing, feature flags, and audit — not just the database. Produces severity-ranked isolation findings with file:line evidence, an isolation test matrix per surface, negative tests proving tenant A cannot reach tenant B's data, and an explicit not-inspected list. Use when asked ...

Define the tenant model for a SaaS product — what a tenant IS (organization, workspace, account), the hierarchy between those concepts, user-to-tenant membership (roles attached to membership, invitations, users in multiple tenants), ownership semantics, and the full tenant lifecycle from provisioning through suspension to offboarding and purge. Produces a tenant model definition, a lifecycle state machine with per-state access/billing/data posture, and a membership + invitation model. Use wh...

Audit what the EXISTING tests actually cover — map requirements, risks, and code surfaces (routes, commands, services, schema, jobs) to the tests that exercise them, then rank the uncovered critical paths by risk. Distinguishes real verification from tests that execute code without asserting behavior. Produces a coverage map, a risk-ranked gap list, and a recommended fill order at the cheapest reliable layer. Use when asked what the tests cover, what's untested, whether coverage is good enoug...

Design the test-data strategy across all test layers — deterministic seed/fixture/factory design (personas, tenants, roles, stable ids), per-layer data sources (inline builders for unit, seeded DB for integration, API-created fixtures for E2E), parallel-run isolation (worker-scoped namespacing, no shared mutable records), PII-safe synthetic data (never production copies without an approved anonymization path), cleanup/TTL and traceability rules, and seed evolution coupled to schema changes. U...

Design the concrete test plan for ONE feature, change, or release — the requirement/risk being verified, in-scope and out-of-scope items, the test-layer split for THIS change (what is automated at which layer, what is manual), test data needs, environment assumptions, entry/exit criteria, named artifacts, and CI placement. Every planned test traces to a requirement or risk; the plan is executable by someone who didn't write it. Use when asked to write a test plan for a feature/release/bugfix,...

Build a threat model for a feature or system BEFORE it is implemented — assets, actors, trust boundaries, data flows, STRIDE-style threat enumeration per boundary, abuse cases written from attacker behavior, risks ranked with concrete exploit paths, mitigations mapped to each threat, and a validation test plan with negative tests per mitigation. Use when designing a security-sensitive feature (auth, uploads, payments, integrations, admin/support tooling), when asked to "threat model" somethin...

Design the metering → pricing → rollup → reconciliation DATA PIPELINE for a multi-tenant SaaS — a billing-safe usage-event table (metadata only, no message/file CONTENT), time-bounded rate cards, cost entries carrying idempotency keys so replays and retries never double-bill, additive rollups (an analytical projection), budgets + breach alerts, spend forecast, and reconciliation of metered totals against provider invoices. Produces the event schema, rate-card model, idempotent cost-entry cont...

MANUAL-ONLY; never auto-invoke. QA the Vite build itself — run the production build and PROVE no secret reached the client bundle (audit VITE_-prefixed env vars, grep dist output for secret values and patterns, check define/import.meta.env usage), verify build vs preview vs dev behavior parity (mode/env-file resolution, base path, asset and dynamic-import URLs), inspect bundle output (size budgets, unexpected inclusions, sourcemap policy for production), and validate preview serving of the bu...

MANUAL-ONLY; never auto-invoke. Implement and run Vitest unit and component tests — pure logic, validators, reducers, mappers, state machines, and UI components in isolation. Chooses the test environment INTENTIONALLY per file (node for logic, jsdom/happy-dom only where DOM is real), uses Testing Library user-facing queries for components, mocks only at owned boundaries, asserts behavior not implementation, and reports the exact commands run with real pass/fail output. Use when asked to write...

Design the analytical data estate a multi-tenant SaaS reports and learns from — warehouse vs lake vs lakehouse decided by workload and team maturity (not fashion), layered zones (raw → conformed → curated marts) with ownership and contracts per zone, modeling per mart (dimensional vs wide tables, slowly-changing-dimension policy), partitioning and format choices tied to query patterns, catalog and access governance, tenant scoping carried into analytics (tenant key mandatory in every zone; pe...

Records a decision note after content-specific approval. Use when a decision needs recording.

Ship the release build to users.

Routes a project through its stages. Use when the next stage owner is unclear.

Formats diagrams for readability. Use when a diagram needs consistent layout.

Builds a delivery roadmap organized by horizon. Use when planning a release.

Captures meeting outcomes. Use when outcomes must outlive the meeting.

Records approval decisions for scope changes. Use when an approval must be recorded.

Read-only review of build configs; changes nothing in the repository.

Audits documentation links. Do NOT use for diagram formatting (clean-skill).

Maintains the project log file. Use when the log needs an entry.

Summarizes changelogs. Use when a changelog needs a summary.

NEUTRAL SYNTHETIC TEST-FIXTURE SOURCE for `scripts/tests/test_validator.py`, not a shipped skill. It is stored under a neutral `dot-claude/` directory on purpose: `test_docs_paths_links` copies this `paths-tree` fixture into a throwaway temporary repository and materializes `dot-claude` -> `.claude` ONLY there, so the link-resolution cases run against a real `.claude/skills/...` target without this file ever living under a literal `.claude/skills/` path in the tracked tree. WHY the neutral la...

SYNTHETIC TEST FIXTURE, not a shipped skill: the canonical-shape SKILL.md that validate-skills.py must accept with zero errors. Use when running scripts/tests/test_validator.py; any error reported against this file is a real validator regression.

SYNTHETIC TEST FIXTURE, not a shipped skill: this description is deliberately padded past the 1024-character ceiling that validate-skills.py enforces on the strict-PARSED description value, so scripts/tests/test_validator.py can prove the parsed-length check still fires rather than merely asserting that it exists. The ceiling matters because external Agent-Skills consumers measure the parsed value and not the raw line: quoting characters and doubled apostrophes are serialization rather than c...

SYNTHETIC TEST FIXTURE, not a shipped skill: identical to good-skill except that the Stop Conditions section is deliberately absent, proving the required-section presence check still fires.