Local Case Analysis — Word 批量读取 + AI 字段生成器

本质是本地判决书全文逐份读取后的多维度信息提取，而非单纯相似度排序。围绕律师提出的任意数量专题问题，逐案完成立场分类、全量证据拆解、相似/差异对比，最终生成问题横向矩阵 + 逐案完整底稿的双层研究底稿。

Default interaction rule

For WorkBuddy live demos, do not ask the lawyer to paste a long startup instruction. The skill itself should drive the task. Once triggered, collect missing inputs in one compact turn and then execute.

• If the user has already provided some inputs, do not ask for them again.
• Ask at most once for the remaining inputs.
• Prefer a compact collection block with these fields only:

- 本案案情 - 类案目录 - 输出目录 - 主检索问题 - 希望验证的观点 - 子问题（可选）

• After the lawyer replies, move directly into processing. Do not restate long rules unless an error occurs.

Confirm inputs first

Before running any script, ask the lawyer for:

1. Current case facts in natural language. Let the lawyer describe the current dispute, claims, defenses, evidence, and the point that needs verification directly in WorkBuddy. Do not require a current-case Word file in the default flow.
2. Cases directory.
3. Output directory.
4. One primary research question.
5. One target position to test. Define "support" and "oppose" relative to this sentence.
6. Zero or more topic questions. There is no upper limit — the lawyer may supply any number of research angles. Each additional question must be answered with case-specific analysis and quotes in every case result.

Do not infer the target position from party identity. If the inputs are complete, do not delay execution with extra confirmations.

Non-negotiable batch rule

Recursively read every .doc, .docx, and .txt file individually. Never sample, stop after the first N files, merge files, or infer content from filenames. Preserve one work item and one case card per supported file.

WorkBuddy workflow

1. Prepare all files, passing the confirmed question inputs:

python scripts/run_pipeline.py --case-text "<current case facts>" --cases-dir <cases-dir> --output <output-dir> --query "<primary question>" --position "<target position>" --subquery "<optional question>" --stage prepare

1. Open processing_manifest.json. Verify supported_file_count equals the number of case_work_items.
2. Read work_items/current_case.txt in full and create model_results/current_case.json using model-protocol.md (references/model-protocol.md).
3. Iterate through every case_work_item in manifest order. For each item:

- Read its complete text_path. - Compare it with the current case, primary question, target position, and subquestions. - Create exactly one model_results/cases/<source_id>.json using the protocol. - Copy exact court passages from that case text. Do not paraphrase quotations. Provide as many verbatim quotes as needed to ground every finding.

1. After every case result exists, create model_results/synthesis.json. For every lawyer question, provide a complete cross-case answer with a direct conclusion, legal basis found in the judgments, shared judicial views, typical exceptions, evidentiary boundaries, and supporting case IDs. Group cases by their structured primary position; do not reclassify them in synthesis.
2. Finalize in strict formal mode:

python scripts/run_pipeline.py --case-text "<current case facts>" --cases-dir <cases-dir> --output <output-dir> --query "<primary question>" --position "<target position>" --subquery "<optional question>" --stage finalize --model-results-dir <output-dir>/model_results

1. If finalization reports missing fields, invalid quotes, missing cases, or invalid synthesis references, fix only the listed model JSON files and rerun. Never bypass strict validation for a formal report. If a required model result is missing, the pipeline must fail instead of generating placeholder conclusions.

1. Return the five core outputs plus the manifest:

• current_case_analysis.json
• case_cards.json
• similar_cases.json
• legal_strategy_dashboard.html
• legal_strategy_report.docx
• processing_manifest.json

1. In a live demo, the preferred visible behavior is:

- One concise intake question if inputs are missing. - Then direct execution. - Then concise reporting of outputs or blocking errors. - Never expose internal fallback ideas, placeholder strategies, or long methodology speeches to the end user unless asked.

Analysis standard

For each case, state:

• Court, case number, year, judgment result, and core holding.
• Primary position: support, oppose, distinguish, or not_addressed.
• Relevance: high, medium, or low; keep numeric score in JSON only.
• Specific similarities and differences. Each item must show the current-case point, precedent point, source quote, and impact on transferability.
• All material evidence mentioned in the judgment. For every evidence item, extract: submitting party, purpose offered, court position (accepted/rejected/partially_accepted/unclear), court reason, and exact source quote. Never skip evidence items mentioned in the judgment. Use unclear when the judgment does not state an acceptance decision.
• Concrete favorable insights and adverse risks tied to the case facts and reasoning.
• Answers to every optional subquestion with supporting quotes.

Use 未识别 or 待人工核对 instead of invention. Distinguish allegations, facts found, and court reasoning.

Reports

Show all successfully parsed cases in both HTML and Word. Both are internal legal research drafts — completeness takes priority; do not truncate content to fit a page limit. Use a two-layer structure:

Layer 1 — Topic horizontal matrix: For every lawyer question (primary + all subquestions), compare all courts' answers side by side. Lead with a substantive cross-case conclusion, then legal basis, shared judicial views, and typical exceptions. Follow with a matrix table showing each case's position, answer, and source quote.

Layer 2 — Per-case full draft: For every case, display the complete record: facts (party claims, defenses, court-found facts), dispute focus, court viewpoint and reasoning, all evidence findings (table of submitting party / purpose / court position / reason / source quote), exact quotations, similarities, differences, favorable insights, adverse risks, and subquestion responses. Include the court in every summary and detail section. Generate trends, evidence suggestions, and strategy only from synthesis.json; never use domain-specific hardcoded prose.

Formal-only rule

This skill is formal-only for the competition build. Never generate placeholder conclusions, placeholder evidence findings, or placeholder synthesis text. If WorkBuddy has not produced the required per-case model JSON files, stop and report the missing artifacts instead of fabricating a report.

When reporting a block, use short production-style wording such as:

• 缺少 current_case.json，已停止生成正式报告。
• 缺少 3 份类案分析结果，已停止生成正式报告。
• 原文校验未通过，已停止生成正式报告。

Do not use wording such as 演示模式、占位、fallback、流程验证.

Environment

• Require Python 3.9+, python-docx, local file read, and code execution.
• .doc 优先使用 macOS textutil 预转 .txt；若失败再尝试 LibreOffice/soffice。两者都不可用时，应提示先手动预转为 .txt/.docx。
• Do not require network for the local pipeline; WorkBuddy model availability follows platform configuration.
• Do not process PDF, OCR, CSV, XLSX, or vector databases in this version.
• --case-file remains only as a legacy compatibility path; the competition flow should use --case-text.

For competition-facing wording, read competition-spec.md (references/competition-spec.md).