feat: 10 new skills scouted from spec-kit and deepseek-harness

Sourced via Codex scan of github/spec-kit and deepseek-ai/deepseek-harness
(scan reports in granja/_temp/codex-logs/), then authored by Codex against
this repo's exact SKILL.md format/density, calibrated against
bastille-jail-provisioning/writing-implementation-plans/tdd. Spot-checked
two directly (write-feature-specification, harden-async-lifecycle-code) --
concrete, code-example-backed procedures, not generic advice.

From spec-kit: write-feature-specification, clarify-feature-specification,
audit-requirements-quality, analyze-spec-plan-task-consistency,
converge-implementation-to-spec.

From deepseek-harness: harden-async-lifecycle-code, test-real-entry-paths,
snapshot-agent-behavior, maintain-decision-records,
remove-reasoning-transcript-prose.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

skills/converge-implementation-to-spec/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: converge-implementation-to-spec
+description: Use when implementation exists and must be compared against its specification, plan, and task ledger to classify remaining intent gaps and append remediation work. Pairs with verification-before-completion but does not replace or duplicate its independent evidence checks.
+---
+
+# Converge Implementation to Specification
+
+Convergence answers “what specified intent is still not represented correctly in the codebase?” It is not a generic final verification pass. Use `verification-before-completion` separately to independently prove completion claims and test results after convergence work is implemented.
+
+## 1. Establish authoritative scope
+
+Read the complete specification, technical plan, current task ledger, and mandatory project principles. Refuse to infer a larger feature from nearby code or conversation history.
+
+Extract named file/component touch-points from the plan and tasks. Expand scope only through repository searches for the exact domain concepts and public interfaces named by the artifacts. Record why each additional file belongs.
+
+If code is sparse or absent, continue: specified obligations are `missing`, not an analysis failure.
+
+## 2. Build an intent inventory
+
+Create one row per:
+
+- functional requirement;
+- buildable success criterion;
+- user-story acceptance scenario;
+- binding plan decision;
+- mandatory project principle relevant to this feature;
+- existing task whose unchecked intent is not fully represented elsewhere.
+
+```text
+Intent key | Source | Obligation | Expected code surface | Evidence sought
+FR-008     | spec   | revoke active challenge | recovery service + public entry | state guard and observable outcome
+US1/AC2    | spec   | expired challenge cannot mutate credentials | validation path | negative path before mutation
+```
+
+Do not count a task checkbox as evidence. The ledger records intent and work history; code and observable tests show realization.
+
+## 3. Inspect implementation by intent
+
+For every row:
+
+1. locate the public entry path and relevant internal owner;
+2. read implementation, tests, migrations/configuration, and wiring;
+3. compare observable behavior and constraints with the source wording;
+4. record concrete evidence by file and symbol or section;
+5. create a finding only when intent is not fully represented.
+
+Classify each gap:
+
+- **missing:** no implementation exists;
+- **partial:** some path or case exists but the obligation is incomplete;
+- **incorrect:** implementation contradicts the intended behavior, constraint, or principle;
+- **obsolete:** code or a task represents intent that has been removed or superseded.
+
+Use `obsolete` for awareness and remediation, not as authorization to delete. First determine whether compatibility, migration, or historical data still depends on it.
+
+## 4. Assign severity
+
+- **CRITICAL:** violates a mandatory principle or makes baseline P1 behavior unsafe or impossible.
+- **HIGH:** missing/incorrect core requirement or acceptance scenario.
+- **MEDIUM:** partial secondary behavior, plan drift with material maintenance cost, or obsolete work of unclear consequence.
+- **LOW:** bounded polish gap or low-risk stale surface.
+
+Severity measures consequence, not estimated effort.
+
+## 5. Present findings before writing
+
+```markdown
+| ID | Gap | Severity | Source | Evidence | Remediation |
+|----|-----|----------|--------|----------|-------------|
+| F001 | partial | HIGH | US1/AC2 | `src/recovery.ts` rejects expiry after credential mutation | Move expiry guard before mutation and add a public-path regression test. |
+```
+
+Include counts of requirements, acceptance scenarios, plan decisions, and principles inspected, plus findings by gap and severity. Distinguish “no evidence found” from “evidence disproves intent.”
+
+## 6. Append concrete remediation tasks
+
+Do not rewrite settled spec/plan text and do not renumber or edit prior tasks. Append a new `Convergence` phase only when actionable findings exist.
+
+1. find the largest existing task number and phase number;
+2. create the next phase at the end;
+3. order CRITICAL, HIGH, MEDIUM, LOW;
+4. emit one independently completable task per finding;
+5. cite the source and gap class;
+6. name exact files/symbols when known and observable acceptance evidence.
+
+```markdown
+## Phase 7: Convergence
+
+- [ ] T042 **CRITICAL** Enforce the project isolation principle in `src/jobs/dispatch.ts` and cover the public submission path; reject cross-tenant job IDs without reading their payload. (Principle II; incorrect)
+- [ ] T043 Move the expiry guard before credential mutation in `src/recovery.ts` and add a real-entry regression test for US1/AC2. (US1/AC2; partial)
+```
+
+For an obsolete surface, phrase the task as “review and justify, migrate, or remove,” with explicit compatibility checks. Do not prejudge deletion.
+
+Never add an empty convergence phase. If a prior convergence phase exists, append a newly numbered phase; its old checkboxes are history, not scratch space.
+
+## 7. Repeat until genuinely converged
+
+After remediation is implemented, rebuild the inventory from current artifacts and inspect again. Do not merely check whether appended tasks are marked done. A follow-up may expose a deeper partial or an obsolete workaround.
+
+Stop only when:
+
+- every inventory row has concrete implementation evidence;
+- no missing, partial, incorrect, or actionable obsolete finding remains;
+- no new out-of-scope behavior requires owner review;
+- task ledger has no unchecked convergence work;
+- mandatory principles are represented in code and appropriate tests.
+
+Then leave the ledger unchanged and report the counts inspected. Phrase the result as convergence against the defined artifact scope, not proof that the whole product is bug-free.
+
+## 8. Hand off to independent verification
+
+Run the repository’s relevant checks and actual entry paths under `verification-before-completion`. That skill owns the rule that test claims and delegate reports must be independently rechecked. This skill owns intent enumeration, semantic code comparison, gap classification, and remediation-ledger maintenance; do not duplicate generic “run tests and trust the output” guidance here.