@shadowclone/cli 0.0.9 → 0.0.12

package/skills/resolve-conflicts-by-intent/SKILL.md

@@ -10,32 +10,23 @@ metadata:
 
 ## Use when
 
-Use this skill only while a merge or rebase is in progress. A conflict is a disagreement between changes, so the correct result comes from understanding both changes rather than choosing the side with newer text.
+A merge or rebase is in progress and Git reports conflicts.
 
 ## Process
 
-1. Inspect the Git operation, conflicting paths, current branch, and commits being combined.
-2. Read each conflicted file with enough surrounding code to understand the affected behavior.
-3. Find the primary source for both sides: commits, pull requests, issues, design records, tests, and nearby callers.
-4. State the intent of each side before editing the hunk.
-5. Decide whether both intents can coexist. When they cannot, choose the intent that matches the merge goal and record the lost behavior for review.
-6. Resolve one hunk at a time in the current architecture. Avoid introducing a third design that neither side requested.
-7. Search the full file for related names and assumptions that Git did not mark as conflicts.
-8. Run focused checks after each coherent file group, then the repository's merge gate.
-9. Stage resolved files and continue the Git operation until no conflicts remain.
-10. Inspect the combined diff against both original intents before reporting completion.
+1. Inspect the operation, conflicting paths, and commits being combined.
+2. Read surrounding code and the commits, design records, tests, or review discussions explaining each side.
+3. Identify both intended behaviors. Preserve compatible requirements; ask about incompatible outcomes when the merge goal does not settle them.
+4. Resolve each hunk in the current architecture. Check related names and assumptions outside Git's conflict markers.
+5. Run focused checks and the repository's merge gate. Separate new failures from failures present on either parent.
+6. Stage resolutions and finish the authorized operation. Review the combined diff against both original intents.
 
 ## Guardrails
 
-- Use whole-file ours or theirs only when one side's entire file is intentionally obsolete.
-- Preserve schema changes, migrations, generated artifacts, and tests as one coherent set.
-- Treat rename and delete conflicts as behavior decisions rather than path cleanup.
-- Keep conflict markers out of the staged tree.
-- Separate failures introduced by the merge from failures already present on either parent.
-- Finish the requested merge or rebase after resolution unless a destructive or irreversible choice needs user input.
+Use whole-file ours or theirs only when that entire side is intentionally obsolete. Keep schema changes, migrations, generated artifacts, and tests coherent. Rename and delete conflicts can change behavior.
 
-When intent remains ambiguous after reading primary sources, present the exact incompatible outcomes and the evidence for each. Ask about that decision instead of guessing from line order.
+Avoid introducing an unrelated third design. Remove all conflict markers and preserve unrelated user edits. Follow the repository's approval requirements for Git operations.
 
 ## Completion
 
-Resolution is complete when Git reports no unmerged paths, each hunk has a stated intent-based result, the combined behavior passes relevant checks, the operation has finished, and the final diff preserves every compatible requirement from both sides.
+No unmerged paths remain, compatible requirements survive, checks cover the combined behavior, and the authorized operation is finished.

package/skills/scope-confirmed-changes/SKILL.md

@@ -10,32 +10,22 @@ metadata:
 
 ## Use when
 
-Use this skill when nearby cleanup, defensive cases, or architectural improvements could easily expand a concrete correction. The scope boundary is the observable failure or requested outcome.
+Fixing a defect or review finding, or making a change whose scope should stay narrow.
 
 ## Process
 
-1. State the defect as reachable input followed by incorrect observable behavior, or state the requested outcome in equally concrete terms.
-2. Trace the path that produces it and confirm the current code can reach that path.
-3. Sort candidate edits into required, supporting, and unrelated changes.
-4. Keep required edits that directly change the outcome.
-5. Keep a supporting edit only when the required change cannot remain correct or testable without it.
-6. Leave unrelated cleanup, speculative guards, and style changes outside the diff.
-7. Add or update the narrow test that expresses the confirmed behavior through its public seam.
-8. Read every final hunk and map it back to the stated defect, outcome, or necessary verification.
-9. Commit each later review round separately so reviewers retain a stable history.
+1. State the reachable input and incorrect behavior, or the requested outcome.
+2. Trace the current path and verify the finding against the working branch.
+3. Keep edits that correct the outcome, plus supporting changes required for correctness or verification.
+4. Leave unrelated cleanup and speculative guards outside the diff.
+5. Verify the behavior through a stable public interface and map each final hunk back to the request.
 
 ## Guardrails
 
-- Verify a review finding against the current branch before changing code.
-- Reject cases that cannot occur under the validated input and type boundaries.
-- Avoid widening public contracts to accommodate an internal implementation shortcut.
-- Keep refactors only when they create the seam required to fix or test the behavior.
-- Preserve unrelated user edits and existing style.
-- Use a separate proposal for improvements that do not affect the confirmed outcome.
-- Never rewrite pushed history to make a correction look like the first attempt.
+Preserve unrelated user edits and existing style. Do not widen a public contract to accommodate an internal shortcut. Refactor only when the requested fix or its verification needs it.
 
