chore: migrate legacy pre-commit hook to .pre-commit-config.yaml

Replaces shell script (.git/hooks/pre-commit.legacy) with ecosystem-managed pre-commit framework:
- gitleaks/gitleaks: secret scanning
- jumanjihouse/pre-commit-hooks: shellcheck wrapper
- pre-commit/pre-commit-hooks: JSON/YAML validation, end-of-file-fixer, trailing-whitespace
- local hooks: SKILL.md frontmatter validation

Uses pinned versions for reproducibility across environments. Includes auto-fixes from hook runs (formatting, trailing whitespace, JSON beautification).

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

docs/notes/skill-implementation-workflow.md

@@ -1,6 +1,6 @@
 # Skill Implementation Workflow
 
-**Produced by:** issue 0016 grill session, 2026-05-17  
+**Produced by:** issue 0016 grill session, 2026-05-17
 **Applies to:** all Chunk 3 skill issues (0017–0028)
 
 ---
@@ -84,7 +84,7 @@ This is not a full grill-with-docs session — it is focused and bounded. If the
 
 Work through the following in order, iterating with the human. Sub-agents handle writing tasks where context accumulation is a risk.
 
-**a. Trigger description**  
+**a. Trigger description**
 Write the `description:` frontmatter field first. Test it against three cases before writing the body:
 1. Explicit invocation — user says the trigger phrase directly
 2. Implicit invocation — user describes the task without the trigger phrase
@@ -92,7 +92,7 @@ Write the `description:` frontmatter field first. Test it against three cases be
 
 For each case, output an explicit **PASS** or **FAIL** result. Do not proceed to step b until all three show PASS. Including the description inside the section walk-through (step b) does not satisfy this gate — it must be a standalone test-then-proceed step with per-case verdicts. If any case fails, revise the description and re-test before continuing.
 
-**b. Per-section options walk-through**  
+**b. Per-section options walk-through**
 Before writing anything, walk through each body section with the human. For each section:
 - State what content is proposed and which upstream source it comes from
 - Present alternatives where upstream sources offered different approaches
@@ -100,24 +100,24 @@ Before writing anything, walk through each body section with the human. For each
 
 Do not write the SKILL.md until the human has confirmed every section. The synthesis grill decisions cover the eval schema and gating questions; this step covers how upstream content maps to each SKILL.md section. These are separate conversations — do not collapse them.
 
-**c. SKILL.md** (sub-agent)  
+**c. SKILL.md** (sub-agent)
 Once all sections are confirmed, spawn a write agent to produce the SKILL.md using `write-skill` (or hand-write for bootstrap skills). The agent receives: trigger description, per-section decisions from step b, upstream content to incorporate, authoring standard (see below).
 
-**c. META.md — `source:` and `references:` fields**  
+**c. META.md — `source:` and `references:` fields**
 Populate `META.md` after upstream review. Two distinct fields:
 - `source:` — upstream provenance tracking (repo slug, commit SHA, files adopted with inline comments, updated date). Present only if content was adopted. Absence = self-authored.
 - `references:` — general citations (research papers, documentation, standard specifications). Present only if the skill cites external research.
 
 Both fields live in `META.md` alongside the SKILL.md — not in frontmatter. See `META-TEMPLATE.md` in `.agents/skills/write-skill/` for the full schema.
 
-**d. eval.yaml** (sub-agent)  
+**d. eval.yaml** (sub-agent)
 Invoke `write-eval` in two steps to preserve its confirmation gate:
 1. Sub-agent proposes test cases and returns the plan to the main conversation.
 2. Human confirms the plan; then sub-agent writes the file.
 
 Do not pass pre-designed test cases directly to a write agent — that collapses the plan-then-confirm gate into a single step, bypassing write-eval's own constraint. Co-located at `.agents/evals/<category>/<skill-name>/eval.yaml`. Must contain all five required test types (see Eval schema below).
 
-**e. HITL behavioral test**  
+**e. HITL behavioral test**
 Human opens a fresh Claude session, invokes the skill with its trigger phrase, and verifies output. Do not batch more than 2–3 skills before running behavioral tests — output volume must stay within genuine human review capacity. An approval that cannot be meaningfully evaluated is not an approval.
 
 ### Step 6 — Session handoff
@@ -127,7 +127,7 @@ After the behavioral test passes, close the skill session by appending a `## Han
 ```markdown
 ## Handoff
 
-**Status:** complete  
+**Status:** complete
 **Files produced:**
 - `.agents/skills/<name>/SKILL.md`
 - `.agents/evals/<category>/<name>/eval.yaml`
@@ -193,7 +193,7 @@ When refactoring an existing Pocock placeholder skill:
 
 ## Eval schema
 
-**Location:** `.agents/evals/<category>/<skill-name>/eval.yaml` — committed to the repo.  
+**Location:** `.agents/evals/<category>/<skill-name>/eval.yaml` — committed to the repo.
 **Enforcement:** CI gates are Chunk 6. The files document expected behaviour before then.
 
 Every eval must contain all five required test types: