@bompus/house-rules 0.0.0-stage → 0.11.0

package/skills/hr-code-review/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: hr-code-review
+description: Review a branch, PR, working-tree changes or changes since a revision for repository standards and spec conformance. Use only when the user requests a change review. Do not use for simplification-only or strictest maintainability audits.
+---
+
+Two-axis review of the changes the user requested: working-tree changes, a committed branch, or changes since a named revision.
+
+- **Standards**: does the code conform to this repo's documented coding standards?
+- **Spec**: does the code implement the originating issue / spec?
+
+Keep both axes distinct. Review small scopes locally; use separate read-only
+subagents when the scope benefits from independent review and the host permits
+it. Missing spec material limits the Spec assessment, not all useful review.
+
+## Process
+
+### 1. Pin the review scope
+
+Use the scope stated by the user or established in the task:
+
+- **Working-tree changes:** use `git diff HEAD` for tracked changes and `git ls-files --others --exclude-standard` to identify untracked files to inspect.
+- **Committed branch comparison:** resolve the base and use `git diff <base>...HEAD`.
+- **Since an exact commit or tag:** use `git diff <revision> HEAD`; include working-tree changes only when requested, using `git diff <revision>` and inspecting in-scope untracked files.
+- **Merge-base comparison including local changes:** resolve `git merge-base <base> HEAD`, compare the working tree with that revision, and inspect in-scope untracked files.
+
+Record the resolved base, comparison command, and whether staged, unstaged, and untracked files are included. Validate supplied refs before dispatching reviewers. Ask only when scope remains ambiguous. Report an empty scope only after checking every included category. Record the commit list when reviewing committed changes.
+
+### 2. Identify the spec source
+
+Look for the originating spec in this order:
+
+1. A path the user passed as an argument.
+2. The linked issue or pull request, or an approved plan or specification in the repository.
+3. The user's request as recorded in the session.
+4. If nothing is found, report "Spec conformance not assessed: no source found" and complete the review supported by available evidence. Ask for a source only when its absence prevents the judgment the user requested; continue independent review while awaiting it. Do not infer requirements from the implementation itself.
+
+### 3. Identify the standards sources
+
+Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
+
+When the diff adds or changes what an API returns (a handler, serializer, DTO,
+response schema or webhook payload), load `hr-api-exposure-check` and give its
+Two answers per field test to the Standards reviewer, or apply it in a local
+review. If that skill is missing or excluded, report the limit on response-field
+assessment and use the available project standards. Do not claim the skill was
+applied or install it without authorization.
+
+Use the design heuristics below when relevant to the changed code. They are prompts to investigate maintenance problems, not a checklist that must produce findings or automatic refactoring prescriptions.
+
+- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.
+- **Always a judgement call.** Each smell is a labelled heuristic ("possible Feature Envy"), never a hard violation. Like any standard here, skip anything tooling already enforces.
+
+Recommend a transformation only when inspected evidence shows a concrete current
+maintenance problem and the remedy reduces it without weakening required behavior.
+State the consequence and any equivalence assumptions; otherwise omit the finding.
+
+- **Naming:** does ambiguity cause a concrete misunderstanding at a call site?
+- **Duplication and repeated branches:** must these sites evolve together, or do they express independent policies? Extraction or polymorphism must earn its coupling and indirection.
+- **Grouped data and domain primitives:** are invalid combinations or repeated invariant checks causing problems that a type would actually prevent?
+- **Module boundaries and data access:** does current coupling force scattered edits, expose internals or mix unrelated responsibilities? Moving code must improve the boundary rather than merely rearrange it.
+- **Delegation and inheritance:** does a wrapper or interface provide a useful contract, isolation or adaptation? One caller or implementation is not itself a defect.
+- **Speculative flexibility:** does configuration or abstraction serve a current requirement? Remove unsupported complexity only after checking its consumers and behavior.
+
+### 4. Review each axis
+
+Use the same pinned scope for both axes, whether reviewing locally or delegating.
+Read [the evidence-assessment method](references/evidence.md) and include it in
+each delegated brief. It covers completion claims, weakened tests, emitted
+results and verification limits.
+When delegating and both sources are available, the reviews may run in parallel.
+If a source arrives later or scope changes, update only the affected assessment.
+
+**Hosts.** Both sub-agents are read-only. Use the current host's native agent mechanism and follow the repository's model-selection rules. A sub-agent never runs the model that wrote the code; when the author is its vendor's strongest model, use another vendor's model where one is available, through the host or that vendor's command-line agent run read-only with the same brief. When no other model is available, use a fresh context and say in the report that the reviewer shares the author's model.
+
+**Correctness of input-to-output code** goes in the Spec brief, using the
+evidence method above. Split a large scope into groups of about three files,
+one reviewer per group. Do not assign this work to a reviewer focused on
+structure or maintainability.
+
+**Standards sub-agent prompt** should include:
+
+- The full diff command and commit list.
+- The applicable standards sources and relevant design heuristics, including their evidence requirement.
+- The brief: "Report documented-standard violations with citations, and design findings only when inspected code shows a concrete current maintenance problem. For each finding give the location, consequence and proportionate remedy that preserves required behavior. Distinguish hard violations from heuristic judgments; repository standards override heuristics. Do not prescribe abstraction from a pattern alone. Skip tooling-enforced issues. Keep findings concise, with enough evidence to assess them."
+
+**Spec sub-agent prompt** should include:
+
+- The diff command and commit list.
+- The path or fetched contents of the spec.
+- The brief: "Report missing or partial requirements, behavior outside the requested scope, and incorrectly implemented requirements. Cite the requirement and code location for each finding. Keep findings concise, with enough evidence to assess their consequence. Where the spec is silent, what a reasonable user of this software would expect is still a requirement; grade it by its effect on that user. Before your verdict, list under `Declined to judge` every behavior you considered and set aside as out of scope, one line each with the reason, or write `none`."
+
+Ground findings in inspected code and cite their locations and applicable
+standards or requirements. Report concrete consequences; smells alone do not
+justify a new abstraction. Mark missing evidence and unassessed requirements
+explicitly rather than claiming a pass.
+
+### 5. Aggregate
+
+Present Standards and Spec separately. Verify delegated findings, remove
+unsupported or duplicate claims, and prioritize within each axis. Preserve the
+distinction between documented violations and heuristic suggestions.
+
+Report a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes; the separation exists to prevent that reranking.
+
+Tag each surviving finding HIGH (corroborated by a second source or a directly cited requirement), MEDIUM (single inspected source), or LOW (inferred; name the check that would confirm it). Nothing is dropped on confidence alone: the operator adjudicates.
+
+Tag each finding with one actionability label, independent of the confidence tag:
+
+- `blocking` must be fixed before merge.
+- `important` should be fixed and may block, depending on context.
+- `nit` is a minor style or preference issue.
+- `suggestion` is an optional improvement worth considering.
+- `learning` is an educational note that needs no action.
+- `praise` marks good work; report it so review is not only defects.
+
+Within each axis, order findings by actionability (`blocking` first, in the list order above), then by confidence (HIGH first).
+
+Grade actionability by the finding's effect on users, not by whether the spec
+mentions the trigger or by the implementer's stated rationale. Rule on each
+line of the Spec reviewer's `Declined to judge` list: promote it to a finding
+or confirm it out of scope, and show both in the report.
+
+### 6. Remediation options
+
+When a finding has more than one viable remedy, or the remedy you would
+recommend differs from the ideal fix, present them as an offer in the house rules' § Offers format
+for the user to choose from. Give each option a rough relative effort and its
+tradeoffs, mark the recommendation, and separately name the right fix, meaning
+the remedy that best serves the codebase absent current constraints. When the
+recommendation is not the right fix, say why: scope, risk, blast radius or
+existing debt. Skip this step for findings with a single obvious remedy; do not
+produce an options list per nit.
+
+When the user rejects, narrows or edits a finding or remedy, record the reason
+in the task's plan or notes. Record why it was wrong or
+unwanted, not merely that it was declined. For each accepted finding, record
+the verifying command or one-line reason with it, so a later session can
+re-check the fix without re-deriving the finding.
+
+## Why two axes
+
+A change can pass one axis and fail the other:
+
+- Code that follows every standard but implements the wrong thing is a **Standards pass, Spec fail.**
+- Code that does exactly what the issue asked but breaks the project's conventions is a **Spec pass, Standards fail.**
+
+Reporting them separately stops one axis from masking the other.

