novahiz 0.2.2 → 0.2.5

package/skills/code-standards/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: "code-standards"
+description: "Pragmatic engineering standards for production code: deep modules over micro-functions, review bar that improves code health, ASVS-aligned security checks, naming and error handling, test strategy. Use when writing or reviewing application code, setting a team style, or checking a PR against a shared bar. Prefer trade-offs over Clean Code dogma."
+license: "Apache-2.0"
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "1.0.0"
+  date: September 2026
+---
+
+# code-standards
+
+A shared bar for code that other people will read and change. Optimize for change cost and debuggability. Line counts and rule purity are secondary.
+
+## Review standard (Google eng-practices shape)
+
+Approve a change when it improves overall code health, even if it is imperfect. Do not block for weeks chasing polish. Technical facts and the style guide beat personal taste.
+
+Blocking:
+
+- Makes the system worse (unclear ownership of a bug fix, silent behavior change without tests).
+- Security or data-loss risk with no mitigation in the PR.
+- Breaks the agreed style guide where the guide already speaks.
+
+Non-blocking (mark as nit):
+
+- Naming and formatting the guide does not cover.
+- “Could be nicer” refactors that belong in a follow-up.
+- Educational comments that do not change the decision.
+
+Escalate when author and reviewer disagree after one round. Do not let a PR idle.
+
+## Design: depth over micro-cuts
+
+A module earns its place when a simple interface hides real work (deep module). Splitting every helper into three lines usually creates entanglement: the reader flips between files to understand one path.
+
+- Prefer one clear function that does the job over a constellation of one-liners.
+- Extract when the interface is simpler than the body. A length rule alone is a weak reason.
+- Duplication that is still evolving may stay until a stable abstraction appears.
+- Comments explain contracts and non-obvious why. Restating the function name in a comment is noise.
+
+## Naming and structure
+
+- Names use the problem domain (`postPayment`, not `handleThing3`).
+- Command or query: a function does something or answers something. A method that both mutates and returns a “status” confuses every caller.
+- Module boundaries match change ownership. Cross-module edits without a contract change are a smell.
+- Error handling returns enough context to act. Swallowed exceptions and bare `null` returns hide production incidents.
+
+## Security floor (ASVS-shaped)
+
+Pick an ASVS level per app (L1 minimum, L2 for sensitive data). At every level:
+
+- Validate untrusted input on a trusted server path; encode output for the interpreter that will run it.
+- Auth and session checks on every non-public resource; deny by default.
+- Secrets never in source; load from a secret store or env injected by the platform.
+- Log security-relevant events without writing passwords, tokens, or full PII into logs.
+- HTTPS and pinned or well-known trust for outbound calls.
+
+Architecture checks (threat model, trust boundaries) belong in design review as well as in CI.
+
+## Testing bar
+
+- Behavior-changing code ships with tests that fail if the behavior regresses.
+- Unit tests are fast, independent, repeatable, self-validating.
+- Integration tests cover the seams that unit tests fake (DB, auth, queues).
+- Flaky tests are bugs. Quarantine with a ticket or fix; do not re-run until green and forget.
+
+## When style fights the codebase
+
+The style guide wins on covered points. On uncovered points, match existing code unless the change makes health worse. Automate what reviewers keep repeating (linters, formatters); a PR that only argues whitespace is a tooling gap.
+
+## Checklist (PR)
+
+- [ ] Intent clear from title and first screen of the diff.
+- [ ] Correctness: edge cases, empty inputs, concurrent use if relevant.
+- [ ] Tests for behavior change; assertions match user-visible outcomes.
+- [ ] No secret, token, or PII in code or logs.
+- [ ] Names and structure match the domain; no dead branches.
+- [ ] Error paths return actionable information.
+- [ ] Docs or migration notes when public interfaces move.
+
+## Sources
+
+Google Engineering Practices (code review standard); OWASP ASVS 4.0 levels and control chapters; A Philosophy of Software Design (deep modules); Pragmatic Programmer patterns. Original Novahiz synthesis; no upstream skill text.

