@bompus/house-rules 0.11.0 → 0.13.0

package/skills/hr-writing-pr/SKILL.md

@@ -42,21 +42,27 @@ Resolve mismatches between the description and the implementation before calling
 
 ## Title and body
 
-Write a title naming the resulting behavior or fixed failure. Use the repository's title convention when it has one. Check the title's type and scope against the diff's dominant change. A `docs:` title on a diff that adds an executable installer misfiles the squash commit. When no PR template exists, the title convention is the only template; default to Conventional Commits `type(scope):` unless the repository's recent history uses another style. Flag a mixed diff as a possible split into separate PRs (the `hr-split-to-prs` skill, where installed) instead of stretching the title to cover it.
+Write a title naming the resulting behavior or fixed failure, in the words of the person who feels it ("fork threads open faster"), not the mechanism ("skip hidden ancestor payloads"). Use the repository's title convention when it has one. When the PR title becomes the squash commit line, keep a measured speedup out of it, because the figure goes stale there. A repository whose convention asks for the figure keeps it. Put the qualified result, with the workload it holds for, in the body's opening sentence.
 
-Lead the body with the concrete problem and resulting behavior. A small change may need only a paragraph and a validation sentence. Expand only where the reviewer needs more context:
+Check the title's type and scope against the diff's dominant change. A `docs:` title on a diff that adds an executable installer misfiles the squash commit. When no PR template exists, the title convention is the only template; default to Conventional Commits `type(scope):` unless the repository's recent history uses another style. Flag a mixed diff as a possible split into separate PRs (the `hr-split-to-prs` skill, where installed) instead of stretching the title to cover it.
+
+Open the body with one sentence that states the benefit, before any problem detail. For a measured change it carries the qualified figure and its workload ("Clean Android builds finish 32% faster, 67.7 s to 46.2 s on a warm Gradle cache"). For a bug fix it says who hit the bug and what now works ("Cursor title generation no longer leaks a SQLite file handle on every call"). The problem and resulting behavior follow. A small change may need only a paragraph and a validation sentence. Expand only where the reviewer needs more context:
 
 - **Bug fix:** trigger, previous behavior, corrected behavior, and regression proof.
 - **Feature:** observable capability, a small usage example, and supported limits.
 - **Refactor:** motivation, the structural change, and evidence that required behavior is preserved.
 
-Explain implementation details only when they clarify a decision or help assess correctness. Include compatibility, dependency, migration, or documentation implications when the diff creates them. When the change has a hard-to-reverse surface (host-level effects such as `sudo install-deps`, migrations, destructive actions), say so in one sentence; never a fixed risk section, and nothing on purely additive changes. Identify a useful review starting point for a complex change, using `path:line` anchors for load-bearing claims.
+Explain implementation details only when they clarify a decision or help assess correctness. Include compatibility, dependency, migration, or documentation implications when the diff creates them. When the change has a hard-to-reverse surface (host-level effects such as `sudo install-deps`, migrations, destructive actions), say so in one sentence; never a fixed risk section, and nothing on purely additive changes.
+
+For a change too large to read in the diff's file order, give a reading order. Use a short numbered list where each step says what it accomplishes ("the contract, then the service that implements it, then its callers"), and anchor load-bearing claims with `path:line`. Put mechanical files in a last step that says what you checked and the pattern that holds ("same rename in all nine drivers"). Add a "Decisions for you" list only when the reviewer has a call that tests cannot make: a tradeoff, a compatibility promise, a product or scope choice, or an accepted risk. Leave bugs, missing tests and nits out of it, and omit the list when there is no such call. Name adjacent work you left out on purpose in a "Not covered" line.
+
+In a stack, open with the parent ("Stacked on #123.") and describe only this layer, measured from its parent; that layer is its final combined change. When the body attributes behavior to another layer or describes a dependency on it, name that layer by number ("added in #123", "wired into the UI in #125"). Do not describe or judge its code.
 
