opencode-anti-slop 0.0.0-stage → 0.1.4

package/.opencode/commands/audit-ui.md

@@ -0,0 +1,34 @@
+---
+description: Audit code for duplication, monolithic structure, missing docs, and layout-reuse violations
+---
+
+Load the `reuse-before-create`, `layout-composition`, `react-composition-patterns`, and `modular-architecture` skills before auditing.
+
+Run the deterministic checks first and read their full output:
+
+!`node scripts/anti-slop/check-duplicates.mjs --min-tokens 20 --threshold 0`
+
+!`node scripts/anti-slop/check-modularity.mjs --report-only`
+
+Scope: $ARGUMENTS. If no scope was given, audit the whole source tree.
+
+Produce a prioritized report (no code changes — a refactor plan only):
+
+1. **Duplication clusters** (from the clone report): for each clone, name the
+   existing component/hook/util that should absorb it, or the new shared
+   abstraction to extract, with exact file paths.
+2. **Monoliths** (from the size report): propose a concrete decomposition for
+   each flagged file/function/class — transport/service/domain/data or
+   container/presentational splits, one paragraph each.
+3. **Layout reuse**: pages that re-implement the same skeletons (columns,
+   shells, headers). Propose the shared template + slot design.
+4. **Missing documentation**: shared components/hooks/utils whose exports lack
+   a one-line `/** When to use ... */` JSDoc; list them in priority order.
+5. **Misplaced logic and abstraction candidates**: load the `abstraction-review`
+   skill and apply it to the scope — load-bearing rules implemented inside
+   presentational components, and structural twins (same skeleton, different
+   slot content) that no longer trip the exact-clone threshold.
+
+Order items by impact: duplication that will multiply next, then monoliths
+actively being extended, then layout rewrites waiting to happen, then docs.
+End with the three highest-value first actions.

package/.opencode/skills/abstraction-review/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: Abstraction Review
+description: Post-refactor review for missed abstractions — load-bearing domain logic living in UI components, and repeated skeletons with different content. Trigger AFTER completing a refactor or extracting components, and before finishing any task that moved shared logic. Reports; does not auto-extract.
+---
+
+# Abstraction Review
+
+Gates catch duplication that already exists. This review catches duplication
+that has not happened yet: logic that is single-consumer today but load-bearing,
+and the same skeleton built twice with different fillings.
+
+Run it **after** a refactor lands, not during. It reports and ranks; it does
+not auto-extract. Speculative abstraction is the same failure as speculative
+feature — the owner chooses what to build from the report.
+
+## 1. Misplaced logic — the load-bearing test
+
+Scan every file the task touched, especially anything under `components/` or
+route files:
+
+- Does a presentational file contain a rule that decides **meaning** — evidence
+  strength, permission, money, time/thresholds, domain state names, dates that
+  carry legal weight?
+- The test: *could a second surface (back office, export, report, audit) need
+  this exact rule?* If yes, it belongs in `src/lib/` (or `src/access/`), with
+  the UI consuming it. Load-bearing rules — evidence, access, audit, money —
+  are extracted even at one consumer; ordinary helpers wait for the second
+  consumer (Rule of Two).
+- Check the rule-locations table in AGENTS.md: after this change, is every row
+  still true? Add or update a row for every rule the task wrote or moved. A
+  rule whose location is not written down is a rule that will be re-implemented.
+
+## 2. Same skeleton, different filling — the slot test
+
+Run the clone report at low sensitivity
+(`node scripts/anti-slop/check-duplicates.mjs --min-tokens 20 --threshold 0`)
+and look past exact clones for **structural twins**:
+
+- Two components rendering the same row/card/section shape with different
+  trailing content (a badge vs a button vs a form) → one shared presentational
+  component with a slot prop. Both consumers must exist today.
+- Cross-surface candidates must respect the surfaces doctrine: only
+  presentational primitives go in `components/ui/`; surface behavior stays in
+  the surface.
+- Two views that differ for *product* reasons are not duplication — do not
+  force unification by turning the differences into config flags.
+
+## 3. Near-clone triage
+
+For each block in the low-sensitivity clone report, classify:
+
+- **Real logic duplicated** → extract now (Rule of Two met; see
+  reuse-before-create).
+- **Framework scaffolding / declarative shape** → leave alone (see
+  reuse-before-create, "What NOT to extract").
+- **Unclear** → list it with the single question whose answer would settle it.
+
+## Output contract — Second-order opportunities
+
+End the task report with a ranked list; nothing is built without the owner
+picking from it:
+
+1. **What** the abstraction is and **where** it would live (exact file path).
+2. **Why**: load-bearing rule (name the failure a diverged copy would cause),
+   or second consumer (name both).
+3. **Cost**: S / M / L.
+4. Only items that meet the bar. A review listing twenty items is noise.
+
+## Anti-patterns
+
+- "We might need it in the back office someday" — that is speculation, not a
+  load-bearing rule and not a second consumer.
+- Forcing two product-different views into one config-flagged component.
+- Reporting everything the low-sensitivity scan finds instead of triaging it.
+- Extracting during the refactor instead of reporting after it — the review
+  keeps the refactor's scope clean.