package/skills/code-standards/references/pr-review-worksheet.md

@@ -0,0 +1,35 @@
+# PR review worksheet
+
+Copy into the review or keep beside the checklist in SKILL.md.
+
+## Change
+
+- Title / ticket:
+- Surface touched (api, ui, data, infra):
+- ASVS level targeted (1 / 2 / 3):
+
+## Blocking
+
+| Finding | Evidence (file:line) | Fix direction |
+|---|---|---|
+| | | |
+
+## Non-blocking (nit)
+
+- 
+
+## Security spot-check
+
+- [ ] Input validated where untrusted data enters
+- [ ] Output encoded for the right sink
+- [ ] Authz on every new route or mutation
+- [ ] No secrets or raw PII in code, tests, or logs
+- [ ] Dependencies pinned; lockfile updated if deps changed
+
+## Decision
+
+- [ ] Approve
+- [ ] Request changes (list blockers only)
+- [ ] Comment (questions, follow-up ticket)
+
+Escalation if disagreement remains after one clarifying round: tech lead or codeowner, same day.

package/skills/design-token-pipeline/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: "design-token-pipeline"
+description: "Design token architecture and pipeline: DTCG 2025.10 format ($value/$type/aliases), base/semantic/component layers, Style Dictionary v4 builds, Figma Variables round-trip, theming and governance. Use when creating or migrating token files, CSS custom properties from a system, multi-brand themes, or design-dev handoff of color/type/spacing."
+license: "Apache-2.0"
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "1.0.0"
+  date: September 2026
+---
+
+# design-token-pipeline
+
+Tokens are the contract between design tools and shipped code. This skill covers the format, the layer model, the build, and the governance rules the format does not prescribe.
+
+## Format: DTCG 2025.10
+
+Stable spec from the W3C Design Tokens Community Group (October 2025). Prefer it for new files.
+
+| Property | Role |
+|---|---|
+| `$value` | The value (reserved word) |
+| `$type` | Kind: `color`, `dimension`, `fontFamily`, `fontWeight`, `duration`, `cubicBezier`, `number`, `string`, `boolean`, `strokeStyle`, `border`, `transition`, `shadow`, `gradient`, `typography`, `fontStyle` |
+| `$description` | Human doc that travels with the token |
+| `$extensions` | Vendor/team metadata, namespaced keys |
+
+- Spec keys use `$`. Token and group names must not start with `$`.
+- A token is an object with `$value`. Without it, the object is a group.
+- Groups may set `$type` (inherited), `$description`, `$deprecated`, `$extends`, `$root`.
+- Aliases: `{color.brand.blue}` curly-brace path references.
+- Colors in 2025.10 are objects with a colour space plus components (`srgb`, `hsl`, `hwb`, `lab`, `lch`, `oklab`, `oklch`), not bare hex. Keep an optional hex only as a fallback for old tools.
+- Do not put `{` `}` `.` in token/group names (alias and path rules).
+
+Style Dictionary v4 reads DTCG natively. Full 2025.10 colour-object support is still landing in v5; check the version you pin before migrating hex-only colour tokens.
+
+## Layer model (the spec does not mandate one)
+
+The spec standardizes the container. Layering is your architecture decision. The common stack:
+
+```
+base (primitives)  →  semantic (intent)  →  component (instance)
+#bada55              color.accent.brand     button.primary.bg
+spacing.4            text.muted             card.padding
+```
+
+| Layer | Names answer | Change cost |
+|---|---|---|
+| Base | What is the literal? | Low (internal) |
+| Semantic | What is it for? | Medium (meaning is public) |
+| Component | Which control? | High (scattered consumers) |
+
+Reference upward with aliases. Theme swaps change base (or a semantic override set), not each component file.
+
+`outputReferences: true` in Style Dictionary keeps `var(--…)` chains in CSS when base and semantic ship in the same bundle. Hardcode when a semantic file must stand alone.
+
+## Pipeline shape
+
+1. Author tokens in DTCG JSON (Figma Variables export or hand-maintained).
+2. Validate against the format (structure, types, unresolved aliases).
+3. Build with Style Dictionary (or Terrazzo): transforms per platform.
+4. Emit CSS custom properties, iOS/Android/Flutter sources as needed.
+5. Point components only at semantic (or component) names, never raw hex in JSX.
+
+Multi-platform: DTCG `dimension` has `px`/`rem`/`em`, not iOS `pt` or Android `dp`. Conversion is an explicit transform step with a documented ratio.
+
+## Governance (outside the spec)
+
+- Who may add a semantic token? Review rule in the repo.
+- Deprecate with `$deprecated`, do not leave `blue-v2-new` beside `blue`.
+- One naming dialect documented (e.g. `color.text.muted`, not mixed `--textColorMuted` and `color-text-muted` at the same layer).
+- Delete unused base tokens on a schedule; cruft accumulates silently.
+
+## Checklist
+
+- [ ] New work is DTCG-shaped (`$value` / `$type`), not legacy `value`/`type`.
+- [ ] Three layers (or a documented reason for fewer).
+- [ ] Components import semantic names only.
+- [ ] Light/dark (and brand) are data, not forked component CSS.
+- [ ] Alias graph resolves; no circular references.
+- [ ] Platform transforms documented for non-web targets.
+- [ ] Governance rule written where contributors will see it.
+
+## Sources
+
+Design Tokens Format Module 2025.10 (designtokens.org), Style Dictionary DTCG docs, W3C Design Tokens CG announcements, Nathan Curtis / Cosima writing on token naming layers. Original Novahiz synthesis.