-Describe the final combined change. Leave out intermediate attempts, commit reshuffling, conversational history, and file inventories already visible in the diff. Write for the reviewer in plain language: no unexplained jargon, and no narrative about how the change was produced. Review panels, models consulted, harnesses, and agent process never appear in titles, bodies, or PR comments; that detail lives in plan files and session records. For routine clarifications, update the title and body. Material scope changes follow the replacement rule above.
+Describe the final combined change. Leave out intermediate attempts, commit reshuffling, conversational history, and file inventories already visible in the diff. Write for the reviewer in plain language: no unexplained jargon, and no narrative about how the change was produced. Review panels, models consulted, harnesses, and agent process never appear in titles, bodies, or PR comments, except for a disclosure the repository's contribution guidelines or PR template ask for, which is given as asked and no further; that detail otherwise lives in plan files and session records. For routine clarifications, update the title and body. Material scope changes follow the replacement rule above.
 
 ## Evidence that earns its space
 
-Report relevant checks and their actual outcomes, including material failures and unverified behavior. Name the tests or commands run and their scope; a suite-wide pass count alone is not evidence for the changed behavior. When generated files dominate the diff, give the authored line count alongside the headline number so the size does not mislead review. Distinguish newly introduced failures from established baseline failures only when a comparison supports that claim. Keep detailed logs in a linked artifact when the short result is sufficient.
+Report relevant checks and their actual outcomes, including material failures and unverified behavior. Name the tests or commands run and their scope, and the head commit they ran against; a suite-wide pass count alone is not evidence for the changed behavior. When generated files dominate the diff, give the authored line count alongside the headline number so the size does not mislead review. Distinguish newly introduced failures from established baseline failures only when a comparison supports that claim. Keep detailed logs in a linked artifact when the short result is sufficient.
 
 Use a small code example when it makes behavior concrete. For visual changes, use comparable before/after images when available. When the change replaces an existing procedure, state the prior and new procedure in one line each. For measured performance claims, follow the installed `hr-benchmarking` skill's
 "Report and decide" guidance for benefit columns, variability and claim limits.
@@ -85,20 +91,29 @@ outcomes visible; collapse long commands or supporting detail when useful.
 Required scope or approval sections stay, with only the justification and links
 the reviewer needs.
 
-For qualified measured performance changes outside the declared no-clear-change
-band, prefer a compact chart alongside the exact result table when it makes
-comparisons easier to scan. Skip charts
-that add no information, such as a single small change. Preview a proposed
-visual with the user before publishing a new visual style. Use labeled units,
-zero-based bar axes, readable contrast and meaningful precision. Show the
-workload and material limits beside it; a synthetic benchmark is not a
-production or UI speedup. Keep the table or equivalent text accessible, and
+A qualified measured change outside the declared variation criterion, with
+identical outputs, gets a
+headline chart directly under the opening sentence, beside the exact result
+table. Render it with `scripts/benefit-chart.py` in this skill's directory. It reads
+a JSON spec and writes a dark PNG with labeled units, zero-based bars and a
+benefit badge per row. Skip the chart only when every row is no clear change,
+or the one row moved by less than 10%. Set the spec's top-level `band`
+(required) to the declared variation criterion as a fraction of the baseline,
+and name it beside the chart. If the criterion cannot be a fraction of the
+baseline, skip the chart and label the result inconclusive.
+
+Show the workload and material limits beside it; a synthetic benchmark is not a
+production or UI speedup. Preview a chart in a different style with the user
+before publishing it. The image is never the only place a value or caveat
+appears. The opening sentence and the result table carry every figure, and `--table`
+prints that table from the chart's spec. The alt text the script prints carries
+them too. An agent or screen reader that cannot read the image loses nothing. Keep the table or equivalent text accessible, and
 attach PR-only graphics without committing them to the product repository.
 
 Scale structure to the change. Omit empty optional sections, placeholder text, guessed risk scores or review times, and coverage percentages that were not measured. Complete a required checklist with this PR's specifics rather than omitting it, and mark non-applicable items N/A with a reason. Preserve required template sections and mark unavailable evidence honestly.
 
 ## Completion check
 