package/.opencode/skills/layout-composition/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: Layout Composition
+description: Enforces shared layout skeletons with slotted content — pages with the same structure (2-column, dashboard, settings) MUST reuse one template with different sub-components, not re-implement markup. Trigger when building or refactoring pages, layouts, screens, grids, or navigation shells.
+---
+
+# Layout Composition
+
+A layout is a skeleton (columns, regions, chrome), not content. Pages with the
+same structure must share one skeleton and differ only in what they put in the
+slots.
+
+## Core rule
+
+When N pages share the same structural shape:
+
+1. Extract the skeleton once: `<TwoColumnLayout>`, `<DashboardShell>`,
+   `<SettingsLayout>` — placement only, no page-specific content, no data
+   fetching.
+2. Each page composes: page decides content, skeleton decides placement.
+3. Page-specific widgets are their own components, passed in via slots.
+
+```tsx
+// Good: three pages, one skeleton
+<TwoColumnLayout sidebar={<AuditFilters />}>
+  <AuditTable events={events} />
+</TwoColumnLayout>
+
+<TwoColumnLayout sidebar={<UserFilters />}>
+  <UserTable users={users} />
+</TwoColumnLayout>
+```
+
+```tsx
+// Bad: the second and third page re-implement the 2-column markup
+export function UsersPage() {
+  return (
+    <div className="grid grid-cols-[280px_1fr] gap-6">
+      <aside>...</aside>
+      <main>...</main>
+    </div>
+  );
+}
+```
+
+Signals that a skeleton wants to exist:
+
+- Copy-pasting grid/flex structure between two or more pages.
+- Repeating the same `<aside>`/`<main>`/header/scaffold markup.
+- "New page" tasks that start by writing container divs instead of picking a
+  template.
+
+## Design rules for skeletons
+
+- **Slots over config.** Named slots (`sidebar`, `header`, `actions`,
+  `footer`) take JSX. Never pass booleans like `showSidebar` down a template —
+  pass the content or don't render the slot.
+- **Skeletons are dumb.** No fetching, no derived state, no store access.
+  Only responsive behavior and placement.
+- **Empty regions stay empty.** An unfilled slot renders nothing — not a
+  placeholder "coming soon" block.
+- **Nesting composes.** `<DashboardShell>` may use `<PageHeader>` and
+  `<TwoColumnLayout>` internally; pages never reach past the outermost shell.
+- **Responsive rules live in the skeleton** (where the grid is), not repeated
+  per page.
+
+## Extraction timing
+
+- First occurrence: build it locally but structure it as slots from day one.
+- Second occurrence: extract the skeleton (Rule of Two — see
+  `reuse-before-create`) and make both pages use it. Never write a third copy.
+
+## Anti-patterns
+
+- `UsersLayout.tsx` + `AuditLayout.tsx` + `ReportsLayout.tsx` that differ only
+  in imported children.
+- A layout component with 10 `show*/hide*` props instead of slots.
+- "Template + slot" where the template secretly renders page content.
+- Pages hand-rolling the same max-width/spacing/padding wrapper.

