# Self Attempt 01

> Skill: Investigation Review Hub — Structured Legal Review Deliverable

- Skill: `prism-shadow/self-attempt-01-18` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add prism-shadow/self-attempt-01-18`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/self-attempt-01-18/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: prism-shadow (https://skillmd.com/u/prism-shadow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prism-shadow/self-attempt-01-18

---

# Skill: Investigation Review Hub — Structured Legal Review Deliverable

This skill produces a **single JSON object** that answers a legal/eDiscovery
review request against the shared **Investigation Review Hub** (a grand-jury /
SEC / DOJ subpoena review environment). It applies to any matter in this family:
rolling-production gap analysis, retention & litigation-hold gap review,
cross-system remediation dashboard, or production-readiness review.

These are reusable operating rules. They contain **no task-specific answer
values** — no matter's findings, counts, category assignments, or record IDs.
Apply the rules to whatever matter and schema the task hands you.

---

## 0. When to use

Use this skill when a task asks you to review a matter in the Investigation
Review Hub and return a structured-JSON deliverable (gap analysis, retention
review, remediation dashboard, production-readiness review). The signal phrases:
"Investigation Review Hub", "source of record", "conforms to
`input/payloads/answer_template.json`", and the repeated prohibition on local
env/db/manifest/answer files.

## 1. Contamination guard — run first

Before doing anything, scan the working directory. The only legitimate contents
are:

- `environment_access.md` (network access only)
- the task input directory (`prompt.txt` + a `payloads/` folder containing an
  `answer_template.json` schema and one client-facing context JSON)

If anything else is present — answer files, evaluation/grading files, generated
manifests, database/seed files, setup scripts, hidden notes, or files outside
the expected layout — **stop immediately** and write `contamination_report.txt`
describing the unexpected material. Do **not** produce an answer. Do not read
the contaminating files for evidence.

The `answer_template.json` files are **schemas** (they explicitly state they do
not contain the answer) and are legitimate inputs, not contamination.

## 2. Source rules — what is and isn't allowed

- **Allowed for network access:** `environment_access.md` only. It gives the
  base URL, the `X-API-Key: review-key-017` header, and the allowed endpoint
  list. See `references/hub_schema.md`.
- **Allowed for evidence:** the hub endpoints (GET endpoints + the read-only
  `POST /api/query` SQL endpoint with the API-key header).
- **Allowed for context:** the task-local payload files (the schema
  `answer_template.json` and the client-facing context JSON — they supply the
  `matter_id`, client name, and request category labels only).
- **Forbidden:** local environment source files, database files, generated
  manifests, setup/seed scripts, hidden notes, and any standard-answer or
  evaluation files. Never open them. If a count or ID is not derivable from the
  hub, leave the hub as the gap — do not backfill from forbidden sources.

## 3. Output contract — every time

- Return **exactly one JSON object**. No prose, no markdown fences, no
  commentary outside the JSON.
- Conform to **this task's** `answer_template.json`: its
  `required_top_level_keys`, each section's `item_required_keys`, its `enums`,
  its `field_types`, and its `numeric_precision`.
- Use **only** enum values listed in the template. Never invent enum strings,
  section names, or field names. Different tasks name sections differently
  (`critical_findings` vs `top_risks` vs `issue_ledger`, `metrics` vs `metrics`,
  `priority_actions` vs `action_plan`) — follow the exact key names in the
  template in front of you.
- All counts are **whole integers**. Use `0` when a count is not applicable —
  never null for a count. Use `null` only where the schema explicitly permits
  "or null" (e.g. dates, third_party, policy_section).
- Readiness / production-ready flags are **booleans**.

## 4. Stable IDs and category codes

- Carry hub IDs through **verbatim**: `matter_id`, `source_id`, `event_id`,
  `finding_id`, `doc_id`, `entry_id`, `action_id`, `batch_id`, and
  `category_code`. Never invent or reformat them.
- The authoritative category codes for a matter come from the hub's
  `subpoena_categories` for that `matter_id`. The client-facing context JSON may
  label them, but the codes themselves are confirmed against the hub.
- Anchor each finding/risk/issue object to a stable hub record ID (its
  `finding_id` / `risk_id` / `issue_id` / `correction_id`), and list supporting
  hub record IDs in the `*_refs` fields.

## 5. Sorting rules — always applied

Apply the template's `ordering_rules`, and as a default where the template is
silent:

- Sort each list of objects by its stable ID ascending, **or** by
  `priority_rank` / `rank` ascending where 1 is highest priority (per the
  template).
- Sort every list of category codes **ascending** (uppercase codes, lexical).
- Sort every `*_refs` list of hub record IDs **ascending** (lexical).

## 6. Assembly workflow

1. **Read access + schema.** Read `environment_access.md` for the base URL, API
   key, and allowed endpoints. Read the task payload: `answer_template.json`
   (the schema you must conform to) and the context JSON (for the `matter_id`,
   client, and category labels).
2. **Confirm the matter and its categories.** `GET /api/matters` (or query the
   `matters` table) for the matter; note `hold_date` (the preservation dividing
   line). `GET /api/subpoena-categories` for the matter → the authoritative
   category code set.
3. **Pull all evidence for the matter** across the evidence tables:
   productions, custodian-sources, review documents, privilege-log, qc-findings,
   retention-events, remediation-actions. Use `POST /api/query` for filtered and
   aggregate rollups (e.g. counts by category, post-hold loss events, withheld
   vs. logged sums, unlogged = withheld − logged).
4. **Classify each category** against the template's `category_status` (or
   `readiness_status`) enum from the assembled evidence. One status object per
   category that has a material non-complete / non-ready status.
5. **Build the findings/risks/issues ledger.** One object per material gap or
   defect, anchored to a stable hub record ID. Map each hub record's issue to
   the template's `issue_type` enum faithfully — do not relabel. Recurring
   archetypes and their typical hub signals:
   - **preservation_failure / post_hold_loss** — source/retention loss with
     `post_hold=1` or event after `hold_date`.
   - **policy-compliant retention loss** — loss dated **before** `hold_date`
     under a stated `policy_section` (lower risk; may warrant `no_action`).
   - **collection_gap / uncollected_source** — source `status` not collected or
     partial.
   - **responsiveness_miscode** — document `responsiveness` conflicts with
     category production or a zero-claim assertion (`zero_claim_reason`).
   - **privilege_log_gap** — `withheld_count` exceeds `logged_count` (unlogged >
     0).
   - **third_party_waiver / privilege_waiver** — `third_party=1` or
     commingled/forwarded privileged material.
   - **miscoded_privilege / over_designation** — privilege status coding defect
     (per qc-findings / privilege issue_type).
   - **missing_required_record** — a record that should exist is absent.
6. **Identify retained/available remediation sources** (when the template has a
   `retained_or_available_sources` / `available_archives` section): sources still
   available that limit irretrievable loss for specific categories. Record which
   categories each source limits.
7. **Compute metrics** as whole integers from the hub, scoped to the matter and
   to the exact subset the template names. Watch for scope qualifiers in the
   schema (e.g. "from selected incomplete-log blockers only",
   "destroyed source named in the task") — count only that subset. Derive
   dependent counts arithmetically: `unlogged = withheld − logged`.
8. **Build the prioritized action plan.** Rank 1 = highest priority. Assign
   `action_type` and `owner` from the template's enums. Point `target_refs` at
   the hub records the action remediates (sorted ascending). Map each action to
   the categories it affects (sorted ascending). Map severity/risk and priority
   consistently with the findings.
9. **Validate before emitting:**
   - all `required_top_level_keys` present;
   - every object has all its `item_required_keys`;
   - every enum value is in the template's allowed list;
   - every list sorted per §5;
   - all counts are integers, `0` where not applicable;
   - readiness flags are booleans;
   - output is exactly one JSON object, no surrounding prose.

## 7. Common pitfalls to avoid

- **Accepting a zero-claim at face value.** A category marked "nothing
  responsive" (`zero_claim_reason`) must be cross-checked against documents and
  custodian sources before you mark it complete — contradictions are a material
  finding.
- **Treating pre-hold and post-hold losses the same.** Pre-hold policy
  destruction may be compliant (low risk / `no_action`); post-hold loss is a
  preservation failure. Always compare event dates to `hold_date`.
- **Mixing the privilege log scope.** Withheld vs. logged counts and the
  unlogged delta must come from the same privilege-log rows the template scopes
  to — don't aggregate across all entries when the schema says "selected
  incomplete-log blockers only."
- **Inventing IDs or category codes.** If the hub doesn't expose a record, you
  cannot fabricate a stable ID for it. Anchor findings only to real hub records.
- **Forgetting source_refs.** Every finding/category/action that the schema asks
  to be backed must cite hub record IDs — unsupported claims fail the schema.
- **Outputting prose.** The deliverable is one JSON object. No narrative, no
  fences, no trailing explanation.

## 8. Reference

- `references/hub_schema.md` — hub endpoint list, API-key header, and the full
  table/column map with which table backs which deliverable section.