@bompus/house-rules 0.0.0-stage → 0.11.0

package/skills/hr-agent-guidance-refresh/references/verification.md

@@ -0,0 +1,47 @@
+# Verify installed guidance and observed behavior
+
+Use this method when guidance verification is selected. It grants no authority
+for model calls, installation, settings changes, restarts or additional probes.
+The host and repository own the supported commands and safeguards.
+
+## Keep the evidence separate
+
+| Claim      | Evidence needed                                                                    | Limit                                               |
+| ---------- | ---------------------------------------------------------------------------------- | --------------------------------------------------- |
+| Installed  | Compare destination bytes with the selected source revision                        | Does not establish discovery or loading             |
+| Discovered | Inspect the actual host catalog from the relevant repository and account           | Does not establish loaded bodies                    |
+| Loaded     | Inspect a fresh context or an approved probe for the selected instruction identity | Does not establish compliance or message visibility |
+| Followed   | Inspect the complete trace of a bounded behavior case                              | Applies to that case, host and tested revision      |
+| Prevented  | Verify enforcement on the actual host and tool paths                               | A request or mode label alone is insufficient       |
+
+Record the source and deployed revisions, host/account, repository, test scope,
+observed result and missing evidence. Keep unavailable, failed and untested
+claims explicit. Linux and native Windows checks are separate; one does not
+qualify the other. Existing sessions may still hold earlier instructions.
+
+## Check behavior without supplying the answer
+
+For an authorized no-tools context probe, ask for an existing distinctive
+instruction without including its answer. Request that the session stop after
+answering. Capture the full prompt and trace, with private data redacted under
+the owning policy. Missing or incomplete traces leave adherence unverified.
+
+Distinguish requested no-tools or skill-read-only behavior, observed adherence
+and verified enforcement. A request alone does not prevent reads, network
+access or tool effects. Read-only mode and never-approval settings do not
+establish those restrictions either. Verify the controls for the actual host
+and tool paths before claiming prevention. A missing check does not prove that
+suitable controls are absent. Do not grant trust or change permissions to make
+a probe pass.
+
+## Check adoption without changing personal choices
+
+Follow the owning source's supported pin, generator and scoped installer when
+adoption is selected. Preserve account settings, exclusions, invocation policy,
+local patches and repository safeguards. Check destinations and repeat the
+scoped restoration to verify no further writes. Do not infer approval or
+active-context loading from byte equality or an upstream commit.
+
+Record each layer's result separately. Unsupported refresh paths remain
+unverified; restarts require their existing authority. A local pass grants no
+production or other-account write authority.

