UN-3396 [MISC] Align SKILL.md terminology with canonical contract format

CodeRabbit (2026-04-08T11:10Z) flagged two remaining terminology
drifts in the design-rules skill instructions:

1. The "What you'll get" row for the `validate` mode claimed the
   script checks "ADR-link resolution" — the script does not, and
   has never done so. Corrected to list the three actual checks:
   forbidden-word scan, compatibility-statement presence, and
   component-directory sanity.

2. Five places inside the skill still used the old "Dos / Don'ts /
   Acceptance criteria" vocabulary to describe per-component content,
   which contradicts the canonical per-component contract requiring
   `## Rules` with `R1..Rn` entries and the four-row (Severity / Why /
   Refs / Enforced by) table. Replaced each with the canonical
   terminology:

   - Quick Start "get" row: "component Dos/Don'ts" → "the component's
     `## Rules` entries (`R1..Rn` with Severity / Why / Refs /
     Enforced by)"
   - Command `get` step 3 bundle item: same replacement, plus an
     explicit mention of `## Known Exceptions` entries when present
   - Command `add` per-component step 4: dropped "Dos / Don'ts in
     source material" wording, replaced with the canonical
     `No component-specific rules yet.` placeholder under `## Rules`
     and an explicit warning that inventing Dos/Don'ts is forbidden
   - Command `review` step 3: walk the component's `## Rules`
     (`R1..Rn`) rather than "the component's Dos / Don'ts"

The only remaining "Dos/Don'ts" mention in SKILL.md is the explicit
prohibition in the `add` step — it tells contributors the old shape
is not allowed, not that they should use it.

No behavioural change. Purely terminology alignment with the contract.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Author: muhammad-ali-e

.claude/skills/design-rules/SKILL.md

@@ -34,11 +34,11 @@ A skill for managing and applying the version-controlled design rule system in t
 | Mode | Output |
 |------|--------|
 | **list** | Compact text list (titles + numbers, no bodies) |
-| **get** | Deduped bundle: compatibility statement, relevant principles, AI Review Checklist, referenced ADRs, security standards, component Dos/Don'ts |
+| **get** | Deduped bundle: compatibility statement, relevant principles, AI Review Checklist, referenced ADRs, security standards, and the component's `## Rules` entries (`R1..Rn` with Severity / Why / Refs / Enforced by) |
 | **add** | New file written + cross-links updated; refused if content describes an aspiration rather than implemented behaviour |
 | **update** | Minimal in-place edit; ADR superseded with a new ADR if the change is a reversal |
 | **review** | Per-file findings table: file, line, principle/ADR violated, why, minimal fix |
-| **validate** | Pass/fail report from forbidden-word grep, compatibility-statement check, ADR-link resolution |
+| **validate** | Pass/fail report from forbidden-word scan, compatibility-statement presence check, and component-directory sanity check |
 
 ---
 
@@ -81,7 +81,7 @@ Fetch the rules that actually apply to a target.
    - AI Review Checklist (always)
    - ADRs referenced by any collected component file
    - Security standards referenced (e.g. `security/tenant-isolation.md`, `security/standards.md`, the inline SQL Safety Standard under `unstract/connectors/.../databases/`)
-   - The component-specific Dos / Don'ts / Acceptance criteria from each collected `DESIGN_RULES.md`
+   - The component-specific `## Rules` entries (`R1..Rn` with Severity / Why / Refs / Enforced by) from each collected `DESIGN_RULES.md`, plus any `## Known Exceptions` entries when present
 4. **Deduplicate.** Never show the same principle or ADR twice.
 5. If asked for "all" design rules, dump the global files (`design-rules/**`) without per-component noise.
 
@@ -120,7 +120,7 @@ Create a new rule, ADR, or per-component file.
 1. Verify the directory exists on disk and contains real source (not just `__pycache__`).
 2. Use the standard template from `design-rules/README.md`. Always include the verbatim compatibility statement.
 3. Include "Read first" links to `principles.md`, `ai-review-checklist.md`, and any relevant ADRs / security standards.
-4. If the component has no specific Dos / Don'ts in source material, write the boilerplate body with `No component-specific rules beyond the global principles.`
+4. If the component has no specific rules yet, use the canonical placeholder under `## Rules`: `No component-specific rules yet.` Do not invent Dos/Don'ts — the canonical format is `R1..Rn` entries with the full four-row table.
 
 ---
 
@@ -141,7 +141,7 @@ Check code or a diff against the design rules. Triggered by "review against desi
 
 1. **Determine the target.** Accept: a list of changed files, a PR number (use `gh pr diff <n> --name-only`), `git diff --name-only` for local changes, or a single file.
 2. **Run `get`** on those targets to collect all applicable rules.
-3. **For each changed file**, walk through the AI Review Checklist questions (`design-rules/ai-review-checklist.md`) and the component's Dos / Don'ts. For every violation, output:
+3. **For each changed file**, walk through the AI Review Checklist questions (`design-rules/ai-review-checklist.md`) and the component's `## Rules` entries (`R1..Rn`). For every violation, output:
    - File and line (when known)
    - Principle / ADR / security standard violated
    - Why it's a violation