package/.opencode/skills/modular-architecture/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: Modular Architecture
+description: Enforces modular, object-oriented design for UI and non-UI code — single-responsibility modules, dependency injection behind adapters, and no monolithic files, god classes, or god functions. Trigger when writing or refactoring Node/backend services, API routes, domain logic, shared libraries, or splitting large files.
+---
+
+# Modular Architecture
+
+Monolithic code is a defect, not a style. Every module has one reason to
+change; behavior enters and leaves through narrow interfaces. Applies to UI
+and non-UI code alike.
+
+## Module rules
+
+- **Single responsibility per module/file.** A file that mixes persistence,
+  business rules, and transport (HTTP) is a monolith — split by responsibility:
+  transport -> service -> domain -> data access.
+- **Program to interfaces.** Domain logic depends on small interfaces/ports
+  (`UserRepository`, `MailSender`, `Clock`), never directly on SDKs, DB
+  clients, `fetch`, or `process.env`. Infrastructure lives in adapters that
+  implement those ports.
+- **Inject dependencies; don't import globals.** Constructors/factories accept
+  their dependencies. This makes composition explicit and testing trivial
+  (pass fakes, no module mocking). One composition root (or config module per
+  entrypoint) wires concrete adapters to ports.
+- **One direction of dependencies.** Domain logic imports nothing from
+  transport or infrastructure. Framework code (Express handlers, Next.js
+  route files) is a thin shell delegating to framework-free services.
+- **Shared logic is extracted, not copied** (see `reuse-before-create`); shared
+  modules are consumed through their public exports, never by reaching into
+  internals.
+- **State stays narrow.** No module-level mutable singletons beyond the
+  composition root. Class state is `private`/`#private` until proven needed.
+
+## Object-oriented rules
+
+- **Classes for things with state + behavior** (entities, adapters, parsers,
+  clients). Plain functions for stateless operations. Don't force everything
+  into classes, and don't write 500-line procedural scripts either.
+- **Small public surface.** Export the minimum; if a class exposes > ~10
+  public methods, it is doing several jobs — split by responsibility.
+- **Composition over inheritance.** Extend behavior by wrapping/injecting,
+  not by deep class hierarchies. Inheritance more than one level deep needs a
+  justification in the Reuse Plan.
+- **God-object test:** naming a class `Manager`, `Helper`, `Utils`, `Common`,
+  or `Service` alone is a design smell — name by responsibility
+  (`InvoiceMailer`, `SessionStore`).
+
+## Size budgets (enforced by scripts/anti-slop/check-modularity.mjs)
+
+- File: <= ~300 lines.
+- Function/method: <= ~80 lines.
+- Class: <= ~10 public methods.
+
+Exceeding a budget is a signal to split by responsibility — not to compress
+code or disable the check.
+
+## Anti-patterns
+
+- 500-line `utils.ts` accumulating everything nobody could place elsewhere.
+- Route/handler files containing validation + business rules + DB queries +
+  email sending inline.
+- `import { pool } from "../db"` inside domain logic instead of an injected
+  repository interface.
+- A class with 25 public methods, 3 of which are used.
+- "Refactoring" a monolith by moving it into two monoliths.

package/.opencode/skills/react-composition-patterns/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: React Composition Patterns
+description: Enforces composable React architecture — container/presentational separation, slots and children over prop drilling, compound components, and feature colocation. Trigger when building, refactoring, or reviewing React UI components, pages, and layouts.
+---
+
+# React Composition Patterns
+
+## Architectural rules
+
+- **Separate data from UI.** Data fetching, routing params, and mutations stay in
+  pages/containers. Presentational components receive plain data and callbacks as
+  props and stay stateless where possible. A component that both fetches and
+  styles is a smell — split it.
+- **Children and slots over prop drilling.** Pass JSX through `children` and named
+  slot props (`header`, `actions`, `footer`) instead of threading config objects
+  down multiple levels. If you are passing a prop through a component that doesn't
+  use it, restructure with slots.
+- **Compound components for multi-part UI.** Cards, modals, tables, tabs, toolbars:
+  expose sub-components (`<Card.Header>`, `<Card.Body>`) rather than one component
+  with a pile of boolean/config props. More than ~10 props, or several booleans
+  that toggle unrelated regions, means the component wants to be compound.
+- **Variant props, not sibling components.** Small appearance differences are
+  `variant`/`size` props on one component, not `PrimaryButton.tsx` next to
+  `SecondaryButton.tsx`.
+- **Colocate, then promote.** Feature-specific subcomponents and hooks live in the
+  feature directory. Promote to shared `components/` only when a second feature
+  needs them (see the reuse-before-create skill).
+
+## Layout rules
+
+- One page shell per application concern. New pages compose existing layouts;
+  they never re-implement header/sidebar/footer scaffolding.
+- Layout components take slots so pages decide content; layouts decide placement.
+
+## Anti-patterns (gotchas)
+
+- Monolithic page components: one file doing fetching, derived state, layout,
+  and markup.
+- Prop drilling: a `config`/`settings` object threaded 3+ levels deep instead of
+  composing children.
+- Boolean-prop explosion: `<Widget isPrimary isCompact showHeader hideFooter>`.
+- Premature abstraction on first use (violates Rule of Two) — colocate first.
+- Over-modularizing trivial one-offs into many files of boilerplate.

