darkmatter/skills

when-to-write-tests

Decide whether a new test is needed.

Zobacz źródło
Oryginalny dokument Skill

Treść z repozytorium z zachowaniem nagłówków, przykładów, kodu, tabel, linków i obrazów.

When to write tests

Test observable behavior through the capability's interface. Follow codebase-design for the shared rules and examples. Prefer a few tests that cover real behavior over a test for every private helper.

Default

No new test.

Smoke the changed path (run the thing). That is verification.

Write a test only when

  • The user asked for one, or
  • A public observable contract is new, changed, or has a reproduced bug that existing tests do not cover (store API, HTTP route, migration backfill, public calculation).

Choose the smallest test that exercises that contract through its interface. For a store, use the real persistence path where practical. For a public pure function, assert its input/output behavior directly. Test failure, ordering, and cleanup when they are part of the contract; do not add a layer of tests for private helpers or assertions about internal calls.

Put it next to the source as <file>.test.ts, not in a separate test/ or tests/ directory. Only a test that spawns the real server or CLI, or spans packages, goes in the repo-root tests/.

Do not write a test for

  • Comment / docs-only edits
  • Internal helpers, encoders, or bind-list rewrites already covered by behavior tests
  • "Every new function/method"
  • Edges an advisory invented that are not the contract
  • Refactors that keep the same public behavior (existing tests are the regression net)

Apply repository requirements

Current user instructions and repository requirements take precedence over this skill. Check existing coverage before adding tests; a required regression test should reproduce the observable bug, not freeze its current implementation. Do not invoke TDD merely because a helper was added or moved. A successful smoke check is useful verification, but does not replace a required automated test.

Fair example

Seed old inbound tables, apply the migration, list events, assert facts and metadata survived and the matches table is gone.

Unfair example

A test per helper or per comment rewrite. Asserting that saveInvoice called private insertRow rather than that the invoice was saved.

z tego samego repozytorium

Więcej Skills

Wszystkie Skills
darkmatter
Społeczność

alchemy

Configure, develop, deploy, review, and troubleshoot Alchemy v2 infrastructure for Darkmatter TypeScript/Effect apps. Triggers for alchemy.run.ts, alchemy dev, public preview URLs, webhook testing, Cloudflare/AWS providers, stages, profiles, state stores, bindings, CI deploys, or examples from alchemy-run/alchemy-effect. Prefer Alchemy for new org deploys. Do NOT trigger for unrelated blockchain Alchemy APIs unless the user explicitly means alchemy.run.

instalacje
2
GitHub Stars
0
Aktualizacja
26 wrz
darkmatter
Społeczność

codebase-cleanup

Multi-pass refactor / code-quality cleanup designed to be dispatched as 8 specialist subagents (one per cleanup concern), each running a research → critical-assessment → high-confidence-implementation cycle. Triggers on "clean up the codebase", "tech-debt pass", "refactor for quality", "find dead code", "remove AI slop", or any explicit request for a comprehensive quality sweep. Do NOT trigger for narrow targeted fixes ("remove this one function") or for net-new feature work.

instalacje
2
GitHub Stars
0
Aktualizacja
26 wrz
darkmatter
Społeczność

darkmatter-design-system

Default design system — darkmatter's dark-first, terminal-inspired design system , built on Tailwind CSS v4, React 19, and Radix UI. Use this as the default design system when working in an app that does not already have an established design system or guidelines. Use it for dashboards, trading/monitoring consoles, forms, tables, settings, navigation, or any screen that should look and feel like darkmatter's brand. This is the canonical source for darkmatter components, tokens (the OKLCH --n- ra

instalacje
2
GitHub Stars
0
Aktualizacja
26 wrz
darkmatter
Społeczność

darkmatter-gitops-conventions

Safe-change playbook for the darkmatter/gitops repo — validation before commit (kubeconform with CI-identical flags, yq for YAML manifests, jq for SOPS JSON, git diff --check), sha-pinned images, KSOPS/SOPS secret editing rules, rollback via revert, and how ArgoCD reconciles. Use for ANY change to darkmatter/gitops (manifests, Helm values, apps/.yaml, secrets), when asked to bump an image tag, wire a secret, or roll back a deploy. Also use when tempted to kubectl apply/edit/patch anything — the

instalacje
2
GitHub Stars
0
Aktualizacja
26 wrz