@bompus/house-rules 0.0.0-stage → 0.11.0

package/skills/hr-better-typography/variable-fonts-and-opentype.md

@@ -0,0 +1,105 @@
+# Variable fonts and OpenType
+
+What a font file can do beyond drawing letters and how to reach those abilities from CSS.
+
+## Static vs variable
+
+- **Static font:** one weight and one style per file. Regular, medium and bold is three files.
+- **Variable font:** a whole range in one file. Any value in it works, such as `font-weight: 589`.
+
+A variable font is not automatically better. At one or two weights, static files can be smaller. At several weights, optical sizes, or custom axes, a variable font usually wins.
+
+## Load intended weights and styles
+
+Use a weight or style the active family does not provide and the browser may synthesize it, so load the faces the design uses. `none` disables weight, style, small-cap, superscript and subscript synthesis together and can erase distinctions when the real face is unavailable. Verify the whole fallback stack and every emphasis state before setting it.
+
+```css
+.brand-wordmark {
+  /* Safe only after this isolated treatment is verified */
+  font-synthesis: none;
+}
+```
+
+For body and interface text, keep synthesis enabled unless a verified font setup supplies every requested form. If only one mode is unwanted, use the specific longhand (`font-synthesis-weight`, `font-synthesis-style` and related properties) instead of the blanket shorthand.
+
+## Axes
+
+Variable-font controls, each with a four-letter tag. A font supports only the axes its designer included.
+
+| Axis         | Tag                       | Controls                                       |
+| ------------ | ------------------------- | ---------------------------------------------- |
+| Weight       | `wght`                    | Stroke thickness (like `font-weight`)          |
+| Optical size | `opsz`                    | Details and spacing tuned for the display size |
+| Width        | `wdth`                    | Glyph width                                    |
+| Slant        | `slnt`                    | Slant angle                                    |
+| Custom       | e.g. `GRAD` (Roboto Flex) | Whatever the designer built                    |
+
+Inter's variable file exposes only `wght` and `opsz`.
+
+Optical sizes predate variable fonts, and many families still ship them as separate files. Heldane Text is sturdier and more spaced for reading sizes, Heldane Display finer for large ones.
+
+## Properties over axis tags
+
+When a property exists, use it. `font-weight` keeps working when a non-variable fallback renders, where `font-variation-settings` silently does nothing. Save raw tags for custom axes with no property of their own:
+
+```css
+/* Good: common axes use the properties */
+.heading {
+  font-weight: 650;
+  font-optical-sizing: auto;
+}
+
+/* Good: custom axis with no property of its own */
+.heading-grade {
+  font-variation-settings: "GRAD" 80;
+}
+
+/* Bad: weight via raw tag breaks on fallback fonts */
+.heading {
+  font-variation-settings: "wght" 650;
+}
+```
+
+## OpenType features
+
+OpenType is the standard behind almost every modern font. Features are extra built-in options and, unlike axes, work the same on static and variable fonts. A font ships only the features its designer included.
+
+| Tag           | Feature                                         |
+| ------------- | ----------------------------------------------- |
+| `tnum`        | Tabular numbers: every digit the same width     |
+| `zero`        | Slashed zero: `0` distinct from `O`             |
+| `liga`        | Ligatures: joins pairs like "fi" into one shape |
+| `ss01`–`ss20` | Stylistic sets (numbered slots)                 |
+| `cv01`–`cv99` | Character variants (numbered slots)             |
+
+Same rule as axes. Prefer the `font-variant-*` properties and reserve `font-feature-settings` for tags with no property:
+
+```css
+/* Good: common features use the properties */
+.price {
+  font-variant-numeric: tabular-nums;
+}
+
+/* Good: slashed zero via the property too */
+.id {
+  font-variant-numeric: slashed-zero;
+}
+
+/* Good: niche feature with no property of its own */
+.logo {
+  font-feature-settings: "ss01" 1;
+}
+```
+
+Tabular numbers matter for changing values. Without them each digit has a different width and the layout shifts as values update.
+
+## Small caps, superscripts, subscripts
+
+- **Small capitals:** uppercase letters drawn at a smaller size. Enable real ones with `font-variant-caps`.
+- **Superscripts** sit above the normal line, the 2 in x², and **subscripts** below it, as in H₂O. Enable proper glyphs with `font-variant-position`.
+
+Both require the font to include the glyphs.
+
+## Stylistic sets and character variants
+
+`ss01` = stylistic set, slot 01. `cv11` = character variant, slot 11. What each slot does differs font to font, which is why they are numbered, not named. Check the font's docs. In Inter, `ss01` switches to open digits and `cv11` swaps in a single-story `a`.

package/skills/hr-better-typography/wrapping-and-punctuation.md

@@ -0,0 +1,57 @@
+# Wrapping and punctuation
+
+Where lines start, where they end, where they break and which characters they use.
+
+## Measure (line length)
+
+Long lines make it harder for the eye to find the start of the next. For long-form text, aim for 60–75 characters per line.
+
+Any unit works. `65ch` measures characters directly, one `ch` being the width of the `0` in the current font, and a pixel or rem cap is just as good. At a `16px` body size the 60–75 character range lands roughly between `560px` and `680px` depending on the font, so Tailwind's `max-w-xl` (`576px`) and `max-w-2xl` (`672px`) both fit. What matters is that a cap exists and the line length sits in range. Recheck it if the body font size changes.
+
+## Alignment
+
+`text-align` controls where each line starts and ends. `justify` stretches spaces until both edges line up, which works in specific editorial layouts and nowhere else in an interface.
+
+## Wrapping
+
+| Property                    | Use                                                                |
+| --------------------------- | ------------------------------------------------------------------ |
+| `text-wrap: balance`        | Distributes text evenly across multiple lines                      |
+| `text-wrap: pretty`         | Avoids leaving a single short word on the final line               |
+| `overflow-wrap: break-word` | Lets long words, links and IDs break before escaping the container |
+| `white-space: nowrap`       | Keeps labels and badges on one line where a break looks broken     |
+
+Use `balance` on headings and `pretty` on descriptions. Skip both in long-form text, because browsers ignore `balance` past a few lines anyway, and evening out a whole paragraph wastes space and makes it harder to read.
+
+## Truncation
+
+- Single line: `text-overflow: ellipsis`, which needs `overflow: hidden` and `white-space: nowrap`.
+- Multiple lines: `line-clamp` allows any number of lines before the ellipsis.
+- Middle: CSS has no middle ellipsis. Split the string in markup, an end-truncating head and a fixed tail such as the extension or last few characters, or shorten it in script with the full value in `title`. Use it where items differ at the end (`Q3-report…v12-final.pdf`).
+- None: numbers, amounts, dates and anything the user compares get the room they need.
+
+Truncation hides content. Where the missing text matters, make the full value available in a tooltip or an expanded view.
+
+## Case
+
+`text-transform` changes how case appears without changing the underlying text. Write copy naturally and control presentation with CSS, so a redesign never means rewriting copy.
+
+## Smart punctuation
+
+Keyboard characters are not always the best characters:
+
+| Instead of               | Use                                                                    |
+| ------------------------ | ---------------------------------------------------------------------- |
+| Straight quotes `"..."`  | Curly quotes that curve around the text (keep straight quotes in code) |
+| Hyphen in ranges         | En dash: `2010–2020`                                                   |
+| Two hyphens for an aside | Em dash character                                                      |
+| Three periods `...`      | The single ellipsis character `…`                                      |
+| Regular space in `16 px` | ` ` so the value never breaks apart                               |
+| Uncontrolled word breaks | `­` to mark where a word may break                                 |
+
+## Internationalization
+
+Two refinements for mixed-direction text:
+
+- **Long paragraphs align by their own language.** A one- or two-line snippet follows the surrounding UI's direction. A paragraph of three or more lines aligns to its own script instead, so an English paragraph stays start-aligned LTR even inside an RTL interface. `text-align: start` with the correct `lang`/`dir` on the paragraph element handles this.
+- **Never reverse digits.** Numbers keep their order in every direction, so a phone number or "541" reads identically in RTL. Browsers handle this through the Unicode bidi algorithm. Never fight it with manual reordering, and wrap mixed number and text values in `<bdi>` where adjacent RTL text disturbs them.

package/skills/hr-better-writing/LICENSE

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2026 Jakub Krehel
+Copyright (c) 2026 Emil Kowalski
+
+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-better-writing/NOTICE.md