-When a proposed fix causes a different observable regression, remove that approach and return to the confirmed failure. Do not accumulate compensating changes around a wrong fix.
+If an approach causes another regression, remove that approach and reconsider the cause. Avoid layering compensating changes onto a wrong fix. Keep later review rounds in separate commits when authorized; never rewrite pushed history.
 
 ## Completion
 
-The change is complete when the original behavior is corrected, its focused verification passes, every diff hunk maps to the requested outcome, unrelated observations are left out, and the commit history preserves each pushed correction round.
+The requested outcome works, focused verification passes, and every hunk has a reason within scope.

package/skills/testing-first/SKILL.md

@@ -11,34 +11,23 @@ metadata:
 
 ## Use when
 
-Use this skill when a behavior can be exercised through an interface that callers already use, or through the interface the change is intended to create.
-
-Before writing a test, identify the observable result and the seam where a real caller sees it. If the seam is unclear, settle the interface before committing to test structure.
+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. Name the user-visible failure the test must detect.
-2. Find the narrowest stable seam that reaches the behavior without exposing private implementation details.
-3. Write one test through that seam with an expected value independent of the implementation.
-4. Run only that test and confirm it fails because the behavior is absent or wrong.
-5. Implement the smallest vertical slice that makes the test pass. Include every layer required for that one behavior.
-6. Run the focused test again. Inspect the failure if it stays red rather than weakening the assertion.
-7. Repeat with the next behavior only after the previous slice is green.
-8. Run the broader checks affected by the completed slices and review the final diff for speculative code.
+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
 
-- Test behavior through the same interface a caller uses.
-- Keep each cycle to one new claim. Multiple assertions may support that claim when they observe one outcome.
-- Use literals, specifications, recorded fixtures, or another independent source for expected results.
-- Prefer real collaborators inside the tested module. Replace a dependency only at an established external seam.
-- Keep the failing output long enough to prove the test can detect the missing behavior.
-- Remove implementation added for a future test that has not been written.
-
-A test is coupled to implementation when a harmless refactor breaks it while public behavior stays the same. Move that test outward to the stable seam.
+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.
 
-A test is tautological when it recreates the production calculation to derive the expected value. Replace the derived expectation with a result obtained independently.
+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
 
-The work is complete when every requested behavior has a focused test that was observed failing first, the implementation passes those tests through public seams, affected repository checks pass, and the diff contains no code justified only by an unwritten future test.
+Requested behaviors have tests observed failing first, implementation passes through public interfaces, and affected checks pass.

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

@@ -11,29 +11,22 @@ metadata:
 
 ## Use when
 
-Use this skill when the change should be tested in proportion to what can break. It fits maintenance work, extensions to tested modules, and changes where a presentation-only edit has a different risk than a state transition or data boundary.
+Choosing coverage in proportion to a change's possible consequences.
 
 ## Process
 
-1. List the observable behaviors touched by the change and the callers that depend on each one.
-2. Rank the risks by consequence, likelihood, and whether an existing check would detect the regression.
-3. Read nearby tests to find the established public seam and fixture style.
-4. Add or change a test for every material risk that existing coverage misses.
-5. Use the smallest fixture that still crosses the real boundary where the regression could occur.
-6. Run the focused tests, then the repository checks that cover affected consumers.
-7. Inspect the final diff and explain any material risk left to manual verification.
+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
 
-- Add coverage for changes to state, permissions, persistence, parsing, routing, and public contracts.
-- Prefer an existing integration seam when a unit test would only mirror private branches.
-- Skip a new test when an existing test already fails under the proposed regression and clearly names the behavior.
-- Skip tests that assert static text, styling, or reversible wiring unless those details are a supported contract.
-- Keep expected results independent from the code that computes them.
-- Do not inflate test count with cases that exercise the same branch and consequence.
+Prioritize state changes, permissions, persistence, parsing, routing, and public contracts. Reuse existing coverage when it already detects the regression.
 
-When the risk cannot be automated, define a manual check with exact setup, action, and expected result. A vague instruction to test manually is not coverage.
+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
 
-The work is complete when every material regression risk is caught by an existing test, a new test, or a concrete manual check; all selected checks have run; and the handoff states any remaining unverified behavior.
+Each material risk has a meaningful automated or manual check, selected checks have run, and remaining uncertainty is explicit.

package/skills/typescript-type-safety/SKILL.md

@@ -10,31 +10,25 @@ metadata:
 
 ## Use when
 
-Use this skill when values change together, optional fields encode hidden states, external input enters typed code, or a type assertion is needed to make the compiler accept an operation.
+Values change together, optional fields hide distinct states, external input enters typed code, or an assertion is needed to satisfy the compiler.
 
 ## Process
 