package/skills/design-token-pipeline/references/dtcg-sample.json

@@ -0,0 +1,37 @@
+{
+  "$description": "Example DTCG 2025.10 snippet: base → semantic → component aliases.",
+  "color": {
+    "base": {
+      "$type": "color",
+      "brand": {
+        "600": {
+          "$value": { "colorSpace": "oklch", "components": [0.55, 0.15, 250] },
+          "$description": "Primary brand",
+          "$extensions": { "novahiz.fallbackHex": "#3B5BDB" }
+        }
+      },
+      "neutral": {
+        "0": { "$value": { "colorSpace": "oklch", "components": [1, 0, 0] } },
+        "900": { "$value": { "colorSpace": "oklch", "components": [0.2, 0.02, 250] } }
+      }
+    },
+    "semantic": {
+      "text": {
+        "default": { "$value": "{color.base.neutral.900}", "$type": "color" },
+        "muted": {
+          "$value": "{color.base.neutral.900}",
+          "$type": "color",
+          "$description": "Secondary text; raise contrast if it drops below AA"
+        }
+      },
+      "action": {
+        "primary": { "$value": "{color.base.brand.600}", "$type": "color" }
+      }
+    }
+  },
+  "button": {
+    "primary": {
+      "bg": { "$value": "{color.semantic.action.primary}", "$type": "color" }
+    }
+  }
+}

