@bohuyeshan/openagent-labforge-core 3.11.2 → 3.11.4

package/generated/skills-bundles/full/skills/research/theory-writing/auto-claude__proof-writer/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: "auto-claude/proof-writer"
+description: "Writes rigorous mathematical proofs for ML/AI theory. Use when asked to prove a theorem, lemma, proposition, or corollary, fill in missing proof steps, formalize a proof sketch, 补全证明, 写证明, 证明某个命题, or determine whether a claimed proof can actually be completed under the stated assumptions."
+argument-hint: ["theorem-statement-and-assumptions"]
+allowed-tools: "Read, Write, Edit, Grep, Glob"
+metadata:
+  category: "research/theory-writing"
+---
+# Proof Write: Rigorous Theorem / Lemma Drafting
+
+Write a mathematically honest proof package, not a polished fake proof.
+
+## Constants
+
+- DEFAULT_PROOF_DOC = `PROOF_PACKAGE.md` in project root
+- STATUS = `PROVABLE AS STATED | PROVABLE AFTER WEAKENING / EXTRA ASSUMPTION | NOT CURRENTLY JUSTIFIED`
+
+## Context: $ARGUMENTS
+
+## Goal
+
+Produce exactly one of:
+1. a complete proof of the original claim
+2. a corrected claim plus a proof of the corrected claim
+3. a blockage report explaining why the claim is not currently justified
+
+## Inputs
+
+Extract and normalize:
+- exact theorem / lemma / proposition / corollary statement
+- explicit assumptions
+- notation and definitions
+- any user-provided proof sketch, partial proof, or intended strategy
+- nearby lemmas or claims in local notes, appendix files, or theorem drafts if the request points to them
+- desired output style if specified: concise, appendix-ready, or full-detail
+
+If notation or assumptions are ambiguous, state the exact interpretation you are using before proving anything.
+
+## Workflow
+
+### Step 1: Gather Proof Context
+Determine the target proof file with this priority:
+1. a file path explicitly specified by the user
+2. a proof draft already referenced in local notes or theorem files
+3. `PROOF_PACKAGE.md` in project root as the default target
+
+Read the relevant local context:
+- the chosen target proof file, if it already exists
+- theorem notes, appendix drafts, or files explicitly mentioned by the user
+
+Extract:
+- exact claim
+- assumptions
+- notation
+- proof sketch or partial proof
+- nearby lemmas that the draft may depend on
+
+### Step 2: Normalize the Claim
+Restate:
+- the exact claim being proved
+- all assumptions, separately from conclusions
+- all symbols used in the claim
+
+Identify:
+- hidden assumptions
+- undefined notation
+- scope ambiguities
+- whether the available sketch proves the full claim or only a weaker variant
+
+Preserve the user's original theorem statement unless a change is explicitly required.
+If you use a stronger normalization or cleaner internal formulation only to make the proof easier, keep that as an internal proof device rather than silently replacing the original claim.
+
+### Step 3: Feasibility Triage
+Before writing a proof, classify the claim into exactly one status:
+- `PROVABLE AS STATED`
+- `PROVABLE AFTER WEAKENING / EXTRA ASSUMPTION`
+- `NOT CURRENTLY JUSTIFIED`
+
+Check explicitly:
+- does the conclusion actually follow from the listed assumptions?
+- is any cited theorem being used outside its conditions?
+- is the claim stronger than what the available argument supports?
+- is there an obvious counterexample, boundary case, or quantifier failure?
+
+If the claim is not provable as stated, do NOT fabricate a proof.
+Do NOT silently strengthen assumptions or narrow the theorem's scope just to make the proof work.
+
+### Step 4: Build a Dependency Map
+Choose a proof strategy, for example:
+- direct
+- contradiction
+- induction
+- construction
+- reduction to a known result
+- coupling / probabilistic argument
+- optimization inequality chaining
+
+Then write a dependency map:
+- main claim
+- required intermediate lemmas
+- named theorems or inequalities that will be cited
+- which assumptions each nontrivial step depends on
+- boundary cases that must be handled separately
+
+If one step is substantial, isolate it as a lemma instead of burying it in one sentence.
+
+### Step 5: Write the Proof Document
+Write to the chosen target proof file.
+
+If the target proof file already exists:
+- read it first
+- update the relevant claim section
+- do not blindly duplicate prior content
+
+If the user does not specify a target, default to `PROOF_PACKAGE.md` in project root.
+
+Do NOT write directly into paper sections or appendix `.tex` files unless the user explicitly asks for that target.
+
+The proof package must include:
+- exact claim
+- explicit assumptions
+- proof status
+- announced strategy
+- dependency map
+- numbered major steps
+- justification for every nontrivial implication
+
+Mathematical rigor requirements:
+- never use "clearly", "obviously", "it can be shown", "by standard arguments", or "similarly" to hide a gap
+- define every constant and symbol before use
+- check quantifier order carefully
+- handle degenerate and boundary cases explicitly, or state why they are excluded
+- if invoking a standard fact, state its name and why its assumptions are satisfied here
+- use `$...$` for inline math and `$$...$$` for display equations
+- never write math in plain text
+- if the proof uses an equivalent normalization that is stronger in appearance than the user's original theorem statement, label it explicitly as a proof device and keep the original claim separate
+
+### Step 6: Final Verification
+Before finishing the target proof file, verify:
+- the theorem statement exactly matches what was actually shown
+- every assumption used is stated
+- every nontrivial implication is justified
+- every inequality direction is correct
+- every cited result is applicable under the stated assumptions
+- edge cases are handled or explicitly excluded
+- no hidden dependence on an unproved lemma remains
+
+If a key step still cannot be justified, downgrade the status and write a blockage report instead of forcing a proof.
+
+## Required File Structure
+
+Write the target proof file using this structure:
+
+```md
+# Proof Package
+
+## Claim
+[exact statement]
+
+## Status
+PROVABLE AS STATED / PROVABLE AFTER WEAKENING / NOT CURRENTLY JUSTIFIED
+
+## Assumptions
+- ...
+
+## Notation
+- ...
+
+## Proof Strategy
+[chosen approach and why]
+
+## Dependency Map
+1. Main claim depends on ...
+2. Lemma A depends on ...
+3. Step k uses ...
+
+## Proof
+Step 1. ...
+Step 2. ...
+...
+Therefore the claim follows. ∎
+
+## Corrections or Missing Assumptions
+- [only if needed]
+
+## Open Risks
+- [remaining fragile points, if any]
+```
+
+## Output Modes
+
+### If the claim is provable as stated
+Write the full file structure above with a complete proof.
+
+### If the original claim is too strong
+Write:
+- why the original statement is not justified
+- the corrected claim
+- the minimal extra assumption if one exists
+- a proof of the corrected claim
+
+### If the proof cannot be completed honestly
+Write:
+- `Status: NOT CURRENTLY JUSTIFIED`
+- the exact blocker: missing lemma, invalid implication, hidden assumption, or counterexample direction
+- what extra assumption, lemma, or derivation would be needed to finish the proof
+- a corrected weaker statement if one is available
+
+## Chat Response
+
+After writing the target proof file, respond briefly with:
+- status
+- whether the original claim survived unchanged
+- what file was updated
+
+## Key Rules
+
+- Never fabricate a missing proof step.
+- Prefer weakening the claim over overclaiming.
+- Separate assumptions, derived facts, heuristics, and conjectures.
+- Preserve the user's original theorem statement unless you explicitly mark a corrected claim or an internal normalization.
+- If the statement is false as written, say so explicitly and give a counterexample or repaired statement.
+- If uncertainty remains, mark it explicitly in `Open Risks`; do not hide it inside polished prose.
+- Correctness matters more than brevity.