@@ -0,0 +1,46 @@
+# Source notices
+
+This notice accompanies the hr-better-writing bundle when copied on its own.
+
+## jakubkrehel/skills
+
+Source: https://github.com/jakubkrehel/skills (compared at revision `267330e1adfc66a718fb65fa6918c1f06d0a689e`)
+
+- `skills/hr-better-accessibility/`, `skills/hr-better-colors/`, `skills/hr-better-layout/`,
+  `skills/hr-better-typography/` and `skills/hr-better-writing/`: adapted skill bundles,
+  including their supporting references and discovery metadata.
+
+Copyright (c) 2026 Jakub Krehel
+
+## emilkowalski/skills
+
+Source: https://github.com/emilkowalski/skills (compared at revision `e8a175de22ae1e49370fc144c1f3bb9aeedf988d`)
+
+- `skills/hr-better-layout/`, `skills/hr-better-typography/` and `skills/hr-better-writing/`:
+  clipping, truncation and plural-form guidance adapted from `skills/break-ui/SKILL.md`.
+
+Copyright (c) 2026 Emil Kowalski
+
+## 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-better-writing/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: hr-better-writing
+description: "Interface copy rules: button and link labels, error messages, empty states, placeholders, toggles and consistent terminology. Use when writing or reviewing text users see in a web UI; commit messages, PRs, docs and replies belong to hr-plain-prose."
+license: MIT
+metadata:
+  upstream: https://github.com/jakubkrehel/skills
+  upstream_ref: 267330e1adfc66a718fb65fa6918c1f06d0a689e
+  upstream_path: skills/better-writing/
+  local_patches: "Use-when description; name-validation example; plural check at 0, 1 and many (from emilkowalski/skills break-ui)"
+  house_rules_patches: "Portable provenance and review verdict"
+  break_ui_source: https://github.com/emilkowalski/skills/blob/e8a175de22ae1e49370fc144c1f3bb9aeedf988d/skills/break-ui/SKILL.md
+---
+
+# Interface writing
+
+Clear and brief beats clever; consistent beats varied. The best error message is the interaction redesigned so the error cannot happen.
+
+How copy renders (capitalization via `text-transform`, truncation, smart punctuation) belongs to `hr-better-typography`. Error markup and announcements (`aria-invalid`, live regions) belong to `hr-better-accessibility`. Room for translated strings belongs to `hr-better-layout`.
+
+## Recon the existing voice
+
+Before writing or reviewing, read the copy nearby. Note the product's terminology, its localization conventions and any voice or content style guide.
+
+A deliberate brand voice is not a defect. Raise a departure from plain language only when it creates inconsistency, ambiguity, translation risk, or a tone the stakes don't support.
+
+## One voice, flexible tone
+
+The product has one voice and its existing copy establishes it. A local edit does not get to invent a new one. Keep terms consistent: if it's "Archive" in the menu, it isn't "Move to storage" in the toast. Tone flexes with the stakes:
+
+| Context                           | Tone                          |
+| --------------------------------- | ----------------------------- |
+| Success, onboarding, empty states | Warm, can be light            |
+| Routine actions, settings         | Neutral, minimal              |
+| Errors, destructive confirmations | Calm, plain, zero playfulness |
+| Data loss, security               | Serious, explicit             |
+
+## Address the reader directly
+
+In instructional copy, write "you", not "the user". In errors, "we" invites ambiguity and reads as deflection, so prefer "Unable to load content" over "We're having trouble loading this content". In success, onboarding and empty-state copy, an established first-person voice can stay if it reads clearly.
+
+Use possessives sparingly: "Favorites" beats "Your Favorites". Hold one perspective throughout a flow.
+
+## Plain words over clever ones
+
+Choose words a tired reader gets on the first pass, and delete every word that does no work. No idioms, no colloquialisms, no humor that won't translate.
+
+Skip unnecessary gender: "Subscribers can post recipes", not "each subscriber can post his or her recipes". Match the input device: "tap" on touch, "click" with a pointer, "select" when both are possible.
+
+Never assemble a sentence from fragments around a variable (`"You have " + n + " new messages"`), because word order changes per language. Use a full templated string with proper pluralization: the i18n library's plural forms or `Intl.PluralRules`, checked at 0, 1 and many so "1 members" never ships.
+
+## Verb-first buttons
+
+A button label starts with a verb naming the action: "Send", "Save draft", "Delete project". Never "OK!", "Let's go!", or a bare "Yes" and "No" on a consequential action.
+
+A confirmation button repeats the consequence, so the dialog is answerable without reading the body. "Delete this project?" offers `Delete project` and `Cancel`.
+
+## Consistent flow vocabulary
+
+A multi-step flow uses one vocabulary throughout: "Get started" to enter, "Continue" or "Next" (pick one) to advance, "Done" to finish. Alternating synonyms makes users wonder whether the buttons do different things.
+
+## Links describe their destination
+
+Link text has to make sense out of context, because screen-reader users navigate by a list of the page's links. Write "Read the billing docs". "Click here" fails this and the device-verb rule at once.
+
+A bare "Learn more" breaks down as soon as two appear on one page. Suffix each one: "Learn more about exports".
+
+## One capitalization policy
+
+Pick title case or sentence case per element type, then apply it to every instance of that type. Sentence case is the safer default. It is calmer, has no per-word rules to remember and localizes cleanly. "Save Changes" beside "Discard changes" reads as sloppiness.
+
+## Settings describe the ON state
+
+Label a toggle for what happens when it is on. "Send read receipts" lets users infer the off state; the negative ("Don't send read receipts") turns the toggle into a double negative.
+
+Link straight to a referenced setting rather than describing the path to it: a "Notification settings" link, not "Go to Settings > Notifications > Email".
+
+## Errors say how to fix, next to where it broke
+
+An error is an instruction, and it belongs beside the field that failed:
+
+| Bad                         | Good                                                 |
+| --------------------------- | ---------------------------------------------------- |
+| That password is too short  | Choose a password with at least 8 characters         |
+| Invalid date                | Enter a date as DD/MM/YYYY                           |
+| Oops! Something went wrong. | Unable to save. Check your connection and try again. |
+
+No blame, no "oops", no exclamation marks. Phrase hints positively ("Use digits only", not "Don't use letters or symbols") and show them before the mistake, not after. When the same error keeps firing, redesign the interaction instead of rewording it.
+
+## Empty states point forward
+
+An empty state says what this place is, how to fill it and offers one clear next action:
+
+```html
+<!-- Bad: a shrug -->
+<p>No results.</p>
+
+<!-- Good: orientation plus a next step -->
+<p class="font-medium">No projects yet</p>
+<p class="text-sm text-zinc-500">Projects keep your tasks and files together.</p>
+<button class="mt-4">Create a project</button>
+```
+
+A search or filter empty state names the query and offers an exit: "No results for 'quarterly'. Clear filters". Never park persistent information in an empty state. It disappears the moment content exists.
+
+## Placeholders are examples, not labels
+
+A placeholder shows the expected format: `name@example.com`, `DD/MM/YYYY`. It vanishes on input, so it is never the only label. Every field keeps a visible one.
+
+## Reporting
+
+**Severity.** `HIGH` misleads the user or hides how to recover from an error. `MEDIUM` breaks voice, terminology, or capitalization consistency. `LOW` is isolated wording polish.
+
+**Verification.** Source alone is enough here. Check every label against the action it invokes, every error for a stated fix and terminology against the copy around it. No browser check is required.
+
+**Format.** Group findings under the principle each violates, ordered by severity, one row per root cause listing every location it appears in:
+
+| Severity | Location | Before | After | Why |
+| -------- | -------- | ------ | ----- | --- |
+
+`Location` is `path/to/file:line`. `Why` names the principle and the user impact.
+
+Report `Block` when any `HIGH` remains. With partial coverage and no `HIGH`, report the coverage gap without a verdict. With complete coverage and no `HIGH`, report `Approve`, leaving lower-severity findings in the table as work to do. With nothing to report, state "No actionable writing findings" and report verification.