-1. Name the domain states and the transitions the code permits.
-2. Replace groups of independent optional fields with a discriminated union when only certain combinations are valid.
-3. Preserve relationships between keys and values with generics, mapped types, or a typed setter rather than erasing both to broad primitives.
-4. Accept external data as `unknown` and validate it once at the boundary.
-5. Narrow values through predicates, control flow, schema results, or destructuring before use.
-6. Make absence explicit when it is a valid state and impossible when the caller must supply a value.
-7. Return a result type that forces callers to handle meaningful failure modes.
-8. Run the type checker and tests that exercise runtime validation at the boundary.
+1. Name valid states and transitions. Use discriminated unions when only certain field combinations are valid.
+2. Preserve key-value relationships with generics, mapped types, or a typed setter.
+3. Accept external input as `unknown` and validate it at the boundary.
+4. Narrow through control flow, predicates, schemas, or destructuring. Make valid absence explicit.
+5. Return types that require callers to handle meaningful failures.
+6. Run type checks and tests for runtime validation.
 
 ## Guardrails
 
-- Keep one source of truth for each state discriminator.
-- Prefer exhaustive switches where every union member requires behavior.
-- Preserve literal relationships instead of widening values to `string` or `number` too early.
-- Use runtime validation for files, network responses, environment values, and parsed JSON or YAML.
-- Treat `any`, non-null assertions, and broad type assertions as evidence that a boundary or relationship is missing.
-- Use a narrow assertion only when the runtime invariant is established outside TypeScript and cannot be expressed through validation or control flow.
-- Avoid generic abstractions that make a local relationship harder to read than explicit types would.
+Keep one source of truth for each discriminator and handle every union member where behavior must be exhaustive. Preserve literals instead of widening them prematurely.
 
-When a library returns an imprecise type, contain the adaptation in one boundary function. Return a precise project type so unsafety does not spread through callers.
+Treat `any`, non-null assertions, and broad casts as signs of a missing relationship or boundary. A narrow assertion is appropriate only when an externally established runtime invariant cannot be expressed through validation or control flow. Follow stricter repository rules where they apply.
+
+Contain imprecise library types in one adapter returning a precise project type. Avoid generic abstractions that obscure a simple relationship.
 
 ## Completion
 
-The work is complete when valid states are directly constructible, invalid combinations are rejected by validation or the compiler, key-value relationships survive through the call path, the type checker passes, and no new unsafe escape is left unexplained at a boundary.
+Valid states are constructible, invalid combinations are rejected, relationships survive the call path, and type and boundary checks pass.

package/skills/verify-and-review/SKILL.md

@@ -10,32 +10,23 @@ metadata:
 
 ## Use when
 
-Use this skill after implementation is complete and before claiming the work is ready. Verification must support the claims in the handoff, while review checks that the diff says one coherent thing.
+Code or documentation changes are ready for handoff. Answers to questions do not need this workflow; answer them directly.
 
 ## Process
 
-1. List the changed behaviors, data paths, public interfaces, and documentation claims.
-2. Discover the repository's own checks from scripts, contributor guidance, and continuous integration configuration.
-3. Run the narrow checks that exercise each changed behavior while failures are cheap to diagnose.
-4. Run the required repository gate once the focused checks pass.
-5. Inspect the final diff with surrounding code, including new files that an ordinary diff may omit.
-6. Trace values entering logs, errors, file writes, and network calls to their source and required redaction boundary.
-7. Compare public documentation and architecture diagrams with the implemented behavior.
-8. Check the working tree for generated files, debug artifacts, secrets, and unrelated edits.
-9. Report the exact commands run, their results, and any behavior that still depends on manual or external verification.
+1. Identify changed behavior, data paths, interfaces, and public claims. Read the repository's required checks.
+2. Run focused verification, then the required gate. Repeat broad checks only when later changes or failures justify it.
+3. Review the full diff with surrounding context, including untracked files. Check for generated output, diagnostics, secrets, and unrelated edits.
+4. For changed data paths, trace logs, errors, writes, and network requests to their source and required redaction boundary.
+5. Compare affected docs and diagrams with the implementation. Exercise changed interfaces and inspect their rendered state.
+6. Report checks and results, separating pre-existing failures and unverified behavior from regressions.
 
 ## Guardrails
 
-- Match each completion claim to evidence from a check or direct inspection.
-- Distinguish a failing pre-existing check from one caused by the change and provide evidence for that distinction.
-- Re-run a broad gate only after a later edit can affect its result.
-- Inspect indentation, scope, and neighboring declarations rather than relying only on compilation.
-- Keep captured user content out of logs and review text unless it has passed the required redaction boundary.
-- Do not present a build artifact as proof of runtime behavior when the changed path was never exercised.
-- Preserve material limitations in the handoff so a reviewer knows what remains uncertain.
+Match claims to checks or direct observations. A successful build does not prove an unexercised runtime path works. Keep captured user content out of reports unless it has crossed the required redaction boundary.
 
-For user interfaces, exercise the changed state and inspect the rendered result at the supported viewport or terminal. For data handling, name every sink and show where raw content becomes safe.
+Preserve unrelated work. An existing dirty worktree is not a reason to delete another contributor's changes or claim that the whole tree is clean.
 
 ## Completion
 
-Verification is complete when every changed behavior has evidence, the required repository gate passes, the final diff and working tree are clean, public claims match the code, sink tracing is accounted for, and remaining manual or external checks are stated plainly.
+The final diff has been reviewed, required checks have run, and the handoff states the evidence and material limitations.