package/skills/hr-code-review/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "HR: Code Review"
+  short_description: "Review a diff on standards and spec"

package/skills/hr-code-review/references/evidence.md

@@ -0,0 +1,57 @@
+# Assess review evidence
+
+Apply this method to the pinned review scope, locally or in a read-only review.
+The repository owns required checks, gates and waivers; this method adds no
+permission to run commands, edit files or expand the review scope.
+
+## Read the scope and its evidence
+
+Start from the requested intent, diff, changed paths and verification evidence.
+Use an existing review packet when supplied; do not require a particular
+artifact path or release workflow. Read applicable repository guidance not
+already in context. Report missing scope or required evidence.
+
+Inspect changed regions first. When a supplied diff or shell is unavailable,
+locate those regions with available read-only search and file tools. Trace
+source, tests and consumers where needed to assess a concrete risk. Respect
+scope limits; name dependencies needing assessment outside them rather than
+asserting they are safe.
+
+Check behavior against requirements, invariants and testing standards. Treat a
+completion claim as a hypothesis to refute from the diff and evidence. For a
+bug fix, look for evidence that its regression test failed on the pre-fix code
+for the intended reason and passed after the fix. Missing evidence is a
+verification limit; whether it blocks follows the project's gate rules.
+
+## Account for weakened tests
+
+Before judging the change, list each existing test the diff deletes, skips,
+marks as expected to fail or weakens. Include narrowed assertions, widened
+tolerances and expected values rewritten to match new output. Require a stated
+reason tied to the changed requirement or supported test-audit evidence.
+An unexplained change is missing verification; classify it under the project's
+verification requirements rather than accepting the new output as its reason.
+
+When test auditing is in scope, use the installed `hr-test-audit` bundle's
+method and floor guard if available and command execution is authorized.
+The guard detects some weakening patterns; a clean result does not replace
+reading changed assertions. Report unavailable coverage without installing or
+running tools outside the selected scope.
+
+## Trace emitted results
+
+For input-to-output code such as resolvers, parsers or extractors, trace every
+path in scope to its emitted result before reporting performance or structure
+findings. Start from the nearest test fixture and construct the smallest input
+change that would emit a wrong result or drop a correct one. Report a confirmed
+counterexample with the fixture, changed input, expected and emitted results,
+and `path:line` for the steps. When no counterexample is found, record the paths
+and cases assessed; do not invent a failing result to fill the report.
+
+## Ground the result
+
+Do not repeat verified lint, type or format checks or invent release gates.
+Confirm each finding with its file and line, violated requirement and evidence.
+Distinguish confirmed defects from unresolved questions and omit speculative
+findings. Report missing evidence and unassessed requirements separately.
+A review pass does not establish that unrun checks passed.