package/skills/llm-threat-review/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: "llm-threat-review"
+description: "Security review for LLM and agent features: OWASP LLM Top 10 2025, MITRE ATLAS technique mapping, prompt injection and excessive agency checks, tool least privilege, output handling, logging. Use when designing or reviewing chat, RAG, or agentic code paths, before ship or during threat modeling."
+license: "Apache-2.0"
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "1.0.0"
+  date: September 2026
+---
+
+# llm-threat-review
+
+Review checklist for systems that call a model, retrieve context, or let a model call tools. Findings carry severity and a control. Score against OWASP LLM Top 10 (2025) and map to MITRE ATLAS where a technique id helps.
+
+## Scope
+
+Chat UIs, RAG pipelines, agent loops, tool/function calling, fine-tunes that ingest user data. Classic web vulns in the host app stay with `novahiz-security` / ASVS work; this skill covers the model surface.
+
+## 1. Threat model first
+
+Answer before listing controls:
+
+1. What private data can the model read?
+2. What untrusted content enters the prompt (user text, web, email, tickets, files)?
+3. What can the model do (call tools, write, spend, message)?
+4. Where does output go (user, HTML, SQL, shell, another model)?
+
+If one path combines private data, untrusted content, and an external action, treat it as critical. That combination is the lethal trifecta agents often assemble by default.
+
+## 2. OWASP LLM 2025 map (review each)
+
+| ID | Risk | Review question | Typical control |
+|---|---|---|---|
+| LLM01 | Prompt injection | Can user or retrieved text override system rules? | Separate instruction from data; ignore embedded orders; HITL on high-impact tools |
+| LLM02 | Sensitive info disclosure | Can the model echo secrets, PII, or system prompt? | Redact before send; restrict what the system prompt may contain; output filters |
+| LLM03 | Supply chain | Where do models, plugins, and datasets come from? | Pin versions; verify hashes/signatures; vendor review; SBOM/ML-BOM |
+| LLM04 | Data and model poisoning | Can training, fine-tune, or RAG data be poisoned? | Provenance on data; sandbox imports; monitor eval regressions |
+| LLM05 | Improper output handling | Is model output fed to interpreter, SQL, or browser without checks? | Parameterized queries; HTML sanitize; no raw shell from model text |
+| LLM06 | Excessive agency | Do tools run with more privilege than the task needs? | Least-privilege tokens; allowlists; confirm destructive calls |
+| LLM07 | System prompt leakage | Is the system prompt secret that matters? | Keep secrets out of the prompt; accept that prompts leak if treated as public |
+| LLM08 | Vector and embedding weaknesses | Who can poison or read the vector store? | Tenant isolation; authz on retrieval; tamper checks on indexes |
+| LLM09 | Misinformation | Where does unverified model text become a decision? | Grounding; citations; human review for high-stakes answers |
+| LLM10 | Unbounded consumption | Can an attacker burn tokens or loop tools? | Rate limits; budgets; max steps; circuit breakers |
+
+## 3. Injection and jailbreak defenses
+
+No single filter stops all injection. Layer:
+
+- Constrain role and allowed topics in the system prompt; instruct the model to treat retrieved content as data.
+- Structure prompts so instructions and untrusted content are visually and logically separate (tags, fields).
+- Deterministic validation of output shape (JSON schema, enums) before side effects.
+- Input screening (pattern + optional classifier) on user text and on every external chunk (web, email, tickets).
+- Output screening before render or tool call; block exfil patterns and unexpected tool names.
+- Human approval for money, deletes, production deploys, mass messages.
+- Rate limit and anomaly-log multi-turn and encoded payloads (base64, zero-width, homoglyphs).
+
+Treat regex alone as weak against creative obfuscation. Best-of-N style attacks eventually slip past static filters; budget and monitoring matter as much as the filter.
+
+## 4. Agency and tools
+
+- Each tool gets the minimum scope (read vs write, record-level limits).
+- Prefer app-held credentials over passing API keys into the prompt.
+- Dual pattern when stakes are high: one process reads untrusted content, another holds tools and only receives structured summaries.
+- Max iteration count and wall-clock budget per user session.
+- Log every tool call with actor, arguments hash, and outcome.
+
+## 5. Output handling
+
+Model text is untrusted input to the next system:
+
+- HTML: sanitize allowlists before DOM insert.
+- SQL: parameterize; never interpolate model identifiers into DDL.
+- Shell: do not execute model-authored commands without an allowlist and sandbox.
+- URLs: validate scheme and host before fetch (SSRF discipline).
+
+## 6. Logging and redaction
+
+Log prompts and outputs for incident work, but redact secrets and unnecessary PII. Alert on: tool calls outside the user’s role, repeated injection-shaped inputs, sudden token spend.
+
+## Report format
+
+```
+## LLM threat review
+Verdict: PASS | PASS_WITH_FIXES | FAIL
+
+### Findings
+- [HIGH|MED|LOW] area : finding (OWASP LLMxx / ATLAS AML.Txxxx if known)
+  Control: ...
+
+### Accepted risk
+- ...
+```
+
+Every finding names a concrete path (route, tool, retrieval source).
+
+## Sources
+
+OWASP Top 10 for LLM Applications 2025 (genai.owasp.org); OWASP LLM Prompt Injection Prevention Cheat Sheet; MITRE ATLAS technique data (AML.T0051 family, agent tool techniques); BSI guidance on evasion attacks. Original Novahiz checklist synthesis.

