@bohuyeshan/openagent-labforge-core 3.11.5 → 3.13.0

package/generated/skills-bundles/full/skills/research/research-ideation/auto-claude__research-pipeline/SKILL.md

@@ -15,7 +15,7 @@ End-to-end autonomous research workflow for: **$ARGUMENTS**
 
 - **AUTO_PROCEED = true** — When `true`, Gate 1 auto-selects the top-ranked idea (highest pilot signal + novelty confirmed) and continues to implementation. When `false`, always waits for explicit user confirmation before proceeding.
 - **ARXIV_DOWNLOAD = false** — When `true`, `/research-lit` downloads the top relevant arXiv PDFs during literature survey. When `false` (default), only fetches metadata via arXiv API. Passed through to `/idea-discovery` → `/research-lit`.
-- **HUMAN_CHECKPOINT = false** — When `true`, the ULTRAWORK loop (Stage 4) pauses after each round to let you inspect progress and provide custom modification instructions before fixes are implemented. When `false` (default), the loop runs fully autonomously. Passed through to `/ulw-loop`.
+- **HUMAN_CHECKPOINT = false** — When `true`, the ULTRAWORK loop (Stage 4) pauses after each round to let you inspect progress and provide custom modification instructions before fixes are implemented. When `false` (default), the loop runs fully autonomously. Passed through to `/ulw-loop`.
 
 > 💡 Override via argument, e.g., `/research-pipeline "topic" — AUTO_PROCEED: false, human checkpoint: true`.
 
@@ -40,7 +40,7 @@ Invoke the idea discovery pipeline:
 /idea-discovery "$ARGUMENTS"
 ```
 
-This internally runs: `/research-lit` → `/idea-creator` → `/novelty-check`
+This internally runs: `/research-lit` → `/idea-creator` → `/novelty-check`
 
 **Output:** `IDEA_REPORT.md` with ranked, validated, pilot-tested ideas.
 
@@ -109,25 +109,25 @@ Deploy the full-scale experiments:
 
 Wait for experiments to complete. Collect results.
 
-### Stage 4: ULTRAWORK Loop (Workflow 2 — Part 2)
+### Stage 4: ULTRAWORK Loop (Workflow 2 — Part 2)
 
 Once initial results are in, start the autonomous improvement loop:
 
 ```
-/ulw-loop "$ARGUMENTS — [chosen idea title]"
+/ulw-loop "$ARGUMENTS — [chosen idea title]"
 ```
 
-**What this does (recommended max 4 rounds):**
-1. Run work → check progress → record evidence
-2. Oracle verifies completion; if not verified, continue iterating
-3. Deploy fixes, collect new results
-4. Repeat until Oracle verification or max rounds reached
-
-**Output:** Maintain a `ULTRAWORK_LOG.md` with each round's changes and evidence.
+**What this does (recommended max 4 rounds):**
+1. Run work → check progress → record evidence
+2. Oracle verifies completion; if not verified, continue iterating
+3. Deploy fixes, collect new results
+4. Repeat until Oracle verification or max rounds reached
+
+**Output:** Maintain a `ULTRAWORK_LOG.md` with each round's changes and evidence.
 
 ### Stage 5: Final Summary
 
-After the ULTRAWORK loop completes, write a final status report:
+After the ULTRAWORK loop completes, write a final status report:
 
 ```markdown
 # Research Pipeline Report
@@ -135,7 +135,7 @@ After the ULTRAWORK loop completes, write a final status report:
 **Direction**: $ARGUMENTS
 **Chosen Idea**: [title]
 **Date**: [start] → [end]
-**Pipeline**: idea-discovery → implement → run-experiment → ulw-loop
+**Pipeline**: idea-discovery → implement → run-experiment → ulw-loop
 
 ## Journey Summary
 - Ideas generated: X → filtered to Y → piloted Z → chose 1
@@ -157,7 +157,7 @@ After the ULTRAWORK loop completes, write a final status report:
 
 - **Human checkpoint after Stage 1 is controlled by AUTO_PROCEED.** When `false`, do not proceed without user confirmation. When `true`, auto-select the top idea after presenting results.
 - **Stages 2-4 can run autonomously** once the user confirms the idea. This is the "sleep and wake up to results" part.
-- **If Stage 4 hits the max rounds without Oracle verification**, stop and report remaining issues. Do not loop forever.
+- **If Stage 4 hits the max rounds without Oracle verification**, stop and report remaining issues. Do not loop forever.
 - **Budget awareness**: Track total GPU-hours across the pipeline. Flag if approaching user-defined limits.
 - **Documentation**: Every stage updates its own output file. The full history should be self-contained.
 - **Fail gracefully**: If any stage fails (no good ideas, experiments crash, review loop stuck), report clearly and suggest alternatives rather than forcing forward.
@@ -169,6 +169,6 @@ After the ULTRAWORK loop completes, write a final status report:
 | 1. Idea Discovery | 30-60 min | Yes if AUTO_PROCEED=true |
 | 2. Implementation | 15-60 min | Yes (autonomous after Gate 1) |
 | 3. Deploy | 5 min + experiment time | Yes ✅ |
-| 4. ULTRAWORK | 1-4 hours (depends on experiments) | Yes ✅ |
+| 4. ULTRAWORK | 1-4 hours (depends on experiments) | Yes ✅ |
 
 **Sweet spot**: Run Stage 1-2 in the evening, launch Stage 3-4 before bed, wake up to a reviewed paper.

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

@@ -6,219 +6,220 @@ 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.
+
+# 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/skills/data-analysis/experiment-monitoring/auto-claude__monitor-experiment/SKILL.md

@@ -6,58 +6,59 @@ 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
+
+# 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