Lab meeting report

Research Group Meeting Markdown Reports

Create a real Markdown report grounded in the user's source material. Choose the output language in this order: follow an explicit language request, otherwise match the language of the user's request, and use English only when a genuinely mixed-language request is ambiguous. Preserve precise technical terms, model names, abbreviations, metric names, equations, citations, and identifiers in their source form.

Workflow

1. Collect sources

• Combine pasted context with user-specified files or directories.
• Prioritize .md, .txt, .pdf, .csv, .xlsx, and common raster images.
• For a large directory, list candidate files first and read only files relevant to the report. Exclude caches, archives, dependencies, and unrelated generated outputs.
• Use structured parsers for structured files when available. Inspect images when they carry experimental evidence.
• Record every source used. Record unreadable or skipped sources and continue with the remaining material.
• Do not search for additional literature unless the user explicitly requests it.

2. Build an evidence inventory

Extract only supported information:

• research objective and current hypothesis;
• experimental or implementation setup;
• results, metrics, figures, and observations;
• failed attempts, negative results, uncertainty, and blockers;
• paper metadata, question, method, findings, and limitations;
• decisions needed and next actions.

Keep facts, interpretations, and hypotheses distinct. When sources conflict, retain each value with its source and describe the conflict. Do not silently reconcile it.

<!-- E1 -->

Before drafting, build an internal evidence ledger for each decision-relevant claim. Record its source path, exact value and unit when numeric, evidence type (source fact, derived calculation, interpretation, or hypothesis), conflicts, and linked negative evidence. Preserve source identifiers exactly; do not assign sequence numbers, seed labels, run IDs, or priority ranks that the source did not supply. Use the ledger for control; do not add it to the final report unless it improves traceability.

<!-- E2 -->

Copy experimental numbers and units exactly from their sources. By default, do not introduce new deltas, percentages, averages, dispersion values, threshold margins, or other experimental numbers; state comparisons qualitatively instead. For a supplied threshold, say that the result exceeds, meets, or falls below it as appropriate without computing a margin. Calculate a new number only when the user explicitly requests it or a supplied source explicitly defines that calculation, then verify every operand and label the result as calculated rather than observed. Never invent a numeric estimate to fill a missing result, uncertainty, threshold, or significance value.

<!-- E3 -->

Create an internal must-retain list for failed experiments, negative results, blockers, uncertainty, and conflicting source values. Check every item against the draft; do not let repeated positive evidence or a smoother narrative displace it. When conflicting sources provide no authority or precedence rule, state explicitly that no authority rule was supplied and leave the result unresolved.

Never invent a result, value, citation, author, venue, DOI, URL, method, or causal explanation. Mark an essential unsupported field as 待补充. Mark unverified citation details as 未核验.

Optional Lark/Feishu sources

Read references/lark-integration.md whenever the user supplies a Lark/Feishu URL, token, chat, meeting, or Minute source, or asks to publish or synchronize the finished report to Lark. Read only resources the user explicitly places in scope. Keep identifiers and source provenance intact, and use user identity for all Lark operations.

3. Select one report mode

• Research progress: Use when the material primarily concerns the user's experiments, implementation, or project results. Read references/progress-report.md.
• Paper review: Use when the material primarily concerns one or more papers. Read references/paper-review.md.
• Mixed: Use when both evidence types are substantial or literature is used to interpret or plan current research. Read references/mixed-report.md.

If routing remains ambiguous, prefer mixed mode and keep current-work evidence separate from literature evidence. Ask one focused question only when the answer would materially change the report's conclusions or structure.

4. Draft the report

• Use the selected reference as the structure, not as text to copy mechanically.
• Treat Chinese headings in the reference templates as structural examples. Translate headings and labels into the selected report language while preserving their semantic order and evidence rules.
• Target roughly 3-5 rendered pages, shortening sparse reports and expanding only when evidence requires it.
• Put each conclusion next to its supporting evidence.
• Use Markdown tables for useful numeric comparisons.
• Use relative paths for figures. Add a figure caption, source, and one-sentence interpretation.
• If a referenced figure is missing, retain the intended caption and source note and flag the missing asset.
• Omit unsupported optional sections. Keep essential missing sections and label their gaps.
• Make next actions concrete: include the action, expected artifact, success criterion, and relevant dependency or risk.
• Avoid decorative filler, generic praise, and activity lists that imply unsupported conclusions.

5. Write safely to disk

<!-- E4 -->

Before editing an existing report, locate and read the authorized source report even when the requested destination does not yet exist. If the source copy is under the supplied input tree, use it as the merge base rather than reconstructing the report from only the new evidence. Inventory manual headings, unrecognized content, earlier evidence, and claims not explicitly superseded, and treat that inventory as protected content. Treat text encoding as protected content. Decode and encode Markdown and text sources with explicit UTF-8 rather than the operating system's default locale; on Windows PowerShell, use Get-Content -Encoding UTF8 or a strict UTF-8 .NET reader instead of default Get-Content. Before overwriting, decode the written report as UTF-8 and verify every protected string exactly; if any protected text changed or became mojibake, leave the original unchanged and write a revised file. Record supersession with both the earlier and replacement sources instead of erasing history.

Resolve the active project as the user's explicit project root when provided; otherwise use the current working directory. Create:

<active-project>/reports/group-meeting/YYYY-MM-DD.md

Use the current local date unless the user specifies a reporting date.

If the same-date file exists:

1. Read it before editing.
2. Merge new evidence into matching sections.
3. Preserve unrecognized headings and manually written content.
4. Do not remove an earlier claim unless the new source explicitly supersedes it; record the change when it does.
5. If a safe merge is ambiguous, write YYYY-MM-DD-revised.md and leave the original unchanged.

Create or edit the Markdown file with the platform's normal file-editing tool. Do not stop after printing an outline in chat.

6. Run the quality gate

<!-- E5 -->

Run a claim audit before completion: match every experimental number to a source fact or explicitly requested calculation, confirm every must-retain negative/conflict item is present, and relabel or remove causal, significance, bibliographic, or mechanism claims not supported by the supplied evidence. A heading, label, or negation cannot make an overstrong proposition evidence-safe; rewrite the sentence so uncertainty and attribution appear in the claim itself. State missing checks directly instead of repeating the unsupported conclusion to deny it. For a source that cannot be decoded or parsed reliably, report only that it was unreadable and that its contents remain unknown; do not characterize its fields, bytes, partial contents, or possible values.

Before finishing, verify:

• every key conclusion is traceable to an input source;
• facts, interpretations, and hypotheses are visibly distinct;
• failed experiments and negative results remain present;
• numeric values and citations match their sources;
• heading levels, tables, and relative image links are internally consistent;
• next actions include expected artifacts and success criteria;
• the report is understandable without the preceding chat;
• unresolved essential gaps are summarized for the user.

7. Publish to Lark when requested

Finish and validate the local Markdown file before any Lark write. Then follow references/lark-integration.md to create or safely append to a Lark cloud document, embed local images, verify the remote result, and write the verified URL back into the local report. A Lark failure must not invalidate the local file.

8. Report completion

Tell the user:

• the output file path;
• the selected report mode;
• the sources used;
• any skipped or unreadable sources;
• any essential gaps or conflicts that remain.
• when Lark was used, the verified remote URL and any partial synchronization failures.

Scope Boundaries

Do not generate PPTX, DOCX, or HTML through this skill. Do not recompute statistics by default, copy external assets automatically, maintain a long-term tracking database, scan all Lark resources, publish silently, switch to bot identity as a fallback, delete remote resources, or publish to services outside the explicit Lark integration request.