package/skills/hr-design-exploration/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: hr-design-exploration
+description: "Explore visual design or redesign alternatives through four ranked directions, top-two feedback and successive refinement toward one chosen design. Use when asked to propose or compare UI design directions; ordinary UI fixes and implementing an already chosen design do not need this workflow."
+---
+
+# Design exploration
+
+Use the user's requested scope and constraints. The default is four initial
+directions, then rounds containing the two selected designs and one variation
+of each. A requested count applies to the initial comparison unless the user
+also specifies refinement rounds. Refinement defaults to four options. Before
+a differently sized refinement round, agree which selected designs to retain
+and how many variations to show. The user's chosen method takes precedence.
+
+## Establish the comparison
+
+Read the brief and current design. Identify the intended users, primary task,
+content, required interactions, brand constraints and target viewports. Use
+existing answers; ask only for missing information that would change the
+alternatives. State the goal used to rank recommendations.
+
+Keep the same real content, states and viewport sizes across previews. Hold
+accessibility and required behavior constant. If content is unavailable, label
+placeholder content and the assumptions it introduces.
+
+## Show the initial directions
+
+Create four meaningfully different approaches by default to the same goal. Differences
+should affect hierarchy, layout, navigation, interaction or density. Color
+swaps alone do not make distinct directions. Stay within the authorized
+prototype scope; keep the current implementation available for comparison.
+
+Show inspectable previews at comparable sizes, using the host's available
+preview or image tools. Include interaction states when they distinguish the
+directions. If rendering is unavailable, label the output as concepts and name
+what remains unverified. Never claim an unseen design was visually checked.
+
+Give each direction a stable ID and a short descriptive name. Present the directions
+in recommendation order, strongest first. Mark the strongest choices
+"(Recommended)" and explain why they fit the stated goal. Recommendations are
+judgments; do not invent usability results, performance gains or scores.
+
+Beside the previews, use a short comparison table with each direction's ID,
+main difference, benefit and tradeoff. Keep IDs stable when rankings change.
+Ask the user to select their top two and give feedback on each, including what
+to retain and what to change. Follow the host's question format. Wait for the
+answer before narrowing or generating the next round.
+
+## Refine the selected two
+
+Record the chosen IDs and feedback in the task's durable design notes. Keep
+eliminated directions there so later rounds do not revive rejected ideas by
+accident. If the user chooses one as final, move to final selection below.
+
+By default, show four options again:
+
+1. The first selected design, unchanged as a comparison.
+2. The second selected design, unchanged as a comparison.
+3. One variation of the first design responding to its feedback.
+4. One variation of the second design responding to its feedback.
+
+Give variations new IDs and name their parent IDs. Explain what changed and
+which feedback it addresses. Keep the inherited strengths visible and the
+variation distinct enough to assess. Rerank the round against the goal and
+latest feedback, mark recommended choices, and ask for the next top two with
+feedback on each.
+
+Repeat this round only after a new selection. Do not add new unrelated
+concepts unless the user asks to reopen exploration. If feedback leaves no
+meaningful variation to test, offer final selection or ask which unresolved
+tradeoff needs another round instead of inventing cosmetic differences.
+
+## Final selection
+
+An explicit final choice ends exploration; no minimum round count is required.
+Record the chosen ID, accepted refinements, rejected directions and remaining
+uncertainties. Summarize the final design's layout, interactions and relevant
+responsive states so implementation can follow it.
+
+Choosing two for refinement authorizes that comparison, not promotion of a
+winner. Apply the final design within existing implementation authorization;
+when implementation or landing has not been authorized, offer that next step.

