@robot-inventor/agent-skills 0.0.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 roboin
+
+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.

package/README.md

@@ -0,0 +1,31 @@
+# Roboin Agent Skills
+
+My personal collection of Agent Skills.
+
+- [cleanup-changes](skills/cleanup-changes/SKILL.md): The skill to revert unnecessary changes and leave only essential changes.
+- [identify-search-maintenance](skills/identify-search-maintenance): The skill to identify web pages that are performing poorly in search results and require maintenance.
+- [prove-it-diagnostics](skills/prove-it-diagnostics/SKILL.md): The skill to fix bugs and improve performance by proving the root cause through minimal reproduction code or benchmarks, rather than relying on speculation based solely on reading the code.
+- [review-loop](skills/review-loop/SKILL.md): Thoroughly improve code quality by requesting a review from a sub-agent.
+- [simple-engineering](skills/simple-engineering/SKILL.md): A skill outlining the fundamental principles to keep in mind when writing or editing code.
+- [web-master](skills/web-master/SKILL.md): A skill outlining the fundamental principles to keep in mind when writing or editing web-related code.
+
+## Installation
+
+```bash
+# Install all skills
+npx skills add Robot-Inventor/agent-skills
+
+# Install a specific skill
+npx skills add Robot-Inventor/agent-skills --skill <skill-name>
+```
+
+## Plugins
+
+```bash
+# Codex
+codex plugin marketplace add Robot-Inventor/agent-skills
+codex plugin add agent-skills@robot-inventor
+
+# OpenCode
+opencode plugin @robot-inventor/agent-skills --global
+```

package/package.json

@@ -0,0 +1,33 @@
+{
+  "name": "@robot-inventor/agent-skills",
+  "version": "0.0.0",
+  "description": "Roboin's personal collection of Agent Skills.",
+  "homepage": "https://github.com/Robot-Inventor/agent-skills#readme",
+  "bugs": {
+    "url": "https://github.com/Robot-Inventor/agent-skills/issues"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Robot-Inventor/agent-skills.git"
+  },
+  "license": "MIT",
+  "author": "Robot-Inventor",
+  "type": "module",
+  "files": ["./plugin.json", "./skills/", "./scripts/opencode.ts"],
+  "publishConfig": {
+    "access": "public",
+    "provenance": false
+  },
+  "scripts": {
+    "ci:version": "changeset version && bun ./scripts/syncVersion.ts && git add .",
+    "ci:publish": "changeset publish"
+  },
+  "devDependencies": {
+    "@changesets/changelog-github": "^1.0.0",
+    "@changesets/cli": "^3.0.0",
+    "@opencode-ai/plugin": "^1.18.18",
+    "@robot-inventor/tsconfig-base": "^7.1.0",
+    "@types/bun": "^1.3.14",
+    "@types/node": "^26.2.0"
+  }
+}

package/plugin.json

@@ -0,0 +1,12 @@
+{
+    "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+    "name": "roboin-agent-skills",
+    "version": "0.7.0",
+    "description": "My personal collection of Agent Skills.",
+    "author": {
+        "name": "Robot-Inventor",
+        "url": "https://roboin.io/"
+    },
+    "repository": "https://github.com/Robot-Inventor/agent-skills",
+    "license": "MIT"
+}

package/scripts/opencode.ts

