Add prompt for collecting data on Theory of Requirement Facts in civil litigation

docs/workflows/knowledge-work.md

@@ -0,0 +1,68 @@
+# Knowledge-Work Workflow
+
+## 1. Frame the task
+
+Record:
+- the exact question or decision;
+- audience and intended use;
+- scope, jurisdictions, industries, entities, and time period;
+- cutoff date for current information;
+- required deliverables and level of detail;
+- material assumptions and exclusions.
+
+## 2. Build the source hierarchy
+
+Default priority:
+1. primary documents, official data, statutes, regulations, judgments, filings, contracts, and original research;
+2. high-quality institutional or peer-reviewed analysis;
+3. reputable secondary reporting;
+4. commentary and discovery sources.
+
+Use lower-tier material to locate or contextualize higher-tier evidence. Do not use it to overrule primary evidence without explanation.
+
+## 3. Retrieve and verify
+
+For each material source:
+- verify title, author or institution, date, version, and relevant scope;
+- inspect the underlying text, table, appendix, or data—not only a snippet or abstract;
+- capture the smallest locator that supports the proposition;
+- note limitations, conflicts, and whether the source is current enough.
+
+## 4. Maintain a claim-evidence matrix
+
+| Material claim | Evidence | Source quality | Counterevidence | Status |
+|---|---|---|---|---|
+| ... | ... | Primary/Secondary | ... | Verified/Qualified/Unverified |
+
+Do not draft a confident synthesis while decisive claims remain unmapped.
+
+## 5. Analyze
+
+Separate:
+- descriptive facts;
+- causal claims and identification assumptions;
+- legal or institutional interpretation;
+- the source author's conclusion;
+- the agent's critique;
+- the agent's proposal.
+
+For quantitative claims, check definitions, units, denominators, sample construction, timing, missingness, and comparability.
+
+## 6. Adversarial review
+
+Before finalizing:
+- search for disconfirming evidence;
+- identify alternative explanations;
+- check whether sources are independent or merely repeat one another;
+- test whether the conclusion depends on a single fragile assumption;
+- identify what evidence would reverse the conclusion.
+
+## 7. Deliver
+
+Lead with the conclusion and decision relevance. Then provide:
+- scope and method;
+- evidence-backed findings;
+- disagreements and counterevidence;
+- assumptions and limitations;
+- implications or recommendations;
+- a clear separation between verified findings and original inference.

docs/workflows/legal-analysis-ko.md