package/generated/skills-bundles/paper/INDEX.md

@@ -2,12 +2,25 @@
 
 This file is generated. Skills are grouped by function for low-token preview before reading full instructions.
 
+## data-analysis / experiment-monitoring
+
+- `auto-claude/monitor-experiment` [auto-claude__monitor-experiment] — Monitor running experiments, check progress, collect results. Use when user says "check results", "is it done", "monitor", or wants experiment output. _(source: auto-claude)_
+
+## data-analysis / experiment-ops
+
+- `auto-claude/run-experiment` [auto-claude__run-experiment] — Deploy and run ML experiments on local or remote GPU servers. Use when user says "run experiment", "deploy to server", "跑实验", or needs to launch training jobs. _(source: auto-claude)_
+
 ## data-analysis / notebooks
 
 - `openai-curated/jupyter-notebook` [openai-curated__jupyter-notebook] — Use when the user asks to create, scaffold, or edit Jupyter notebooks (`.ipynb`) for experiments, explorations, or tutorials; prefer the bundled templates and run the helper script `new_notebook.py` to generate a clean starting notebook. _(source: openai-curated)_
 
+## data-analysis / optimization
+
+- `auto-claude/dse-loop` [auto-claude__dse-loop] — Autonomous design space exploration loop for computer architecture and EDA. Runs a program, analyzes results, tunes parameters, and iterates until objective is met or timeout. Use when user says \"DSE\", \"design space exploration\", \"sweep parameters\", \"optimize\", \"find best config\", or wants iterative parameter tuning. _(source: auto-claude)_
+
 ## data-analysis / statistics
 
