{"id":"d8b16edc-9f61-4b86-b78c-2b169b4e6a0d","entityType":"agent","slug":"clawhub-athola-nm-imbue-justify","name":"justify","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-imbue-justify","canonicalPath":"/agent/clawhub-athola-nm-imbue-justify","generatedAt":"2026-10-13T07:09:53.396Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T22:04:03.706Z","emptyReason":null},"description":"Audits changes for additive bias and Iron Law compliance Skill: justify Owner: athola Summary: Audits changes for additive bias and Iron Law compliance Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:12:36.278Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:34:13.478Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:50:57.554Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:00:01.221Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:18:46.818Z | user Release v1.9.1","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 987 downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-imbue-justify","sourceUrl":"https://clawhub.ai/athola/nm-imbue-justify","homepage":"https://clawhub.ai/athola/skills/nm-imbue-justify","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-imbue-justify","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-imbue-justify","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Audits changes for additive bias and Iron Law compliance Skill: justify Owner: athola Summary: Audits changes for additive bias and Iron Law compliance Tags: la"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:04:03.706Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:04:03.706Z","emptyReason":null},"stars":null,"forks":null,"downloads":987,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"987 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:04:03.644Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T22:04:03.706Z","lastCrawledAt":"2026-10-11T22:04:03.644Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T22:04:03.645Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:12:36.278Z","changelog":"Release v1.9.19","fileCount":3,"zipByteSize":6778},{"version":"1.9.17","createdAt":"2026-07-30T05:34:13.478Z","changelog":"Release v1.9.17","fileCount":3,"zipByteSize":6828},{"version":"1.9.16","createdAt":"2026-07-14T19:50:57.554Z","changelog":"Release v1.9.16","fileCount":3,"zipByteSize":6949},{"version":"1.9.14","createdAt":"2026-06-30T18:00:01.221Z","changelog":"Release v1.9.14","fileCount":3,"zipByteSize":6803},{"version":"1.9.13","createdAt":"2026-06-27T16:18:46.818Z","changelog":"Release v1.9.13","fileCount":3,"zipByteSize":6817},{"version":"1.9.12","createdAt":"2026-06-19T03:12:54.358Z","changelog":"Release v1.9.12","fileCount":3,"zipByteSize":6826},{"version":"1.0.0","createdAt":"2026-06-18T14:08:05.334Z","changelog":"Initial release of the \"justify\" skill for auditing software changes for additive bias and compliance with the Iron Law. - Audits code changes for additive bias, scoring several signals such as line ratio, new files, test logic changes, new abstractions, and workaround patterns. - Checks for Iron Law compliance by verifying that test logic was only changed if requirements changed. - Provides a step-by-step audit protocol with recommended tooling and scoring methodology. - Guides users through minimal intervention analysis and invariant impact assessment for each change. - Encourages generation of a structured Justification Report before merging changes.","fileCount":3,"zipByteSize":6767}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-imbue-justify","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-13T07:09:53.394Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-imbue-justify/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T22:04:03.706Z","emptyReason":null},"readme":"Skill: justify\n\nOwner: athola\n\nSummary: Audits changes for additive bias and Iron Law compliance\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:12:36.278Z | user\n\nRelease v1.9.19\n\nv1.9.17 | 2026-07-30T05:34:13.478Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:50:57.554Z | user\n\nRelease v1.9.16\n\nv1.9.14 | 2026-06-30T18:00:01.221Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:18:46.818Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:12:54.358Z | user\n\nRelease v1.9.12\n\nv1.0.0 | 2026-06-18T14:08:05.334Z | auto\n\nInitial release of the \"justify\" skill for auditing software changes for additive bias and compliance with the Iron Law.\n\n- Audits code changes for additive bias, scoring several signals such as line ratio, new files, test logic changes, new abstractions, and workaround patterns.\n- Checks for Iron Law compliance by verifying that test logic was only changed if requirements changed.\n- Provides a step-by-step audit protocol with recommended tooling and scoring methodology.\n- Guides users through minimal intervention analysis and invariant impact assessment for each change.\n- Encourages generation of a structured Justification Report before merging changes.\n\nArchive index:\n\nArchive v1.9.19: 3 files, 6778 bytes\n\nFiles: skill-card.md (1870b), SKILL.md (12410b), _meta.json (136b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| Aggregate | Zone | Action |\n|-----------|------|--------|\n| 0.0 - 0.5 | GREEN | Proceed |\n| 0.5 - 1.5 | YELLOW | Justify each signal |\n| 1.5 - 2.5 | RED | Rethink approach |\n| 2.5+ | STOP | Likely wrong approach |\n\n### Step 3: Iron Law Compliance Check\n\nThe Iron Law states: tests drive implementation, not\nthe other way around. Check for violations:\n\n```bash\n# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\"\n```\n\n**Violation patterns (test logic was tampered):**\n\n- Assertion values changed (expected output modified)\n- Test cases removed or commented out\n- `@skip` or `@pytest.mark.skip` added\n- Error expectations weakened (broad exception types)\n- Mock return values changed to match new behavior\n- Test renamed to no longer describe original behavior\n\n**Each violation requires explicit justification:**\n\n> \"I changed this test assertion because the\n> *requirement* changed, not because my implementation\n> couldn't meet the original requirement.\"\n\nIf the requirement didn't change, the test should not\nchange. Fix the implementation instead.\n\n### Step 4: Minimal Intervention Analysis\n\nFor each changed file, answer:\n\n1. **Was this change necessary?**\n Could the goal be achieved without touching this file?\n\n2. **Was this the minimal change?**\n Could fewer lines achieve the same result?\n\n3. **Did this change add or remove complexity?**\n New functions, classes, or control flow = added\n complexity that needs justification.\n\n4. **Is there a subtraction-first alternative?**\n Could removing code fix the problem instead of\n adding code?\n\n### Step 4.5: Invariant Impact Analysis\n\nChanges can be minimal and still catastrophically wrong\nif they silently revise a load-bearing design decision.\nFor each changed file, check whether it touches a design\ninvariant:\n\n**What counts as an invariant:**\n\n- Architectural patterns (module boundaries, layer\n separation, data flow direction)\n- Data structure choices (why a map vs list, why\n normalized vs denormalized)\n- API contracts (public interfaces, protocol formats)\n- Error handling strategies (fail-fast vs recovery)\n- Concurrency models (single-threaded assumption,\n actor model, shared-nothing)\n\n**Detection heuristic:**\n\n```bash\n# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\"\n```\n\n**When an invariant conflict is detected:**\n\nDo NOT silently pick a resolution. Present the three\noptions to the human:\n\n| Option | Description | When Right |\n|--------|-------------|------------|\n| **Preserve** | Don't add the feature; the invariant pays dividends | Invariant simplifies many things; feature is marginal |\n| **Layer** | Add feature inelegantly on top | Feature is needed; invariant is still valuable; imperfection is acceptable |\n| **Revise** | Change the invariant itself | Genuine new learning invalidates the original decision |\n\n**Add to Justification Report:**\n\n```markdown\n### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge\n```\n\n**Compounding risk warning:** Bad invariant decisions\naccumulate. If this branch has multiple invariant\nrevisions, flag the entire branch for architectural\nreview. Each silent invariant change multiplies the\nprobability of an unsalvageable codebase.\n\n### Step 5: Generate Justification Report\n\nOutput a structured report:\n\n```markdown\n## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]\n```\n\n## Decision Weights\n\nWhen evaluating competing approaches, weight\nthese factors:\n\n| Factor | Weight | Rationale |\n|--------|--------|-----------|\n| Fewer lines changed | HIGH | Less risk, easier review |\n| No new files | HIGH | No new maintenance burden |\n| No test logic changes | HIGH | Iron Law compliance |\n| Root cause fix | HIGH | Prevents recurrence |\n| Removes code | BONUS | Reduces maintenance surface |\n| Adds abstraction | PENALTY | Only justified at 3rd use |\n| Adds error handling | NEUTRAL | Only at system boundaries |\n\n**The Subtraction Test**: Before accepting any change,\nask: \"Could I achieve this by *removing* code instead\nof *adding* it?\" If yes, prefer the subtractive approach.\n\n## Integration with Proof of Work\n\nJustify extends proof-of-work with change-level\naccountability:\n\n- **proof-of-work**: \"Did it work?\" (evidence)\n- **justify**: \"Was this the right way?\" (reasoning)\n\nBoth are required before claiming work is complete.\nRun proof-of-work first, then justify.\n\n## Anti-Patterns to Flag\n\n### 1. Test Mutation\nChanging test expectations to match broken code.\n**Fix**: Revert the test change, fix the implementation.\n\n### 2. Shotgun Addition\nAdding code in many files for a single-concern fix.\n**Fix**: Find the single point of change.\n\n### 3. Defensive Overengineering\nAdding try/catch, null checks, or validation for\nscenarios that can't happen in practice.\n**Fix**: Trust internal code. Only validate at boundaries.\n\n### 4. Premature Abstraction\nCreating a helper/utility/base class for one use case.\n**Fix**: Inline the code. Abstract at the 3rd use.\n\n### 5. Compatibility Shim\nAdding backward-compatibility code instead of\nupdating callers.\n**Fix**: Update callers directly. Delete dead paths.\n\n### 6. Silent Invariant Revision\nChanging an architectural pattern, data structure\nchoice, or API contract without acknowledging\nthat a design invariant is being revised.\n**Fix**: Name the invariant. Present the 3 options\n(preserve, layer, revise) to a human. Do not make\nthe judgment call yourself — models default to the\n\"average\" of training data, and wrong invariant\ndecisions compound into unsalvageable codebases.\n\n## Scrutiny Questions (from leyline:additive-bias-defense)\n\nBefore justifying any change, apply these questions.\nIf the answer to questions 4 and 5 is not concrete\nevidence, the change is unjustified.\n\n1. **Priority alignment**: Is this a deviation from the\n current priority?\n2. **Criticality**: Is it critical to implement at this\n juncture?\n3. **Simplicity**: Does a simpler or more elegant\n solution exist?\n4. **Evidence**: What evidence proves this is needed\n (not assumed)?\n5. **Consequence**: What breaks if we do not add this?\n\n## Burden of Proof Inversion\n\nThe default stance is: **this addition should not\nexist.** The change must prove its necessity, not the\nreviewer must prove it unnecessary.\n\nWhen generating the Justification Report (Step 5), add\na `Burden of Proof` section:\n\n| Change | Scrutiny Q4 Answer | Scrutiny Q5 Answer | Verdict |\n|--------|--------------------|--------------------|---------|\n| file.py | [evidence] | [consequence] | justified/needs_evidence/unjustified |\n\nChanges with `unjustified` verdict MUST be removed or\nreworked before the report passes.\n\n## The Wise Counsel\n\n> Is what you are doing a deviation of your priority?\n> Is it critical to implement at this juncture?\n> Rely less on AI and initial lines of thinking.\n> Challenge yourself to be better, to think of a more\n> elegant implementation or a simpler solution.\n\n## Related Skills\n\n- `imbue:karpathy-principles` - \"Surgical Changes\" and\n \"Goal-Driven Execution\" principles invoke this audit\n from a higher-level synthesis\n- `leyline:additive-bias-defense` - the contract this\n audit enforces in detail\n- `imbue:proof-of-work` - the validation layer this\n audit complements (proof-of-work asks \"did it work?\",\n justify asks \"did it need to exist?\")\n- See `docs/quality-gates.md#skill-level-quality-gate-composition`\n for the full gate-skill federation graph\n\nFile v1.9.19:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.9.19\",\n \"publishedAt\": 1787749956278\n}\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nAudits changes for additive bias and Iron Law compliance.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill after implementation work or before commits and pull requests to review diffs for additive-bias patterns, Iron Law test-discipline issues, and unnecessary complexity.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad triggers may activate the skill during ordinary code-review conversations.\n\nMitigation: Narrow trigger phrases or invoke the skill explicitly in workflows where accidental activation would distract from review.\n\nRisk: The skill reviews git diffs and may produce incorrect or overly strict guidance about proposed code changes.\n\nMitigation: Treat its report as review guidance and have a human reviewer confirm conclusions before merging.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-imbue-justify)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, guidance]\n\n**Output Format:** [Markdown report with inline shell commands and review tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces a structured justification report with additive-bias scoring, Iron Law checks, file-by-file rationale, risk assessment, and recommendations.]\n\n## Skill Version(s):\n\n1.9.19 (source: release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 3 files, 6828 bytes\n\nFiles: skill-card.md (2109b), SKILL.md (12410b), _meta.json (136b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| Aggregate | Zone | Action |\n|-----------|------|--------|\n| 0.0 - 0.5 | GREEN | Proceed |\n| 0.5 - 1.5 | YELLOW | Justify each signal |\n| 1.5 - 2.5 | RED | Rethink approach |\n| 2.5+ | STOP | Likely wrong approach |\n\n### Step 3: Iron Law Compliance Check\n\nThe Iron Law states: tests drive implementation, not\nthe other way around. Check for violations:\n\n```bash\n# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\"\n```\n\n**Violation patterns (test logic was tampered):**\n\n- Assertion values changed (expected output modified)\n- Test cases removed or commented out\n- `@skip` or `@pytest.mark.skip` added\n- Error expectations weakened (broad exception types)\n- Mock return values changed to match new behavior\n- Test renamed to no longer describe original behavior\n\n**Each violation requires explicit justification:**\n\n> \"I changed this test assertion because the\n> *requirement* changed, not because my implementation\n> couldn't meet the original requirement.\"\n\nIf the requirement didn't change, the test should not\nchange. Fix the implementation instead.\n\n### Step 4: Minimal Intervention Analysis\n\nFor each changed file, answer:\n\n1. **Was this change necessary?**\n Could the goal be achieved without touching this file?\n\n2. **Was this the minimal change?**\n Could fewer lines achieve the same result?\n\n3. **Did this change add or remove complexity?**\n New functions, classes, or control flow = added\n complexity that needs justification.\n\n4. **Is there a subtraction-first alternative?**\n Could removing code fix the problem instead of\n adding code?\n\n### Step 4.5: Invariant Impact Analysis\n\nChanges can be minimal and still catastrophically wrong\nif they silently revise a load-bearing design decision.\nFor each changed file, check whether it touches a design\ninvariant:\n\n**What counts as an invariant:**\n\n- Architectural patterns (module boundaries, layer\n separation, data flow direction)\n- Data structure choices (why a map vs list, why\n normalized vs denormalized)\n- API contracts (public interfaces, protocol formats)\n- Error handling strategies (fail-fast vs recovery)\n- Concurrency models (single-threaded assumption,\n actor model, shared-nothing)\n\n**Detection heuristic:**\n\n```bash\n# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\"\n```\n\n**When an invariant conflict is detected:**\n\nDo NOT silently pick a resolution. Present the three\noptions to the human:\n\n| Option | Description | When Right |\n|--------|-------------|------------|\n| **Preserve** | Don't add the feature; the invariant pays dividends | Invariant simplifies many things; feature is marginal |\n| **Layer** | Add feature inelegantly on top | Feature is needed; invariant is still valuable; imperfection is acceptable |\n| **Revise** | Change the invariant itself | Genuine new learning invalidates the original decision |\n\n**Add to Justification Report:**\n\n```markdown\n### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge\n```\n\n**Compounding risk warning:** Bad invariant decisions\naccumulate. If this branch has multiple invariant\nrevisions, flag the entire branch for architectural\nreview. Each silent invariant change multiplies the\nprobability of an unsalvageable codebase.\n\n### Step 5: Generate Justification Report\n\nOutput a structured report:\n\n```markdown\n## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]\n```\n\n## Decision Weights\n\nWhen evaluating competing approaches, weight\nthese factors:\n\n| Factor | Weight | Rationale |\n|--------|--------|-----------|\n| Fewer lines changed | HIGH | Less risk, easier review |\n| No new files | HIGH | No new maintenance burden |\n| No test logic changes | HIGH | Iron Law compliance |\n| Root cause fix | HIGH | Prevents recurrence |\n| Removes code | BONUS | Reduces maintenance surface |\n| Adds abstraction | PENALTY | Only justified at 3rd use |\n| Adds error handling | NEUTRAL | Only at system boundaries |\n\n**The Subtraction Test**: Before accepting any change,\nask: \"Could I achieve this by *removing* code instead\nof *adding* it?\" If yes, prefer the subtractive approach.\n\n## Integration with Proof of Work\n\nJustify extends proof-of-work with change-level\naccountability:\n\n- **proof-of-work**: \"Did it work?\" (evidence)\n- **justify**: \"Was this the right way?\" (reasoning)\n\nBoth are required before claiming work is complete.\nRun proof-of-work first, then justify.\n\n## Anti-Patterns to Flag\n\n### 1. Test Mutation\nChanging test expectations to match broken code.\n**Fix**: Revert the test change, fix the implementation.\n\n### 2. Shotgun Addition\nAdding code in many files for a single-concern fix.\n**Fix**: Find the single point of change.\n\n### 3. Defensive Overengineering\nAdding try/catch, null checks, or validation for\nscenarios that can't happen in practice.\n**Fix**: Trust internal code. Only validate at boundaries.\n\n### 4. Premature Abstraction\nCreating a helper/utility/base class for one use case.\n**Fix**: Inline the code. Abstract at the 3rd use.\n\n### 5. Compatibility Shim\nAdding backward-compatibility code instead of\nupdating callers.\n**Fix**: Update callers directly. Delete dead paths.\n\n### 6. Silent Invariant Revision\nChanging an architectural pattern, data structure\nchoice, or API contract without acknowledging\nthat a design invariant is being revised.\n**Fix**: Name the invariant. Present the 3 options\n(preserve, layer, revise) to a human. Do not make\nthe judgment call yourself — models default to the\n\"average\" of training data, and wrong invariant\ndecisions compound into unsalvageable codebases.\n\n## Scrutiny Questions (from leyline:additive-bias-defense)\n\nBefore justifying any change, apply these questions.\nIf the answer to questions 4 and 5 is not concrete\nevidence, the change is unjustified.\n\n1. **Priority alignment**: Is this a deviation from the\n current priority?\n2. **Criticality**: Is it critical to implement at this\n juncture?\n3. **Simplicity**: Does a simpler or more elegant\n solution exist?\n4. **Evidence**: What evidence proves this is needed\n (not assumed)?\n5. **Consequence**: What breaks if we do not add this?\n\n## Burden of Proof Inversion\n\nThe default stance is: **this addition should not\nexist.** The change must prove its necessity, not the\nreviewer must prove it unnecessary.\n\nWhen generating the Justification Report (Step 5), add\na `Burden of Proof` section:\n\n| Change | Scrutiny Q4 Answer | Scrutiny Q5 Answer | Verdict |\n|--------|--------------------|--------------------|---------|\n| file.py | [evidence] | [consequence] | justified/needs_evidence/unjustified |\n\nChanges with `unjustified` verdict MUST be removed or\nreworked before the report passes.\n\n## The Wise Counsel\n\n> Is what you are doing a deviation of your priority?\n> Is it critical to implement at this juncture?\n> Rely less on AI and initial lines of thinking.\n> Challenge yourself to be better, to think of a more\n> elegant implementation or a simpler solution.\n\n## Related Skills\n\n- `imbue:karpathy-principles` - \"Surgical Changes\" and\n \"Goal-Driven Execution\" principles invoke this audit\n from a higher-level synthesis\n- `leyline:additive-bias-defense` - the contract this\n audit enforces in detail\n- `imbue:proof-of-work` - the validation layer this\n audit complements (proof-of-work asks \"did it work?\",\n justify asks \"did it need to exist?\")\n- See `docs/quality-gates.md#skill-level-quality-gate-composition`\n for the full gate-skill federation graph\n\nFile v1.9.17:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.9.17\",\n \"publishedAt\": 1785389653478\n}\n\nFile v1.9.17:skill-card.md\n\n## Description:
\nAudits changes for additive bias and Iron Law compliance
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and engineers use this skill after implementation or before commits and pull requests to audit code changes for additive bias, test mutation, unnecessary abstractions, and invariant-impact risks.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may activate for generic code-review requests and spend extra effort producing justification reports before work is considered complete.
\nMitigation: Use it intentionally for post-change review, pre-commit review, or pull-request readiness checks where that review discipline is desired.
\nRisk: The generated review guidance could be incorrect or misleading if accepted without review.
\nMitigation: Review and scan the skill before deployment, and have a human reviewer evaluate recommendations before merging changes.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-imbue-justify)
\n- [Clawdis homepage](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)
\n\n\n## Skill Output:
\n**Output Type(s):** [Text, Markdown, Shell commands, Guidance]
\n**Output Format:** [Markdown with inline bash code blocks and review tables]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a structured justification report covering additive bias, Iron Law compliance, invariant impact, risk assessment, and recommendations.]
\n\n## Skill Version(s):
\n1.9.17 (source: server release metadata; artifact frontmatter says 1.9.8)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.16: 3 files, 6949 bytes\n\nFiles: skill-card.md (2455b), SKILL.md (12410b), _meta.json (136b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| Aggregate | Zone | Action |\n|-----------|------|--------|\n| 0.0 - 0.5 | GREEN | Proceed |\n| 0.5 - 1.5 | YELLOW | Justify each signal |\n| 1.5 - 2.5 | RED | Rethink approach |\n| 2.5+ | STOP | Likely wrong approach |\n\n### Step 3: Iron Law Compliance Check\n\nThe Iron Law states: tests drive implementation, not\nthe other way around. Check for violations:\n\n```bash\n# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\"\n```\n\n**Violation patterns (test logic was tampered):**\n\n- Assertion values changed (expected output modified)\n- Test cases removed or commented out\n- `@skip` or `@pytest.mark.skip` added\n- Error expectations weakened (broad exception types)\n- Mock return values changed to match new behavior\n- Test renamed to no longer describe original behavior\n\n**Each violation requires explicit justification:**\n\n> \"I changed this test assertion because the\n> *requirement* changed, not because my implementation\n> couldn't meet the original requirement.\"\n\nIf the requirement didn't change, the test should not\nchange. Fix the implementation instead.\n\n### Step 4: Minimal Intervention Analysis\n\nFor each changed file, answer:\n\n1. **Was this change necessary?**\n Could the goal be achieved without touching this file?\n\n2. **Was this the minimal change?**\n Could fewer lines achieve the same result?\n\n3. **Did this change add or remove complexity?**\n New functions, classes, or control flow = added\n complexity that needs justification.\n\n4. **Is there a subtraction-first alternative?**\n Could removing code fix the problem instead of\n adding code?\n\n### Step 4.5: Invariant Impact Analysis\n\nChanges can be minimal and still catastrophically wrong\nif they silently revise a load-bearing design decision.\nFor each changed file, check whether it touches a design\ninvariant:\n\n**What counts as an invariant:**\n\n- Architectural patterns (module boundaries, layer\n separation, data flow direction)\n- Data structure choices (why a map vs list, why\n normalized vs denormalized)\n- API contracts (public interfaces, protocol formats)\n- Error handling strategies (fail-fast vs recovery)\n- Concurrency models (single-threaded assumption,\n actor model, shared-nothing)\n\n**Detection heuristic:**\n\n```bash\n# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\"\n```\n\n**When an invariant conflict is detected:**\n\nDo NOT silently pick a resolution. Present the three\noptions to the human:\n\n| Option | Description | When Right |\n|--------|-------------|------------|\n| **Preserve** | Don't add the feature; the invariant pays dividends | Invariant simplifies many things; feature is marginal |\n| **Layer** | Add feature inelegantly on top | Feature is needed; invariant is still valuable; imperfection is acceptable |\n| **Revise** | Change the invariant itself | Genuine new learning invalidates the original decision |\n\n**Add to Justification Report:**\n\n```markdown\n### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge\n```\n\n**Compounding risk warning:** Bad invariant decisions\naccumulate. If this branch has multiple invariant\nrevisions, flag the entire branch for architectural\nreview. Each silent invariant change multiplies the\nprobability of an unsalvageable codebase.\n\n### Step 5: Generate Justification Report\n\nOutput a structured report:\n\n```markdown\n## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]\n```\n\n## Decision Weights\n\nWhen evaluating competing approaches, weight\nthese factors:\n\n| Factor | Weight | Rationale |\n|--------|--------|-----------|\n| Fewer lines changed | HIGH | Less risk, easier review |\n| No new files | HIGH | No new maintenance burden |\n| No test logic changes | HIGH | Iron Law compliance |\n| Root cause fix | HIGH | Prevents recurrence |\n| Removes code | BONUS | Reduces maintenance surface |\n| Adds abstraction | PENALTY | Only justified at 3rd use |\n| Adds error handling | NEUTRAL | Only at system boundaries |\n\n**The Subtraction Test**: Before accepting any change,\nask: \"Could I achieve this by *removing* code instead\nof *adding* it?\" If yes, prefer the subtractive approach.\n\n## Integration with Proof of Work\n\nJustify extends proof-of-work with change-level\naccountability:\n\n- **proof-of-work**: \"Did it work?\" (evidence)\n- **justify**: \"Was this the right way?\" (reasoning)\n\nBoth are required before claiming work is complete.\nRun proof-of-work first, then justify.\n\n## Anti-Patterns to Flag\n\n### 1. Test Mutation\nChanging test expectations to match broken code.\n**Fix**: Revert the test change, fix the implementation.\n\n### 2. Shotgun Addition\nAdding code in many files for a single-concern fix.\n**Fix**: Find the single point of change.\n\n### 3. Defensive Overengineering\nAdding try/catch, null checks, or validation for\nscenarios that can't happen in practice.\n**Fix**: Trust internal code. Only validate at boundaries.\n\n### 4. Premature Abstraction\nCreating a helper/utility/base class for one use case.\n**Fix**: Inline the code. Abstract at the 3rd use.\n\n### 5. Compatibility Shim\nAdding backward-compatibility code instead of\nupdating callers.\n**Fix**: Update callers directly. Delete dead paths.\n\n### 6. Silent Invariant Revision\nChanging an architectural pattern, data structure\nchoice, or API contract without acknowledging\nthat a design invariant is being revised.\n**Fix**: Name the invariant. Present the 3 options\n(preserve, layer, revise) to a human. Do not make\nthe judgment call yourself — models default to the\n\"average\" of training data, and wrong invariant\ndecisions compound into unsalvageable codebases.\n\n## Scrutiny Questions (from leyline:additive-bias-defense)\n\nBefore justifying any change, apply these questions.\nIf the answer to questions 4 and 5 is not concrete\nevidence, the change is unjustified.\n\n1. **Priority alignment**: Is this a deviation from the\n current priority?\n2. **Criticality**: Is it critical to implement at this\n juncture?\n3. **Simplicity**: Does a simpler or more elegant\n solution exist?\n4. **Evidence**: What evidence proves this is needed\n (not assumed)?\n5. **Consequence**: What breaks if we do not add this?\n\n## Burden of Proof Inversion\n\nThe default stance is: **this addition should not\nexist.** The change must prove its necessity, not the\nreviewer must prove it unnecessary.\n\nWhen generating the Justification Report (Step 5), add\na `Burden of Proof` section:\n\n| Change | Scrutiny Q4 Answer | Scrutiny Q5 Answer | Verdict |\n|--------|--------------------|--------------------|---------|\n| file.py | [evidence] | [consequence] | justified/needs_evidence/unjustified |\n\nChanges with `unjustified` verdict MUST be removed or\nreworked before the report passes.\n\n## The Wise Counsel\n\n> Is what you are doing a deviation of your priority?\n> Is it critical to implement at this juncture?\n> Rely less on AI and initial lines of thinking.\n> Challenge yourself to be better, to think of a more\n> elegant implementation or a simpler solution.\n\n## Related Skills\n\n- `imbue:karpathy-principles` - \"Surgical Changes\" and\n \"Goal-Driven Execution\" principles invoke this audit\n from a higher-level synthesis\n- `leyline:additive-bias-defense` - the contract this\n audit enforces in detail\n- `imbue:proof-of-work` - the validation layer this\n audit complements (proof-of-work asks \"did it work?\",\n justify asks \"did it need to exist?\")\n- See `docs/quality-gates.md#skill-level-quality-gate-composition`\n for the full gate-skill federation graph\n\nFile v1.9.16:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.9.16\",\n \"publishedAt\": 1784058657554\n}\n\nFile v1.9.16:skill-card.md\n\n## Description:
\nAudits changes for additive bias and Iron Law compliance.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and code reviewers use this skill after implementation work and before commits or pull requests to audit local changes for additive bias, test expectation drift, unnecessary abstractions, and unreviewed invariant changes.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may activate on general code-review language even when a full justification audit is not intended.
\nMitigation: Use it deliberately for post-implementation or pre-merge review, and treat incidental activations as advisory unless the local diff is being audited.
\nRisk: Review reports can introduce incorrect or misleading guidance if the agent misreads the local diff or project requirements.
\nMitigation: Review the report against the actual git diff, test changes, and stated requirements before changing implementation or merge decisions.
\nRisk: The artifact covers the skill content only; related Claude Code plugin agents, hooks, or commands are not included in this release artifact.
\nMitigation: Review and scan any separately installed plugin components before relying on them in the same workflow.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-imbue-justify)
\n- [Publisher profile](https://clawhub.ai/user/athola)
\n- [OpenClaw homepage metadata](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)
\n\n\n## Skill Output:
\n**Output Type(s):** [markdown, shell commands, guidance]
\n**Output Format:** [Markdown report with tables and inline shell command examples.]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces an additive-bias score, Iron Law compliance check, change-by-change justification, risk assessment, and recommendations.]
\n\n## Skill Version(s):
\n1.9.16 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.14: 3 files, 6803 bytes\n\nFiles: skill-card.md (2031b), SKILL.md (12410b), _meta.json (136b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| Aggregate | Zone | Action |\n|-----------|------|--------|\n| 0.0 - 0.5 | GREEN | Proceed |\n| 0.5 - 1.5 | YELLOW | Justify each signal |\n| 1.5 - 2.5 | RED | Rethink approach |\n| 2.5+ | STOP | Likely wrong approach |\n\n### Step 3: Iron Law Compliance Check\n\nThe Iron Law states: tests drive implementation, not\nthe other way around. Check for violations:\n\n```bash\n# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\"\n```\n\n**Violation patterns (test logic was tampered):**\n\n- Assertion values changed (expected output modified)\n- Test cases removed or commented out\n- `@skip` or `@pytest.mark.skip` added\n- Error expectations weakened (broad exception types)\n- Mock return values changed to match new behavior\n- Test renamed to no longer describe original behavior\n\n**Each violation requires explicit justification:**\n\n> \"I changed this test assertion because the\n> *requirement* changed, not because my implementation\n> couldn't meet the original requirement.\"\n\nIf the requirement didn't change, the test should not\nchange. Fix the implementation instead.\n\n### Step 4: Minimal Intervention Analysis\n\nFor each changed file, answer:\n\n1. **Was this change necessary?**\n Could the goal be achieved without touching this file?\n\n2. **Was this the minimal change?**\n Could fewer lines achieve the same result?\n\n3. **Did this change add or remove complexity?**\n New functions, classes, or control flow = added\n complexity that needs justification.\n\n4. **Is there a subtraction-first alternative?**\n Could removing code fix the problem instead of\n adding code?\n\n### Step 4.5: Invariant Impact Analysis\n\nChanges can be minimal and still catastrophically wrong\nif they silently revise a load-bearing design decision.\nFor each changed file, check whether it touches a design\ninvariant:\n\n**What counts as an invariant:**\n\n- Architectural patterns (module boundaries, layer\n separation, data flow direction)\n- Data structure choices (why a map vs list, why\n normalized vs denormalized)\n- API contracts (public interfaces, protocol formats)\n- Error handling strategies (fail-fast vs recovery)\n- Concurrency models (single-threaded assumption,\n actor model, shared-nothing)\n\n**Detection heuristic:**\n\n```bash\n# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\"\n```\n\n**When an invariant conflict is detected:**\n\nDo NOT silently pick a resolution. Present the three\noptions to the human:\n\n| Option | Description | When Right |\n|--------|-------------|------------|\n| **Preserve** | Don't add the feature; the invariant pays dividends | Invariant simplifies many things; feature is marginal |\n| **Layer** | Add feature inelegantly on top | Feature is needed; invariant is still valuable; imperfection is acceptable |\n| **Revise** | Change the invariant itself | Genuine new learning invalidates the original decision |\n\n**Add to Justification Report:**\n\n```markdown\n### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge\n```\n\n**Compounding risk warning:** Bad invariant decisions\naccumulate. If this branch has multiple invariant\nrevisions, flag the entire branch for architectural\nreview. Each silent invariant change multiplies the\nprobability of an unsalvageable codebase.\n\n### Step 5: Generate Justification Report\n\nOutput a structured report:\n\n```markdown\n## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]\n```\n\n## Decision Weights\n\nWhen evaluating competing approaches, weight\nthese factors:\n\n| Factor | Weight | Rationale |\n|--------|--------|-----------|\n| Fewer lines changed | HIGH | Less risk, easier review |\n| No new files | HIGH | No new maintenance burden |\n| No test logic changes | HIGH | Iron Law compliance |\n| Root cause fix | HIGH | Prevents recurrence |\n| Removes code | BONUS | Reduces maintenance surface |\n| Adds abstraction | PENALTY | Only justified at 3rd use |\n| Adds error handling | NEUTRAL | Only at system boundaries |\n\n**The Subtraction Test**: Before accepting any change,\nask: \"Could I achieve this by *removing* code instead\nof *adding* it?\" If yes, prefer the subtractive approach.\n\n## Integration with Proof of Work\n\nJustify extends proof-of-work with change-level\naccountability:\n\n- **proof-of-work**: \"Did it work?\" (evidence)\n- **justify**: \"Was this the right way?\" (reasoning)\n\nBoth are required before claiming work is complete.\nRun proof-of-work first, then justify.\n\n## Anti-Patterns to Flag\n\n### 1. Test Mutation\nChanging test expectations to match broken code.\n**Fix**: Revert the test change, fix the implementation.\n\n### 2. Shotgun Addition\nAdding code in many files for a single-concern fix.\n**Fix**: Find the single point of change.\n\n### 3. Defensive Overengineering\nAdding try/catch, null checks, or validation for\nscenarios that can't happen in practice.\n**Fix**: Trust internal code. Only validate at boundaries.\n\n### 4. Premature Abstraction\nCreating a helper/utility/base class for one use case.\n**Fix**: Inline the code. Abstract at the 3rd use.\n\n### 5. Compatibility Shim\nAdding backward-compatibility code instead of\nupdating callers.\n**Fix**: Update callers directly. Delete dead paths.\n\n### 6. Silent Invariant Revision\nChanging an architectural pattern, data structure\nchoice, or API contract without acknowledging\nthat a design invariant is being revised.\n**Fix**: Name the invariant. Present the 3 options\n(preserve, layer, revise) to a human. Do not make\nthe judgment call yourself — models default to the\n\"average\" of training data, and wrong invariant\ndecisions compound into unsalvageable codebases.\n\n## Scrutiny Questions (from leyline:additive-bias-defense)\n\nBefore justifying any change, apply these questions.\nIf the answer to questions 4 and 5 is not concrete\nevidence, the change is unjustified.\n\n1. **Priority alignment**: Is this a deviation from the\n current priority?\n2. **Criticality**: Is it critical to implement at this\n juncture?\n3. **Simplicity**: Does a simpler or more elegant\n solution exist?\n4. **Evidence**: What evidence proves this is needed\n (not assumed)?\n5. **Consequence**: What breaks if we do not add this?\n\n## Burden of Proof Inversion\n\nThe default stance is: **this addition should not\nexist.** The change must prove its necessity, not the\nreviewer must prove it unnecessary.\n\nWhen generating the Justification Report (Step 5), add\na `Burden of Proof` section:\n\n| Change | Scrutiny Q4 Answer | Scrutiny Q5 Answer | Verdict |\n|--------|--------------------|--------------------|---------|\n| file.py | [evidence] | [consequence] | justified/needs_evidence/unjustified |\n\nChanges with `unjustified` verdict MUST be removed or\nreworked before the report passes.\n\n## The Wise Counsel\n\n> Is what you are doing a deviation of your priority?\n> Is it critical to implement at this juncture?\n> Rely less on AI and initial lines of thinking.\n> Challenge yourself to be better, to think of a more\n> elegant implementation or a simpler solution.\n\n## Related Skills\n\n- `imbue:karpathy-principles` - \"Surgical Changes\" and\n \"Goal-Driven Execution\" principles invoke this audit\n from a higher-level synthesis\n- `leyline:additive-bias-defense` - the contract this\n audit enforces in detail\n- `imbue:proof-of-work` - the validation layer this\n audit complements (proof-of-work asks \"did it work?\",\n justify asks \"did it need to exist?\")\n- See `docs/quality-gates.md#skill-level-quality-gate-composition`\n for the full gate-skill federation graph\n\nFile v1.9.14:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.9.14\",\n \"publishedAt\": 1782842401221\n}\n\nFile v1.9.14:skill-card.md\n\n## Description:
\nAudits changes for additive bias and Iron Law compliance.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and engineering reviewers use this skill after implementation work and before merges to audit diffs for additive bias, test mutation, invariant changes, and insufficient justification.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Repository diffs and selected evidence files may be sent to the configured reviewer provider CLI.
\nMitigation: Use this skill only when that disclosure is acceptable; choose --no-web-search or narrower engine and tool settings when external lookup is not appropriate.
\nRisk: The generated audit can contain incorrect or overly strict review findings.
\nMitigation: Treat findings as reviewer guidance and manually confirm recommendations before applying code or test changes.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-imbue-justify)
\n- [OpenClaw metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, shell commands, guidance]
\n**Output Format:** [Markdown report with inline shell command examples]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a structured justification report with additive bias scoring, Iron Law review, change-by-change justification, risk assessment, and recommendations.]
\n\n## Skill Version(s):
\n1.9.14 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.13: 3 files, 6817 bytes\n\nFiles: skill-card.md (2130b), SKILL.md (12410b), _meta.json (136b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| Aggregate | Zone | Action |\n|-----------|------|--------|\n| 0.0 - 0.5 | GREEN | Proceed |\n| 0.5 - 1.5 | YELLOW | Justify each signal |\n| 1.5 - 2.5 | RED | Rethink approach |\n| 2.5+ | STOP | Likely wrong approach |\n\n### Step 3: Iron Law Compliance Check\n\nThe Iron Law states: tests drive implementation, not\nthe other way around. Check for violations:\n\n```bash\n# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\"\n```\n\n**Violation patterns (test logic was tampered):**\n\n- Assertion values changed (expected output modified)\n- Test cases removed or commented out\n- `@skip` or `@pytest.mark.skip` added\n- Error expectations weakened (broad exception types)\n- Mock return values changed to match new behavior\n- Test renamed to no longer describe original behavior\n\n**Each violation requires explicit justification:**\n\n> \"I changed this test assertion because the\n> *requirement* changed, not because my implementation\n> couldn't meet the original requirement.\"\n\nIf the requirement didn't change, the test should not\nchange. Fix the implementation instead.\n\n### Step 4: Minimal Intervention Analysis\n\nFor each changed file, answer:\n\n1. **Was this change necessary?**\n Could the goal be achieved without touching this file?\n\n2. **Was this the minimal change?**\n Could fewer lines achieve the same result?\n\n3. **Did this change add or remove complexity?**\n New functions, classes, or control flow = added\n complexity that needs justification.\n\n4. **Is there a subtraction-first alternative?**\n Could removing code fix the problem instead of\n adding code?\n\n### Step 4.5: Invariant Impact Analysis\n\nChanges can be minimal and still catastrophically wrong\nif they silently revise a load-bearing design decision.\nFor each changed file, check whether it touches a design\ninvariant:\n\n**What counts as an invariant:**\n\n- Architectural patterns (module boundaries, layer\n separation, data flow direction)\n- Data structure choices (why a map vs list, why\n normalized vs denormalized)\n- API contracts (public interfaces, protocol formats)\n- Error handling strategies (fail-fast vs recovery)\n- Concurrency models (single-threaded assumption,\n actor model, shared-nothing)\n\n**Detection heuristic:**\n\n```bash\n# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\"\n```\n\n**When an invariant conflict is detected:**\n\nDo NOT silently pick a resolution. Present the three\noptions to the human:\n\n| Option | Description | When Right |\n|--------|-------------|------------|\n| **Preserve** | Don't add the feature; the invariant pays dividends | Invariant simplifies many things; feature is marginal |\n| **Layer** | Add feature inelegantly on top | Feature is needed; invariant is still valuable; imperfection is acceptable |\n| **Revise** | Change the invariant itself | Genuine new learning invalidates the original decision |\n\n**Add to Justification Report:**\n\n```markdown\n### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge\n```\n\n**Compounding risk warning:** Bad invariant decisions\naccumulate. If this branch has multiple invariant\nrevisions, flag the entire branch for architectural\nreview. Each silent invariant change multiplies the\nprobability of an unsalvageable codebase.\n\n### Step 5: Generate Justification Report\n\nOutput a structured report:\n\n```markdown\n## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]\n```\n\n## Decision Weights\n\nWhen evaluating competing approaches, weight\nthese factors:\n\n| Factor | Weight | Rationale |\n|--------|--------|-----------|\n| Fewer lines changed | HIGH | Less risk, easier review |\n| No new files | HIGH | No new maintenance burden |\n| No test logic changes | HIGH | Iron Law compliance |\n| Root cause fix | HIGH | Prevents recurrence |\n| Removes code | BONUS | Reduces maintenance surface |\n| Adds abstraction | PENALTY | Only justified at 3rd use |\n| Adds error handling | NEUTRAL | Only at system boundaries |\n\n**The Subtraction Test**: Before accepting any change,\nask: \"Could I achieve this by *removing* code instead\nof *adding* it?\" If yes, prefer the subtractive approach.\n\n## Integration with Proof of Work\n\nJustify extends proof-of-work with change-level\naccountability:\n\n- **proof-of-work**: \"Did it work?\" (evidence)\n- **justify**: \"Was this the right way?\" (reasoning)\n\nBoth are required before claiming work is complete.\nRun proof-of-work first, then justify.\n\n## Anti-Patterns to Flag\n\n### 1. Test Mutation\nChanging test expectations to match broken code.\n**Fix**: Revert the test change, fix the implementation.\n\n### 2. Shotgun Addition\nAdding code in many files for a single-concern fix.\n**Fix**: Find the single point of change.\n\n### 3. Defensive Overengineering\nAdding try/catch, null checks, or validation for\nscenarios that can't happen in practice.\n**Fix**: Trust internal code. Only validate at boundaries.\n\n### 4. Premature Abstraction\nCreating a helper/utility/base class for one use case.\n**Fix**: Inline the code. Abstract at the 3rd use.\n\n### 5. Compatibility Shim\nAdding backward-compatibility code instead of\nupdating callers.\n**Fix**: Update callers directly. Delete dead paths.\n\n### 6. Silent Invariant Revision\nChanging an architectural pattern, data structure\nchoice, or API contract without acknowledging\nthat a design invariant is being revised.\n**Fix**: Name the invariant. Present the 3 options\n(preserve, layer, revise) to a human. Do not make\nthe judgment call yourself — models default to the\n\"average\" of training data, and wrong invariant\ndecisions compound into unsalvageable codebases.\n\n## Scrutiny Questions (from leyline:additive-bias-defense)\n\nBefore justifying any change, apply these questions.\nIf the answer to questions 4 and 5 is not concrete\nevidence, the change is unjustified.\n\n1. **Priority alignment**: Is this a deviation from the\n current priority?\n2. **Criticality**: Is it critical to implement at this\n juncture?\n3. **Simplicity**: Does a simpler or more elegant\n solution exist?\n4. **Evidence**: What evidence proves this is needed\n (not assumed)?\n5. **Consequence**: What breaks if we do not add this?\n\n## Burden of Proof Inversion\n\nThe default stance is: **this addition should not\nexist.** The change must prove its necessity, not the\nreviewer must prove it unnecessary.\n\nWhen generating the Justification Report (Step 5), add\na `Burden of Proof` section:\n\n| Change | Scrutiny Q4 Answer | Scrutiny Q5 Answer | Verdict |\n|--------|--------------------|--------------------|---------|\n| file.py | [evidence] | [consequence] | justified/needs_evidence/unjustified |\n\nChanges with `unjustified` verdict MUST be removed or\nreworked before the report passes.\n\n## The Wise Counsel\n\n> Is what you are doing a deviation of your priority?\n> Is it critical to implement at this juncture?\n> Rely less on AI and initial lines of thinking.\n> Challenge yourself to be better, to think of a more\n> elegant implementation or a simpler solution.\n\n## Related Skills\n\n- `imbue:karpathy-principles` - \"Surgical Changes\" and\n \"Goal-Driven Execution\" principles invoke this audit\n from a higher-level synthesis\n- `leyline:additive-bias-defense` - the contract this\n audit enforces in detail\n- `imbue:proof-of-work` - the validation layer this\n audit complements (proof-of-work asks \"did it work?\",\n justify asks \"did it need to exist?\")\n- See `docs/quality-gates.md#skill-level-quality-gate-composition`\n for the full gate-skill federation graph\n\nFile v1.9.13:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.9.13\",\n \"publishedAt\": 1782577126818\n}\n\nFile v1.9.13:skill-card.md\n\n## Description:
\nAudits changes for additive bias and Iron Law compliance.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and engineers use this skill after implementation work or before merging changes to audit diffs for additive bias, test mutation, unnecessary abstractions, and invariant changes.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Generic review-related prompts may activate the strict justification checklist when a narrower audit was intended.
\nMitigation: Use explicit triggers or narrower activation rules when installing the skill in environments that only need this audit on direct request.
\nRisk: The skill proposes review judgments about code changes and may surface incorrect or overly strict recommendations.
\nMitigation: Have a human reviewer confirm the justification report and scan proposed changes before merging or deployment.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-imbue-justify)
\n- [ClawHub publisher profile](https://clawhub.ai/user/athola)
\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)
\n\n\n## Skill Output:
\n**Output Type(s):** [markdown, shell commands, guidance]
\n**Output Format:** [Markdown report with inline shell commands and review tables]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a structured justification report covering additive-bias score, Iron Law compliance, change-by-change justification, risk assessment, and recommendations.]
\n\n## Skill Version(s):
\n1.9.13 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.12: 3 files, 6826 bytes\n\nFiles: skill-card.md (2094b), SKILL.md (12410b), _meta.json (136b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| Aggregate | Zone | Action |\n|-----------|------|--------|\n| 0.0 - 0.5 | GREEN | Proceed |\n| 0.5 - 1.5 | YELLOW | Justify each signal |\n| 1.5 - 2.5 | RED | Rethink approach |\n| 2.5+ | STOP | Likely wrong approach |\n\n### Step 3: Iron Law Compliance Check\n\nThe Iron Law states: tests drive implementation, not\nthe other way around. Check for violations:\n\n```bash\n# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\"\n```\n\n**Violation patterns (test logic was tampered):**\n\n- Assertion values changed (expected output modified)\n- Test cases removed or commented out\n- `@skip` or `@pytest.mark.skip` added\n- Error expectations weakened (broad exception types)\n- Mock return values changed to match new behavior\n- Test renamed to no longer describe original behavior\n\n**Each violation requires explicit justification:**\n\n> \"I changed this test assertion because the\n> *requirement* changed, not because my implementation\n> couldn't meet the original requirement.\"\n\nIf the requirement didn't change, the test should not\nchange. Fix the implementation instead.\n\n### Step 4: Minimal Intervention Analysis\n\nFor each changed file, answer:\n\n1. **Was this change necessary?**\n Could the goal be achieved without touching this file?\n\n2. **Was this the minimal change?**\n Could fewer lines achieve the same result?\n\n3. **Did this change add or remove complexity?**\n New functions, classes, or control flow = added\n complexity that needs justification.\n\n4. **Is there a subtraction-first alternative?**\n Could removing code fix the problem instead of\n adding code?\n\n### Step 4.5: Invariant Impact Analysis\n\nChanges can be minimal and still catastrophically wrong\nif they silently revise a load-bearing design decision.\nFor each changed file, check whether it touches a design\ninvariant:\n\n**What counts as an invariant:**\n\n- Architectural patterns (module boundaries, layer\n separation, data flow direction)\n- Data structure choices (why a map vs list, why\n normalized vs denormalized)\n- API contracts (public interfaces, protocol formats)\n- Error handling strategies (fail-fast vs recovery)\n- Concurrency models (single-threaded assumption,\n actor model, shared-nothing)\n\n**Detection heuristic:**\n\n```bash\n# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\"\n```\n\n**When an invariant conflict is detected:**\n\nDo NOT silently pick a resolution. Present the three\noptions to the human:\n\n| Option | Description | When Right |\n|--------|-------------|------------|\n| **Preserve** | Don't add the feature; the invariant pays dividends | Invariant simplifies many things; feature is marginal |\n| **Layer** | Add feature inelegantly on top | Feature is needed; invariant is still valuable; imperfection is acceptable |\n| **Revise** | Change the invariant itself | Genuine new learning invalidates the original decision |\n\n**Add to Justification Report:**\n\n```markdown\n### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge\n```\n\n**Compounding risk warning:** Bad invariant decisions\naccumulate. If this branch has multiple invariant\nrevisions, flag the entire branch for architectural\nreview. Each silent invariant change multiplies the\nprobability of an unsalvageable codebase.\n\n### Step 5: Generate Justification Report\n\nOutput a structured report:\n\n```markdown\n## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]\n```\n\n## Decision Weights\n\nWhen evaluating competing approaches, weight\nthese factors:\n\n| Factor | Weight | Rationale |\n|--------|--------|-----------|\n| Fewer lines changed | HIGH | Less risk, easier review |\n| No new files | HIGH | No new maintenance burden |\n| No test logic changes | HIGH | Iron Law compliance |\n| Root cause fix | HIGH | Prevents recurrence |\n| Removes code | BONUS | Reduces maintenance surface |\n| Adds abstraction | PENALTY | Only justified at 3rd use |\n| Adds error handling | NEUTRAL | Only at system boundaries |\n\n**The Subtraction Test**: Before accepting any change,\nask: \"Could I achieve this by *removing* code instead\nof *adding* it?\" If yes, prefer the subtractive approach.\n\n## Integration with Proof of Work\n\nJustify extends proof-of-work with change-level\naccountability:\n\n- **proof-of-work**: \"Did it work?\" (evidence)\n- **justify**: \"Was this the right way?\" (reasoning)\n\nBoth are required before claiming work is complete.\nRun proof-of-work first, then justify.\n\n## Anti-Patterns to Flag\n\n### 1. Test Mutation\nChanging test expectations to match broken code.\n**Fix**: Revert the test change, fix the implementation.\n\n### 2. Shotgun Addition\nAdding code in many files for a single-concern fix.\n**Fix**: Find the single point of change.\n\n### 3. Defensive Overengineering\nAdding try/catch, null checks, or validation for\nscenarios that can't happen in practice.\n**Fix**: Trust internal code. Only validate at boundaries.\n\n### 4. Premature Abstraction\nCreating a helper/utility/base class for one use case.\n**Fix**: Inline the code. Abstract at the 3rd use.\n\n### 5. Compatibility Shim\nAdding backward-compatibility code instead of\nupdating callers.\n**Fix**: Update callers directly. Delete dead paths.\n\n### 6. Silent Invariant Revision\nChanging an architectural pattern, data structure\nchoice, or API contract without acknowledging\nthat a design invariant is being revised.\n**Fix**: Name the invariant. Present the 3 options\n(preserve, layer, revise) to a human. Do not make\nthe judgment call yourself — models default to the\n\"average\" of training data, and wrong invariant\ndecisions compound into unsalvageable codebases.\n\n## Scrutiny Questions (from leyline:additive-bias-defense)\n\nBefore justifying any change, apply these questions.\nIf the answer to questions 4 and 5 is not concrete\nevidence, the change is unjustified.\n\n1. **Priority alignment**: Is this a deviation from the\n current priority?\n2. **Criticality**: Is it critical to implement at this\n juncture?\n3. **Simplicity**: Does a simpler or more elegant\n solution exist?\n4. **Evidence**: What evidence proves this is needed\n (not assumed)?\n5. **Consequence**: What breaks if we do not add this?\n\n## Burden of Proof Inversion\n\nThe default stance is: **this addition should not\nexist.** The change must prove its necessity, not the\nreviewer must prove it unnecessary.\n\nWhen generating the Justification Report (Step 5), add\na `Burden of Proof` section:\n\n| Change | Scrutiny Q4 Answer | Scrutiny Q5 Answer | Verdict |\n|--------|--------------------|--------------------|---------|\n| file.py | [evidence] | [consequence] | justified/needs_evidence/unjustified |\n\nChanges with `unjustified` verdict MUST be removed or\nreworked before the report passes.\n\n## The Wise Counsel\n\n> Is what you are doing a deviation of your priority?\n> Is it critical to implement at this juncture?\n> Rely less on AI and initial lines of thinking.\n> Challenge yourself to be better, to think of a more\n> elegant implementation or a simpler solution.\n\n## Related Skills\n\n- `imbue:karpathy-principles` - \"Surgical Changes\" and\n \"Goal-Driven Execution\" principles invoke this audit\n from a higher-level synthesis\n- `leyline:additive-bias-defense` - the contract this\n audit enforces in detail\n- `imbue:proof-of-work` - the validation layer this\n audit complements (proof-of-work asks \"did it work?\",\n justify asks \"did it need to exist?\")\n- See `docs/quality-gates.md#skill-level-quality-gate-composition`\n for the full gate-skill federation graph\n\nFile v1.9.12:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.9.12\",\n \"publishedAt\": 1781838774358\n}\n\nFile v1.9.12:skill-card.md\n\n## Description:
\nAudits proposed code changes for additive bias, Iron Law test compliance, invariant impact, and minimal-intervention justification.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and code reviewers use this skill after implementation or before merging to evaluate whether changes are minimal, root-cause oriented, and properly justified, especially for AI-assisted work.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Broad activation wording may invoke the review posture during ordinary code-review language.
\nMitigation: Invoke the skill explicitly or narrow local triggers when only additive-bias audits should run.
\nRisk: The generated review report may contain incorrect or overly strict judgments about whether a change is justified.
\nMitigation: Treat the report as reviewer guidance and verify findings against requirements and the actual diff before merging.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/nm-imbue-justify)
\n- [Publisher profile](https://clawhub.ai/user/athola)
\n- [Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, shell commands, guidance]
\n**Output Format:** [Markdown report with shell command snippets]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Includes additive-bias score, Iron Law status, invariant-impact analysis, change-by-change justification, risk assessment, and recommendations.]
\n\n## Skill Version(s):
\n1.9.12 (source: release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.0: 3 files, 6767 bytes\n\nFiles: skill-card.md (1957b), SKILL.md (12410b), _meta.json (135b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| Aggregate | Zone | Action |\n|-----------|------|--------|\n| 0.0 - 0.5 | GREEN | Proceed |\n| 0.5 - 1.5 | YELLOW | Justify each signal |\n| 1.5 - 2.5 | RED | Rethink approach |\n| 2.5+ | STOP | Likely wrong approach |\n\n### Step 3: Iron Law Compliance Check\n\nThe Iron Law states: tests drive implementation, not\nthe other way around. Check for violations:\n\n```bash\n# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\"\n```\n\n**Violation patterns (test logic was tampered):**\n\n- Assertion values changed (expected output modified)\n- Test cases removed or commented out\n- `@skip` or `@pytest.mark.skip` added\n- Error expectations weakened (broad exception types)\n- Mock return values changed to match new behavior\n- Test renamed to no longer describe original behavior\n\n**Each violation requires explicit justification:**\n\n> \"I changed this test assertion because the\n> *requirement* changed, not because my implementation\n> couldn't meet the original requirement.\"\n\nIf the requirement didn't change, the test should not\nchange. Fix the implementation instead.\n\n### Step 4: Minimal Intervention Analysis\n\nFor each changed file, answer:\n\n1. **Was this change necessary?**\n Could the goal be achieved without touching this file?\n\n2. **Was this the minimal change?**\n Could fewer lines achieve the same result?\n\n3. **Did this change add or remove complexity?**\n New functions, classes, or control flow = added\n complexity that needs justification.\n\n4. **Is there a subtraction-first alternative?**\n Could removing code fix the problem instead of\n adding code?\n\n### Step 4.5: Invariant Impact Analysis\n\nChanges can be minimal and still catastrophically wrong\nif they silently revise a load-bearing design decision.\nFor each changed file, check whether it touches a design\ninvariant:\n\n**What counts as an invariant:**\n\n- Architectural patterns (module boundaries, layer\n separation, data flow direction)\n- Data structure choices (why a map vs list, why\n normalized vs denormalized)\n- API contracts (public interfaces, protocol formats)\n- Error handling strategies (fail-fast vs recovery)\n- Concurrency models (single-threaded assumption,\n actor model, shared-nothing)\n\n**Detection heuristic:**\n\n```bash\n# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\"\n```\n\n**When an invariant conflict is detected:**\n\nDo NOT silently pick a resolution. Present the three\noptions to the human:\n\n| Option | Description | When Right |\n|--------|-------------|------------|\n| **Preserve** | Don't add the feature; the invariant pays dividends | Invariant simplifies many things; feature is marginal |\n| **Layer** | Add feature inelegantly on top | Feature is needed; invariant is still valuable; imperfection is acceptable |\n| **Revise** | Change the invariant itself | Genuine new learning invalidates the original decision |\n\n**Add to Justification Report:**\n\n```markdown\n### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge\n```\n\n**Compounding risk warning:** Bad invariant decisions\naccumulate. If this branch has multiple invariant\nrevisions, flag the entire branch for architectural\nreview. Each silent invariant change multiplies the\nprobability of an unsalvageable codebase.\n\n### Step 5: Generate Justification Report\n\nOutput a structured report:\n\n```markdown\n## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]\n```\n\n## Decision Weights\n\nWhen evaluating competing approaches, weight\nthese factors:\n\n| Factor | Weight | Rationale |\n|--------|--------|-----------|\n| Fewer lines changed | HIGH | Less risk, easier review |\n| No new files | HIGH | No new maintenance burden |\n| No test logic changes | HIGH | Iron Law compliance |\n| Root cause fix | HIGH | Prevents recurrence |\n| Removes code | BONUS | Reduces maintenance surface |\n| Adds abstraction | PENALTY | Only justified at 3rd use |\n| Adds error handling | NEUTRAL | Only at system boundaries |\n\n**The Subtraction Test**: Before accepting any change,\nask: \"Could I achieve this by *removing* code instead\nof *adding* it?\" If yes, prefer the subtractive approach.\n\n## Integration with Proof of Work\n\nJustify extends proof-of-work with change-level\naccountability:\n\n- **proof-of-work**: \"Did it work?\" (evidence)\n- **justify**: \"Was this the right way?\" (reasoning)\n\nBoth are required before claiming work is complete.\nRun proof-of-work first, then justify.\n\n## Anti-Patterns to Flag\n\n### 1. Test Mutation\nChanging test expectations to match broken code.\n**Fix**: Revert the test change, fix the implementation.\n\n### 2. Shotgun Addition\nAdding code in many files for a single-concern fix.\n**Fix**: Find the single point of change.\n\n### 3. Defensive Overengineering\nAdding try/catch, null checks, or validation for\nscenarios that can't happen in practice.\n**Fix**: Trust internal code. Only validate at boundaries.\n\n### 4. Premature Abstraction\nCreating a helper/utility/base class for one use case.\n**Fix**: Inline the code. Abstract at the 3rd use.\n\n### 5. Compatibility Shim\nAdding backward-compatibility code instead of\nupdating callers.\n**Fix**: Update callers directly. Delete dead paths.\n\n### 6. Silent Invariant Revision\nChanging an architectural pattern, data structure\nchoice, or API contract without acknowledging\nthat a design invariant is being revised.\n**Fix**: Name the invariant. Present the 3 options\n(preserve, layer, revise) to a human. Do not make\nthe judgment call yourself — models default to the\n\"average\" of training data, and wrong invariant\ndecisions compound into unsalvageable codebases.\n\n## Scrutiny Questions (from leyline:additive-bias-defense)\n\nBefore justifying any change, apply these questions.\nIf the answer to questions 4 and 5 is not concrete\nevidence, the change is unjustified.\n\n1. **Priority alignment**: Is this a deviation from the\n current priority?\n2. **Criticality**: Is it critical to implement at this\n juncture?\n3. **Simplicity**: Does a simpler or more elegant\n solution exist?\n4. **Evidence**: What evidence proves this is needed\n (not assumed)?\n5. **Consequence**: What breaks if we do not add this?\n\n## Burden of Proof Inversion\n\nThe default stance is: **this addition should not\nexist.** The change must prove its necessity, not the\nreviewer must prove it unnecessary.\n\nWhen generating the Justification Report (Step 5), add\na `Burden of Proof` section:\n\n| Change | Scrutiny Q4 Answer | Scrutiny Q5 Answer | Verdict |\n|--------|--------------------|--------------------|---------|\n| file.py | [evidence] | [consequence] | justified/needs_evidence/unjustified |\n\nChanges with `unjustified` verdict MUST be removed or\nreworked before the report passes.\n\n## The Wise Counsel\n\n> Is what you are doing a deviation of your priority?\n> Is it critical to implement at this juncture?\n> Rely less on AI and initial lines of thinking.\n> Challenge yourself to be better, to think of a more\n> elegant implementation or a simpler solution.\n\n## Related Skills\n\n- `imbue:karpathy-principles` - \"Surgical Changes\" and\n \"Goal-Driven Execution\" principles invoke this audit\n from a higher-level synthesis\n- `leyline:additive-bias-defense` - the contract this\n audit enforces in detail\n- `imbue:proof-of-work` - the validation layer this\n audit complements (proof-of-work asks \"did it work?\",\n justify asks \"did it need to exist?\")\n- See `docs/quality-gates.md#skill-level-quality-gate-composition`\n for the full gate-skill federation graph\n\nFile v1.0.0:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.0.0\",\n \"publishedAt\": 1781791685334\n}\n\nFile v1.0.0:skill-card.md\n\n## Description:
\nAudits changes for additive bias and Iron Law compliance.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and engineers use this skill before merging code changes to audit additive bias, Iron Law compliance, minimal intervention, invariant impact, and change justification.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill can trigger during ordinary code-review requests because its trigger set is broad.
\nMitigation: Use it when a strict pre-merge justification review is desired and treat its output as review guidance rather than an automatic merge decision.
\nRisk: The artifact links to a separate Claude Code plugin that is not included in this release.
\nMitigation: Review and scan the companion plugin separately before installing it.
\n\n\n## Reference(s):
\n- [ClawHub Skill Page](https://clawhub.ai/athola/nm-imbue-justify)
\n- [Metadata Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)
\n\n\n## Skill Output:
\n**Output Type(s):** [Analysis, Markdown, Shell commands, Guidance]
\n**Output Format:** [Markdown report with inline shell commands and audit tables]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a structured Justification Report with additive-bias scoring, Iron Law status, invariant impact notes, risk assessment, and recommendations.]
\n\n## Skill Version(s):
\n1.0.0 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
","readmeExcerpt":"Skill: justify Owner: athola Summary: Audits changes for additive bias and Iron Law compliance Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:12:36.278Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:34:13.478Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:50:57.554Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:00:01.221Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:18:46.818Z | user Release v1.9.1","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files"},{"language":"text","snippet":"bias_score = sum(signal_score * weight) / sum(weights)"},{"language":"bash","snippet":"# Find test files that were modified\ngit diff \"$base\" --name-only | rg \"test_|_test\\.|spec\\.\" \\\n || git diff \"$base\" --name-only | grep -E \"test_|_test\\.|spec\\.\"\n\n# For each modified test file, check what changed\ngit diff \"$base\" -- | rg \"^[-+].*assert|^[-+].*expect|^[-+].*should\""},{"language":"bash","snippet":"# Check for structural changes (new modules, moved\n# boundaries, changed interfaces)\ngit diff \"$base\" --name-only | rg \"(interface|abstract|base|core|types|schema|model)\" \\\n || git diff \"$base\" --name-only | grep -E \"(interface|abstract|base|core|types|schema|model)\"\n\n# Check for pattern-breaking changes\ngit diff \"$base\" -U5 | rg \"(TODO.*refactor|HACK|WORKAROUND|XXX)\" \\\n || git diff \"$base\" -U5 | grep -E \"(TODO.*refactor|HACK|WORKAROUND|XXX)\""},{"language":"markdown","snippet":"### Invariant Impact: NONE / DETECTED\n\n[If DETECTED:]\n- **Invariant**: [name the design decision]\n- **Conflict**: [what change clashes with it]\n- **Option chosen**: Preserve / Layer / Revise\n- **Justification**: [why this option, not the others]\n- **Human reviewed**: YES / NO — if NO, flag as\n requiring review before merge"},{"language":"markdown","snippet":"## Justification Report\n\n**Branch**: feature/xyz\n**Base**: master\n**Delta**: +N/-M lines, X files changed\n\n### Additive Bias Score: X.X (ZONE)\n\n| Signal | Score | Detail |\n|--------|-------|--------|\n| Line ratio | N | +A/-D = R:1 |\n| New files | N | [list] |\n| Test changes | N | [list] |\n| New abstractions | N | [list] |\n| Workarounds | N | [list] |\n\n### Iron Law Compliance: PASS/FAIL\n\n[List any test logic modifications with justification]\n\n### Change-by-Change Justification\n\n#### file.py (+N/-M)\n- **What**: [description]\n- **Why**: [root cause this addresses]\n- **Alternatives considered**: [what else could work]\n- **Why this is minimal**: [why fewer changes won't work]\n\n#### test_file.py (+N/-M)\n- **What**: [description]\n- **Justification**: [why test logic changed, if it did]\n- **Iron Law status**: PASS/VIOLATION\n\n### Risk Assessment\n\n| Factor | Rating |\n|--------|--------|\n| Lines changed | LOW/MED/HIGH |\n| Files touched | LOW/MED/HIGH |\n| Test modifications | NONE/JUSTIFIED/VIOLATION |\n| New abstractions | NONE/JUSTIFIED/UNNECESSARY |\n| Overall merge risk | LOW/MED/HIGH |\n\n### Recommendations\n\n[List any changes that should be reconsidered,\nsimpler alternatives, or unnecessary additions]"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: justify\ndescription: Audits changes for additive bias and Iron Law compliance\nversion: 1.9.8\ntriggers:\n - justification\n - proof-of-work\n - anti-additive-bias\n - code-review\n - iron-law\n - reviewing completed work before merging or after AI-assisted implementation\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/imbue\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.imbue:proof-of-work\", \"night-market.leyline:additive-bias-defense\"]}}}\nsource: claude-night-market\nsource_plugin: imbue\n---\n\n> **Night Market Skill** — ported from [claude-night-market/imbue](https://github.com/athola/claude-night-market/tree/master/plugins/imbue). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n> The simplest change that fixes the problem is the\n> safest change to merge.\n> Adding code is easy. Removing the need for code is\n> engineering.\n\n# Justify\n\n## The Additive Bias Problem\n\nAI models are trained to be helpful, which creates\na systematic bias toward *adding* code rather than\n*fixing* root causes:\n\n| AI Default Behavior | Correct Behavior |\n|---------------------|------------------|\n| Add a workaround | Fix the root cause |\n| Modify test expectations | Fix the implementation |\n| Create a new helper | Use an existing one |\n| Add error handling | Prevent the error |\n| Add a compatibility shim | Remove the old code |\n| Wrap in try/catch | Fix the exception source |\n\nThis skill audits changes for these patterns and\nrequires explicit justification for each.\n\n## When to Use\n\n- After completing implementation work\n- Before committing or creating PRs\n- When reviewing your own changes for quality\n- When scope-guard flags RED/YELLOW zone\n\n## Audit Protocol\n\n### Step 1: Gather the Delta\n\n```bash\n# Determine base branch\nbase=$(git merge-base master HEAD 2>/dev/null \\\n || git merge-base main HEAD 2>/dev/null)\n\n# Get change statistics\ngit diff \"$base\" --stat\ngit diff \"$base\" --shortstat\ngit diff \"$base\" --diff-filter=A --name-only # new files\ngit diff \"$base\" --diff-filter=M --name-only # modified files\ngit diff \"$base\" --diff-filter=D --name-only # deleted files\n```\n\n### Step 2: Compute Additive Bias Score\n\nScore each dimension 0-3 (0 = clean, 3 = high bias):\n\n| Signal | Weight | How to Measure |\n|--------|--------|----------------|\n| Line ratio | 2x | `additions / max(deletions, 1)` |\n| New files | 2x | Count of `--diff-filter=A` |\n| Test logic changes | 3x | Test assertion/expectation diffs |\n| New abstractions | 1x | New classes, functions, modules |\n| Workaround patterns | 2x | Try/catch, if/else guards added |\n\n**Line Ratio Scoring:**\n\n| Ratio | Score | Interpretation |\n|-------|-------|----------------|\n| < 2:1 | 0 | Balanced change |\n| 2:1 to 5:1 | 1 | Mildly additive |\n| 5:1 to 10:1 | 2 | Additive bias likely |\n| > 10:1 | 3 | Strong additive bias |\n\n**Aggregate Score:**\n\n```\nbias_score = sum(signal_score * weight) / sum(weights)\n```\n\n| A"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-imbue-justify\",\n \"version\": \"1.9.19\",\n \"publishedAt\": 1787749956278\n}"},{"path":"skill-card.md","content":"## Description:\n\nAudits changes for additive bias and Iron Law compliance.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill after implementation work or before commits and pull requests to review diffs for additive-bias patterns, Iron Law test-discipline issues, and unnecessary complexity.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad triggers may activate the skill during ordinary code-review conversations.\n\nMitigation: Narrow trigger phrases or invoke the skill explicitly in workflows where accidental activation would distract from review.\n\nRisk: The skill reviews git diffs and may produce incorrect or overly strict guidance about proposed code changes.\n\nMitigation: Treat its report as review guidance and have a human reviewer confirm conclusions before merging.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-imbue-justify)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/imbue)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, guidance]\n\n**Output Format:** [Markdown report with inline shell commands and review tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces a structured justification report with additive-bias scoring, Iron Law checks, file-by-file rationale, risk assessment, and recommendations.]\n\n## Skill Version(s):\n\n1.9.19 (source: release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Audits changes for additive bias and Iron Law compliance Skill: justify Owner: athola Summary: Audits changes for additive bias and Iron Law compliance Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:12:36.278Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:34:13.478Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:50:57.554Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:00:01.221Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:18:46.818Z | user Release v1.9.1","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1046,"uniquenessScore":56,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T22:04:03.706Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T22:04:03.706Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-13T07:09:53.396Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}