-Every factual claim must be supported by inspected code, the originating request, or observed results. The opening explains what changes and why; the remaining text helps review it. Deliver the title and body in the form requested. Apply them to a remote PR only within the user's authorized scope. When the user's rules turn attribution off, include no `Made with` or other host attribution. After `gh pr create` or `gh pr edit`, reread the published body and strip any footer a harness appended.
+Every factual claim must be supported by inspected code, the originating request, or observed results. The opening explains what changes and why; the remaining text helps review it. Deliver the title and body in the form requested. Apply them to a remote PR only within the user's authorized scope. When the user's rules turn attribution off, include no `Made with` or other host attribution beyond a disclosure the repository asks for. After `gh pr create` or `gh pr edit`, reread the published body and strip any footer a harness appended.
 
 Relevant validation stays in the description; extensive templates and review automation are outside this skill.

package/skills/hr-writing-pr/scripts/benefit-chart.py

@@ -0,0 +1,200 @@
+#!/usr/bin/env python3
+"""Render a before/after benefit chart as a PNG for a pull request, issue or discussion.
+
+Usage: benefit-chart.py <spec.json> <out.png> [--table]
+
+The spec holds a headline, a workload line and one row per measured metric:
+
+    {
+      "headline": "Sidebar search: typing one letter takes 319 ms, was 1,136 ms",
+      "workload": "1,300 threads, 1,057 matches, dev build; median of 3 runs",
+      "arms": ["Before", "After"],
+      "band": 0.03,
+      "note": "Lower is better.",
+      "rows": [
+        {"label": "Type one letter", "before": 1136, "after": 319, "unit": "ms"},
+        {"label": "Renders", "before": 36950, "after": 7693, "unit": "",
+         "words": ["fewer", "more"]}
+      ]
+    }
+
+Row fields: label, before, after, unit (text after the value), lower_is_better
+(default true), words (the two words after the percentage, for a good and a bad
+change; default "lower"/"higher", or "higher"/"lower" when lower_is_better is false), and
+note (extra text under the label). band is required: the variation criterion
+declared before the first run, as a fraction of the baseline. A change at or
+inside it is labeled "no clear change". Bars start at zero and share a scale per row.
+
+Values must be non-negative. Prints the alt text for the image on stdout. With --table it
+also prints a Markdown table of the same values, the text version of the chart
+for readers and agents that cannot parse the image. Requires matplotlib.
+"""
+import json
+import math
+import sys
+import textwrap
+
+try:
+    import matplotlib
+
+    matplotlib.use("Agg")
+    import matplotlib.pyplot as plt
+    from matplotlib.patches import FancyBboxPatch
+except ImportError:
+    sys.exit("benefit-chart.py needs matplotlib (pip install matplotlib).")
+
+BACKGROUND = "#0d1117"
+TEXT = "#e6edf3"
+MUTED = "#9da7b3"
+BEFORE = "#6e7681"
+GOOD = "#3fb950"
+BAD = "#f85149"
+NEUTRAL = "#8b949e"
+
+
+def fmt(value):
+    magnitude = abs(value)
+    if float(value).is_integer():
+        return f"{value:,.0f}"
+    if magnitude >= 100:
+        return f"{value:,.0f}"
+    if magnitude >= 10:
+        return f"{value:,.1f}"
+    if magnitude >= 1:
+        return f"{value:,.2f}"
+    return f"{value:,.3f}"
+
+
+def band_of(spec):
+    if "band" not in spec:
+        sys.exit('spec needs a top-level "band": the declared variation criterion as a fraction '
+                 "of the baseline, such as 0.04.")
+    try:
+        if isinstance(spec["band"], bool):
+            raise TypeError
+        band = float(spec["band"])
+    except (TypeError, ValueError):
+        band = float("nan")
+    if not math.isfinite(band) or band < 0:
+        sys.exit('spec "band" must be a finite non-negative number.')
+    return band
+
+
+def judge(row, band):
+    before, after = float(row["before"]), float(row["after"])
+    lower_is_better = row.get("lower_is_better", True)
+    if before == 0:
+        return NEUTRAL, "no baseline to compare", "no baseline to compare"
+    change = (after - before) / before
+    if abs(change) <= band:
+        return NEUTRAL, "no clear change", "no clear change"
+    improved = change < 0 if lower_is_better else change > 0
+    default_words = ("lower", "higher") if lower_is_better else ("higher", "lower")
+    words = row.get("words") or default_words
+    word = words[0] if improved else words[1]
+    percent = abs(change) * 100
+    if 99 <= percent < 100:
+        percent_text = f"{int(percent * 10) / 10:.1f}%"  # never rounds up to "100%"
+    else:
+        percent_text = f"{percent:,.0f}%" if percent >= 10 else f"{percent:,.1f}%"
+    ratio = max(before, after) / min(before, after) if min(before, after) > 0 else None
+    times = f" ({ratio:,.1f}×)" if ratio and ratio >= 1.5 else ""
+    text = f"{percent_text} {word}{times}"
+    return (GOOD if improved else BAD), text, text
+
+
+def render(spec, out_path):
+    rows = spec["rows"]
+    for row in rows:
+        if float(row["before"]) < 0 or float(row["after"]) < 0:
+            sys.exit(f"row {row['label']!r}: negative values are not supported (bars start at zero).")
+    band = band_of(spec)
+    arms = spec.get("arms", ["Before", "After"])
+    count = len(rows)
+    headline_lines = textwrap.wrap(spec["headline"], 54)
+    head = 0.75 + 0.45 * len(headline_lines)
+    height = head + 0.6 + 1.25 * count + (0.5 if spec.get("note") else 0.2)
+    fig = plt.figure(figsize=(10, height), dpi=160, facecolor=BACKGROUND)
+    ax = fig.add_axes([0, 0, 1, 1])
+    ax.set_xlim(0, 10)
+    ax.set_ylim(0, height)
+    ax.axis("off")
+    ax.set_facecolor(BACKGROUND)
+
+    top = height - 0.3
+    ax.text(0.4, top, "\n".join(headline_lines), color=TEXT, fontsize=19, fontweight="bold",
+            va="top", linespacing=1.25)
+    ax.text(0.4, top - 0.4 * len(headline_lines) - 0.2, spec.get("workload", ""), color=MUTED,
+            fontsize=10.5, va="top")
+
+    arm_right, bar_left, bar_span = 1.35, 1.5, 5.6
+    y = height - head - 0.45
+    alts = []
+    for row in rows:
+        before, after = float(row["before"]), float(row["after"])
+        unit = row.get("unit", "")
+        suffix = f" {unit}" if unit else ""
+        color, badge, alt_badge = judge(row, band)
+        top_value = max(before, after) or 1.0
+        ax.text(0.4, y, row["label"], color=TEXT, fontsize=12.5, fontweight="bold", va="center")
+        ax.text(9.6, y, badge, color=color, fontsize=15, fontweight="bold", va="center", ha="right")
+        if row.get("note"):
+            ax.text(0.4, y - 0.24, row["note"], color=MUTED, fontsize=9, va="center")
+        bars = ((arms[0], before, BEFORE), (arms[1], after, color))
+        for index, (arm, value, bar_color) in enumerate(bars):
+            bar_y = y - 0.5 - index * 0.32
+            width = max(bar_span * value / top_value, 0.03)
+            ax.add_patch(FancyBboxPatch((bar_left, bar_y - 0.11), width, 0.22,
+                                        boxstyle="round,pad=0,rounding_size=0.04",
+                                        linewidth=0, facecolor=bar_color))
+            ax.text(arm_right, bar_y, arm, color=MUTED, fontsize=9.5, va="center", ha="right")
+            ax.text(bar_left + width + 0.12, bar_y, f"{fmt(value)}{suffix}", color=TEXT,
+                    fontsize=10.5, va="center")
+        row_alt = f"{row['label']}: {fmt(before)}{suffix} to {fmt(after)}{suffix}, {alt_badge}"
+        if row.get("note"):
+            row_alt += f" ({row['note']})"
+        alts.append(row_alt)
+        y -= 1.25
+
+    if spec.get("note"):
+        ax.text(0.4, 0.3, spec["note"], color=MUTED, fontsize=9.5, va="center")
+    fig.savefig(out_path, facecolor=BACKGROUND)
+    plt.close(fig)
+    lead = spec["headline"] + (f". {spec['note']}" if spec.get("note") else "")
+    if spec.get("workload"):
+        lead += f". Workload: {spec['workload']}"
+    return f"{lead}. " + "; ".join(alts) + "."
+
+
+def table(spec):
+    band = band_of(spec)
+    arms = spec.get("arms", ["Before", "After"])
+    lines = [f"| Metric | {arms[0]} | {arms[1]} | Change |", "| --- | ---: | ---: | --- |"]
+    for row in spec["rows"]:
+        suffix = f" {row['unit']}" if row.get("unit") else ""
+        change = judge(row, band)[2]
+        label = row["label"].replace("|", "\\|")
+        lines.append(f"| {label} | {fmt(float(row['before']))}{suffix} | "
+                     f"{fmt(float(row['after']))}{suffix} | {change} |")
+    notes = [f"Workload: {spec['workload']}"] if spec.get("workload") else []
+    notes += [spec["note"]] if spec.get("note") else []
+    notes += [f"{row['label']}: {row['note']}" for row in spec["rows"] if row.get("note")]
+    if notes:
+        lines += ["", *notes]
+    return "\n".join(lines)
+
+
+def main():
+    args = [a for a in sys.argv[1:] if a != "--table"]
+    if len(args) != 2:
+        sys.exit(__doc__)
+    with open(args[0]) as handle:
+        spec = json.load(handle)
+    print(render(spec, args[1]))
+    if "--table" in sys.argv[1:]:
+        print()
+        print(table(spec))
+
+
+if __name__ == "__main__":
+    main()