+- `auto-claude/analyze-results` [auto-claude__analyze-results] — Analyze ML experiment results, compute statistics, generate comparison tables and insights. Use when user says "analyze results", "compare", or needs to interpret experimental data. _(source: auto-claude)_
 - `data-analysis` [builtin__data-analysis__data-analysis] — Statistical analysis workflow with reproducible outputs. _(source: builtin:data-analysis)_
 
 ## data-analysis / tabular-analysis
@@ -15,6 +28,10 @@ This file is generated. Skills are grouped by function for low-token preview bef
 - `openai-curated/spreadsheet` [openai-curated__spreadsheet] — Use when tasks involve creating, editing, analyzing, or formatting spreadsheets (`.xlsx`, `.csv`, `.tsv`) with formula-aware workflows, cached recalculation, and visual review. _(source: openai-curated)_
 - `xlsx-analyst` [builtin__xlsx-analyst__xlsx-analyst] — Analyze and format XLSX files with reproducible calculations. _(source: builtin:xlsx-analyst)_
 
+## data-analysis / visualization
+
+- `auto-claude/paper-figure` [auto-claude__paper-figure] — Generate publication-quality figures and tables from experiment results. Use when user says \"画图\", \"作图\", \"generate figures\", \"paper figures\", or needs plots for a paper. _(source: auto-claude)_
+
 ## engineering / app-integration
 
 - `openai-curated/chatgpt-apps` [openai-curated__chatgpt-apps] — Build, scaffold, refactor, and troubleshoot ChatGPT Apps SDK applications that combine an MCP server and widget UI. Use when Codex needs to design tools, register UI resources, wire the MCP Apps bridge or ChatGPT compatibility APIs, apply Apps SDK metadata or CSP or domain settings, or produce a docs-aligned project scaffold. Prefer a docs-first workflow by invoking the openai-docs skill or OpenAI developer docs MCP tools before generating code. _(source: openai-curated)_
@@ -85,12 +102,17 @@ This file is generated. Skills are grouped by function for low-token preview bef
 ## productivity / communication
 
 - `anthropic/internal-comms` [anthropic__internal-comms] — A set of resources to help me write all kinds of internal communications, using the formats that my company likes to use. Claude should use this skill whenever asked to write some sort of internal communications (status reports, leadership updates, 3P updates, company newsletters, FAQs, incident reports, project updates, etc.). _(source: anthropic)_
+- `auto-claude/feishu-notify` [auto-claude__feishu-notify] — Send notifications to Feishu/Lark. Internal utility used by other skills, or manually via /feishu-notify. Supports push-only (webhook) and interactive (bidirectional) modes. Use when user says \"发飞书\", \"notify feishu\", or other skills need to send status updates. _(source: auto-claude)_
 
 ## productivity / issue-tracking
 
 - `microsoft/github-issue-creator` [microsoft__github-issue-creator] — Convert raw notes, error logs, voice dictation, or screenshots into crisp GitHub-flavored markdown issue reports. Use when the user pastes bug info, error messages, or informal descriptions and wants a structured GitHub issue. Supports images/GIFs for visual evidence. _(source: microsoft)_
 - `openai-curated/linear` [openai-curated__linear] — Manage issues, projects & team workflows in Linear. Use when the user wants to read, create or updates tickets in Linear. _(source: openai-curated)_
 
