Claude Skills by d4rkNinja

Use when thinking through, reviewing, changing, or verifying an AI or LLM system: RAG, model routing, memory, tool use, autonomous or multi-agent workflows, safety, evaluation, latency, cost, or rollout. Trigger when model, data, policy, tool, or approval boundaries are central. Use system-architecture-harness for surrounding non-AI architecture and architecture-review-gate for an independent approval gate.

Use when thinking through, reviewing, changing, or verifying APIs and client contracts: endpoint design, validation, errors, pagination, filtering, bulk behavior, versioning, serialization, webhooks, realtime channels, SDKs, or CLIs. For whole-system architecture use system-architecture-harness; for identity and permissions use auth-access; for event delivery use async-messaging; for compatibility rollout use migration-evolution.

Use when independently reviewing or verifying an architecture specification, RFC, ADR, diagram, migration plan, AI or agent design, production-readiness proposal, architecture metrics, or post-incident structural causes. May frame review criteria or recommend bounded remediation, but does not own greenfield design or repository changes. Use pull-request-review-gate for concrete pull-request, patch, or code-diff content review.

Use when thinking through, reviewing, changing, or verifying asynchronous work: jobs, workers, schedules, queues, events, outbox or inbox, batch processing, deduplication, email, or notifications. For transaction invariants use transactions-consistency; for retry and overload controls use resilience-flow-control; for event evolution use migration-evolution.

Use when thinking through, reviewing, changing, or verifying identity and access behavior: login, signup, recovery, sessions, tokens, OAuth/OIDC, MFA, passkeys, API keys, service identity, permissions, account lifecycle, tenant isolation, or privileged administration. For whole-system architecture use system-architecture-harness; for API contracts use api-contracts; for secrets and cryptography use security-privacy.

Use when thinking through, reviewing, changing, or verifying data models and storage behavior: schemas, identifiers, time, money, constraints, indexes, queries, deletion, lifecycle, files, media, search, provenance, authority, reconciliation, or cleanup. For concurrency use transactions-consistency; for schema evolution use migration-evolution; for caching use resilience-flow-control.

Use when thinking through, reviewing, changing, or verifying Git repositories and version-control workflows: branches, commits, merges, rebases, cherry-picks, conflicts, worktrees, remotes, pull-request workflows, hosted review state, protected refs, force pushes, tags, semantic versions, release branches, history rewrites, secret removal, merge queues, Git-aware CI, repository migrations, recovery, or source-to-artifact provenance. Distinguishes local Git state from hosted policy, authorizat...

Use when thinking through, reviewing, changing, or verifying data and contract evolution: schema migrations, expand-and-contract, resumable backfills, API or event compatibility, synchronization, CDC, reindexing, traffic cutover, or legacy integration. For outbox and inbox delivery use async-messaging; for transaction invariants use transactions-consistency; for deployment mechanics use runtime-delivery.

Use when thinking through, reviewing, changing, or verifying production operations: logs, metrics, tracing, health, audit, async observability, runbooks, incidents, import or export, backup, restore, disaster recovery, high availability, multi-region, or residency. For rollout sequencing use migration-evolution; for independent review use architecture-review-gate.

Use when independently reviewing a concrete pull request, merge request, commit range, patch, or repository diff for merge readiness: apply repository instructions, documented contracts, applicable ArcForge domain rules, and current candidate evidence; identify correctness, security, compatibility, regression, test, and maintainability issues; deduplicate root causes; distinguish evidence gaps, likely or verified false positives, and nits; return fix-formatted findings, a deterministic instru...

Use when thinking through, reviewing, changing, or verifying quality and release readiness: test strategy, test data, concurrency and failure testing, load and performance evidence, scalability, resource management, compression, release exceptions or waivers, cross-domain completion, and production-ready claims. For independent architecture approval use architecture-review-gate; for concrete pull-request or code-diff content review use pull-request-review-gate; for SLO design use system-archi...

Use when thinking through, reviewing, changing, or verifying resilience and flow controls: caches, invalidation, rate limits, quotas, external integrations, retries, timeouts, circuit breakers, bulkheads, degradation, backpressure, or admission control. For queue delivery use async-messaging; for transactional effects use transactions-consistency; for whole-system capacity use system-architecture-harness.

Use when thinking through, reviewing, changing, or verifying runtime and delivery foundations: project structure, bootstrap, configuration, connection pools, networking, discovery, service communication, graceful startup or shutdown, deployment gates, CI/CD, migration ordering, or infrastructure configuration. For schema evolution use migration-evolution; for telemetry use production-operations.

Use when thinking through, reviewing, changing, or verifying security and privacy controls: secrets, encryption, TLS or PKI, cryptography, hashing, sensitive-data lifecycle, redaction, abuse defense, feature flags, temporary data, or secure randomness. For identity flows use auth-access; for public contract attacks use api-contracts; for whole-system threats use system-architecture-harness.

Use when thinking through or changing a production software architecture, or when reviewing or verifying architecture work inside the same design flow: greenfield systems, decomposition, migration, scale, reliability, security, data ownership, distributed workflows, clients, platform governance, or rewrites. Use architecture-review-gate for an independent approval gate and ai-agent-system-architecture when model, data, tool, or approval boundaries are central.

Use for an unqualified ArcForge routing question when the user asks which skill, mode, or order to use and has not explicitly asked to inspect, review, change, or verify yet: name the owning skill, mode, sequence, companions, and coverage gaps, then stop. When the owner is already named and only its mode or handoff is asked, confirm it in a compact short circuit. Read-only by contract. Use using-forge only when the user explicitly asks routing to continue into the work.

Use when thinking through, reviewing, changing, or verifying transactional or concurrent behavior: isolation, anomalies, locking, state machines, idempotency, sagas, consistency, replication, sharding, consensus, distributed locks, fencing, or ordering. For jobs, queues, and outbox delivery use async-messaging; for retries and timeouts use resilience-flow-control.

Use when a request needs ArcForge routing and explicitly asks to continue into inspection, review, change, or verification: choose the owning skill, choose Think, Review, Change, or Verify, resolve required, recommended, handoff, and optional-depth companions, sequence the work, then begin the routed first step. Produces an ordered routing plan with handoff payloads and names any skill that is not installed. Use think-forge for an unqualified route-only question.