submission-planner

Plan a detailed submission BEFORE drafting — issues → propositions → verified authorities per proposition → application mapping, with a verification gate and a fact/argument register plan. Use when asked to draft, outline, or plan a court submission, skeleton argument, note of argument, memorial, response, or adjudication pleading, or to restructure an existing draft around a plan. Pairs with draft-augmenter (post-draft augmentation) and the register skills (during drafting).

Source: .opencode/skills/submission-planner/SKILL.md — site rebuilt 2026-09-05.

submission-planner¶

Plan-gate skill for detailed submissions. The lesson behind it: verification belongs BEFORE prose. Every proposition is assigned its authorities and checked before a single paragraph is drafted; anything that cannot be verified is flagged for human decision, never assumed.

Produces PLAN_<ref>_<date>.md in the matter folder as the approval gate. Drafting starts only after the plan is signed off.

When to use¶

Court submissions, skeleton arguments, notes of argument, memorials, referral notices/responses, adjudication pleadings — anything structured, detailed and authority-heavy.
Restructuring an existing draft around a verified plan.
NOT for letters or short advice — a plan is still useful but the full gate is overkill.

Workflow (phases 0–4)¶

Phase 0 — Instructions. Read the instructing material (pleadings, referral, questions, judgment, client instructions, evidence bundle). List the DISPOSITIVE issues — the points that decide the matter. Everything else is context and is excluded from the plan unless a proposition needs it.

Phase 1 — Issue tree. Issues → sub-issues → propositions. One proposition per future paragraph; each must be a single assertable sentence. Reject compound propositions (split them) and propositions that smuggle in two authorities.

Phase 1.5 — Graph consultation (knowledge-graph map of the corpus). Before building the authority map, query the corpus knowledge graphs (graphify query "<question>" with --graph <corpus>/graphify-out/graph.json, interpreter cached in the corpus's graphify-out/.graphify_python) for each proposition's subject: which authorities the corpus holds, their pinned locations (loc fields), and cross-document connections. Use the graph as a MAP of the corpus — it tells you what is in-tree and where; it is NOT itself authority. Every pinpoint the graph suggests is still verified against the text in Phase 3.

Phase 2 — Authority map. For every proposition assign, in the plan: - primary authority, with CONFIRMED paragraph pinpoint + verbatim chunk (case-law skill standards: pinpoint + context verified before reliance); - persuasive support (FTT/GRC, English and other foreign decisions) marked "persuasive only"; - statutory text verified against legislation.gov.uk, EXTENT CHECKED (E+W vs S — e.g. Care Act 2014 s.42 is England & Wales only; the Scottish analogue governs here); - factual support from the matter corpus (document + page/para reference), cited to the Inventory of Productions (e.g. "Third Inventory, pp.724–779") wherever the document is exhibited — a Facts row without a production citation is incomplete.

No pinpoint confirmed → the row is [UNVERIFIED], never silent.

Phase 3 — Verification gate. Run the verification pass over the whole map: cite, pinpoint, verbatim chunk, status per row. Unverified rows remain in the plan, flagged, for human decision. The draft inherits the [UNVERIFIED] convention: a marked claim may be drafted only if the user accepts it at the gate. Verification is of PROPOSITIONS, not pinpoints: read the holding paras verbatim and distinguish holdings from recorded submissions and counsel's arguments quoted in judgments (Johnston [13] was the IC's submission, holding at [27]; YSL 85 a strike-out ground, holding at [234]/[238]); check the case's outcome and which limbs succeeded (AB v BTP [90]–[94]: award upheld on the Art 8 ground, the accuracy limb having failed). A correct pinpoint can carry a wrong proposition — case-law skill, lesson 2026-08-12.

Phase 3.5 — Fact-check gate (mandatory, before drafting and before the draft is shown). Every factual claim, quoted concession and attribution in the plan's Fact rows and in the draft is audited by the fact-checker subagent (.opencode/agent/fact-checker.md) against the source documents — who said it, which document and date, verbatim text, context/status (concession vs characterization vs submission vs holding), and whether the proposition follows. Nothing is shown with a FAIL verdict. Worked example (2026-08-12): "records as a narrative fact" was drafted as a defender concession; it is the PURSUER's characterization in his 15 January 2026 letter, the defender's own response asserting only that the letter "reflected information reported to me at the time and my contemporaneous professional impressions" — the draft was corrected and the skill updated.

Phase 4 — Structure + register. Skeleton sections mirroring the issue tree; every paragraph numbered with its proposition; every passage tagged FACT or ARGUMENT so the right register skill applies during drafting; Scots applicability checked per proposition; persuasive-only authorities marked in the skeleton. Every FACT passage carries its production citation in the skeleton ("Third Inventory, pp.724–779") — the fact register is written with the inventories open, not after.

Deliverable¶

Approval gate: no prose drafting until the plan is signed off; any [UNVERIFIED] rows the user accepts are recorded in the plan BEFORE drafting.

Hard rules¶

No proposition without a source row; the draft must never contain an authority the plan does not.
Never fabricate pinpoints, citations or statutory extents.
Register is planned, not mixed: each passage is FACT or ARGUMENT before it is written.
Never guess figures or facts — [CONFLICT]/[LOW CONFIDENCE] residuals stay for human decision.

Self-learning¶

Append lessons (what the gate caught, what slipped through, what made plans useful or useless) to learnings.md.