+## productivity / visual-design
+
+- `auto-claude/pixel-art` [auto-claude__pixel-art] — Generate pixel art SVG illustrations for READMEs, docs, or slides. Use when user says "画像素图", "pixel art", "make an SVG illustration", "README hero image", or wants a cute visual. _(source: auto-claude)_
+
 ## research / api-documentation
 
 - `openai-curated/openai-docs` [openai-curated__openai-docs] — Use when the user asks how to build with OpenAI products or APIs and needs up-to-date official documentation with citations, help choosing the latest model for a use case, or explicit GPT-5.4 upgrade and prompt-upgrade guidance; prioritize OpenAI docs MCP tools, use bundled references only as helper context, and restrict any fallback browsing to official OpenAI domains. _(source: openai-curated)_
@@ -98,6 +120,10 @@ This file is generated. Skills are grouped by function for low-token preview bef
 
 ## research / document-authoring
 
+- `auto-claude/paper-compile` [auto-claude__paper-compile] — Compile LaTeX paper to PDF, fix errors, and verify output. Use when user says \"编译论文\", \"compile paper\", \"build PDF\", \"生成PDF\", or wants to compile LaTeX into a submission-ready PDF. _(source: auto-claude)_
+- `auto-claude/paper-plan` [auto-claude__paper-plan] — Generate a structured paper outline from review conclusions and experiment results. Use when user says \"写大纲\", \"paper outline\", \"plan the paper\", \"论文规划\", or wants to create a paper plan before writing. _(source: auto-claude)_
+- `auto-claude/paper-write` [auto-claude__paper-write] — Draft LaTeX paper section by section from an outline. Use when user says \"写论文\", \"write paper\", \"draft LaTeX\", \"开始写\", or wants to generate LaTeX content from a paper plan. _(source: auto-claude)_
+- `auto-claude/paper-writing` [auto-claude__paper-writing] — Workflow 3: Full paper writing pipeline. Orchestrates paper-plan → paper-figure → paper-write → paper-compile → ULTRAWORK QA to go from a narrative report to a polished, submission-ready PDF. Use when user says \"写论文全流程\", \"write paper pipeline\", \"从报告到PDF\", \"paper writing\", or wants the complete paper generation workflow. _(source: auto-claude)_
 - `docx-workbench` [builtin__docx-workbench__docx-workbench] — Create, edit, and review DOCX documents with reproducible formatting. _(source: builtin:docx-workbench)_
 - `openai-curated/doc` [openai-curated__doc] — Use when the task involves reading, creating, or editing `.docx` documents, especially when formatting or layout fidelity matters; prefer `python-docx` plus the bundled `scripts/render_docx.py` for visual checks. _(source: openai-curated)_
 - `openai-curated/pdf` [openai-curated__pdf] — Use when tasks involve reading, creating, or reviewing PDF files where rendering and layout matter; prefer visual checks by rendering pages (Poppler) and use Python tools such as `reportlab`, `pdfplumber`, and `pypdf` for generation and extraction. _(source: openai-curated)_
@@ -105,6 +131,9 @@ This file is generated. Skills are grouped by function for low-token preview bef
 
 ## research / literature-and-web-search
 
+- `auto-claude/arxiv` [auto-claude__arxiv] — Search, download, and summarize academic papers from arXiv using MCP tools. Use when user says "search arxiv", "download paper", "fetch arxiv", "arxiv search", "get paper pdf", or wants to find and save papers from arXiv to the local paper library. _(source: auto-claude)_
+- `auto-claude/novelty-check` [auto-claude__novelty-check] — Verify research idea novelty against recent literature. Use when user says "查新", "novelty check", "有没有人做过", "check novelty", or wants to verify a research idea is novel before implementing. _(source: auto-claude)_
+- `auto-claude/research-lit` [auto-claude__research-lit] — Search and analyze research papers, find related work, summarize key ideas. Use when user says "find papers", "related work", "literature review", "what does this paper say", or needs to understand academic papers. _(source: auto-claude)_
 - `web-research` [builtin__web-research__web-research] — Structured web research and source triage with citations. _(source: builtin:web-research)_
 
 ## research / media-transcription
@@ -115,3 +144,14 @@ This file is generated. Skills are grouped by function for low-token preview bef
 
 - `openai-curated/slides` [openai-curated__slides] — Create and edit presentation slide decks (`.pptx`) with PptxGenJS, bundled layout helpers, and render/validation utilities. Use when tasks involve building a new PowerPoint deck, recreating slides from screenshots/PDFs/reference decks, modifying slide content while preserving editable output, adding charts/diagrams/visuals, or diagnosing layout issues such as overflow, overlaps, and font substitution. _(source: openai-curated)_
 - `pptx-studio` [builtin__pptx-studio__pptx-studio] — Generate and edit PPTX decks with structured layouts. _(source: builtin:pptx-studio)_