package/.opencode/skills/react-state-and-effects/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: React State, Effects and Context
+description: Enforces correct usage of useState, useEffect, useMemo, useCallback, and React Context — bans derived-state effects, event-handling effects, premature memoization, and Context misuse. Trigger when managing state, side effects, memoization, or shared data in React code.
+---
+
+# React State, Effects and Context
+
+## 1. `useEffect` — strict bans
+
+- **Never compute derived state in an effect.** Calculate during render:
+  `const fullName = `${first} ${last}``. If it needs to be cached, `useMemo` —
+  never `useEffect` + `setState`.
+- **Never react to user events with an effect.** Form submits, clicks, toasts,
+  analytics belong in event handlers, not in an effect watching state change.
+- **Never hand-roll data fetching in `useEffect` with raw `fetch`** when the
+  project has React Query / SWR / RTK / Server Components (check `package.json`
+  first). Use the project's existing mechanism.
+- **Valid uses are narrow:** synchronizing with external systems outside React —
+  DOM APIs (observers, measurement), WebSockets, `localStorage` listeners,
+  third-party widget instances, non-React subscriptions. Always return a cleanup
+  function that undoes exactly what was set up.
+- **Effect dependency arrays must be complete.** No suppression comments to make
+  warnings go away; if the array needs a lie, the design is wrong.
+
+## 2. `useMemo` / `useCallback` — no premature memoization
+
+Banned unless one of the "allowed" cases below applies:
+
+- Never wrap primitives, string formatting, small array maps, or cheap boolean
+  logic.
+- `useMemo` is allowed only for: genuinely expensive transformations
+  (filter/sort/aggregate on large datasets), or preserving referential identity
+  of an object/array that flows into a `React.memo` child or an effect
+  dependency array.
+- `useCallback` is allowed only for: callbacks passed to memoized children, or
+  functions used inside another hook's dependency array.
+- The React Compiler (if enabled in the project) makes most manual memoization
+  redundant — do not add it "just in case".
+
+## 3. Context — composition first
+
+- **Try composition first.** Before creating a Context to avoid prop drilling,
+  check whether passing JSX via `children`/slots solves it. Most "prop drilling"
+  problems are actually composition problems (see react-composition-patterns).
+- **Context is for low-frequency global or subtree values:** theme, auth user,
+  locale, i18n, compound-component coordination.
+- **Never put high-frequency state in Context:** form inputs, scroll position,
+  hover state, server-cache data. These re-render every consumer on every
+  keystroke. Use component-local state, or a store library if the project has
+  one.
+- If a Context mixes a fast-changing value with a stable one, split into two
+  contexts (value vs. dispatch/actions) so consumers can subscribe separately.
+
+## Anti-patterns (gotchas)
+
+- `useEffect(() => setState(derive(state)), [state])` — infinite-loop-prone and
+  always wrong.
+- `useEffect` + `fetch` + local loading flags when React Query exists.
+- `useMemo` on `<100 item` arrays to "optimize" a table that renders fine.
+- A `FormContext` wrapping every input on the page.
+- New Context created where a slot prop would do.