package/skills/hr-design-exploration/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "HR: Design exploration"
+  short_description: "Compare four design directions and refine the top two"
+  default_prompt: "Use $hr-design-exploration to show four ranked visual directions and refine my top two toward a final design."

package/skills/hr-diagnosing-bugs/NOTICE.md

@@ -0,0 +1,45 @@
+# Source notices
+
+This notice accompanies the hr-diagnosing-bugs bundle when copied on its own.
+
+## mattpocock/skills
+
+Source: https://github.com/mattpocock/skills (compared at revision `d81f3a1`)
+
+- `skills/hr-diagnosing-bugs/`: written for this repository after
+  `skills/engineering/diagnosing-bugs/`, which it shares a purpose with.
+
+Copyright (c) 2026 Matt Pocock
+
+## cursor/plugins (pstack)
+
+Source: https://github.com/cursor/plugins (compared at revision `e43c7ee`)
+
+- `skills/hr-diagnosing-bugs/SKILL.md`: § Question the premise is adapted from
+  `pstack/skills/principle-attack-the-premise/`.
+
+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-diagnosing-bugs/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: hr-diagnosing-bugs
+description: Investigate unknown-cause or intermittent bugs and performance regressions systematically. Evident fixes only on explicit diagnosis requests; exclude change reviews.
+---
+
+# Diagnosing bugs
+
+When filing an upstream bug, follow [Reporting a bug](references/reporting.md)
+for reduction, submission and fix verification.
+
+Follow project guidance for source paths, domain safeguards, tests and deployment.
+Read relevant domain documents when they help explain the affected behavior.
+Choose the next probe from the evidence; these techniques are not mandatory phases.
+
+## Choose a model when needed
+
+Use the project or host's current benchmark-backed order for bug-finding models
+and efforts. Primary, secondary and tertiary choices can change with benchmark
+results; read the current selection rather than carrying names from an old run.
+If the primary is unavailable through quota, outage or an unsupported route,
+use the next available eligible choice within authorized billing limits only
+when changing provider, model or effort is authorized. When the low-quota
+handoff rule applies, use the `hr-handoff` skill and stop, even if a model change
+was authorized. Preserve review independence and record the model, effort and fallback
+reason.
+If no eligible model is available, report the blocker.
+
+## Establish the symptom
+
+Identify expected and observed behavior and seek a repeatable signal for the
+reported failure. Source inspection and initial hypotheses can help construct it.
+Prefer an existing test, command or captured input before building a harness.
+Minimize the scenario when doing so helps distinguish causes or create a useful
+regression test; an exhaustively minimal reproduction is not a prerequisite.
+
+For intermittent failures, record attempts and failures under comparable
+conditions. Increase the reproduction rate when practical within host load and
+environment safeguards; do not impose a fixed retry count or success threshold.
+For performance regressions, establish a measured baseline before changing code.
+
+If reproduction is unavailable, continue useful source and artifact analysis,
+label hypotheses as unverified, and report what would confirm them. Ask for
+missing access or evidence only when it blocks further progress. Production
+instrumentation still requires the applicable authorization.
+
+## Distinguish causes
+
+State a falsifiable prediction for the likely cause and test it. Consider
+alternatives when evidence is ambiguous or a probe fails; there is no hypothesis
+quota. Use targeted inspection, a debugger, logs, replay, bisection or differential
+testing according to the uncertainty each resolves. Keep probes attributable by
+changing one relevant variable at a time where practical.
+
+When the cause depends on event order between actors, control the relevant
+boundaries in an implementation test. Pause a response or write, interrupt the
+process, then resume or restart it and assert the visible result. Use barriers
+or explicit signals instead of sleeps to force the failing order. When the
+failing order is unknown, the `hr-ordering-tests` skill enumerates the orderings
+through the real code and names the sequence that breaks.
+
+Keep secrets out of commands and shared artifacts; use environment variables
+for credentials and redact captured headers or logs before displaying them.
+Tag temporary instrumentation so it can be found and removed. When a human must
+perform a reproduction step, give clear steps and the expected observation.
+
+## Bound the loop
+
+When retrying a probe or fix, cap attempts per hypothesis, stop on
+no-progress (repeated identical calls, oscillation, unchanged error class),
+and enforce time/token/cost ceilings outside the agent so a stuck loop
+terminates instead of retrying.
+
+## Question the premise
+
+When two fixes that rest on the same assumption have failed the same check,
+stop fixing and test the assumption. Write it down as the one sentence every
+failed fix took for granted. Before a third fix, gather evidence that would
+show the sentence false, such as a count per input, actor or run, and keep it
+as a script that can be rerun. If the evidence contradicts the sentence, find
+what made it false and fix that, instead of compensating for it on every run.
+If the evidence supports the sentence, keep it as a record and look for the
+cause elsewhere.
+
+## Fix and verify
+
+When the confirmed cause admits more than one viable fix, such as a targeted
+workaround versus a root-cause correction, present the fixes as an offer (the house rules' § Offers) with
+rough relative effort before changing code. Mark the recommendation and name
+the right fix when it differs, with the reason: scope, risk, blast radius or
+existing debt. Skip this when the evidence supports a single obvious fix or
+the user already prescribed the remedy.
+
+Make the smallest fix supported by the evidence. Use a regression assertion that
+exercises the actual failure when a suitable seam exists and the change warrants
+it under project guidance. It must fail on the pre-fix code for the intended
+reason and pass after the fix, as `hr-test-audit` requires. Test-first ordering is optional
+unless requested or required by the project.
+
+Recheck the original symptom, including the original scenario if a minimized
+case was used. For intermittent or performance issues, compare measurements and
+report their limits. If verification is blocked or coverage lacks a suitable
+seam, state the gap rather than claiming the fix is proven or expanding the
+architecture without authorization.
+
+Remove temporary instrumentation and throwaway artifacts. Report the cause,
+change, checks actually run and remaining uncertainty. Recommend preventive work
+only when the evidence supports a concrete benefit; follow project completion
+and scope boundaries.

package/skills/hr-diagnosing-bugs/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "HR: Diagnosing Bugs"
+  short_description: "Diagnose hard bugs and regressions"

package/skills/hr-diagnosing-bugs/references/reporting.md

@@ -0,0 +1,72 @@
+# Reporting a bug
+
+Before filing, apply the submission search in your loaded agent guidance's "Repository work" section.
+If that section is unavailable, locate the local house-rules checkout and read
+`rules/core.md` there. Report an unavailable local source before submitting.
+Inspect labels, linked changes and timeline actions as well as comments.
+For the same problem and scope, add new evidence to a matching open issue.
+When a closed report still reproduces and remains materially unchanged,
+explain the failed fix or changed conditions and request reopening. If reopening
+is unavailable, file one linked follow-up. For material changes, use the
+replacement workflow below.
+
+Reduce the failure to the smallest self-contained reproduction you can verify.
+Remove unrelated code, dependencies, data and setup. Keep reducing until each
+remaining part is needed to reproduce the failure. For a library failure,
+trace the failing path and isolate its underlying runtime API or language
+operation. Use source inspection, profiling or controlled substitutions to
+choose the next reduction; a slow dependency does not establish its cause.
+
+Verify both the final reduction and the original scenario with exact commands
+and pinned versions. Preserve the inputs, output checks and relevant allocation,
+retention, concurrency or lifecycle behavior. A similar standalone failure is
+a contributor observation until evidence connects it to the original symptom.
+For performance or memory bugs, compare equivalent work under the applicable
+benchmark protocol. State units, repetitions, variability and measured controls;
+put the focused case before a larger comparison matrix.
+
+Include a cause-and-reduction note in the report: the isolated operation,
+evidence connecting it to the original failure, and remaining uncertainty.
+Test the proposed cause by changing or removing the suspected factor while
+preserving the other relevant conditions. Distinguish a reproduced operation,
+a supported causal explanation and a confirmed internal defect. Do not infer
+an engine defect merely because one runtime is slower on a library workload.
+
+Lead with one symptom, the reproduction, expected and actual text results,
+and the versions and environment needed to reproduce it. Check the current
+stable release; identify development builds separately when tested. A verified
+small reproduction can be reported while its internal cause remains unknown.
+
+Show direct reproduction commands. Omit incidental scheduling, resource-control
+and observer wrappers from issue and pull request examples. When a control is
+required to reproduce the defect, include it and explain why. Keep exact executed
+commands in measurement records; disclose material conditions beside performance
+results without presenting local controls as prerequisites or changing historical
+conditions. This reporting choice is checked by the author, not a syntax gate.
+
+When reduction is blocked, record the attempted isolations and why the remaining
+parts are necessary before asking whether to submit the broader case.
+
+Read the repository's contribution guidance and matching issue template,
+including organization defaults. Complete required fields and checklists.
+Submit issue forms through the form or tooling that preserves required fields,
+labels and routing; copied headings alone do not preserve form metadata.
+Verify the published body and metadata. If available tooling cannot preserve
+the form, prepare the report and ask for access or user submission.
+
+When an issue needs major or material changes, replace it with a new issue
+in any repository. Compare the proposed revision with the published report.
+A revision is major or material if it changes the reported problem, scope,
+reproduction mechanism or main conclusion. Carry forward relevant evidence and unresolved
+questions, and link the old and new reports both ways. Submit and verify the
+replacement before closing the old report as superseded, not fixed. Routine
+corrections and evidence that leave the report materially unchanged stay in place.
+
+Keep one active report per problem after replacement. Follow up with new
+evidence or a specific unanswered question. An absent bot comment is not
+evidence that nothing happened. Do not duplicate a report or close and reopen it merely to seek
+priority. Small examples help investigation; they do not guarantee action or a fix deadline.
+
+When a fix build is available, test the same reproduction and report the
+revision and before/after result. Distinguish triage, an open fix, a merged fix
+and a released fix. Verify the affected behavior before calling it resolved.

package/skills/hr-explain-code/NOTICE.md

@@ -0,0 +1,37 @@
+# Source notices
+
+This notice accompanies the hr-explain-code bundle when copied on its own.
+
+## humanlayer/skills
+
+Source: https://github.com/humanlayer/skills (compared at revision `bba9d13ab34f0a87f1cc33df4dd196372393ddfc`)
+
+- `skills/hr-explain-code/SKILL.md` and `skills/hr-writing-pr/SKILL.md`: compact
+  visual explanation and focused structural-diff guidance adapted from
+  `plugins/show-me/skills/show-me/SKILL.md`.
+
+Copyright (c) 2026 HumanLayer
+
+## 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.