@shadowclone/cli 0.0.9 → 0.0.11

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 is ready for handoff.
 
 ## 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.