@@ -0,0 +1,26 @@
+import type { Plugin } from "@opencode-ai/plugin";
+import { SKILLS } from "./skills";
+import { exists } from "node:fs/promises";
+import { join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const plugin: Plugin = async ({ project, directory }) => {
+    const isWebProject = await exists(join(directory, "package.json"));
+    const skills = isWebProject ? SKILLS.web : SKILLS.nonWeb;
+
+    return {
+        config: async (config) => {
+            config.instructions ??= [];
+
+            for (const skill of skills) {
+                const path = fileURLToPath(new URL(`../skills/${skill}/SKILL.md`, import.meta.url));
+
+                if (!config.instructions.includes(path)) {
+                    config.instructions.push(path);
+                }
+            }
+        }
+    };
+};
+
+export { plugin };

package/skills/cleanup-changes/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: cleanup-changes
+description: The skill to revert unnecessary changes and leave only essential changes when a user requests a cleanup of changes, or before committing and creating a pull request.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Cleanup Changes Skill
+
+Both humans and agents typically go through a trial-and-error process when writing code, making numerous changes (including non-essential and unnecessary ones) to achieve their final goals. However, non-essential and unnecessary changes resulting from this trial-and-error process should not be included in the final code. Changes should be reviewed as needed, and unnecessary changes should be reversed to focus only on essential ones.
+
+## When to apply
+
+You should perform this skill when a user requests a cleanup of changes, or before creating a commit or pull request.
+
+## Steps
+
+The following is the core of this skill; please follow the specified steps. Do not change the Git staging state unless explicitly instructed to do so by the user. Users may have staged their changes as a snapshot of the code in its last expected state.
+
+### 1. Looking back on the trial-and-error process
+
+Reflect on the trial-and-error process of the task and distinguish between changes that were essentially necessary and changes that, despite being tried, ultimately proved ineffective and unnecessary.
+
+You shouldn't make assumptions about whether a change is essentially necessary. For example, when fixing a bug, review the changes made when the bug was finally fixed, understand the essential and root cause of the bug, and then, based on that, determine whether each change is essentially necessary.
+
+When determining whether each change is necessary, pay particular attention to bugs caused by multiple factors. Bugs can be caused by a single, simple cause, or by multiple factors. If it's caused by a single, simple cause, the last change made when the bug is fixed may be sufficient, and previous changes may be unnecessary. If it's a bug caused by multiple factors, the last change alone may not be enough, and some of the changes made during the trial-and-error process leading up to it may also be necessary. Carefully consider the underlying cause of the bug, including whether it's due to a single cause or multiple factors, and then determine which changes are necessary and which are not.
+
+### 2. Undo unnecessary changes
+
+Revert any changes you determined were unnecessary in the previous step, leaving only the essential changes.
+
+However, even if a change isn't strictly necessary, minor corrections to typos around the current change or small refactorings are acceptable. Generally, in coding, correcting typos found around a change or making small refactorings related to the current change are generally tolerated, even if they aren't strictly necessary.

package/skills/identify-search-maintenance/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: identify-search-maintenance
+description: Identify and diagnose organic-search articles that need maintenance. Use when asked to find pages whose organic traffic declined mainly from ranking loss rather than search-demand decline, analyze Search Console or GA4 data across recent and year-over-year periods, prioritize a maintenance backlog, or compare target pages with current Google results. Do not use this skill to edit article content.
+---
+
+# Identify Search Maintenance
+
+Find pages that merit search-maintenance work, with evidence that separates rank-driven losses from changes in demand. The deliverable is a ranked investigation backlog and diagnosis; it is never an article rewrite or publishing task.
+
+## Scope and guardrails
+
+- Confirm the property, traffic channel, dates, locale/device, and whether Google must be inspected through the user's signed-in Chrome session.
+- Use both recent comparison (normally the latest 3 months vs. the preceding 3 months) and a year-over-year comparison (normally the same recent 3 months one year earlier). End periods on the latest Search Console date that is complete enough to compare, use equal day counts and comparable weekday mix, and state any unavailable baseline as `N/A`, never as zero.
+- Fix the Search Console search type, country, device, property scope, canonical-URL handling, and any brand-query exclusion across each comparison. Record GA4 timezone, Organic Search channel definition, and landing-page URL normalization.
+- Treat a page as a candidate only after checking page-level **and** query-level Search Console data. GA4 is corroborating traffic evidence, not a substitute for query and rank data.
+- Do not attribute a loss to rankings from clicks alone. URL-filtered and property-wide Search Console impressions are affected by the site's own visibility and are not standalone demand measures. Check an independent demand proxy (for example Google Trends for the query/topic, Keyword Planner where available, or a documented market-data source), then use property-wide query data only as corroboration. Also check URL/query rank changes, cannibalization, and live SERP composition.
+- Do not alter CMS content, metadata, internal links, or publish settings. If the user asks for changes, finish this investigation first and obtain a separate article-update scope.
+
+## Workflow
+
+### 1. Collect comparable evidence
+
+1. Export Search Console performance by **page** for the two period pairs. Prefer an export/CSV over manually paging a truncated table.
+2. Retain clicks, impressions, CTR, and average position for each period. Record filters, property, and export dates.
+3. Obtain GA4 organic-search landing-page sessions or views for the same dates when available. Note that GA4 and Search Console count different things.
+4. Normalize both the recent-pair and year-over-year page exports to the columns in [selection-rubric.md](references/selection-rubric.md). Run the bundled filter on each, take the union of the two candidate lists, and label the comparison(s) that surfaced each URL. A page that only passes one comparison still needs the full evidence checks in both.
+
+```powershell
+python "<skill-directory>/scripts/select_rank_led_candidates.py" normalized-pages.csv --format markdown
+```
+
+Replace `<skill-directory>` with the directory containing this `SKILL.md`. Use the script to screen candidates, not to make the final decision. Tune its thresholds only if the report explains why.
+
+### 2. Separate causes before selecting pages
+
+Classify each materially declining page into one of these mutually exclusive buckets:
+
+| Bucket                               | Evidence                                                                                 | Action                                                                                 |
+| ------------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
+| Rank-led maintenance candidate       | Clicks materially down; impressions broadly stable; average position/query ranks worsen  | Investigate and prioritize                                                             |
+| Demand/obsolescence decline          | Impressions and clicks fall together, or the task/query has ended                        | Exclude from the rank-led list                                                         |
+| CTR/SERP change                      | Position broadly stable but CTR falls; SERP features or title/snippet changes explain it | Keep separate; do not call it rank-led                                                 |
+| Technical/indexing issue             | Indexing, canonical, rendering, or availability evidence                                 | Escalate separately                                                                    |
+| Cannibalization/internal competition | Another site URL gained the same query or intent                                         | Exclude from this content-maintenance list; route for consolidation/targeting decision |
+| Insufficient evidence                | Low volume or no comparable baseline                                                     | Do not force into the top 10                                                           |
+
+For every selected URL, verify at least three previously valuable declined queries. For each query, collect three views with identical search type/country/device/date filters: (a) the target URL's query metrics and position, (b) the **whole property** query metrics without a page filter, and (c) an independent demand proxy. Treat (c) as the demand evidence; use (b) only to understand the site's overall visibility. Use year-over-year data to catch longer-running changes. Check whether another URL in the property gained the same query; classify confirmed cannibalization in its own exclusion bucket. If the query mix changed, say so.
+
+Before retaining a content-maintenance candidate, perform a minimum health check: URL Inspection/index status, user-selected canonical, HTTP availability, and rendered-page accessibility. Classify a failing page as a technical/indexing issue instead of diagnosing an editorial gap.
+
+### 3. Diagnose each selected page in Google
+
+When the user specifies Chrome or Google, use the Chrome browser, not a general web-search backend. For each selected URL:
+
+1. Search at least three declined, historically valuable queries in Google, using the required locale/device context where possible.
+2. Capture the target URL's visible rank or absence, the top competing URLs, and material SERP features (AI Overview, official result, video carousel, PAA, news, forums, etc.). Use fresh tabs and do not change account or site settings.
+3. Compare the target and the leading pages on search intent, freshness, direct answer quality, task completion, factual completeness, first-party evidence, visual/media support, structure, and trust signals. Base observations on actual page content; distinguish observed facts from inference.
+4. Identify the gap to investigate, not the edit itself. Examples: outdated UI steps, missing current constraints, poor intent match, weak original evidence, or a SERP now dominated by official sources.
+
+If parallel agents are available, assign no more than two pages to each agent. Require each agent to return the period metrics, three or more queries, Google competitors, SERP features, observed content gaps, exclusions, and source URLs. Consolidate only after all agents return evidence.
+
+### 4. Produce the maintenance report
+
+Create or append to `report.md`; preserve earlier findings unless the user asks to replace them. Use this structure:
+
+1. Scope, dates, data sources, filters, and limitations.
+2. Selection method and explicit rank-led thresholds.
+3. A prioritized table of up to the requested number of rank-led pages (default 10): URL, recent metrics, year-over-year metrics, property-wide query-demand evidence, ranking evidence, priority, and confidence. If fewer pages meet the evidence threshold, report fewer and explain the shortfall.
+4. Per-page diagnosis: three or more declined queries, current Google competitors/SERP observations, and content gaps to investigate.
+5. Excluded near-misses with the evidence for demand decline, obsolete intent, CTR-only loss, technical issue, cannibalization, or insufficient data.
+6. A separate follow-up queue for work that needs a technical or editorial decision.
+
+Before delivery, verify that every page in the final rank-led list has stable-enough independent demand evidence, a documented query-level rank deterioration, and a passing health check. Never fill a quota with demand-led losses.
+
+## Resources
+
+- [selection-rubric.md](references/selection-rubric.md): normalization schema, default thresholds, and report checklist.
+- `scripts/select_rank_led_candidates.py`: deterministic first-pass filter for normalized Search Console page exports.

package/skills/identify-search-maintenance/references/selection-rubric.md

@@ -0,0 +1,45 @@
+# Rank-led candidate selection rubric
+
+## Normalize the export
+
+Create a CSV with this exact header before using the script:
+
+```csv
+url,current_clicks,previous_clicks,current_impressions,previous_impressions,current_position,previous_position
+```
+
+`current_*` is the recent period and `previous_*` is its comparison period. Preserve the original Search Console exports as evidence. Do not combine GA4 and Search Console counts in the same columns. The normalized page CSV is only a ranking-loss screen; it cannot establish search demand.
+
+For annual comparison, make a second normalized CSV where `previous_*` is the equivalent period one year earlier. Run the screen on both CSVs, union their candidates, and show which comparison surfaced each URL. If that page did not exist then or the data is unavailable, report `N/A`.
+
+## Default first-pass thresholds
+
+The bundled script selects a page only if all conditions hold:
+
+| Signal                                  |                       Default | Reason                                   |
+| --------------------------------------- | ----------------------------: | ---------------------------------------- |
+| Previous-period clicks                  |                  at least 100 | Avoid low-volume noise                   |
+| Click change                            |                 -20% or worse | Requires a material loss                 |
+| Impression change                       |                   within ±25% | Excludes most demand-led losses          |
+| Position change                         |                 +0.5 or worse | Requires a measurable rank deterioration |
+| Click decline beyond impression decline | at least 10 percentage points | Requires loss beyond demand movement     |
+
+These are screening defaults, not proof. A page can be excluded despite passing them when an independent demand proxy shows demand loss, a one-off event occurred, a competing URL gained the query, or the task is obsolete. A page can be included with explained threshold adjustments only when the report documents why.
+
+## Interpret the metrics
+
+- Position delta is `current_position - previous_position`; a positive number is worse.
+- Page-level impressions are not demand: a lower rank can itself lower the page's impressions. Property-wide query impressions can also fall when the whole site loses visibility. Use Google Trends, Keyword Planner, or another documented independent source to assess demand. Compare property-wide (unfiltered-by-page) query impressions only as a corroborating visibility signal, then compare the target URL's rank/clicks separately.
+- A stable page-level impression total can hide query-mix movement. Verify individual declined queries before calling the loss rank-led, and inspect pages that gained the query for cannibalization.
+- A stable position with a falling CTR is a CTR/SERP case, not a rank-led case.
+- A fall in impressions paired with a similar fall in clicks is normally demand-led or obsolescence-led until evidence proves otherwise.
+- Search Console average position is an aggregate. Use live Google searches only as a point-in-time confirmation and label locale, device, signed-in state, and date.
+
+## Completion checklist
+
+- [ ] Recent and year-over-year comparisons were both attempted.
+- [ ] Every final candidate has page-level metrics, at least three declined historic queries, and property-wide visibility checks for those queries.
+- [ ] Every final candidate has independent demand evidence, a URL Inspection/index/canonical/availability health check, and no confirmed cannibalization.
+- [ ] Google SERP checks list query, target visibility, competitors, and material SERP features.
+- [ ] The report explicitly separates rank-led candidates from demand-led, CTR-only, technical, and insufficient-evidence cases.
+- [ ] The report contains diagnoses and maintenance priorities, but no article edits.

package/skills/identify-search-maintenance/scripts/select_rank_led_candidates.py

@@ -0,0 +1,212 @@
+#!/usr/bin/env python3
+"""Screen normalized Search Console page data for rank-led traffic-loss candidates."""
+
+from __future__ import annotations
+
+import argparse
+import csv
+import math
+import sys
+from pathlib import Path
+from typing import Iterable, TextIO
+
+REQUIRED_COLUMNS = (
+    "url",
+    "current_clicks",
+    "previous_clicks",
+    "current_impressions",
+    "previous_impressions",
+    "current_position",
+    "previous_position",
+)
+
+
+def parse_number(value: str, column: str, row_number: int) -> float:
+    try:
+        number = float(value.replace(",", "").strip())
+    except (AttributeError, ValueError) as error:
+        raise ValueError(
+            f"Row {row_number}: {column} must be numeric, got {value!r}."
+        ) from error
+    if not math.isfinite(number):
+        raise ValueError(f"Row {row_number}: {column} must be finite, got {value!r}.")
+    if (column.endswith("clicks") or column.endswith("impressions")) and number < 0:
+        raise ValueError(
+            f"Row {row_number}: {column} cannot be negative, got {value!r}."
+        )
+    if column.endswith("position") and number <= 0:
+        raise ValueError(
+            f"Row {row_number}: {column} must be greater than zero, got {value!r}."
+        )
+    return number
+
+
+def percentage_change(current: float, previous: float) -> float:
+    return (current - previous) / previous
+
+
+def read_rows(stream: TextIO) -> Iterable[dict[str, str]]:
+    reader = csv.DictReader(stream)
+    if reader.fieldnames is None:
+        raise ValueError("Input CSV has no header row.")
+
+    reader.fieldnames[0] = reader.fieldnames[0].lstrip("\ufeff")
+    missing = [column for column in REQUIRED_COLUMNS if column not in reader.fieldnames]
+    if missing:
+        raise ValueError(
+            f"Input CSV is missing required columns: {', '.join(missing)}."
+        )
+
+    return reader
+
+
+def select_candidates(
+    rows: Iterable[dict[str, str]],
+    min_previous_clicks: float,
+    max_click_change: float,
+    max_absolute_impression_change: float,
+    min_position_worsening: float,
+    min_click_gap_vs_impressions: float,
+) -> list[dict[str, float | str]]:
+    candidates: list[dict[str, float | str]] = []
+    seen_urls: set[str] = set()
+    for row_number, row in enumerate(rows, start=2):
+        url = row["url"].strip()
+        if not url:
+            raise ValueError(f"Row {row_number}: url cannot be empty.")
+        if url in seen_urls:
+            raise ValueError(
+                f"Row {row_number}: duplicate url {url!r}; aggregate the export first."
+            )
+        seen_urls.add(url)
+        values = {
+            column: parse_number(row[column], column, row_number)
+            for column in REQUIRED_COLUMNS[1:]
+        }
+        previous_clicks = values["previous_clicks"]
+        previous_impressions = values["previous_impressions"]
+        if previous_clicks <= 0 or previous_impressions <= 0:
+            continue
+
+        click_change = percentage_change(values["current_clicks"], previous_clicks)
+        impression_change = percentage_change(
+            values["current_impressions"], previous_impressions
+        )
+        position_worsening = values["current_position"] - values["previous_position"]
+        click_gap_vs_impressions = impression_change - click_change
+
+        if (
+            previous_clicks >= min_previous_clicks
+            and click_change <= max_click_change
+            and abs(impression_change) <= max_absolute_impression_change
+            and position_worsening >= min_position_worsening
+            and click_gap_vs_impressions >= min_click_gap_vs_impressions
+        ):
+            candidates.append(
+                {
+                    "url": url,
+                    "current_clicks": values["current_clicks"],
+                    "previous_clicks": previous_clicks,
+                    "click_change": click_change,
+                    "current_impressions": values["current_impressions"],
+                    "previous_impressions": previous_impressions,
+                    "impression_change": impression_change,
+                    "current_position": values["current_position"],
+                    "previous_position": values["previous_position"],
+                    "position_worsening": position_worsening,
+                    "click_gap_vs_impressions": click_gap_vs_impressions,
+                }
+            )
+
+    return sorted(
+        candidates,
+        key=lambda candidate: (
+            float(candidate["previous_clicks"]) - float(candidate["current_clicks"])
+        ),
+        reverse=True,
+    )
+
+
+def percentage(value: float) -> str:
+    return f"{value * 100:.1f}%"
+
+
+def markdown(candidates: Iterable[dict[str, float | str]]) -> str:
+    lines = [
+        "| URL | Clicks (current / previous) | Click change | Impressions change | Position worsening |",
+        "| --- | ---: | ---: | ---: | ---: |",
+    ]
+    for candidate in candidates:
+        lines.append(
+            "| {url} | {current_clicks:.0f} / {previous_clicks:.0f} | {click_change} | {impression_change} | {position_worsening:+.1f} |".format(
+                url=candidate["url"],
+                current_clicks=float(candidate["current_clicks"]),
+                previous_clicks=float(candidate["previous_clicks"]),
+                click_change=percentage(float(candidate["click_change"])),
+                impression_change=percentage(float(candidate["impression_change"])),
+                position_worsening=float(candidate["position_worsening"]),
+            )
+        )
+    return "\n".join(lines)
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(description=__doc__)
+    parser.add_argument(
+        "input", help="Normalized CSV path, or - to read CSV from standard input."
+    )
+    parser.add_argument("--min-previous-clicks", type=float, default=100)
+    parser.add_argument("--max-click-change", type=float, default=-0.20)
+    parser.add_argument("--max-absolute-impression-change", type=float, default=0.25)
+    parser.add_argument("--min-position-worsening", type=float, default=0.5)
+    parser.add_argument("--min-click-gap-vs-impressions", type=float, default=0.10)
+    parser.add_argument("--format", choices=("markdown", "csv"), default="markdown")
+    arguments = parser.parse_args()
+
+    try:
+        if arguments.input == "-":
+            candidates = select_candidates(
+                read_rows(sys.stdin),
+                arguments.min_previous_clicks,
+                arguments.max_click_change,
+                arguments.max_absolute_impression_change,
+                arguments.min_position_worsening,
+                arguments.min_click_gap_vs_impressions,
+            )
+        else:
+            with Path(arguments.input).open(
+                encoding="utf-8-sig", newline=""
+            ) as input_file:
+                candidates = select_candidates(
+                    read_rows(input_file),
+                    arguments.min_previous_clicks,
+                    arguments.max_click_change,
+                    arguments.max_absolute_impression_change,
+                    arguments.min_position_worsening,
+                    arguments.min_click_gap_vs_impressions,
+                )
+    except (OSError, ValueError, csv.Error) as error:
+        parser.error(str(error))
+
+    if arguments.format == "markdown":
+        print(markdown(candidates))
+        return 0
+
+    writer = csv.DictWriter(
+        sys.stdout,
+        fieldnames=(
+            "url",
+            *REQUIRED_COLUMNS[1:],
+            "click_change",
+            "impression_change",
+            "position_worsening",
+            "click_gap_vs_impressions",
+        ),
+    )
+    writer.writeheader()
+    writer.writerows(candidates)
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

package/skills/prove-it-diagnostics/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: prove-it-diagnostics
+description: Prove it for debugging, performance investigation, bottleneck analysis, profiling, and optimization work. When reading code does not prove the cause, run a minimal reproduction, add temporary traces, measure bottlenecks, and verify the fix or improvement.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Prove It Diagnostics
+
+Use this skill to pinpoint the causes of bugs and performance bottlenecks and fix them. Reading code alone may not reveal the source of a bug or bottleneck. Do not claim that a speculative code change fixed a bug or improved performance. Run the code, gather evidence, identify the cause, and verify the fix.
+
+## Steps
+
+The following is the core of this skill; please follow the specified steps.
+
+## 1. Establish a performance baseline for optimization tasks
+
+For performance optimization tasks, create and run a benchmark before making changes. Run the benchmark as many times as practical. Use averages, percentiles, and other relevant statistics to establish a stable baseline instead of relying on a single run.
+
+## 2. Read the code
+
+Read the code related to the bug or performance issue. For debugging tasks, you may fix the issue and skip the remaining steps when you find a clear cause, such as an incorrect operator or an obvious contradiction in the logic.
+
+Continue with the remaining steps when you cannot identify the cause with confidence or when you find suspicious code but lack enough evidence to blame it.
+
+### 3. Verify the cause
+
+Do not rely on code inspection alone. Run experiments to identify the source of the bug or bottleneck.
+
+For debugging tasks:
+
+1. Create a reproduction in a temporary file or REPL and run it to confirm the bug. If the reproduction does not fail, add relevant behavior from the target code until it reproduces the bug.
+2. Remove or revert each part of the reproduction to find the smallest program that still triggers the bug. A minimal reproduction narrows the list of possible causes.
+3. Investigate the minimal reproduction, identify the cause, and fix it. Address the root cause instead of applying a superficial workaround, as described in the Rules section.
+4. Confirm that the fix prevents the bug in the minimal reproduction.
+5. Apply the fix to the production code and confirm that it resolves the original bug. If the bug remains, return to the reproduction step and repeat the process.
+
+For performance optimization tasks:
+
+1. Use benchmarks, profilers, timing logs, or similar tools to identify the slow operation.
+2. Fix the bottleneck, then use the same measurements to confirm that performance improved.
+3. Apply the fix to the production code and confirm the improvement there. If performance does not improve, return to bottleneck analysis and repeat the process.
+
+### 4. Clean up
+
+Remove temporary logs, reproduction code, generated files, and log data created during verification.
+
+## Rules
+
+If a user reports that your fix did not resolve the bug or improve performance, treat your previous diagnosis as unverified and restart the investigation.
+
+Surface-level and stop-gap fixes are shameful; identify and fix the root cause. For example, when an error triggers a bug, find and fix the source of the error instead of adding a fallback for the failure. Keep asking yourself, “Is this the root cause?”
+
+When evidence points to a bug in a dependency, do not patch the dependency. Tell the user that the dependency appears to contain a bug, describe the evidence, and propose changes they can make in their project without modifying the dependency.
+
+When you get stuck, try these approaches:
+
+- Add temporary logs across the affected path. Use them to find the boundary between correct and incorrect behavior, or between fast and slow execution.
+- When behavior contradicts the code’s logic or you cannot make progress, search the relevant library’s GitHub issues and pull requests, Stack Overflow, and community articles for reports of the same problem and possible solutions.

package/skills/review-loop/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: review-loop
+description: Thoroughly improve code quality by requesting a review from a sub-agent after completing tasks requiring code editing, before returning the conversation turn to the user. Use for any task that edits code or configuration. Read this skill before starting edits, and after completing the requested changes run an isolated sub-agent review loop before returning the final response.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Review Loop Skill
+
+This skill involves thoroughly improving code quality by repeatedly requesting a review from a sub-agent after editing and improving the code based on the results. Humans typically improve code quality by creating a pull request after editing code and having it reviewed by a reviewer. Such reviews are important because they can identify problems that might be missed through self-review alone.
+
+## When to apply
+
+Apply this skill in the following situations:
+
+- When you have performed a task that requires code editing, and
+- After completing the task instructed by the user, and
+- Before returning the conversation to the user
+
+## Steps
+
+The following is the core of this skill; please follow the specified steps.
+
+### 1. Request a code review
+
+Request a code review from the subagent.
+
+If you have the option to choose whether to fork the context or launch the subagent in an isolated context when starting it, **always** launch it in an isolated context. Forking the context would be equivalent to a self-review, so you need to launch a subagent in an isolated context to review it from a different perspective.
+
+When requesting a review from a sub-agent, be sure to provide them with an overview of the task requested by the user, and instruct them to thoroughly review the changes made to the current workspace.
+
+### 2. Receive reviews and improve your code
+
+Once you receive the review results from the sub-agent, consider whether each point is valid. You may ignore clearly unreasonable points, but you must address valid points and correct the code accordingly.
+
+In particular, if you receive feedback on a part that doesn't strictly follow the user's instructions as a result of compromises, do not ignore it. Instead, correct it according to the review to align with the user's instructions as much as possible. If you absolutely cannot comply with the user's request, you may ignore the sub-agent's point about that part, but be sure to inform the user of the compromise you made when you return the conversation to them.
+
+### 3. Review loop
+
+After addressing valid feedback from the subagent, repeat steps 1 and 2 ("1. Request a code review" and "2. Receive reviews and improve your code") until there is no more valid feedback from the subagent, thoroughly improving your code quality. In this review loop, always have a new subagent review your code each time.
+
+### 4. Report the results to the user
+
+Once the review loop is complete, return the conversation to the user. Be sure to honestly report to the user any points where you had to compromise and did not strictly follow their instructions.

package/skills/simple-engineering/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: simple-engineering
+description: A skill outlining the fundamental principles to keep in mind when writing or editing code. Read this skill before developing an implementation plan or writing or reviewing code, and apply it to your work.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Simple Engineering
+
+## Keep it simple and elegant
+
+Overengineering is a shameful and foolish act, and it is important to always pursue simple and elegant solutions.
+
+Before implementing a feature or fixing a bug, consider all options. Instead of just listing similar choices or being bound by preconceptions and previous thinking, consider all options, including completely different approaches. Among the available options, choose the one that is the clearest, simplest, requires the fewest lines of code, and meets the user's requirements. There is no need to use iron plates and nails to repair torn clothes. Choose a right-sized, simple approach rather than an overly large and complex one.
+
+Also avoid bringing unnecessary complexity into your code. Carefully examine related processing to ensure there are no impossible conditional branches or unnecessary try-catch blocks. Check the type definitions and actual processing, and remove any impossible conditional branches. There is no need to wrap code in a new try-catch block if an exception is unlikely to occur normally or if a try-catch already exists inside the called function.
+
+## Avoid reinventing the wheel
+
+Reinventing the wheel should be avoided. Before adding code, check whether existing code in the project or the project's dependencies already provide functionality that covers part or all of that processing. When implementing complex processing, investigate whether a popular and well-maintained library that achieves equivalent functionality exists, and if so, propose using it to the user.
+
+## Keep only necessary changes
+
+Keep the YAGNI (You aren't gonna need it) principle in mind. You should not introduce complexity just because you might need it in the future. Also, there is no need to maintain backward compatibility for unreleased features.
+
+The code ultimately delivered to the user should be such that every line of change is necessary and no unnecessary code remains. Carefully review the diff line by line, rather than file by file, to ensure that all changes are truly necessary.

package/skills/web-master/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: web-master
+description: A skill outlining the fundamental principles to keep in mind when writing or editing web-related code. Read this skill before developing an implementation plan or writing or reviewing code for web-related tasks, and apply it to your work.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Web Master
+
+Follow these instructions when writing web-related code.
+
+## TypeScript
+
+### Do not use type assertions
+
+Do not reach for type assertions unless you need one. Never add a type assertion up front because you think you might need it later. You may use a type assertion only when all of these conditions apply:
+
+- You first write the code without a type assertion and encounter a type error.
+- You cannot resolve that type error by improving type definitions elsewhere.
+- Adding the type assertion does not compromise type safety.
+
+### Do not use `ReturnType`
+
+Do not use `ReturnType` unless you need it. Use the following approaches instead.
+
+If you need to use the return type of a specific function defined in the project somewhere other than that function:
+
+- For a simple primitive type such as `boolean` or `string`, write the type directly.
+- For a complex type, define a named type, specify it as the function's return type (`(): T => {}`), and reuse `T`.
+
+If you need the return type of a library function:
+
+- Check the function's type definitions first.
+- If the library exports that type, use the exported type.
+  - If you need to pass the return type of another library function as a type argument and the library does not export that function's return type, you may use `ReturnType` inside the type argument.
+- If the library does not export the type:
+  - Write the type directly if it is a simple primitive type.
+  - Otherwise, you may use `ReturnType`.
+
+```ts
+// Incorrect
+import foo from "foo";
+
+const myFunc = (): string => {...};
+
+const myFunc2 = (arg: ReturnType<typeof foo>, arg2: ReturnType<typeof myFunc>): number => {...};
+
+// Correct
+import type { FooResult } from "foo";
+
+const myFunc = (): string => {...};
+
+const myFunc2 = (arg: FooResult, arg2: string): number => {...};
+```
+
+### Prefer `as const satisfies` over type annotations
+
+Do not add type annotations unless you need them. Start by writing the code without a type annotation. If that causes a type error, first try to resolve it by improving type definitions elsewhere. Use a type annotation only as a last resort when those changes cannot solve the problem.
+
+When you write an object and need to guarantee that it conforms to a specific type, use `satisfies`. If the object will not change, also use `as const`.
+
+```ts
+// Incorrect
+const foo: Record<string, string> = {
+  bar: "bar",
+};
+
+// Correct
+const foo = {
+  bar: "bar",
+} as const satisfies T;
+```
+
+### Do not disable ESLint rules
+
+Do not disable ESLint rules as an easy workaround. ESLint errors usually identify low-quality code rather than create pointless obstacles. Disabling a rule to silence an error leaves the underlying problem in place.
+
+Disable an ESLint rule only as a last resort when no better option exists. Handle ESLint errors as follows:
+
+1. Understand what ESLint is reporting. Identify the affected code and the purpose behind the rule.
+2. Improve the code in a way that addresses that purpose.
+3. Disable the rule only when complying with it would make the code **excessively** complex, the warning is a clear false positive, you have another legitimate reason to disable it, or a possible fix would conflict with the rule's underlying intent.
+
+#### Examples
+
+The ESLint `sort-imports` rule defines a consistent import order. In properly modularized code, behavior should not depend on import order, so you should follow the rule.
+
+```ts
+// Incorrect
+/* eslint-disable sort-imports */
+import foo from "foo";
+import bar from "bar";
+
+// Correct
+import bar from "bar";
+import foo from "foo";
+```
+
+The `no-magic-numbers` rule exists to give numeric values meaningful names when their purpose would otherwise be unclear. You do not need to force an obvious value, such as `60` when it represents the number of seconds in a minute, into a constant just to satisfy the rule. In that case, disabling the rule is acceptable. Replacing `1` with a constant named `ONE` also defeats the purpose of `no-magic-numbers`. Give the value a meaningful name instead, or disable the rule if its meaning is already obvious. Also consider whether the number needs to be hard-coded in the first place.
+
+```ts
+// Incorrect
+// eslint-disable-next-line no-magic-numbers
+if (myArray.length !== 0) {...}
+
+// Correct
+if (myArray.length) {...}
+```