package/.opencode/skills/reuse-before-create/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: Reuse Before Create
+description: Enforces reuse of existing layouts, UI components, hooks, services, and utilities before creating any new file, component, hook, helper, or abstraction. Trigger BEFORE creating any new file, component, hook, utility, service, or module — and before duplicating anything that might already exist.
+---
+
+# Reuse Before Create
+
+Agents duplicate code because they don't know what already exists. This skill makes
+"what already exists" a mandatory check, not an afterthought.
+
+## 1. Pre-flight check (mandatory, before writing ANY new file)
+
+In order:
+
+1. **Read the inventory.** Read `docs/COMPONENT_INDEX.md` if it exists. If it does not
+   exist, generate it first:
+   `node scripts/anti-slop/generate-component-index.mjs`
+   (paths are relative to the repo root; adjust only if the repo uses different locations).
+2. **Search the tree.** Grep/glob the source directories for anything that already
+   solves the problem: components, layouts, hooks, utils, services, constants.
+   Search by concept ("format date", "modal", "auth guard"), not just by exact name.
+3. **Check `package.json`.** Before writing any custom utility, check whether an
+   installed library already does it (date formatting, class merging, debounce,
+   deep-clone, validation, state management, data fetching). Prefer the installed
+   library. Only suggest a new dependency if nothing installed fits, and say so
+   explicitly with the reason.
+4. **Check for near-duplicates.** If an existing component solves 80% of the need,
+   the answer is to extend it (props, `children`, variants) — never to clone it
+   into a new file.
+
+## 2. Hard rules
+
+- **Never rewrite page shells.** Wrap pages/screens in the existing layout
+  components. If a new page needs something the layout doesn't support, extend the
+  layout with a slot (`children`, `header`, `actions` props) instead of building a
+  parallel layout.
+- **Rule of Two.** Create a NEW shared component/hook/util only when the pattern is
+  used in 2+ places, or a single file exceeds ~150 lines. Otherwise keep it local
+  to the feature. Conversely: on the second duplication, extract — do not write a
+  third copy.
+- **Extend, don't clone.** Existing primitives are extended via props, variants,
+  render props, `children`, or slots. "I needed a slightly different version" is an
+  extension task, not a new-file task.
+- **Colocate, then promote.** Feature-specific helpers live inside the feature
+  directory. Only promote to shared directories (`components/`, `hooks/`, `lib/`)
+  when a second feature needs it — and then delete the local copy.
+
+## 2b. What NOT to extract — framework scaffolding is not duplication
+
+- **Declarative config is shape, not logic.** Repetition a framework *makes you
+  write* — collection/field definitions, route tables, schema registrations,
+  DI container setup — cannot "drift" the way two copies of logic can. The
+  Rule of Two does not apply to it, and the clone gate excludes such files
+  (list them under `ignore` in `anti-slop.config.json`). Do not wrap framework
+  scaffolding in your own abstraction layers just because it repeats.
+- **Framework primitives beat hand-rolled ones.** Before building any
+  abstraction, check whether the framework already provides the primitive:
+  auth/session handling, field-level access, validation, caching, file
+  handling, background jobs. Reimplementing what the platform gives you
+  creates a second source of truth — that is worse than repetition.
+- **The dividing line is drift.** Extract a repeated block only when its copies
+  could *behave differently* — a rule enforced in two places, an algorithm
+  fixed in two spots. Shape that stays identical by nature of being
+  declarative needs no extraction. If a declarative block embeds a real rule
+  (e.g. who may read a record), extract that *rule* into one place and have
+  every block reference it — the config stays, the behavior is single-source.
+
+## 3. Backend / Node rules
+
+- **Wrap external services behind adapters.** Direct SDK calls, `fetch` to third
+  parties, and database clients live inside adapter/service modules. Feature code
+  consumes the adapter interface. This keeps services swappable and mockable.
+- **One env/config loader.** Never add a second way to read configuration. Extend
+  the existing config module.
+- **Shared logic goes in shared modules.** Validation, date/time, money, IDs,
+  serialization: if it exists in one service, the next service imports it — it does
+  not copy it.
+- **Monoliths are defects.** If a file is growing past ~300 lines or a function
+  past ~80, stop and split by responsibility (transport/service/domain/data —
+  see the `modular-architecture` skill). Do not keep extending a god file.
+
+## 4. Output requirement — the Reuse Plan
+
+Before writing code, state briefly:
+
+1. What you are reusing (exact file paths from the index/tree/package.json).
+2. What you are extending (which file, which mechanism: props/slots/variant).
+3. Anything genuinely new, and why existing abstractions cannot cover it.
+
+If the Reuse Plan says "nothing new" there should be no new files in the diff.
+If a task produces a new file that duplicates an existing one, that is a bug in
+the plan, not in the code.
+
+## 5. Keep the index true
+
+Whenever this session adds a new shared component, hook, layout, or utility,
+give it a one-line `/** When to use ... */` JSDoc above the export and update
+`docs/COMPONENT_INDEX.md` (rerun the generator — it picks the description up
+from the JSDoc automatically). A stale or undocumented index defeats the whole
+system: the next session will duplicate what it cannot find.
+
+## Anti-patterns (gotchas)
+
+- Over-modularizing: tiny one-off features split into 5 files of boilerplate.
+- Copying an existing component and changing one class name.
+- Writing `formatDate`, `cn`, `debounce`, or `truncate` by hand while the
+  equivalent sits in `package.json`.
+- Creating a "v2" layout next to the existing layout instead of extending it.