+
+## research / research-ideation
+
+- `auto-claude/idea-creator` [auto-claude__idea-creator] — Generate and rank research ideas given a broad direction. Use when user says "找idea", "brainstorm ideas", "generate research ideas", "what can we work on", or wants to explore a research area for publishable directions. _(source: auto-claude)_
+- `auto-claude/idea-discovery` [auto-claude__idea-discovery] — Workflow 1: Full idea discovery pipeline. Orchestrates research-lit → idea-creator → novelty-check to go from a broad research direction to validated, pilot-tested ideas. Use when user says \"找idea全流程\", \"idea discovery pipeline\", \"从零开始找方向\", or wants the complete idea exploration workflow. _(source: auto-claude)_
+- `auto-claude/idea-discovery-robot` [auto-claude__idea-discovery-robot] — Workflow 1 adaptation for robotics and embodied AI. Orchestrates robotics-aware literature survey, idea generation, novelty check, and internal critique to go from a broad robotics direction to benchmark-grounded, simulation-first ideas. Use when user says \"robotics idea discovery\", \"机器人找idea\", \"embodied AI idea\", \"机器人方向探索\", \"sim2real 选题\", or wants ideas for manipulation, locomotion, navigation, drones, humanoids, or general robot learning. _(source: auto-claude)_
+- `auto-claude/research-pipeline` [auto-claude__research-pipeline] — Full research pipeline: Workflow 1 (idea discovery) → implementation → Workflow 2 (ULTRAWORK loop). Goes from a broad research direction all the way to a submission-ready paper. Use when user says \"全流程\", \"full pipeline\", \"从找idea到投稿\", \"end-to-end research\", or wants the complete autonomous research lifecycle. _(source: auto-claude)_
+
+## research / theory-writing
+
+- `auto-claude/proof-writer` [auto-claude__proof-writer] — Writes rigorous mathematical proofs for ML/AI theory. Use when asked to prove a theorem, lemma, proposition, or corollary, fill in missing proof steps, formalize a proof sketch, 补全证明, 写证明, 证明某个命题, or determine whether a claimed proof can actually be completed under the stated assumptions. _(source: auto-claude)_

package/generated/skills-bundles/paper/skills/data-analysis/experiment-monitoring/auto-claude__monitor-experiment/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: "auto-claude/monitor-experiment"
+description: "Monitor running experiments, check progress, collect results. Use when user says \"check results\", \"is it done\", \"monitor\", or wants experiment output."
+argument-hint: ["server-alias or screen-name"]
+allowed-tools: "Bash(ssh *), Bash(echo *), Read, Write, Edit"
+metadata:
+  category: "data-analysis/experiment-monitoring"
+---
+# Monitor Experiment Results
+
+Monitor: $ARGUMENTS
+
+## Workflow
+
+### Step 1: Check What's Running
+```bash
+ssh <server> "screen -ls"
+```
+
+### Step 2: Collect Output from Each Screen
+For each screen session, capture the last N lines:
+```bash
+ssh <server> "screen -S <name> -X hardcopy /tmp/screen_<name>.txt && tail -50 /tmp/screen_<name>.txt"
+```
+
+If hardcopy fails, check for log files or tee output.
+
+### Step 3: Check for JSON Result Files
+```bash
+ssh <server> "ls -lt <results_dir>/*.json 2>/dev/null | head -20"
+```
+
+If JSON results exist, fetch and parse them:
+```bash
+ssh <server> "cat <results_dir>/<latest>.json"
+```
+
+### Step 4: Summarize Results
+
+Present results in a comparison table:
+```
+| Experiment | Metric | Delta vs Baseline | Status |
+|-----------|--------|-------------------|--------|
+| Baseline  | X.XX   | —                 | done   |
+| Method A  | X.XX   | +Y.Y              | done   |
+```
+
+### Step 5: Interpret
+- Compare against known baselines
+- Flag unexpected results (negative delta, NaN, divergence)
+- Suggest next steps based on findings
+
+### Step 6: Feishu Notification (if configured)
+
+After results are collected, check `~/.claude/feishu.json`:
+- Send `experiment_done` notification: results summary table, delta vs baseline
+- If config absent or mode `"off"`: skip entirely (no-op)
+
+## Key Rules
+- Always show raw numbers before interpretation
+- Compare against the correct baseline (same config)
+- Note if experiments are still running (check progress bars, iteration counts)
+- If results look wrong, check training logs for errors before concluding