package/skills/hr-api-exposure-check/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: hr-api-exposure-check
+description: Keep API responses to the fields a real consumer reads and the caller is allowed to read. Use when designing, changing or reviewing what an endpoint, resolver, webhook, serializer or server action returns, or when checking an API for excess data exposure.
+---
+
+# API exposure check
+
+A response is both a contract and a disclosure: clients come to depend on
+every field, and anyone holding the response can read it. Build responses
+from what consumers use, and remove or flag the rest.
+
+## Two answers per field
+
+For every field a response returns, at every depth, write down:
+
+1. **Who uses it.** A named consumer: a client screen, an SDK method, a
+   partner integration, a background job, or a published contract that
+   promises it.
+2. **Why this caller may see it.** The rule that lets this caller, in this
+   role, read this value on this object.
+
+Client behavior counts as a use, including pagination cursors, concurrency
+ETags or version numbers, and retry timing. Metadata still needs a consumer
+and an access rule; its transport role alone does not justify disclosure.
+Where a consumer needs only to identify a related object, use a small summary
+or an opaque reference instead of the full object.
+
+A field with both answers stays. A field missing either one is removed. When
+removal might break a consumer you cannot see (a public API, a third-party
+integration, an old mobile build still in use), do not remove it silently:
+report it as unresolved and say what evidence would settle it.
+
+## Finding consumers
+
+Search for actual reads, not declarations:
+
+- client code, including old app versions still supported
+- generated or hand-written SDKs and their published docs
+- integrations, webhook receivers, scheduled jobs and other services
+- OpenAPI, GraphQL schema or protobuf files that are published to others
+- contract tests and consumer-driven pacts
+
+A field that appears only in a type definition, a fixture, a mock or a
+snapshot has no proven consumer. Code that spreads or forwards the whole
+object proves nothing either; follow it to the place that reads a named
+field. If a field is part of a published, versioned contract, it leaves
+through a deprecation: mark it, announce it, keep it for the stated window,
+then remove it in a new version.
+
+## Cover the whole response
+
+The top-level object is the easy part. Check each of these too:
+
+- nested objects and embedded relations, which often serialize a full model
+- every item in a list, and the shape of an empty list
+- pagination and metadata blocks (total counts can reveal what the caller
+  cannot otherwise see)
+- response headers, including debug, server and timing headers
+- error bodies, for every status the endpoint can return
+- each role or tenant variant of the same endpoint
+- webhook payloads and server-action return values, which are easy to forget
+
+Hiding a field in the UI does not protect it. The raw response is visible in
+browser tools, proxies and logs. If the screen should not show it, the server
+should not send it.
+
+## Building responses
+
+- Map from an explicit allowlist or a purpose-built output type per use. Never
+  serialize a whole model or database row and then delete the fields you
+  remember. A column added next month will leak by default under that pattern.
+- Check access to the object and to each sensitive field before mapping, not
+  after. Mapping first and filtering later invites a code path that forgets
+  the filter.
+- When the client chooses fields (GraphQL selections, `fields=` or `include=`
+  parameters, sparse fieldsets), intersect its request with a server-side
+  allowlist for that caller. A client request never widens what the caller
+  may see.
+- When the stack supports runtime output validation, use a closed schema that
+  rejects undeclared properties. Keep the explicit output allowlist either way.
+- Fetch only the columns the response needs where practical. The explicit
+  output type stays the boundary either way.
+- In GraphQL, check access on every sensitive field that stays queryable,
+  not only on the parent object.
+- Give errors their own minimal shape: a stable code, a short message safe to
+  show, and a request or correlation ID. Stack traces, SQL, internal paths,
+  upstream responses and validation internals go to the server log.
+- Prefer separate output types for separate audiences (public, owner, admin)
+  over one type with conditional blanks. A `null` where a field used to be
+  still tells the reader the field exists.
+
+## High-risk fields
+
+Treat these as exposure by default and require a strong second answer:
+
+- credentials, tokens, password hashes, API keys, session or reset data
+- personal data: contact details, addresses, birth dates, government IDs,
+  location, health data
+- financial data: card or bank details, balances, billing history
+- permission internals, role lists, feature flags, fraud or risk scores,
+  moderation notes
+- internal identifiers that enable enumeration, plus hostnames, IPs, bucket
+  names, queue names, versions and other infrastructure details
+- any data belonging to another user or tenant
+
+## Tests
+
+Test the endpoint's real response, not only its mapping function. For each
+caller type the endpoint supports, assert the exact set of keys or validate
+against a closed schema that rejects unknown properties. Cover anonymous,
+owner, other-user, other-tenant, admin and reduced-access callers where those
+cases apply. Include:
+
+- fields that must be absent for this caller, named explicitly
+- nested objects and list items, not only the top level
+- supported detail, list and search paths, including empty results
+- error responses, for each status the endpoint returns
+- a guard that adding a field to the underlying model does not change the
+  response; a closed schema or exact key set does this for free
+
+A test that only checks that expected fields are present will pass while
+extra fields leak.
+
+## Scope
+
+Keep the work to the response surface. Do not widen it into general input
+validation or security cleanup unless asked, and leave unrelated
+working-tree changes alone.
+
+## Reporting changes
+
+After changing responses, report the endpoints changed, the fields removed
+and why, the fields kept with the consumer that needs each, the access rules
+added or kept, and the tests run with any unresolved compatibility risk.
+
+## Reporting findings
+
+When reviewing, sort each finding into one of three kinds:
+
+- **Exposure**: a caller can read data it should not. State who can read
+  what, how they would get it, and the impact.
+- **Unneeded surface**: a field with no consumer but no sensitive content.
+  Worth removing to shrink the contract; not a vulnerability.
+- **Unresolved**: you could not confirm the consumer or the access rule.
+  Name what you checked and what would settle it.
+
+Give each finding a confidence level and the evidence behind it. Do not call
+every extra field a security issue; that buries the findings that are. For
+a broader change review, hand the rest to `hr-code-review`.
+
+## Sources
+
+- OWASP API Security Top 10 (2023), API3: [Broken Object Property Level
+  Authorization](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/),
+  which merges excessive data exposure and mass assignment.
+- OWASP Web Security Testing Guide, on testing for excessive data exposure.
+- GDPR ([Regulation 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj))
+  Article 5(1)(c) on data minimisation and Article 25 on data protection by
+  design and by default.