package/docs/npm-release.md

@@ -1,45 +0,0 @@
-# npm release setup
-
-The package name is `@bompus/house-rules`; the executable is `house-rules`.
-It has no runtime dependencies or install hooks. Installing the package does
-not install skills into an agent host. Composition writes the requested rules
-file, its `house-rules-references/` directory when the rules include reference
-procedures, and any `--skills-out` directory.
-
-Keep the `package.json` version, changelog version and `v<version>` tag
-identical.
-
-## First publication
-
-This one-time setup applies to 0.11.0, the first published version. The first publication requires an npm account that owns the `bompus` scope.
-An earlier publication of another package does not establish current login or
-scope access. Authenticate using npm's web login and complete its 2FA approval.
-Do not put credentials into the repository or workflow.
-
-On the selected release commit, run `npm run check:package -- --out <directory>`.
-Publish that verified `house-rules.tgz` with `npm publish <tarball> --access public`.
-Then configure its trusted publisher on npm for GitHub user `bompus`, repository
-`house-rules`, workflow filename `npm-publish.yml`. Enable direct `npm publish`.
-The default staged-publication permission alone does not permit this workflow.
-
-The first GitHub release workflow checks the published tarball integrity and
-skips an identical existing version. Different bytes at the same version fail
-the workflow. Subsequent versions publish automatically after trusted publisher
-setup. Do not create another release solely to test authentication.
-
-## Subsequent releases
-
-Publishing a stable GitHub release triggers `.github/workflows/npm-publish.yml`.
-It verifies that the tagged commit belongs to `main`, checks the package version
-and dated changelog entry, and checks the packed CLI and skill resources before
-publishing the same tarball. Prereleases are excluded.
-
-The workflow uses a GitHub-hosted runner and npm's OIDC trusted publishing.
-It stores no npm token. npm requires Node 22.14 or newer and npm 11.5.1 or newer;
-the workflow uses Node 26. npm automatically supplies provenance for this public
-repository and package. See the [official trusted publishing documentation](https://docs.npmjs.com/trusted-publishers/).
-
-CI runs `npm run check:package -- --bun`. It installs the actual local tarball
-into isolated scratch with lifecycle scripts disabled, exercises the CLI under
-Node and Bun, and compares composed skills and resources with the source.
-Scratch honors `HOUSE_RULES_TEST_TMP` and is removed when the check exits normally.

package/rules/modifiers/swarmail.md

@@ -1,12 +0,0 @@
----
-description: Locate Swarmail-owned instructions and tool contracts for local session coordination.
-after: Coordination and isolation
----
-
-## Swarmail coordination
-
-When Swarmail is connected, read its server instructions and tool contracts
-before using it. If those instructions are unavailable or omit a needed detail,
-read `swarmail --help` and `README.md` in its owning checkout at the installed
-or host-approved revision. If available sources do not establish that detail,
-report it as unverified rather than guessing the product's operations.

package/skills/hr-benchmarking/references/priority-findings-20261006.md

@@ -1,115 +0,0 @@
-# CPU priority findings: 2026-10-06
-
-Read this record before answering whether negative, zero or positive nice values
-improved the tested workload. Reuse these results for the same question; a new
-experiment needs a materially different workload, contention regime or hypothesis.
-Follow the host's authorization rules before changing priority or measuring again.
-
-## Result and scope
-
-Negative nice did not establish a timing or memory benefit in this small WSL
-allocation experiment. Verified effective nice 0 was the only setting that met
-the preset variation criterion for both runtimes. It is a baseline candidate for
-comparable isolated measurements, not a universal priority policy.
-
-The workload performed 16,384 warmup and 65,536 measured `Buffer.alloc(size, 1)`
-operations, cycling 1,000, 16,000, 128,000 and 1,000,000-byte buffers and retaining
-at most 128 references. Timing and CPU cover the measured loop; peak RSS covers
-the whole process. This allocation case is also reported in
-[Bun issue 44661](https://github.com/oven-sh/bun/issues/44661).
-This is a priority sensitivity comparison, not a general Bun-versus-Node ranking,
-a contention-resistance test or an explanation of that issue's root cause.
-
-## Recorded experiment
-
-The measured interval was 2026-10-06 23:42:55Z–23:45:40Z. Bun 1.4.2 and
-Node 26.10.0 used unchanged sources and binaries. Three independent processes
-per runtime/priority cell ran in counterbalanced order, for 24 processes total.
-All passed correctness, effective-control and quiet-host admission checks;
-none was rejected. The preset criterion was `(maximum - minimum) / median <= 10%`.
-
-Controls were Windows-hosted WSL, Linux kernel 7.2.8 with an unverified custom
-scheduler implementation, ordinary fair scheduling, unprivileged workload UID
-1000, CPU affinity 0–7 and identical 704 MiB `memory.high`/`memory.max` limits.
-No CPU quota was present at inspected cgroup ancestors. The launcher set absolute
-priority before dropping privileges and verified it afterward; the workload did
-not run as root. Main-thread scheduler wait included warmup and cannot establish
-timed-region or all-GC-thread scheduling effects.
-
-| Runtime | Nice | Median wall ms | Wall range ms |   Span | Median CPU ms | Median peak RSS MiB | Variation passes |
-| ------- | ---: | -------------: | ------------: | -----: | ------------: | ------------------: | ---------------- |
-| bun     |  +10 |         1445.9 | 1195.6–1467.9 | 18.83% |        1812.3 |               191.5 | no               |
-| bun     |   +0 |         1356.4 | 1326.5–1412.4 |  6.34% |        1778.9 |               191.3 | yes              |
-| bun     |  -10 |         1416.1 | 1291.2–1468.1 | 12.49% |        1781.2 |               189.2 | no               |
-| bun     |  -20 |         1346.1 | 1287.4–1497.2 | 15.58% |        1691.4 |               190.1 | no               |
-| node    |  +10 |         1196.5 | 1083.8–1231.8 | 12.37% |        1849.8 |               193.5 | no               |
-| node    |   +0 |         1136.2 | 1133.3–1138.5 |  0.46% |        1735.8 |               192.1 | yes              |
-| node    |  -10 |         1148.1 | 1097.3–1152.7 |  4.82% |        1747.0 |               191.9 | yes              |
-| node    |  -20 |         1191.7 | 1189.9–1277.3 |  7.33% |        1825.9 |               192.7 | yes              |
-
-Bun +10, -10 and -20 failed the variation criterion. Node -10 overlapped nice 0;
-Node -20 was slower. These three-process samples support no confirmed negative
-priority gain. The small quiet-host cohort does not predict behavior under
-contention or on another scheduler. The per-process measurement values below
-make the reported aggregates auditable; their scope limits still apply.
-
-## Per-process measurement values
-
-These are the 24 retained output measurements used above, with path and process
-identity fields omitted. Repetition numbers identify each process within its
-runtime/priority cell; they are not execution order. CPU is in microseconds and
-peak RSS in KiB to retain the source units. Wall values retain nine decimal
-places for aggregate recalculation, not a claim of clock accuracy.
-
-Recalculation from these samples matches every aggregate before display rounding.
-Each source output passed correctness and effective-control checks before and
-after the workload. No process was rejected. The broader host-admission receipts
-remain outside this bundle; this table provides sample-level auditability for
-the reported wall, CPU, RSS and variation values, not complete host reproduction.
-
-| Runtime | Nice | Repetition |        Wall ms |  CPU us | Peak RSS KiB |
-| ------- | ---: | ---------: | -------------: | ------: | -----------: |
-| bun     |  +10 |          1 | 1195.596419000 | 1505936 |       196116 |
-| bun     |  +10 |          2 | 1445.887323000 | 1812345 |       190948 |
-| bun     |  +10 |          3 | 1467.863081000 | 1852217 |       197132 |
-| bun     |   +0 |          1 | 1326.456355000 | 1659644 |       195900 |
-| bun     |   +0 |          2 | 1412.394017000 | 1778913 |       189540 |
-| bun     |   +0 |          3 | 1356.414170000 | 1779749 |       199772 |
-| bun     |  -10 |          1 | 1291.186539000 | 1638686 |       190644 |
-| bun     |  -10 |          2 | 1468.095042000 | 1847875 |       195332 |
-| bun     |  -10 |          3 | 1416.096128000 | 1781215 |       193692 |
-| bun     |  -20 |          1 | 1287.427399000 | 1628746 |       194676 |
-| bun     |  -20 |          2 | 1497.167736000 | 1893806 |       191196 |
-| bun     |  -20 |          3 | 1346.090557000 | 1691437 |       195036 |
-| node    |  +10 |          1 | 1083.811791000 | 1655921 |       200988 |
-| node    |  +10 |          2 | 1196.507378000 | 1849814 |       198100 |
-| node    |  +10 |          3 | 1231.812016000 | 1913550 |       197184 |
-| node    |   +0 |          1 | 1138.547173000 | 1717254 |       196524 |
-| node    |   +0 |          2 | 1136.151985000 | 1735839 |       197480 |
-| node    |   +0 |          3 | 1133.265512000 | 1736305 |       196716 |
-| node    |  -10 |          1 | 1097.328563000 | 1684817 |       196008 |
-| node    |  -10 |          2 | 1152.692612000 | 1789165 |       197780 |
-| node    |  -10 |          3 | 1148.141853000 | 1746972 |       196516 |
-| node    |  -20 |          1 | 1277.348138000 | 1994581 |       196600 |
-| node    |  -20 |          2 | 1191.670413000 | 1825925 |       197344 |
-| node    |  -20 |          3 | 1189.945316000 | 1821113 |       198976 |
-
-## Omitting nice versus requesting zero
-
-A child inherits its parent's nice value, and `exec` preserves it. Omitting
-`nice` therefore yields zero only when the parent already has effective nice 0.
-GNU `nice -n 0 COMMAND` adds zero to the inherited value; it does not reset +10
-to zero. Bare `nice COMMAND` applies the default +10 adjustment. `setpriority`
-sets an absolute value, subject to permissions; verify the effective value
-rather than treating the requested command as proof.
-
-Positive nice lowers CPU scheduling priority; negative nice raises it. Neither
-reserves a core or replaces host admission and resource controls. Keep effective
-values equal across ordinary comparison arms. General +10 background/build
-policies serve responsiveness and are separate from this experiment; these
-results do not authorize removing them or changing installed settings.
-
-Sources: [Linux getpriority/setpriority](https://man7.org/linux/man-pages/man2/setpriority.2.html)
-for inheritance, absolute values and permissions; [GNU nice](https://www.gnu.org/software/coreutils/manual/html_node/nice-invocation.html)
-for relative adjustment. GNU online retrieval was unavailable during verification;
-the installed command's help confirmed the adjustment and default +10.

package/skills/hr-change-impact/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "HR: Change impact"
-  short_description: "Check what a change could break before merging"
-policy:
-  allow_implicit_invocation: false