package/skills/hr-better-writing/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "HR: Better Writing"
+  short_description: "UX writing, interface copy and microcopy"

package/skills/hr-change-impact/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: hr-change-impact
+description: "Check what a change can break beyond the lines it edits, and back the claim that it is safe with something that ran. Use when the user asks what a change might break, wants its impact checked before merging, or distrusts a small diff."
+disable-model-invocation: true
+---
+
+# Change impact
+
+The diff shows what changed. This skill asks what else depends on the old
+behavior, and whether the change is safe for a reason someone has seen work.
+Follow project guidance for commands, test runners and domain safeguards.
+
+## Scope the change
+
+Read the whole diff and the code around each hunk. Write one or two sentences
+on what the change does, including behavior a reader of the diff could miss:
+a new default, a reordered side effect, a changed error type, a value that is
+now computed lazily or cached. If you cannot explain the change yet, read the
+code first (see `hr-explain-code`) before judging its impact.
+
+When the reason for old behavior affects the risk, inspect relevant history.
+Use a scoped `git log -p` or `git log -S<symbol>` where it can answer that
+question; a literal symbol search may miss renames or indirect behavior.
+
+## Look past the call sites
+
+List direct callers quickly; a compiler or a symbol search usually covers them,
+and they are rarely where the surprise is. Spend the effort on coupling that a
+symbol search does not see:
+
+- **Stored and serialized shapes.** Field names, enum values, JSON keys,
+  cache keys, database columns, file formats and anything written today and
+  read back after a deploy or by an older version.
+- **Other readers.** Another process, service, job, script or client that
+  consumes the output, the queue message, the log line or the API response.
+  Search for the literal strings, not only the symbol.
+- **Supported surfaces.** Other screens, entry points, clients, providers and
+  connection modes that reach the behavior. Check reverse operations and
+  state transitions too, such as enabling/disabling or connecting/disconnecting,
+  when the feature supports them. Use the project's actual supported cases;
+  do not invent surfaces or expand project-mandated verification to cover
+  unsupported cases. Keep the focused probe below when existing tests do not
+  exercise a load-bearing assumption.
+- **Timing.** Startup order, background workers, scheduled jobs, retries,
+  timeouts and shutdown. A change that is correct on the request path can
+  break a job that runs once a night.
+- **Configuration.** Environment variables, feature flags, defaults that
+  differ between environments, and code paths only one flag value reaches.
+- **Dependencies as pinned.** How the library behaves at the version in the
+  lockfile, including local patches the project applies, not the version in
+  current upstream docs. Check the effective installed source, patch files or
+  changelog when the change relies on a specific behavior.
+
+Each search is a finding. "No other reader of `order_status` found in this
+repository or its deploy config" is worth reporting; say where you looked.
+Never name a caller, consumer or API you have not seen at a real location.
+
+## Find the load-bearing assumption
+
+A change that looks risky usually rests on one or two facts: no
+consumer reads the old field, the flag is off in production, the migration
+runs before the new code. Name those assumptions explicitly. Then put most of
+the remaining effort into confirming or breaking them, rather than adding more
+hypothetical risks to a list.
+
+A risk that depends on an assumption you have already confirmed does not need
+its own entry. A risk nobody can check deserves a sentence on why it cannot be
+checked and who could.
+
+## Back each claim
+
+A claim can rest on your word alone, on a source location that shows it, on
+a failure path you walked step by step, or on real code that ran and gave the
+result. These are not equal, and the reader cannot tell them apart unless you
+say. Next to each important claim, state in a few words what backs it: "the
+only reader is `billing/export.py:88`", "traced: a missing key falls through
+to the default", "ran `test_legacy_payload`, passes".
+
+When feasible within the selected scope, reproduce the behavior in the
+running application for the strongest backing. Get the load-bearing assumption
+at least to something that ran. A careful trace is enough for lesser claims.
+A claim with nothing behind it is a gap; report it as one instead of dressing it up.
+
+Prefer evidence that already exists: run the tests that cover the changed code
+and read what they actually assert. When none exercise the assumption, write
+the smallest probe that does, such as a script that round-trips an old
+serialized record through the new code. Keep probes outside committed source,
+or delete them before reporting, and say in the report that you did.
+
+## Report
+
+Use these parts, in order:
+
+1. **What it does**: the change in plain terms, with the non-obvious behavior.
+2. **What it relies on**: each load-bearing assumption, its support, and
+   whether it held.
+3. **Risks**: for each real one, the location, how likely it is, what it costs
+   if it happens, and how to check it.
+4. **Ruled out**: concerns you examined and dismissed, with where you looked.
+   This keeps a reviewer from redoing the same search.
+5. **Before merging**: the specific check to run, with the command when there
+   is one, or "none needed" with the reason.
+
+Keep the list of risks short. Three real ones with locations beat fifteen
+possibilities. Before sharing publicly, follow the project's data-classification
+policy. Remove credentials, personal data, private project names and URLs,
+and local paths.
+
+## Related skills
+
+- `hr-explain-code` when you need to understand the code before judging a change.
+- `hr-code-review` for standards, style and spec conformance of the same diff.
+- `hr-diagnosing-bugs` once something is actually broken.

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

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

package/skills/hr-code-review/LICENSE

@@ -0,0 +1,21 @@
+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-code-review/NOTICE.md

@@ -0,0 +1,26 @@
+# Source notices
+
+Source: https://github.com/no-human-ai/no_human (compared at revision `9b50bf6`)
+
+The evidence method's test-weakening assessment and refutation of completion
+claims are informed by this source. The method is independently written.
+
+Copyright (c) 2026 Eyal Golan
+
+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.