package/skills/hr-api-exposure-check/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "HR: API exposure check"
+  short_description: "Return only the fields consumers need and callers may see"

package/skills/hr-audit-choices/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: hr-audit-choices
+description: "Audit the decisions an implementing agent made on the user's behalf, not its diff: trace the work into a choices ledger with a verdict per choice, changing no code. Use when the user asks which choices or assumptions went into implemented work, before landing delegated or AI-implemented work the user wants to review by decision, or when a fix works but may be shaped to one failing case."
+---
+
+# Audit choices
+
+Where a task is underspecified, the implementer decides for the user, and the
+diff does not flag it. Working code can still rest on a data shape, storage
+location, dependency, API contract or tradeoff the user never chose, and later
+work inherits each one. This audit lists those decisions so the user reviews
+choices instead of lines. It changes no code and never blocks a run; acting on
+the verdicts belongs to the caller. For whether the diff meets its spec and the
+repository's standards, use `hr-code-review`.
+
+## Steps
+
+1. **Fix the baseline.** Collect what the user actually specified: the prompt,
+   later user replies, the plan file and any spec. Choices those sources
+   explicitly left to the implementer are discretion, not audit items. Done
+   when each requirement cites its source.
+2. **Trace every choice.** Walk the session's steps, subagent reports and
+   transcripts, diffs and commits. Ask a live implementer which choices it is
+   least sure of, but treat its answer as a floor, since implementers
+   under-report. Sweep each category: data shapes and formats; storage, paths
+   and naming schemes; API contracts and error behavior; added dependencies;
+   concurrency, performance and resource tradeoffs; scope interpretation;
+   patterns later code will copy. Done when every category has been checked
+   against the diff and every choice found is either listed or cited to the
+   baseline.
+3. **Judge each choice.** Give one verdict:
+   - **sound**: general and defensible.
+   - **unsound**: state the corrected decision, the property that must hold in
+     general, rather than a patch on top. A fix shaped to the one failing case
+     is unsound even when the tests pass.
+   - **needs-user**: only for taste, product direction or external cost.
+     Record a reversible provisional call so an unattended run can continue.
+4. **Write the ledger** below. When the task has a plan file, promote
+   load-bearing sound choices into it as givens. Done when every choice from step 2 has an entry;
+   trivial discretion (internal names, cosmetic calls) may collapse to a
+   one-line count.
+5. **Report.** Group by verdict in the order needs-user, unsound, sound. Within
+   each group, put first the choices the user is least likely to have made the
+   same way. When the ledger is long, open with the two or three such choices
+   overall. Each needs-user entry becomes a close-out question, shaped as the house
+   rules' § Offers describes, with its provisional call as the recommended
+   option. List sound entries too: they
+   are the architecture the user now owns.
+
+## Ledger
+
+Write `choices.md` beside the task's plan file, or in the task's notes
+directory (§ Durable notes) when there is no plan file. Each entry carries:
+
+- **Choice**: a one-line headline, then a scenario that stands alone without
+  the diff: the triggering event, what the work does now, and what the
+  alternative would do. Define any term of art where it first appears.
+- **Gap**: what the baseline left unspecified.
+- **Reach**: what later work this constrains or enables.
+- **Verdict**, with a one-line reason, plus the corrected decision or the
+  provisional call and how to reverse it.
+- **Where**: the commit or pass that introduced it.
+
+A `sound` choice already in the ledger or promoted into the plan is settled;
+later passes do not list or decide it again. `unsound` and `needs-user` entries
+stay open until they are fixed or the user decides them. When entries cluster in one area, the
+plan was vague there, so say so in the report.

package/skills/hr-audit-choices/agents/openai.yaml

@@ -0,0 +1,2 @@
+interface:
+  display_name: "HR: Audit choices"

package/skills/hr-benchmarking/NOTICE.md

@@ -0,0 +1,36 @@
+# Source notices
+
+This notice accompanies the hr-benchmarking bundle when copied on its own.
+
+## cursor/plugins (pstack)
+
+Source: https://github.com/cursor/plugins (compared at revision `e43c7ee`)
+
+- `skills/hr-benchmarking/SKILL.md`: the validity checks are adapted from
+  `pstack/skills/benchmark-checklist/`.
+
+Copyright (c) 2026 Lauren Tan
+
+## house-rules and MIT permission notice
+
+MIT License
+
+Copyright (c) 2026 Aaron Queen
+
+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/skills/hr-benchmarking/SKILL.md

