atom-lite 0.5.1 → 0.6.3

package/skills/code-review/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: code-review
+description: >
+  Review code changes against repository standards and the originating spec.
+  Use for "review this PR", "review the diff", "code review", or before merging.
+---
+
+# Code Review
+
+Two-axis review of a change. Run both axes and report them separately.
+
+## Axes
+
+1. **Standards** — does the code follow this repo's documented conventions?
+   Sources: `AGENTS.md`, `CONTRIBUTING.md`, `docs/adr/*`, TypeScript strict mode,
+   NodeNext ESM, named exports, no new runtime deps without discussion.
+   Also apply the smell baseline: mysterious name, duplicated code, feature envy,
+   data clumps, primitive obsession, repeated switches, shotgun surgery,
+   divergent change, speculative generality, message chains, middle man,
+   refused bequest. A documented repo standard always overrides a smell.
+
+2. **Spec** — does the code implement what the issue/spec asked for?
+   Find the spec under `.scratch/<feature>/spec.md` or the referenced issue.
+
+## Process
+
+1. Pin the fixed point: `git diff <base>...HEAD` (three-dot). List commits.
+2. Identify standards sources and the spec source.
+3. For each file/hunk, report:
+   - Standards: hard violations (cite file + rule) and judgement-call smells.
+   - Spec: missing/partial requirements, scope creep, wrong-looking implementations.
+   Quote the spec line for each spec finding.
+4. Aggregate under `## Standards` and `## Spec` headings. Do not merge axes.
+
+## Output format
+
+- `## Standards` — findings per file/hunk, hard vs judgement.
+- `## Spec` — findings keyed to spec lines.
+- One-line summary per axis: count + worst issue.
+
+## Rules
+
+- Skip anything tooling enforces (tsc, tests, lint).
+- Smells are judgement calls, never hard violations.
+- Report facts, not opinions; cite paths and lines.
+- Small, reviewable findings are preferred over exhaustive nitpicks.

package/skills/optimization/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: optimization
+description: >
+  Optimize code for performance and efficiency while preserving behavior.
+  Use for "optimize", "make faster", "reduce memory", "performance".
+---
+
+# Optimization
+
+Expert performance engineer. Maximize speed/efficiency without changing observable behavior, APIs, return values, errors, side effects, ordering, or compatibility.
+
+## Strategy
+
+1. Understand implementation and hot paths.
+2. Find real bottlenecks (profile/analyze), not guesses.
+3. Fix algorithmic complexity before micro-optimizations.
+4. Cut allocations, copies, parsing/serialization, redundant I/O, repeated work.
+5. Improve data structures, caching, batching, concurrency where safe.
+6. Prefer small, safe, high-impact changes over risky rewrites.
+
+## Constraints
+
+- Never change behavior, validation, error handling, or edge cases.
+- Never weaken type safety or security.
+- Never introduce races or observable reordering.
+- Never edit tests to fit a change.
+- No speculative complexity without measurable gain.
+- Behavior preservation always beats performance.
+
+## Verification
+
+Before: understand behavior, find tests/benchmarks, establish baseline.
+After: run tests/typecheck/build; compare baseline; check edge cases and diff.
+
+No tests/benchmarks? State what is unverified.
+
+## Execution
+
+Work autonomously. Keep investigating until further gains are negligible, unsafe, or unjustified.
+
+## Report
+
+Provide concise, evidence-based summary:
+
+- Changes made
+- Bottlenecks eliminated
+- Before/after metrics (only measured)
+- Verification status
+- Limitations
+
+Use actual numbers only. If unmeasured, say "Not benchmarked" or "Expected benefit". If no improvement, say so.