@@ -0,0 +1,113 @@
+# Legal Analysis Workflow — Republic of Korea Focus
+
+Apply this workflow to Korean-law tasks unless the task specifies another jurisdiction. For another jurisdiction, adapt the authority hierarchy and precedent rules explicitly.
+
+## 1. Intake and legal frame
+
+Identify before concluding:
+- governing jurisdiction;
+- legally relevant date or period;
+- procedural posture and tribunal;
+- parties and legal relationships;
+- requested remedy or decision;
+- stipulated, alleged, disputed, and missing facts;
+- applicable burdens, presumptions, and standards of review or proof.
+
+If one of these is outcome-determinative and absent, ask or branch the analysis.
+
+## 2. Issue decomposition
+
+Create an issue tree that distinguishes:
+- claim or legal basis;
+- constituent elements;
+- defenses, exceptions, exclusions, and limitation periods;
+- procedural prerequisites;
+- remedy, causation, damages, and enforcement questions;
+- constitutional, statutory, regulatory, administrative, and private-law interactions.
+
+Do not skip directly from a broad doctrine to a conclusion.
+
+## 3. Authority hierarchy and temporal validity
+
+For Korean law, ordinarily examine as applicable:
+- Constitution;
+- statutes;
+- presidential decrees;
+- ordinances of the Prime Minister or ministries;
+- local ordinances and rules;
+- administrative rules, notices, guidelines, and interpretations;
+- Constitutional Court and court decisions;
+- authoritative legislative history and official materials;
+- secondary commentary.
+
+For every material provision:
+- verify the text effective on the relevant date;
+- check promulgation and effective dates;
+- check amendment history, supplementary provisions, transitional rules, exceptions, and delegated legislation;
+- distinguish legal binding force from interpretive or practical weight.
+
+For decisions:
+- verify court, case number, decision date, type of disposition, and procedural posture;
+- read the operative reasoning or full text when available;
+- distinguish the actual holding from official summaries, headnotes, dicta, later commentary, and factual description;
+- identify later decisions that affirm, narrow, distinguish, criticize, or supersede the proposition;
+- characterize Korean precedent by its institutional and practical authority rather than mechanically importing common-law stare decisis terminology.
+
+## 4. Element-by-element application
+
+Use a matrix:
+
+| Issue/Element | Governing rule | Supporting facts | Opposing facts | Missing facts | Counterargument | Preliminary conclusion |
+|---|---|---|---|---|---|---|
+| ... | ... | ... | ... | ... | ... | ... |
+
+For each element:
+- state the rule precisely;
+- identify the authority and its temporal applicability;
+- apply both favorable and unfavorable facts;
+- identify evidentiary or pleading gaps;
+- explain whether the result is rule-driven or fact-sensitive.
+
+## 5. Adverse review
+
+Actively test:
+- competing characterization of the transaction or conduct;
+- contrary statutory interpretation;
+- adverse or limiting decisions;
+- procedural bars, standing, jurisdiction, limitation, exhaustion, or burden failures;
+- remedy mismatch;
+- factual scenarios under which the conclusion reverses.
+
+If an adverse point cannot be resolved, preserve it as residual uncertainty rather than burying it.
+
+## 6. Citation integrity
+
+Never fabricate a case number, quotation, statutory text, or administrative interpretation.
+
+A legal authority entry should include, when available:
+- issuing body or court;
+- date;
+- case number or official identifier;
+- relevant provision or paragraph;
+- exact proposition supported;
+- authority weight;
+- verification status.
+
+Memory may suggest a search lead. It may not serve as decisive authority in a final legal conclusion.
+
+## 7. Output structure
+
+Unless another form is requested:
+
+1. Executive conclusion.
+2. Scope, assumptions, and legally relevant date.
+3. Facts and unresolved factual disputes.
+4. Issues presented.
+5. Governing law and authority hierarchy.
+6. Element-by-element application.
+7. Adverse authority and counterarguments.
+8. Remedy and procedural considerations.
+9. Conclusion by issue, with confidence and reversal conditions.
+10. Verification record and sources requiring human confirmation.
+
+Treat the result as a professional draft requiring review against the complete record and current official authorities.

docs/workflows/python-work.md

@@ -0,0 +1,61 @@
+# Python and Quantitative Work Workflow
+
+## 1. Inspect before changing
+
+Determine:
+- Python version and execution environment;
+- package manager and lockfile;
+- existing dependencies, style, tests, and entry points;
+- data schema, units, keys, time indexes, missing values, and expected outputs;
+- whether the task is exploratory, production, or evidentiary.
+
+Do not replace the project's toolchain without a task-specific reason.
+
+## 2. Design the smallest adequate solution
+
+Prefer:
+- existing dependencies before new dependencies;
+- small functions with explicit inputs and outputs;
+- `pathlib` for paths;
+- type hints for nontrivial interfaces;
+- deterministic random seeds;
+- clear units, index conventions, and numerical tolerances;
+- scripts or modules as the reproducible source of truth, even when a notebook is used for exploration.
+
+Avoid hidden global state, silent data coercion, and unrelated refactoring.
+
+## 3. Protect data and secrets
+
+- Treat raw data as immutable.
+- Write intermediate and final results to designated derived-data or artifact paths.
+- Never print, commit, or transmit secrets.
+- Confirm before accessing external systems, installing production dependencies, or performing costly computation.
+- Record material transformations and exclusions.
+
+## 4. Validate
+
+Select checks proportionate to the task:
+- syntax/import check;
+- targeted unit tests;
+- smoke test on a small sample;
+- edge cases and failure paths;
+- schema, uniqueness, merge, and index-alignment checks;
+- missing-value and outlier checks;
+- unit and dimensional consistency;
+- tolerance-based numerical assertions;
+- independent formula or implementation;
+- benchmark or regression test against a known result;
+- look-ahead, survivorship, leakage, and timing checks for empirical finance or econometrics.
+
+## 5. Report
+
+State:
+- files changed;
+- commands actually run;
+- tests and numerical checks;
+- results;
+- data or environment assumptions;
+- warnings, failures, and untested branches;
+- reproduction steps.
+
+Never convert an unexecuted suggestion into a claim that the code works.