@@ -0,0 +1,316 @@
+---
+name: hr-benchmarking
+description: Benchmark equivalent work with repeated timing, CPU and memory measurements under stated inputs and controls, and check whether saved results support a performance claim. Use when asked to benchmark, to measure which option is faster or uses less memory, or to time agent or model runs. Public model leaderboard research is outside this measurement workflow.
+---
+
+# Benchmarking
+
+Follow the repository and host's commands, resource limits, authorization and
+landing rules. Reuse an existing workload and runner before building a harness.
+Read [the tool reference](references/tools.md) when selecting a benchmark,
+profiler or correctness check, or interpreting its measurements.
+
+## Define the comparison
+
+State the question, baseline, candidate, representative input and timed region.
+Exercise ordinary supported inputs and cases that disable an optimization.
+State any restrictions behind a performance claim.
+
+For a requested candidate set, record its inventory and distinguish
+configurations or capacity modes. Keep untested, invalid and unsupported
+candidates visible with reasons. A subset comparison establishes results only
+for its tested scope, not a winner across the full inventory.
+
+Before running, list the selected engines, workloads, metrics, controls and
+repetitions. Count the planned runs explicitly, including controls and stages;
+state which decision each retained dimension helps make. Choose combinations
+for that decision rather than automatically running every combination. Use a
+broader matrix when its required coverage is stated.
+Name the measurement unit: request, operation, batch or whole command. State
+whether setup, startup, compilation, input loading, retries and cleanup count.
+
+Record exact runtime, compiler, dependency and runner versions, build flags,
+input identity and source revisions. Freeze copied quality and control artifacts;
+record their hashes and the executed artifact's identity. Agreement across
+runtimes alone does not verify the intended artifact. Keep these fixed across
+repeated arms; reject mixed versions when resuming a checkpoint.
+
+Compare runtime knobs within the same build. Use equivalent outputs, release
+settings and comparable tuning. An untuned arm compares configurations rather
+than implementations.
+
+Keep warm and cold conditions explicit. Reset state or use fresh processes
+where the question requires independence. Record warmup and cache conditions.
+A reused service needs equivalent state across arms, not an arbitrary restart.
+
+## Confirm the work
+
+Validate outputs, consumed results and error counts outside the timed region
+where practical. Confirm requests arrived and asynchronous work was awaited.
+Include failures, timeouts and unresolved attempts in both arms' denominators.
+A faster wrong result or skipped operation is not a performance improvement.
+
+Identify the limiting resource from CPU versus wall time, resource counters or
+a separate profile. Check that throughput is possible given the machine and
+input. When the generator limits the result, report that limit.
+
+## Measure without changing the experiment
+
+Coordinate resource use under the host's rules. During isolated local performance
+measurements, the measuring session only monitors. Other sessions may do light
+work within the run's resource limits. Keep measured files, toolchains and
+services unchanged.
+
+Prefer removing competing work to raising priority. Record effective CPU and
+I/O scheduling policies and memory protections; keep them equal across arms.
+Use normal scheduling and all available CPUs for ordinary measurements. Omit
+automatic `nice` and `taskset` wrappers; verify inherited priority and affinity
+rather than assuming their omission resets either. Use restricted affinity or
+changed priority only for representative deployment settings, an explicit resource
+agreement or a stated sensitivity question. Record the reason and effective values.
+Preserve frozen protocols and report constrained results within their tested scope.
+
+Treat a priority or affinity change as a separate sensitivity pilot under the host's rules, with preset variation
+criteria and retained raw results. Verify that the controls apply and that
+dependencies and monitoring still progress before adopting them for the
+declared experiment. Priority changes never replace admission checks, resource
+caps or pressure rejection. Read [scheduling controls](references/tools.md#scheduling-controls)
+before choosing them. When brief bursts from other sessions keep failing host-wide
+admission on a shared host, read the [fenced-core arm](references/tools.md#fenced-core-arm)
+before proposing one; it needs the user's authorization. For questions about negative, zero or positive nice values,
+read the [recorded priority findings](references/priority-findings-20261006.md)
+before proposing another experiment.
+
+Classify the timed region against the host's budget for concurrent light work.
+A local phase is heavy when measured or expected CPU, memory or I/O exceeds
+that budget. Inspect the command, its hooks, wrappers and children before calling
+demand
+unknown. Inspection can qualify bounded ordinary work within that budget;
+missing resource samples alone does not require a trial. When inspection leaves
+potentially incompatible demand unresolved, contact the active reservation owner
+or host coordinator. If neither is identified, ask the operator. Launch that
+workload only after recording agreement on a bounded trial with CPU, memory and
+I/O limits, or an exclusive run window. Resolve input and authorization conflicts
+separately; resource admission does not override them.
+
+Apply worker limits to requested processing concurrency. Report sampled OS-thread
+counts separately; runtime background threads are not processing workers. A
+thread count alone does not establish CPU contention. Use CPU, memory, I/O and
+elapsed-time controls for the admitted resource budget. Keep thread count
+diagnostic unless a host limit or experiment requirement separately justifies
+using it to stop or reject a run.
+
+When an existing admission binds thread count, obtain revised admission before
+relaxing that condition. Preserve the other controls, held inputs and original
+run verdicts. Record the revised observer and limits before execution.
+
+For an unknown competing job, record a preset time or query limit, then inspect
+its process identity, actual demand and access to measured inputs. Stop at that
+limit. A cap, service name or active state alone does not establish incompatible
+work. Keep unresolved overlap or observer gaps unqualified; input mutation remains
+incompatible even at low demand.
+
+A retained benchmark lock does not pause other sessions or reserve every phase
+of their tasks. Qualified non-heavy checks, edits and coordination proceed without
+acquiring that lock while staying within the concurrent-work budget and preserving
+measured inputs. Classify actual commands and children, including hooks; reuse
+qualification only for comparable inputs, runtimes and worker counts. When
+inspection leaves demand unresolved, identify the missing evidence and arrange
+the bounded qualification above. Defer only the incompatible phase, naming its
+resource or input conflict;
+do not use lock ownership alone to block qualified non-heavy work. Keep repository
+integration and installation write locks separate from benchmark admission.
+
+Reserve the host only for heavy local phases or deliberately isolated local
+performance measurements. Remote model
+inference, light CLI/API work and remote waits need no exclusive slot; a
+memory cap or elapsed-time record alone does not establish heavy work. For
+remote agent/model evaluations, record the timing regime and concurrent local
+work. Apply the local admission and pressure rules below when measuring local
+performance, rather than treating every model call as a CPU benchmark.
+
+Before collecting results, declare required observers, their measurement interval
+and coverage criteria. Require successful execution and recorded coverage that
+meets those criteria. Preserve observer exit status, errors and missing samples;
+reject evidence with unexplained observer failures or insufficient coverage.
+Require empty stderr only when the observer's declared contract requires it;
+documented harmless diagnostics alone do not invalidate observation.
+
+Declare observer CPU, resident-memory and I/O budgets separately from foreign-load
+and pressure gates. Include every collector and reader, with process birth
+identities and aligned intervals. Record CPU time, average core-equivalent use,
+workload-relative CPU, resident peaks, logical log bytes and attributable storage
+I/O. Separate setup from collection; disclose missing platform counters and
+shared provider or writeback costs. A log-byte count is not physical disk I/O.
+Retain over-budget runs with an over-budget status and exclude them from accepted
+performance evidence. Declare any stop rule and replacement limit before
+execution. When automation applies a stop rule, compute it with the same code as
+the acceptance analysis. Record budget failures separately from foreign-load and pressure
+failures.
+
+Choose budgets for the host, workload duration and decision precision; there is
+no universal workload-relative CPU percentage. A budget permits collection but
+does not prove unchanged latency. Before claiming negligible observer impact or
+a small decisive gain, test sensitivity to observation separately with balanced
+controls and a preset precision criterion. Retain inconclusive controls; do not
+subtract observer CPU from workload wall time. Assign and record each run's
+protocol version before execution. A changed observer budget creates a new
+protocol version. Keep historical rejection verdicts with their original version.
+
+Before each arm, inspect CPU outside the measuring scope, memory headroom and
+pressure, swap and competing CPU, memory or I/O jobs. Use the host's admission
+limits; when it has none, declare the metrics and pass/fail thresholds before
+collecting performance results. Start only when every admission condition passes.
+During measurements, attribute CPU, load and resident memory to the recorded
+benchmark process tree or resource scope before calling them competing work.
+Expected benchmark utilization is not contention; total host CPU and load
+average include it. Collect boundary counters adjacent to the measured work,
+with unrelated probes outside that interval. Record sample times and observer
+overhead. A counter interval extending past completion cannot by itself
+establish overlap. Keep post-run observations diagnostic and use a fresh
+settled interval before the next arm.
+
+Keep uncalibrated activity counters diagnostic. Before using an activity cutoff
+to reject measurements, establish its relevance through separate sensitivity
+evidence with comparison conditions and an interference criterion set before
+analysis. Retain raw observations and inconclusive outcomes. Preserve declared
+pressure and observer checks; distinguish a conservative limit from evidence
+that interference occurred.
+
+Reject a run when inputs change, competing work crosses a declared contention
+limit, or a declared pressure condition fails. Before collecting performance
+results, define pressure rejection using stall duration, swap activity and
+memory-limit/OOM events; name any additional signals and their thresholds.
+Set a stall-duration budget from the experiment's timing precision. Record
+smaller stalls without rejecting them. Stalls exceeding the budget, swapping
+or memory-limit/OOM events invalidate measurements even when the benchmark
+causes them. Resource rejection invalidates the measurement; it alone does not
+establish an implementation defect. Investigate uncertain overlap and repeat
+affected runs within authorized retry budgets before a decisive comparison.
+A light session's presence alone is not rejection evidence.
+
+Declare per-case retry budgets before attempts; a budget grants no retry
+authority. Retain rejected attempts outside accepted samples. A later qualifying
+attempt neither erases a rejection nor relaxes its gates. After rejecting a case,
+continue other independently selected cases only when their admission passes
+and the failure cannot invalidate shared controls. Otherwise hold affected cases.
+
+Hold reservations during heavy local phases or declared isolated local performance
+measurements. Release them during remote waits, light work and reviews.
+Declare finite phase boundaries or stopping conditions, release at those
+boundaries and seek fresh admission for the next phase. While waiting, keep the
+blocked phase in the ledger and advance already-authorized independent light
+work within the active measurement's allowance. Preserve measured inputs;
+backlog presence does not authorize new implementation.
+
+Screen correctness and quality first, then use one run per selected arm to
+explore timing and resource behavior. Preserve screened-out results and their
+reasons. Label screening exploratory; one run does not support a performance
+claim. A correctness-only check can use one candidate run; report its coverage.
+
+Before exploratory runs, define the decision-relevant signal for selecting
+comparisons for confirmation. Choose comparisons that meet that signal, plus
+decision-critical comparisons, for repeated confirmation; keep necessary controls.
+Set the confirmation plan before its runs and update the explicit run count
+when the scope changes. Repetition counts depend on the
+decision and observed variation; there is no universal minimum.
+
+For a performance claim, add alternating runs to assess run-to-run variation.
+Before the first run used in that claim, set a repetition count or stopping
+rule and a reproducible variation criterion (statistic and threshold).
+
+For short or tail metrics, such as the longest stall in a run, give the
+threshold an absolute floor or use a percentile or count metric; a percentage
+of a single small maximum can fail on the workload's own variation.
+Retain every result. Keep pilots that informed the plan separate from the
+claim's sample. Capture raw results, exit status, elapsed time, CPU and memory
+observations. Report admission and monitoring overhead separately from the
+measured workload; batch compatible probes when they dominate elapsed time.
+Report the selected repetition count or stopping rule, variation statistic and
+threshold, sample count, median and range. Apply the preset
+criterion and treat a gap within run-to-run variation as inconclusive. Profile
+separately from the runs used to claim a speed difference.
+
+When using saved evidence for a performance claim, bind archived inputs, source,
+cohort and results to their recorded identities and artifact hashes. Validate
+historical reports against that frozen archive; later changes in the live
+checkout alone do not invalidate historical evidence. Verify run identities and
+stages against the declared plan.
+
+Recompute qualification from recorded raw counters and preset limits; an accepted
+summary or changed label is insufficient. Reject missing, duplicate or
+misclassified required observations. When an evidence reader exists, put these
+checks and focused corruption regressions there. After a rebase or merge
+touches the reader or a check it imports, run the integrated reader over the
+saved archive before landing, and compare its accepted and excluded records
+with the frozen reader's. A shared check changed on the base branch can reject
+records that the frozen reader accepted.
+
+Record memory by what it measures. Whole-process peak RSS includes startup,
+inputs and dependencies. Heap snapshots describe retained objects; allocation
+profiles describe allocation activity. Forced-GC probes are separate from
+ordinary latency measurements. Match retention semantics and payloads when
+comparing caches; equal requested capacities need not mean equal memory use.
+For cache-retention probes, keep the cache owner reachable through the final
+observation; otherwise collection of the owner can be mistaken for release by
+the cache operation.
+
+For WeakRef-based retention probes, use bounded allocation batches and calibrated
+collection boundaries after creating or dereferencing targets. Avoid observer
+arrays or locals that keep measured values strongly reachable; preserve the
+intended owner lifetime. Report live payload, cache occupancy and process RSS
+separately. Keep this collection protocol outside ordinary latency runs; yielding
+or forced collection alone does not guarantee that a target is reclaimed.
+
+Batch latency percentiles describe batches, not individual requests.
+
+## Report and decide
+
+Keep the full workload, versions, conditions, repetitions, output identity,
+errors and measurement units in the measurement record. Include excluded costs,
+coverage limits, collector overhead, scheduling, resource caps, admission checks
+and rejected attempts there.
+
+Pull requests and other change summaries show the workload, baseline and
+candidate, measured results, relevant checks and limits that affect the claim.
+Omit operational measurement details unless the reader needs them to interpret
+the result or asks for them. A claimed difference with unknown limits, unequal
+work or missing repetitions is unverified or inconclusive.
+
+Show numeric before/after results in a table with a benefit column containing
+percent change or a times improvement. Use the metric's direction and label
+worsening, unchanged or inconclusive results. With a zero or missing baseline,
+show an absolute change or state that the benefit cannot be calculated.
+
+Use 3% as the default practical no-clear-change band for reported differences.
+This is a reporting convention, not a statistical margin of error. Use the
+variation statistic and threshold declared before collecting results. When that
+threshold, expressed as a percentage of the baseline, exceeds 3%, widen the
+reporting band to at least that percentage and name the statistic and threshold.
+If the variation criterion cannot support a percentage band, keep its result
+separate and label unsupported differences inconclusive. A change outside the
+band still needs qualified evidence and must meet the declared variation criterion. Set a different
+precision target before collecting results when the workload requires it;
+changing presentation does not change frozen acceptance or rejection gates.
+
+For agent, model, rule or skill comparisons, distinguish development cases
+from held-out cases and report runs per case. Include a one-line instruction
+control when claiming an improvement from a rule or skill. Keep helper,
+setup and retry costs visible. Before collecting results, define a per-case
+contribution threshold. If a case exceeds it, report results both with and
+without that case.
+
+For bug-review evaluations, freeze the supported input contract and label
+procedure before calls. A passing reference suite does not certify a clean
+control. Adjudicate additional findings against that contract. A confirmed extra
+defect makes the affected specificity estimate unavailable; retain earlier
+receipts and introduce a new control version. Leave disputed domains unresolved.
+
+Report provider completion, output-format compliance and independently checked
+artifact acceptance separately. Distinguish observed call time from verification
+and rework time. Keep returned usage units separate from attributable account
+charges; unknown attribution remains unknown.
+
+Record every experiment, rejected ones included, with the observed result and
+disposition. End with adopt, reject or inconclusive, and the evidence for that
+decision. Any implementation or publication still follows the user's scope.

package/skills/hr-benchmarking/agents/openai.yaml

@@ -0,0 +1,2 @@
+interface:
+  display_name: "HR: Benchmarking"

package/skills/hr-benchmarking/references/javascript.md

@@ -0,0 +1,17 @@
+# JavaScript and TypeScript measurement
+
+Use built-in runtime profilers and oha from [the tool reference](tools.md).
+TypeScript applications execute through a runtime; compiler timing and
+application timing answer different questions.
+
+## TypeScript measurement
+
+Use [compiler diagnostics](https://www.typescriptlang.org/tsconfig/extendedDiagnostics.html)
+for compiler phases and repeated whole-command timing for builds. For application
+performance, record the executed artifact, build target, module format and source
+maps. Use the same compiled JS artifact for an engine-only comparison; report
+startup or transformation separately when it is part of the question.
+
+[Node type stripping](https://nodejs.org/api/typescript.html) performs no type
+checking and ignores `tsconfig.json`. A successful direct `.ts` execution does
+not establish TypeScript correctness.