package/generated/skills-bundles/paper/skills/data-analysis/experiment-ops/auto-claude__run-experiment/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: "auto-claude/run-experiment"
+description: "Deploy and run ML experiments on local or remote GPU servers. Use when user says \"run experiment\", \"deploy to server\", \"跑实验\", or needs to launch training jobs."
+argument-hint: ["experiment-description"]
+allowed-tools: "Bash(*), Read, Grep, Glob, Edit, Write, Agent"
+metadata:
+  category: "data-analysis/experiment-ops"
+---
+# Run Experiment
+
+Deploy and run ML experiment: $ARGUMENTS
+
+## Workflow
+
+### Step 1: Detect Environment
+
+Read the project's `CLAUDE.md` to determine the experiment environment:
+
+- **Local GPU**: Look for local CUDA/MPS setup info
+- **Remote server**: Look for SSH alias, conda env, code directory
+
+If no server info is found in `CLAUDE.md`, ask the user.
+
+### Step 2: Pre-flight Check
+
+Check GPU availability on the target machine:
+
+**Remote:**
+```bash
+ssh <server> nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv,noheader
+```
+
+**Local:**
+```bash
+nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv,noheader
+# or for Mac MPS:
+python -c "import torch; print('MPS available:', torch.backends.mps.is_available())"
+```
+
+Free GPU = memory.used < 500 MiB.
+
+### Step 3: Sync Code (Remote Only)
+
+Only sync necessary files — NOT data, checkpoints, or large files:
+```bash
+rsync -avz --include='*.py' --exclude='*' <local_src>/ <server>:<remote_dst>/
+```
+
+### Step 4: Deploy
+
+#### Remote (via SSH + screen)
+
+For each experiment, create a dedicated screen session with GPU binding:
+```bash
+ssh <server> "screen -dmS <exp_name> bash -c '\
+  eval \"\$(<conda_path>/conda shell.bash hook)\" && \
+  conda activate <env> && \
+  CUDA_VISIBLE_DEVICES=<gpu_id> python <script> <args> 2>&1 | tee <log_file>'"
+```
+
+#### Local
+
+```bash
+# Linux with CUDA
+CUDA_VISIBLE_DEVICES=<gpu_id> python <script> <args> 2>&1 | tee <log_file>
+
+# Mac with MPS (PyTorch uses MPS automatically)
+python <script> <args> 2>&1 | tee <log_file>
+```
+
+For local long-running jobs, use `run_in_background: true` to keep the conversation responsive.
+
+### Step 5: Verify Launch
+
+**Remote:**
+```bash
+ssh <server> "screen -ls"
+```
+
+**Local:**
+Check process is running and GPU is allocated.
+
+### Step 6: Feishu Notification (if configured)
+
+After deployment is verified, check `~/.claude/feishu.json`:
+- Send `experiment_done` notification: which experiments launched, which GPUs, estimated time
+- If config absent or mode `"off"`: skip entirely (no-op)
+
+## Key Rules
+
+- ALWAYS check GPU availability first — never blindly assign GPUs
+- Each experiment gets its own screen session + GPU (remote) or background process (local)
+- Use `tee` to save logs for later inspection
+- Run deployment commands with `run_in_background: true` to keep conversation responsive
+- Report back: which GPU, which screen/process, what command, estimated time
+- If multiple experiments, launch them in parallel on different GPUs
+
+## CLAUDE.md Example
+
+Users should add their server info to their project's `CLAUDE.md`:
+
+```markdown
+## Remote Server
+- SSH: `ssh my-gpu-server`
+- GPU: 4x A100 (80GB each)
+- Conda: `eval "$(/opt/conda/bin/conda shell.bash hook)" && conda activate research`
+- Code dir: `/home/user/experiments/`
+
+## Local Environment
+- Mac MPS / Linux CUDA
+- Conda env: `ml` (Python 3.10 + PyTorch)
+```