@shadowclone/cli 0.0.17 → 0.0.19

package/skills/prove-regression-tests/SKILL.md

@@ -1,33 +0,0 @@
----
-name: prove-regression-tests
-description: Prove that a regression test detects the defect it claims to guard by temporarily removing or inverting the enforcing change. Use when adding a test for a confirmed bug or review finding.
-metadata:
-  shadowclone-category: testing
-  shadowclone-section: workflow
-  shadowclone-applies-when: adding a regression test for a confirmed defect
----
-# Prove Regression Tests
-
-## Use when
-
-A confirmed defect has a focused test and a fix. Verify that the test can detect the original failure.
-
-## Process
-
-1. Identify the smallest production change that enforces the fix.
-2. Temporarily invert it to restore the defect while keeping the code compilable.
-3. Print the changed lines with file and line numbers. Run the narrow test and confirm its assertion fails on the original symptom.
-4. If it passes or fails for another reason, improve the test before claiming coverage.
-5. Restore and display the enforcing lines, then rerun the same test and affected suite.
-
-## Guardrails
-
-Keep the mutation local and reversible. Preserve unrelated work and avoid destructive Git operations. Mutate production behavior, not the assertion.
-
-A setup error, compilation failure, timeout, or unrelated assertion does not prove the regression. Restore the code before starting other work. Broaden the proof only when the fix covers distinct public behaviors.
-
-## Completion
-
-The visible inverse fails the intended assertion, restoration passes, and the final diff contains no proof mutation.
-
-Report the test name, the inverse you applied, the assertion line that failed under it, and the passing run after restoring. Keep the reply to these facts. When a pull request exists, put full command output in its verification section instead of the reply.

package/skills/testing-first/SKILL.md

@@ -1,35 +0,0 @@
----
-name: testing-first
-description: Build observable behavior through a red-green cycle at a stable public seam. Use when the user asks for test-first work, TDD, or a regression test before implementation.
-metadata:
-  shadowclone-category: testing
-  shadowclone-section: engineering
-  shadowclone-applies-when: changing observable behavior with a test-first workflow
-  shadowclone-axis: testing-approach
----
-# Test First Through a Public Seam
-
-## Use when
-
-Following a test-first workflow for behavior that a caller can observe. Settle the intended interface before choosing test structure.
-
-## Process
-
-1. State one behavior as concrete input and observable output.
-2. Write a test through the narrowest stable caller interface, using an expected result obtained independently of the implementation.
-3. Run it and confirm it fails because the behavior is missing or wrong.
-4. Implement the smallest complete slice that makes it pass, including every required layer.
-5. Repeat for the next behavior once the current test is green.
-6. Run affected checks and remove code justified only by an unwritten future test.
-
-## Guardrails
-
-Keep each cycle to one behavioral claim; several assertions can describe that outcome. Prefer real collaborators inside the module and replace dependencies only at established external boundaries.
-
-Do not weaken an assertion to make a failing implementation pass. If harmless refactoring breaks a test without changing behavior, move it to a more stable interface. Avoid recreating the production calculation to derive expected values.
-
-## Completion
-
-Requested behaviors have tests observed failing first, implementation passes through public interfaces, and affected checks pass.
-
-Report each test name with the assertion that failed first and its passing run, then the affected checks with their result. Keep the reply to these facts. When a pull request exists, put full command output in its verification section instead of the reply.

package/skills/testing-risk-based/SKILL.md

@@ -1,34 +0,0 @@
----
-name: testing-risk-based
-description: Select tests from concrete regression risk instead of applying test-first work to every edit. Use for changes where the user wants proportional coverage or where existing behavior may regress.
-metadata:
-  shadowclone-category: testing
-  shadowclone-section: engineering
-  shadowclone-applies-when: changing observable behavior with proportional test coverage
-  shadowclone-axis: testing-approach
----
-# Test Where Behavior Is at Risk
-
-## Use when
-
-Choosing coverage in proportion to a change's possible consequences.
-
-## Process
-
-1. Identify affected behavior and callers. Rank risks by consequence, likelihood, and existing coverage.
-2. Read nearby tests for the established public interface and fixture style.
-3. Cover material gaps with the smallest fixture that crosses the real failure boundary.
-4. Run focused tests and the repository checks covering affected consumers.
-5. Define any necessary manual check with its setup, action, and expected result, then report what remains unverified.
-
-## Guardrails
-
-Prioritize state changes, permissions, persistence, parsing, routing, and public contracts. Reuse existing coverage when it already detects the regression.
-
-Skip tests that mirror private branches or assert reversible text and styling changes unless those details are a supported contract. Keep expected results independent of production calculations and avoid redundant cases for the same risk.
-
-## Completion
-
-Each material risk has a meaningful automated or manual check, selected checks have run, and remaining uncertainty is explicit.
-
-Report each material risk with the check that covers it and its result, and each risk left uncovered with the reason. Keep the reply to these facts. When a pull request exists, put full command output in its verification section instead of the reply.