package/.opencode/skills/verify-clean-code/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: Verify Clean Code
+description: Deterministic end-of-task verification — lint, typecheck, tests, duplicate-code detection, import boundaries, docs, and component-index freshness. Trigger before marking ANY coding task complete.
+---
+
+# Verify Clean Code
+
+A task is not complete when the code works; it is complete when the checks pass.
+Run from the repo root. Derive exact commands from `package.json` — do not guess.
+
+## 1. Standard verification (in this order)
+
+1. **Typecheck** — e.g. `tsc --noEmit` (or the repo's `typecheck` script).
+2. **Lint** — the repo's `lint` script. Fix violations you introduced; do not
+   disable rules or add `eslint-disable` comments to pass.
+3. **Targeted tests** — run only tests covering the files you changed first;
+   the full suite only if the change is cross-cutting.
+
+## 2. Duplicate-code check
+
+```sh
+node scripts/anti-slop/check-duplicates.mjs
+```
+
+It tokenizes the source tree and fails when copy-paste duplication exceeds the
+threshold (defaults tuned for typical repos; adjust in the target repo if it
+has legacy duplication). If it flags your new code: extract into the existing
+shared module (see reuse-before-create) rather than adjusting the threshold.
+Never weaken the check to make it pass. Repos with a committed
+`anti-slop.baseline.json` instead fail only on duplication newer than the
+baseline — do not update the baseline to absorb your new debt.
+
+## 3. Modularity check
+
+```sh
+node scripts/anti-slop/check-modularity.mjs
+```
+
+Flags files over ~300 lines, functions over ~80, and classes with > ~10
+public methods. The files you touched must pass. If the repo has pre-existing
+violations elsewhere, report them — do not drive-by-fix unrelated files.
+With a committed baseline, the gate fails only on violations beyond it.
+
+## 4. Import-boundary check
+
+```sh
+node scripts/anti-slop/check-imports.mjs
+```
+
+Fails on circular dependencies and on any `imports.deny` layer rules the repo
+has declared. A cycle means two responsibilities are fused — extract the shared
+part into a module both can import; never fix a cycle with a re-export shim.
+
+## 5. Documentation of shared exports
+
+Every shared component, hook, util, service, or type you added or changed must
+carry a one-line JSDoc above the export:
+
+```ts
+/** Renders the standard 2-column page shell; use for any new listing/settings page. */
+export function TwoColumnLayout({ sidebar, children }: TwoColumnLayoutProps) {
+```
+
+This is mechanically enforced: `node scripts/anti-slop/check-docs.mjs` fails on
+undocumented exports (the pre-commit hook runs it on staged files). Rerun
+`node scripts/anti-slop/generate-component-index.mjs` after adding or removing
+shared exports, and confirm the new entries show their description (not `-`) in
+`docs/COMPONENT_INDEX.md`.
+
+## 6. If the task was a refactor, review what you may have missed
+
+Gates catch duplication that exists; they cannot catch load-bearing logic left
+in the wrong layer or a skeleton built twice with different fillings. When the
+task extracted components, merged duplicated flows, or moved rules between
+files, run the `abstraction-review` skill before reporting, and include its
+"Second-order opportunities" list in the report.
+
+## 7. Report
+
+End the task with a short summary: checks run, results, files touched, and any
+pre-existing issues you noticed but did not fix (report, don't drive-by-fix).

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 hyperbolictonic
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.