package/skills/llm-threat-review/references/review-worksheet.md

@@ -0,0 +1,34 @@
+# LLM review worksheet
+
+## Inventory
+
+| Path | Model | Tools | Untrusted in | Output sink |
+|---|---|---|---|---|
+| | | | | |
+
+## Lethal trifecta
+
+- [ ] Private data in context
+- [ ] Untrusted content in context
+- [ ] External action or exfil channel
+
+If all three: severity floor HIGH until a control breaks the chain.
+
+## Findings
+
+| ID | Severity | Control |
+|---|---|---|
+| LLM01 | | |
+| LLM05 | | |
+| LLM06 | | |
+| LLM10 | | |
+
+## Sign-off
+
+- [ ] Tool scopes minimal and tested
+- [ ] HITL on destructive tools
+- [ ] Output sanitization for the real sink
+- [ ] Budgets and rate limits on
+- [ ] Logs redacted
+
+Verdict: PASS | PASS_WITH_FIXES | FAIL

package/skills/llm-threat-review/scripts/llm_risk_lint.mjs

@@ -0,0 +1,105 @@
+#!/usr/bin/env node
+/**
+ * llm-threat-review: static heuristics on prompt/tool code paths.
+ * Flags high-risk patterns for human review. Not a proof of safety.
+ *
+ * Usage: node scripts/llm_risk_lint.mjs <file-or-dir> [...]
+ * Exit 1 if any HIGH finding.
+ */
+
+import { readFileSync, readdirSync, statSync } from "node:fs";
+import { join, extname } from "node:path";
+
+const EXTS = new Set([".ts", ".tsx", ".js", ".jsx", ".mjs", ".cjs", ".py"]);
+
+const RULES = [
+  {
+    id: "tool-shell-from-model",
+    level: "HIGH",
+    re: /exec(?:Sync)?\s*\(\s*(?:result|output|completion|text|message)|child_process[\s\S]{0,120}(?:result|completion|modelOutput)/i,
+    msg: "Possible shell exec of model output",
+  },
+  {
+    id: "sql-interpolate-model",
+    level: "HIGH",
+    re: /(?:query|execute|raw)\s*\(\s*[`'"](?:SELECT|INSERT|UPDATE|DELETE)[\s\S]{0,80}(?:\$\{|output|completion|model)/i,
+    msg: "Possible SQL built from model text",
+  },
+  {
+    id: "html-inject-model",
+    level: "HIGH",
+    re: /innerHTML\s*=\s*(?:result|output|completion|message\.(?:content|text))|dangerouslySetInnerHTML\s*\{\s*__html:\s*(?:result|output|completion)/i,
+    msg: "Model output assigned to HTML sink without visible sanitize",
+  },
+  {
+    id: "system-prompt-secret",
+    level: "HIGH",
+    re: /system(?:Prompt|_prompt)?[\s\S]{0,80}(?:API_KEY|SECRET|PASSWORD|PRIVATE_KEY)\s*=/i,
+    msg: "Credential-like value near system prompt (LLM07)",
+  },
+  {
+    id: "unbounded-agent-loop",
+    level: "MED",
+    re: /while\s*\(\s*true\s*\)[\s\S]{0,200}(?:tool|agent|llm|openai|anthropic)/i,
+    msg: "Unbounded loop around agent/tool calls (LLM10)",
+  },
+  {
+    id: "tool-all-scope",
+    level: "MED",
+    re: /scope:\s*['"][\w:.*]+\s*\*/i,
+    msg: "Wildcard scope on credential or tool",
+  },
+  {
+    id: "fetch-untrusted-url",
+    level: "MED",
+    re: /fetch\s*\(\s*(?:url|href|link|inputUrl)\b/i,
+    msg: "Fetch of caller-controlled URL; check SSRF allowlist",
+  },
+];
+
+function walk(path, out = []) {
+  const st = statSync(path);
+  if (st.isDirectory()) {
+    for (const name of readdirSync(path)) {
+      if (name === "node_modules" || name === ".git" || name === "dist") continue;
+      walk(join(path, name), out);
+    }
+  } else if (EXTS.has(extname(path).toLowerCase())) {
+    out.push(path);
+  }
+  return out;
+}
+
+function scanFile(file) {
+  const text = readFileSync(file, "utf8");
+  const findings = [];
+  for (const rule of RULES) {
+    const m = rule.re.exec(text);
+    if (m) {
+      const line = text.slice(0, m.index).split(/\r?\n/).length;
+      findings.push({ file, line, ...rule });
+    }
+  }
+  return findings;
+}
+
+const roots = process.argv.slice(2);
+if (roots.length === 0) {
+  console.error("usage: node scripts/llm_risk_lint.mjs <file-or-dir> [...]");
+  process.exit(2);
+}
+
+const files = roots.flatMap((r) => walk(r));
+const all = files.flatMap(scanFile);
+const byLevel = { HIGH: [], MED: [], LOW: [] };
+for (const f of all) byLevel[f.level].push(f);
+
+for (const level of ["HIGH", "MED", "LOW"]) {
+  for (const f of byLevel[level]) {
+    console.log(`${level}\t${f.id}\t${f.file}:${f.line}\t${f.msg}`);
+  }
+}
+
+const high = byLevel.HIGH.length;
+console.error(`llm_risk_lint: ${files.length} files, ${all.length} findings (${high} HIGH)`);
+process.exit(high > 0 ? 1 : 0);

package/skills/novahiz-audit/SKILL.md

@@ -45,7 +45,7 @@ Agent memory is never evidence. If a claim cannot be traced to one of the four s
 
 Fourteen categories are checked when encountered: `code`, `debug`, `review`, `audit`, `browser`, `design-ui`, `database-supabase`, `docs-writing`, `planning`, `devops`, `data`, `test`, `security`, `general`.
 
-`general` carries the rules that apply everywhere (humanizer on prose, honesty, todo discipline). A category not in the list falls back to `general` only.
+`general` carries the rules that apply everywhere (honesty, todo discipline). Design skills (`novahiz-humanizer`, `ui-slop-remover`) are checked only under `design-ui`. A category not in the list falls back to `general` only.
 
 ## Rules of the audit
 

package/skills/novahiz-gate/SKILL.md

@@ -26,10 +26,11 @@ Le gate pose une seule question : les skills exigées par le contexte sont-elles
 
 | Règle | Se déclenche sur | Exige |
 |---|---|---|
-| R1-docs | texte, data, config | `novahiz-humanizer` |
-| R1-code-prose | code ou design dont le contenu porte de la prose | `novahiz-humanizer` |
+| R13-design-craft | tâche design frontend (catégorie design-ui, fichiers style css/scss/html/…) | `novahiz-humanizer`, `ui-slop-remover`, `ui-craft-rules` |
 | R3-supabase | chemin `**/supabase/**` ou `**/migrations/**`, catégorie `database-supabase` | `supabase`, `supabase-postgres-best-practices` |
 
+Hors design frontend, `novahiz-humanizer` et `ui-slop-remover` ne sont plus exigés par le gate.
+
 **Les étapes de roadmap** (`catalog/categories.json`) : seules celles marquées `kind: "skill"` sans `optional` bloquent. Les étapes `edit`, `verify` et `advisory` apparaissent dans `requiredSkills` mais ne refusent rien.
 
 ## Sémantique de l'index (gate.ts, lignes 229 à 236)
@@ -50,11 +51,11 @@ Trois conséquences à connaître :
 ```json
 {
   "allow": false,
-  "missingSkills": ["humanizer"],
+  "missingSkills": ["novahiz-humanizer", "ui-slop-remover"],
   "indexMissing": false,
   "targets": [{
-    "path": "...", "fileClass": "text", "roadmap": "feature",
-    "matchedRules": ["R1-docs"], "reasons": ["missing skill: humanizer"]
+    "path": "...", "fileClass": "design", "roadmap": "design",
+    "matchedRules": ["R13-design-craft"], "reasons": ["missing skill: novahiz-humanizer"]
   }]
 }
 ```
@@ -67,7 +68,7 @@ Charger chaque skill manquante avec `skill({name})`. Le chargement est enregistr
 
 ## Contournement
 
-Le seul prévu par le code : `novahiz_GATE=off` (ou `0`, `false`, `no`, `disabled`) dans l'environnement, lu via `gate.envEscape`. L'utilisateur peut aussi demander explicitement de passer outre. Dans les deux cas, la dérogation se dit à voix haute et se rattrape après coup. Le jugement de l'agent n'est pas un contournement valide.
+Le seul prévu par le code : `NOVAHIZ_GATE=off` (ou `0`, `false`, `no`, `disabled`) dans l'environnement. Le nom de la variable est codé en dur (le champ `gate.envEscape` de la config ne le redirige pas). L'utilisateur peut aussi demander explicitement de passer outre. Dans les deux cas, la dérogation se dit à voix haute et se rattrape après coup. Le jugement de l'agent n'est pas un contournement valide.
 
 ## Anti-patterns
 

package/skills/novahiz-humanizer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: novahiz-humanizer
-description: "Remove AI writing patterns from text. Rewrite AI-sounding prose so it reads like the human writer: not-X-but-Y contrasts, forced triads, em dashes, chatbot residue, inflated significance, and statistical tells. Use novahiz-humanizer on every text, documentation, commit message, PR description, or code comment meant for a reader."
+description: "Remove AI writing patterns from text. Rewrite AI-sounding prose so it reads like the human writer: not-X-but-Y contrasts, forced triads, em dashes, chatbot residue, inflated significance, and statistical tells. Use novahiz-humanizer on frontend design tasks (R13); it is not required by the gate outside design."
 license: MIT
 metadata:
   author: Novahiz

package/skills/novahiz-implement/SKILL.md

@@ -47,7 +47,7 @@ novahiz_task action="done"  id="<todo>" proof="<command and result>"
 
 ## The gate will trigger
 
-Writing code fires rules: R1-code-prose requires `novahiz-humanizer` whenever the content carries prose (comments, messages, labels). Load it before writing, ahead of the refusal.
+Writing code fires rules. On frontend design work, R13 requires `novahiz-humanizer`, `ui-slop-remover` and `ui-craft-rules`. Outside design, those skills are not required by the gate. Load design skills before writing, ahead of the refusal.
 
 ## Writing rules
 

package/skills/novahiz-init/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: novahiz-init
+description: |
+  novahiz-init bootstraps Novahiz inside a project: memory skeleton, novahiz-docs/,
+  deep read of the codebase, documentation fill-in, and a reviewed cleanup list.
+  Use when the user says "/novahiz init", "init novahiz", "initialize novahiz in this project",
+  "set up project docs and memory", or wants a one-shot project onboarding.
+license: Apache-2.0
+compatibility: opencode
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "1.0.0"
+---
+
+# novahiz-init
+
+One entry point to bring Novahiz into the current project: scaffold first, then deepen with an agent read.
+
+## When to run
+
+- `/novahiz init` or `novahiz init` in the project root
+- A new repo needs docs + `project-memory/`
+- Docs or memory are missing after a clone
+
+Do **not** use this to install Novahiz on the machine. That stays `novahiz setup` / `install.mjs`.
+
+## Pipeline
+
+```
+1. CLI scaffold     novahiz init [--dry-run] [--docs-only|--memory-only]
+2. Deep read        novahiz-analyse on the real code
+3. Fill docs        novahiz-docs templates already created by CLI
+4. Seed memory      memory_write a baseline slot from findings
+5. Cleanup review   confirm list, then novahiz init --apply --json
+```
+
+### 1. Scaffold (CLI, deterministic)
+
+From the project root:
+
+```
+novahiz init --dry-run --json
+```
+
+Review the plan, then run without `--dry-run` unless the user only wanted a preview.
+
+Flags:
+
+| Flag | Effect |
+|---|---|
+| `--dry-run` | Print steps and cleanup candidates, write nothing |
+| `--docs-only` | Only `novahiz-docs/` |
+| `--memory-only` | Only `project-memory/` |
+| `--no-seed` | Create memory root without the baseline slot |
+| `--apply` | Delete the listed cleanup candidates (never without review) |
+| `--json` | Machine-readable result |
+
+The CLI creates:
+
+- `project-memory/index.json` + `slots/` (plus one baseline slot unless `--no-seed`)
+- `novahiz-docs/{ARCHITECTURE,CONVENTIONS,DECISIONS,STANDARDS}.md` from the `novahiz-docs` templates when the folder is absent
+- A cleanup candidate list (logs, `*.orig`, `*.novahiz-bak`, …). Nothing is deleted without `--apply`.
+
+### 2. Deep read
+
+Load `novahiz-analyse` and walk manifests, entry points, and data flow. Every claim cites a path. This step is agent work; the CLI does not invent architecture.
+
+### 3. Fill documentation
+
+Edit only the four files under `novahiz-docs/`:
+
+- Replace HTML comment placeholders with observed facts
+- Keep DECISIONS.md empty until a real decision exists
+- If older docs live in `README.md` or `docs/`, migrate unique facts into the right file, then leave a pointer in the README. Do not delete the README.
+
+On frontend design docs or style copy, load `novahiz-humanizer` (R13). Outside design it is not required by the gate.
+
+### 4. Seed memory
+
+After docs are filled, append one slot via MCP `memory_write` or `novahiz init` baseline (already written by CLI):
+
+- stack and markers
+- entry points
+- where docs live
+- open unknowns
+
+### 5. Cleanup (optional, reviewed)
+
+1. Show the CLI cleanup list to the user.
+2. Use the `question` tool: apply all, apply none, or hand-pick.
+3. Only after an explicit choice:
+
+```
+novahiz init --apply --json
+```
+
+`--yes` alone is never enough to delete files the user has not seen.
+
+## Exit criteria
+
+- `novahiz init --json` has `failed: []`
+- `novahiz-docs/` has four files with no remaining fill-in comments on architecture/conventions/standards
+- `project-memory/` has at least one slot
+- Cleanup either applied with consent or left unapplied on purpose
+
+## Pitfalls
+
+- Running `novahiz init` thinking it installs the global tool (`setup` does that).
+- Filling templates with guessed architecture instead of a real read.
+- Deleting cleanup candidates without showing the list.
+- Duplicating content that already belongs in `novahiz-docs` update / converge.