Mediation Problem Generator

Mediation Problem Generator

Create original, competition-ready commercial mediation materials. Treat internal consistency, balanced difficulty, and a narrow but workable settlement corridor as design requirements rather than cleanup tasks.

Load the Required Guidance

Read all four references before drafting:

• resources/case-model-schema.md for the author-only source of truth.
• resources/design-grammar.md for problem construction and originality rules.
• resources/packet-templates.md for the public and confidential packet structures.
• resources/semantic-audit.md for balance, feasibility, and exit criteria.

Before promising outputs, confirm that the host can read and write local files. Python 3 is recommended for the bundled deterministic checks. If Python is unavailable, perform the manual fallbacks described below and state in the delivery summary which scripts were not run.

Select the Entry Route

Route A - Sparse Prompt to Full Package

Use when the user supplies a topic area, industry, relationship, dispute seed, or short sketch.

Produce by default:

1. case-model.json - author-only; never distribute to participants.
2. general-information.md - available to both parties.
3. confidential-information-party-a.md.
4. confidential-information-party-b.md.
5. validation-report.md - author-only.
6. clarification-risk.md - author-only.

Make reasonable creative assumptions. Ask a question only when a missing choice would materially change the exercise and guessing would create a substantial risk of divergence. Otherwise state the assumptions in the author-only model and continue.

Route B - General Packet to Confidential Packets

Use when the user provides a general packet in PDF, DOCX, Markdown, or text.

1. Extract and inspect the complete packet using whatever document-reading capability the host provides. If the host cannot reliably read the format, ask the user for extracted text or a supported conversion; do not claim to have inspected content that was unavailable.
2. Reconstruct all public facts in case-model.json without changing them.
3. Design the hidden settlement architecture for both sides together.
4. Generate both confidential packets by default.
5. If the user requests one named side only, deliver only that packet, but still design both sides' private constraints and the full settlement corridor in the author-only model. Do not generate or expose the unrequested packet.

Never repair, contradict, or silently supplement a supplied public fact in a distributed packet. Record defects or necessary assumptions in validation-report.md and, if material, ask the user before finalizing.

Build the Canonical Model First

Never draft the distributed packets independently. Create case-model.json first and record:

• objective public facts and chronology;
• party identities, roles, authority, and relationships;
• claims, defenses, and deliberately unresolved legal questions;
• financial data and calculation rules;
• each side's positions, interests, constraints, targets, reservation conditions, BATNA, and WATNA;
• fact visibility and epistemic status;
• protected interests that cannot simply be traded away;
• cross-trades, contingent terms, implementation mechanisms, and candidate packages;
• the intended settlement corridor and its failure boundaries.

Classify every material fact as objective, belief, allegation, legal_uncertainty, or deliberate_ambiguity. Classify visibility as public, party:<party-id>, shared_private, or author_only.

Use <skill-dir>/scripts/scaffold_case_model.py to create a starting model when useful. Resolve <skill-dir> to this skill's directory. Validate the model with <skill-dir>/scripts/validate_case_model.py after every material revision.

Design a Narrow but Sound Settlement Corridor

Require all of the following:

• At least two and ordinarily no more than four materially different sound packages.
• No sound package that merely splits the public monetary positions without using confidential information.
• At least two linked concessions in each sound package.
• At least one value-creating, non-cash, contingent, relational, informational, or implementation term.
• A credible reason each party prefers settlement to its BATNA.
• A protected interest or hard constraint for each party.
• Enough overlap for agreement, but not enough for an obvious or costless agreement.
• No package that requires a party to promise money, authority, rights, performance, or information it does not possess.

Reject designs that are impossible, depend on one brittle hidden solution, make one side dominant on every dimension, or reveal the complete bargain merely by reading either confidential packet.

Draft the Packets

Generate the public packet only from public fields in the model. Provide enough commercial, legal, financial, and relational context to make the dispute understandable without disclosing reservation values or intended trades.

Generate each confidential packet only from:

• the public model;
• that party's private facts;
• facts the party could reasonably know;
• its beliefs and allegations clearly labeled as such.

Write each packet in second person unless the user requests another convention. Give each side realistic internal tensions, priorities, and authority. Do not tell a party the other side's secret or prescribe a single settlement script.

Do not give both packets parallel menus of the same candidate packages. If one party has internally considered a direction, describe only that party's partial concept and the dependencies it cannot resolve alone. Present tradeable ingredients and constraints asymmetrically; leave package assembly to the mediation.

Follow resources/packet-templates.md. Preserve a supplied packet's style and naming conventions when using Route B.

Run the Iterative Validation Loop

Repeat this cycle:

1. Validate case-model.json with:

   python3 <skill-dir>/scripts/validate_case_model.py <case-model.json>

2. Run the information-firewall check after drafting:

   python3 <skill-dir>/scripts/check_information_firewall.py <case-model.json> <general.md> --party-a <party-a.md> --party-b <party-b.md>

   When Route B produces one side only, supply only the corresponding --party-a or --party-b option.

3. Apply every semantic audit in resources/semantic-audit.md.

4. Record defects by severity in validation-report.md.

5. Revise the canonical model, not an isolated packet.

6. Regenerate every affected packet.

7. Repeat until the exit criteria pass.

Treat deterministic scripts as minimum checks. They do not replace semantic review.

Manual fallback when Python is unavailable

Before delivery, manually verify the required top-level model fields, exactly two parties, visibility and epistemic-status labels, required private-case fields, two to four candidate packages, calculations and payment totals, the narrow-window settings, and the last two audit iterations. Compare each distributed packet against the model's visibility labels for possible leaks. Record that the manual fallback was used; never describe it as equivalent to running the scripts.