AI TOOLS RADAR
Tous les Skills / AICODEKING
aicodeking/deepseek-stack

ds-tdd

Fix a bug by first writing a focused test that fails for the right reason, then making the smallest change that makes it pass.

Voir la source

Mode d’emploi

  1. Copiez la commande et examinez le paquet avant de l’installer dans votre environnement agent.
  2. Consultez le document original pour les outils, identifiants et environnements requis.
  3. Décrivez les entrées et le livrable souhaité ; comparez la sortie aux sources.
npx skills add https://github.com/aicodeking/deepseek-stack --skill ds-tdd

Avant de commencer

  • L’installation n’inclut ni abonnement au modèle, ni quota API, ni accès aux fichiers.
  • Étoiles et installations reflètent l’activité, pas un test indépendant de qualité ou de sécurité.
Document Skill original

Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.

ds-tdd

Make the bug executable before touching production code, so the fix is proven, not claimed.

Steps

  1. Pin down the bug: expected behavior, actual behavior, the code path, and the smallest way to reproduce it.
  2. Find the nearest existing test style for that code path. Use it. Do not build a new harness just for this.
  3. Write the smallest test that would have caught the bug. It checks intended behavior, not the current implementation.
  4. Run it. Show the output. It must fail, and fail for the bug, not for a typo or missing import. If not, fix the test first.
  5. Make the smallest production change that gives the intended behavior without breaking nearby contracts.
  6. Run the new test and the surrounding suite. Show the output.
  7. If a clean test is impractical (heavy setup, brittle mocks, production-only state), use the closest runnable check instead: a script, a repro command or a log check. Say why you skipped the test.

Stop when

  • The new test failed before the fix and passes after it, both shown with output, and the surrounding suite passes.
  • Or after three fix attempts the test still fails. Stop, report what you learned and run /ds-unstick.

Rules

  • Never edit a test to match a wrong implementation.
  • Do not weaken existing assertions without a clear, stated reason.
  • No test beats a bad test: one that mostly tests mocks, depends on timing, or would be deleted right after.
du même dépôt

Autres Skills

Tous les Skills
aicodeking
Communauté

ds-adopt

Takes over an existing PR, branch or agent thread and finishes its original goal while keeping credit for the first contributors. Use when the user says take over, adopt, pick up or finish this PR, or /ds-adopt.

Installations / 1h
2
GitHub Stars
75
Mis à jour
28 oct.
MIT1 Fichiers
Voir les détails →
aicodeking
Communauté

ds-best-of-n

Run N independent attempts at the same task in parallel, pick the strongest as the base, and graft the best parts of the others into it. Use when one attempt at a non-trivial artifact could land on the wrong shape, or for /ds-best-of-n, 'try a few versions', 'best of 3'.

Installations / 1h
2
GitHub Stars
75
Mis à jour
28 oct.
MIT1 Fichiers
Voir les détails →
aicodeking
Communauté

ds-blast-radius

Find what a change could break outside its own diff, then prove the key safety fact by running real code. Use before shipping a risky or untrusted change, for 'what could this break', 'blast radius of X', or /ds-blast-radius.

Installations / 1h
2
GitHub Stars
75
Mis à jour
28 oct.
MIT1 Fichiers
Voir les détails →
aicodeking
Communauté

ds-blueprint

Design the types, function signatures and module layout first, agree on that shape, then implement against it. Use when work is non-trivial and coding straight away would lock in the wrong structure, or for /ds-blueprint, 'design this first', 'architect this'.

Installations / 1h
2
GitHub Stars
75
Mis à jour
28 oct.
MIT1 Fichiers
Voir les détails →