dsh-aris-panel 0.1.0

package/skills/skills-codex/experiment-queue/SKILL.md

@@ -0,0 +1,401 @@
+---
+name: experiment-queue
+description: SSH job queue for multi-seed/multi-config ML experiments with OOM-aware retry, stale-screen cleanup, and wave-transition race prevention. Use when user says "batch experiments", "队列实验", "run grid", "multi-seed sweep", "auto-chain experiments", or when /run-experiment is insufficient for 10+ jobs that need orchestration.
+argument-hint: "[manifest-or-grid-spec]"
+allowed-tools: Bash(*), Read, Grep, Glob, Edit, Write, Skill(run-experiment), Skill(monitor-experiment)
+---
+
+# Experiment Queue
+
+Orchestrate large batches of ML experiments on SSH remote GPU servers with proper state tracking, OOM retry, stale cleanup, and wave transitions.
+
+## When to Use This Skill
+
+Use when `/run-experiment` is insufficient:
+- **≥10 jobs** that need batching across GPUs
+- **Multi-seed sweeps** (e.g., 21 seeds × 12 cells)
+- **Wave transitions** (run wave 1, wait, run wave 2, wait, run wave 3...)
+- **Teacher+student chains** (train teacher then distill; auto-trigger student after teacher done)
+- **OOM-prone configs** where you need to retry with different GPU or wait
+- **Mixed seed grids** where failed cells need re-running
+
+Do NOT use for:
+- Single ad-hoc experiment (use `/run-experiment`)
+- Modal/Vast.ai deployments (those have their own orchestration)
+- Experiments that need manual inspection between runs
+
+## Why This Exists
+
+Based on session audit (2026-04-16), the major wall-clock sinks in multi-seed grid experiments are:
+
+1. **Stale screens** — python finishes, wandb uploads, screen hangs, next wave blocked
+2. **OOM on shared GPU** — previous job's memory not yet released
+3. **Wave race** — new wave launches before previous wave fully settles
+4. **Missing checkpoints** — student launches before teacher saved
+5. **Parser duplication** — rewriting multi-seed analysis python every batch
+
+All of these are pure engineering friction that can be orchestrated.
+
+## Core Concepts
+
+> **Environment contract**: queue jobs assume the target env is already built
+> and validated per `../shared-references/compute-env-contract.md` (spec-hash
+> ledger + kernel witness). A wave of jobs dying at import time = the env
+> contract was skipped, not a queue bug; check the provider's
+> `.aris/compute/<provider>.md` ledger before re-queueing.
+
+### Job Manifest
+
+A manifest lists jobs with explicit state:
+
+```yaml
+project: my_grid_experiment
+cwd: /home/user/your_project
+conda: my_env
+# Optional: override conda hook path if conda is not at a standard location.
+# Can be a bare path (wrapped automatically) or a full `eval "$(... shell.bash hook)"` string.
+# Falls back to auto-detect of ~/anaconda3, ~/miniconda3, /opt/anaconda3, etc.,
+# or the ARIS_CONDA_HOOK environment variable.
+# conda_hook: /custom/path/to/conda
+ssh: gpu-server
+default_cmd: >
+  python run_distill.py --backbone softmax --lam 0.5
+  --K 500 --L 96 --W 16 --n_steps 30000 --batch_size 128 --lr 1e-4
+
+preconditions:
+  - type: checkpoint_exists
+    path: checkpoints/transformer/teacher_L96_K500_N{N}.pt
+
+gpus: [0, 1, 2, 3, 4, 5, 6, 7]
+max_parallel: 8
+gpu_free_threshold_mib: 500  # optional, default 500; raise for shared servers, lower for tight packing
+oom_retry:
+  delay: 120
+  max_attempts: 3
+
+jobs:
+  - id: s200_N64_n50K
+    args: {seed: 200, n_hidden: 64, n_train_subset: 50000, subset_seed: 2024}
+  - id: s200_N128_n50K
+    args: {seed: 200, n_hidden: 128, n_train_subset: 50000, subset_seed: 2024}
+  # ... 14 more
+```
+
+### Job State Machine
+
+```
+pending → running → completed
+                 ↘ failed_oom → pending (after delay) [retry up to N]
+                 ↘ failed_other → stuck (needs manual inspection)
+stale screen (process gone, screen lingering) → failed_other → stuck
+```
+
+> **Operator note on `stuck` (the agent's move, not the queue's):** the queue
+> deterministically parks `failed_other` jobs as `stuck` — that part is code and
+> unchanged. Before handing a `stuck` batch to the human, the OPERATING AGENT
+> should check: if the same failure repeats across jobs, try ONE clean
+> reimplement of the **agent-generated wrapper/attempt script only** — never
+> user/project source, the manifest, queue state, logs, or results (per
+> [`external-cadence.md`](../shared-references/external-cadence.md), "Let a broken attempt restart, not just patch").
+> Reserve the human handoff for contract/environment doubts, not merely broken
+> attempt code.
+
+### Wave Orchestration
+
+A "wave" is a batch of jobs that fit available GPUs. Next wave only starts when:
+1. All current-wave python processes have exited
+2. No stale screens remain for current-wave tags
+3. GPU memory has dropped below threshold (≤500 MiB)
+4. Precondition checks pass for next-wave jobs
+
+## Workflow
+
+### Step 1: Parse Manifest / Build from Grid
+
+Input can be:
+- **YAML manifest** (explicit job list, recommended for complex cases)
+- **Grid spec** (Cartesian product of param values, e.g., `N=[64,128,256] × n=[50K,150K,500K,652K]`)
+- **Natural language description** (Claude parses into manifest)
+
+Bind run identifiers once so every later step refers to the same paths:
+
+```bash
+# REPLACE the placeholder path before running, or pre-export PROJECT_DIR:
+PROJECT_DIR="${PROJECT_DIR:?set PROJECT_DIR to the local project root}"
+RUN_TS=$(date -u +%Y%m%dT%H%M%SZ)
+LOCAL_RUN_DIR="$PROJECT_DIR/experiment_queue/$RUN_TS"
+mkdir -p "$LOCAL_RUN_DIR"
+```
+
+Save the built manifest to `$LOCAL_RUN_DIR/manifest.json` for reproducibility.
+
+### Step 2: Pre-flight
+
+- Check SSH connection works
+- Check conda env exists on remote
+- Check `cwd` exists on remote
+- Check all preconditions (checkpoints, input files)
+- Check GPU availability (at least `max_parallel` free GPUs)
+
+If any precondition fails, show user which jobs are blocked and why.
+
+### Step 3: Launch Scheduler
+
+Resolve the bundled helper directory (`$PROJECT_DIR` / `$RUN_TS` / `$LOCAL_RUN_DIR` already set in Step 1). Phase 3.3 (Arch C) moved the canonical scripts to `skills/experiment-queue/scripts/`; `tools/experiment_queue/` retains `os.execv` shims for legacy resolver layers:
+
+```bash
+if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills-codex.txt ]; then
+    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills-codex.txt 2>/dev/null) || true
+fi
+[ -n "${ARIS_REPO:-}" ] || { echo "ERROR: ARIS_REPO not set. Use install_aris_codex.sh managed install or export ARIS_REPO=/path/to/ARIS."; exit 1; }
+# Prefer the new canonical location; fall back to legacy tools/ shim path.
+QUEUE_TOOLS="$ARIS_REPO/skills/experiment-queue/scripts"
+[ -f "$QUEUE_TOOLS/queue_manager.py" ] || QUEUE_TOOLS="$ARIS_REPO/tools/experiment_queue"
+[ -f "$QUEUE_TOOLS/queue_manager.py" ] || { echo "ERROR: queue_manager.py not found at $ARIS_REPO/skills/experiment-queue/scripts/ or $ARIS_REPO/tools/experiment_queue/"; exit 1; }
+```
+
+Compute remote paths (note: modern `scp` runs in SFTP mode and does NOT reliably expand `$HOME` in destination paths — use remote-relative for `scp`, `$HOME`-prefixed for `ssh` command strings):
+
+```bash
+REMOTE_RUN_REL=".aris_queue/runs/$RUN_TS"
+REMOTE_RUN_DIR="\$HOME/$REMOTE_RUN_REL"
+```
+
+Bootstrap remote run dir + copy helpers + copy manifest. Per-invocation, idempotent:
+
+```bash
+ssh <server> "mkdir -p \"$REMOTE_RUN_DIR/logs\" \"\$HOME/.aris_queue\""
+scp "$QUEUE_TOOLS/queue_manager.py" "$QUEUE_TOOLS/build_manifest.py" <server>:.aris_queue/
+scp "$LOCAL_RUN_DIR/manifest.json" <server>:"$REMOTE_RUN_REL/manifest.json"
+```
+
+Launch the scheduler as a detached `nohup` process:
+
+```bash
+ssh <server> "nohup python3 \"\$HOME/.aris_queue/queue_manager.py\" \\
+  --manifest \"$REMOTE_RUN_DIR/manifest.json\" \\
+  --state    \"$REMOTE_RUN_DIR/queue_state.json\" \\
+  --log-dir  \"$REMOTE_RUN_DIR/logs\" \\
+  > \"$REMOTE_RUN_DIR/queue_mgr.log\" 2>&1 &"
+```
+
+Notes: `--log-dir` is what `queue_manager.py` actually consumes (per-job log files for OOM detection). Do NOT pass `--log <path>` — that flag is declared but unused.
+
+Persist run identifiers for monitoring + resume (sourceable later):
+
+```bash
+{
+  printf 'PROJECT_DIR=%q\n'    "$PROJECT_DIR"
+  printf 'RUN_TS=%q\n'         "$RUN_TS"
+  printf 'LOCAL_RUN_DIR=%q\n'  "$LOCAL_RUN_DIR"
+  printf 'REMOTE_RUN_REL=%q\n' "$REMOTE_RUN_REL"
+  printf 'REMOTE_RUN_DIR=%q\n' "$REMOTE_RUN_DIR"
+} > "$LOCAL_RUN_DIR/run_meta.txt"
+```
+
+`%q` shell-escapes values; `REMOTE_RUN_DIR` keeps a literal `$HOME` (correct for later reuse inside `ssh "..."`).
+
+**Resume an existing queue.** Do NOT regenerate `RUN_TS`. Reload from `run_meta.txt` and re-run only the launch command above (not the bootstrap):
+
+```bash
+LOCAL_RUN_DIR="/abs/path/to/project/experiment_queue/<existing-run-ts>"
+. "$LOCAL_RUN_DIR/run_meta.txt"
+# Then re-run the launch command verbatim; do NOT re-run mkdir/scp.
+```
+
+The scheduler:
+- Reads manifest
+- Loops: for each pending job, assign to free GPU, launch via `screen`
+- Polls job status (every 60s)
+- Detects stale screens (python exited but screen detached → kill)
+- Detects OOM (CUDA OOM in log → mark failed_oom → retry after delay)
+- Detects completion (expected output JSON/file exists) → mark completed
+- Launches next wave when current wave settles
+- Writes state to `queue_state.json` continuously
+
+### Step 4: Monitoring
+
+User can check state anytime, using `$REMOTE_RUN_DIR` from Step 3 (or reload it from `$LOCAL_RUN_DIR/run_meta.txt`):
+
+```bash
+ssh <server> "cat \"$REMOTE_RUN_DIR/queue_state.json\"" \
+  | jq '.jobs | group_by(.status) | map({(.[0].status): length}) | add'
+```
+
+Note: `/monitor-experiment` is currently focused on screen sessions, result JSONs, and W&B; it does not yet read `queue_state.json` directly. For queue-state monitoring, use the literal command above.
+
+### Step 5: Post-completion
+
+When all jobs in `manifest.json` are `completed` or `stuck`:
+- The remote scheduler (`queue_manager.py`) exits cleanly with `All jobs done` to its own stdout (captured in `$REMOTE_RUN_DIR/queue_mgr.log`). It does NOT write the local summary.
+- The **local** skill agent then aggregates state into `$LOCAL_RUN_DIR/summary.md` (read `$REMOTE_RUN_DIR/queue_state.json`, group by status, optionally pull per-job logs).
+- Local skill agent invokes `/analyze-results` if `analyze_on_complete: true`.
+
+## Grid Spec Syntax
+
+Instead of writing 24 job entries manually:
+
+```yaml
+grid:
+  N: [64, 128, 256]
+  n: [50000, 150000, 500000, 652000]
+  seed: [42, 200, 201]
+template:
+  id: "s${seed}_N${N}_n${n}"
+  args: {seed: ${seed}, n_hidden: ${N}, n_train_subset: ${n}}
+```
+
+Expands to 36 jobs automatically.
+
+## Wave Chaining
+
+For sequential phases (teacher → student):
+
+```yaml
+phases:
+  - name: train_teachers
+    grid:
+      N: [384, 512]
+    template:
+      cmd: python run_train.py --direction c --backbone softmax --n_hidden ${N} ...
+      expected_output: checkpoints/transformer/teacher_L96_K500_N${N}.pt
+  
+  - name: distill_students
+    depends_on: [train_teachers]        # must be a LIST, even for a single dependency
+    grid:
+      N: [384, 512]
+      seed: [42, 200, 201]
+    template:
+      cmd: python run_distill.py --n_hidden ${N} --seed ${seed} ...
+      expected_output: figures/distill_sw_N${N}_*_seed${seed}.json
+```
+
+Scheduler enforces `depends_on`: `distill_students` jobs stay `pending` until every
+`train_teachers` job is terminal — `completed` **or** `stuck`. A failed teacher does not
+hold its students back, so check `queue_state.json` for `stuck` jobs before trusting a
+dependent wave.
+
+## OOM Handling
+
+Detect OOM from stdout:
+```regex
+torch\.OutOfMemoryError: CUDA out of memory
+```
+
+On detection:
+1. Mark job `failed_oom`
+2. Kill screen
+3. Wait `oom_retry.delay` seconds
+4. Check if current GPU is free; if not, try another free GPU
+5. Requeue as `pending`
+6. Max `oom_retry.max_attempts` before marking `stuck`
+
+## Stale Screen Detection
+
+Every 60s, for each running screen:
+1. Check screen exists (`screen -ls`)
+2. Check python PID still running (`ps -p`)
+3. If screen exists but python exited:
+   - If expected output file exists → mark `completed`, kill stale screen
+   - If no output file → mark `failed_other`, kill screen
+
+## Resume-on-restart
+
+If scheduler crashes / is killed:
+1. Read `queue_state.json`
+2. For each `running` job: check screen; if still alive, keep; if not, re-evaluate state
+3. For each `pending`: continue normally
+4. Idempotent: safe to restart scheduler without losing state
+
+## Output: Summary Report
+
+```markdown
+# Experiment Queue Summary
+
+**Project**: my_grid_experiment
+**Started**: 2026-04-16 11:36:29
+**Completed**: 2026-04-16 18:02:14
+**Total wall-clock**: 6h 25m
+**Jobs**: 40 completed, 2 OOM-retried then completed, 0 stuck
+
+## Phases
+| Phase | Jobs | Success | OOM retries | Duration |
+| --- | --- | --- | --- | --- |
+| train_teachers | 2 | 2 | 0 | 58m |
+| distill_students | 24 | 24 | 2 | 4h 02m |
+| multi_seed_validation | 16 | 16 | 0 | 1h 25m |
+
+## Results Files
+- 42 JSON files in `figures/distill_sw_*.json`
+
+## Next Steps
+- Run `/analyze-results` on output JSONs
+- Figures auto-regen via `artifact-sync` (if configured)
+```
+
+## Comparison with `/run-experiment`
+
+| Feature | `/run-experiment` | `experiment-queue` |
+| --- | --- | --- |
+| Single-shot experiment | ✅ | ✅ (overkill) |
+| Multi-GPU parallel | Basic | Proper scheduling |
+| Wave transitions | Manual | Automatic |
+| OOM retry | Manual | Automatic |
+| Stale screen cleanup | Manual | Automatic |
+| Teacher→student chain | Manual | Built-in |
+| State persistence | No | Yes (JSON) |
+| Resume on crash | No | Yes |
+| Grid expansion | Manual | Declarative |
+
+**Rule**: Use `/run-experiment` for ≤5 jobs. Use `experiment-queue` for ≥10 jobs or anything with phases.
+
+## Key Rules
+
+- **Never overlap screens on the same GPU** — always wait for `memory.used < 500 MiB` before launching new job
+- **Always write state to disk** — every state change flushed to `queue_state.json`
+- **Idempotent scheduler** — safe to restart; picks up from state file
+- **Expected-output-based completion** — don't trust screen state alone; verify output file exists
+- **Bounded retry** — max N OOM retries, then mark `stuck` and alert
+- **Dependencies enforced at launch** — a wave launches only after every job in the phases it
+  depends on has reached a terminal state. Note "terminal" includes `stuck`: if a teacher job
+  fails, the phase still completes and its students launch against a missing checkpoint. Check
+  `queue_state.json` for `stuck` jobs before trusting a dependent wave's results.
+
+## Known Failure Modes
+
+- **SSH connection drop during scheduling**: scheduler keeps running on remote (nohup), just reconnect and check
+- **GPU reservation by another user**: scheduler waits, does not pre-empt
+- **Disk full on remote**: scheduler detects write failure, marks all pending `stuck`, alerts
+
+## Example Session
+
+User: "跑 T5+T6 全部实验：T5 = N∈{80,192} × n 4 values × seed {200,201}, T6 = N∈{384,512} × n 4 values × seed {42,200,201}; T6 需要先 train teacher"
+
+Claude invokes `/experiment-queue`:
+1. Parses description into 2-phase manifest
+2. Phase 1: T5 (16 jobs, no teacher dependency) + T6 teacher training (2 jobs)
+3. Phase 2: T6 distillation (24 jobs, depends on teachers)
+4. Deploys scheduler via nohup
+5. Reports: "Scheduler PID 93534, total 42 jobs, estimated 6-7h wall-clock"
+
+Then user can check anytime or wait for summary report.
+
+## See Also
+
+- `/run-experiment` — single experiment deployment
+- `/monitor-experiment` — check progress (now reads from queue_state.json)
+- `/analyze-results` — post-hoc analysis
+- `skills/experiment-queue/scripts/queue_manager.py` (canonical, Phase 3.3 move) — the scheduler implementation. Legacy entry at `tools/experiment_queue/queue_manager.py` is an `os.execv` shim.
+- `skills/experiment-queue/scripts/build_manifest.py` (canonical, Phase 3.3 move) — build manifest from grid spec. Legacy entry at `tools/experiment_queue/build_manifest.py` is an `os.execv` shim.
+
+## Rationale / Source
+
+Identified via 2026-04-16 post-mortem analysis (Codex GPT-5.5 xhigh) of a 1.5-day
+multi-seed paper experiment session:
+
+- Wall-clock sink: stale screens, OOM, wave transitions, manual parser
+- Token sink: re-writing orchestration code each session
+- Cognitive sink: tracking which cells succeeded, which failed, which to retry
+
+This skill targets the wall-clock sink specifically; see `artifact-sync` and
+`paper-fix-auto-apply` for the other two.

package/skills/skills-codex/feishu-notify/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: "feishu-notify"
+description: "Send notifications to Feishu/Lark. Internal utility used by other skills, or manually via /feishu-notify. Use when user says \"发飞书\", \"notify feishu\", or other skills need to send status updates."
+---
+
+# Feishu/Lark Notification
+
+Send a notification: **$ARGUMENTS**
+
+## Overview
+
+This skill provides Feishu/Lark integration for ARIS. It is designed as an **internal utility** — other skills call it at key events (experiment done, review scored, checkpoint waiting). It can also be invoked manually.
+
+**Zero-impact guarantee**: If no `feishu.json` config exists, this skill does nothing and returns silently. All existing workflows are completely unaffected.
+
+## Configuration
+
+The skill reads `~/.codex/feishu.json`. If this file does not exist, **all Feishu functionality is disabled** — skills behave exactly as before.
+
+### Config Format
+
+```json
+{
+  "mode": "push",
+  "webhook_url": "https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_WEBHOOK_ID",
+  "interactive": {
+    "bridge_url": "http://localhost:5000",
+    "timeout_seconds": 300
+  }
+}
+```
+
+### Modes
+
+| Mode | `"mode"` value | What it does | Requires |
+|------|----------------|--------------|----------|
+| **Off** | `"off"` or file absent | Nothing. Pure CLI as-is | Nothing |
+| **Push only** | `"push"` | Send webhook notifications at key events. Mobile push, no reply | Feishu bot webhook URL |
+| **Interactive** | `"interactive"` | Full bidirectional. Approve/reject from Feishu, reply to checkpoints | [feishu-claude-code](https://github.com/joewongjc/feishu-claude-code) running |
+
+## Workflow
+
+### Step 1: Read Config
+
+```bash
+cat ~/.codex/feishu.json 2>/dev/null
+```
+
+- **File not found** → return silently, do nothing
+- **`"mode": "off"`** → return silently, do nothing
+- **`"mode": "push"`** → proceed to Step 2 (push)
+- **`"mode": "interactive"`** → proceed to Step 3 (interactive)
+
+### Step 2: Push Notification (webhook)
+
+Send a rich card to the Feishu webhook:
+
+```bash
+curl -s -X POST "$WEBHOOK_URL" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "msg_type": "interactive",
+    "card": {
+      "header": {
+        "title": {"tag": "plain_text", "content": "TITLE"},
+        "template": "COLOR"
+      },
+      "elements": [
+        {"tag": "markdown", "content": "BODY"}
+      ]
+    }
+  }'
+```
+
+**Card templates by event type:**
+
+| Event | Title | Color | Body |
+|-------|-------|-------|------|
+| `experiment_done` | Experiment Complete | `green` | Results table, delta vs baseline |
+| `review_scored` | Review Round N: X/10 | `blue` (≥6) / `orange` (<6) | Score, verdict, top 3 weaknesses |
+| `checkpoint` | Checkpoint: Waiting for Input | `yellow` | Question, options, context |
+| `error` | Error: [type] | `red` | Error message, what failed |
+| `pipeline_done` | Pipeline Complete | `purple` | Final summary, deliverables |
+| `custom` | Custom | `blue` | Free-form message from $ARGUMENTS |
+
+**Return immediately after curl** — push mode never waits for a response.
+
+### Step 3: Interactive Notification (bidirectional)
+
+Interactive mode uses [feishu-claude-code](https://github.com/joewongjc/feishu-claude-code) as a bridge:
+
+1. **Send message** to the bridge:
+   ```bash
+   curl -s -X POST "$BRIDGE_URL/send" \
+     -H "Content-Type: application/json" \
+     -d '{"type": "EVENT_TYPE", "title": "TITLE", "body": "BODY", "options": ["approve", "reject", "custom"]}'
+   ```
+
+2. **Wait for reply** (with timeout):
+   ```bash
+   curl -s "$BRIDGE_URL/poll?timeout=$TIMEOUT_SECONDS"
+   ```
+   Returns: `{"reply": "approve"}` or `{"reply": "reject"}` or `{"reply": "user typed message"}` or `{"timeout": true}`
+
+3. **On timeout**: Fall back to `AUTO_PROCEED` behavior (proceed with default option).
+
+4. **Return the user's reply** to the calling skill so it can act on it.
+
+### Step 4: Verify Delivery
+
+- **Push mode**: Check curl exit code. If non-zero, log warning but do NOT block the workflow.
+- **Interactive mode**: If bridge is unreachable, fall back to push mode (if webhook configured) or skip silently.
+
+## Helper Function (for other skills)
+
+Other skills should use this pattern to send notifications:
+
+```markdown
+### Feishu Notification (if configured)
+
+Check if `~/.codex/feishu.json` exists and mode is not "off":
+- If **push** mode: send webhook notification with event summary
+- If **interactive** mode: send notification and wait for user reply
+- If **off** or file absent: skip entirely (no-op)
+```
+
+**This check is always guarded.** If the config file doesn't exist, the skill skips the notification block entirely — zero overhead, zero side effects.
+
+## Event Catalog
+
+Skills send these events at these moments:
+
+| Skill | Event | When |
+|-------|-------|------|
+| `/auto-review-loop` | `review_scored` | After each round's review score |
+| `/auto-review-loop` | `pipeline_done` | Loop complete (positive or max rounds) |
+| `/auto-paper-improvement-loop` | `review_scored` | After each round's review score |
+| `/auto-paper-improvement-loop` | `pipeline_done` | All rounds complete |
+| `/run-experiment` | `experiment_done` | Screen session finishes |
+| `/idea-discovery` | `checkpoint` | Between phases (if interactive) |
+| `/idea-discovery` | `pipeline_done` | Final report ready |
+| `/monitor-experiment` | `experiment_done` | Results collected |
+| `/research-pipeline` | `checkpoint` | Between workflow stages |
+| `/research-pipeline` | `pipeline_done` | Full pipeline complete |
+
+## Key Rules
+
+- **NEVER block a workflow** because Feishu is unreachable. Always fail open.
+- **NEVER require Feishu config** — all skills must work without it.
+- **Config file absent = mode off.** No error, no warning, no log.
+- **Push mode is fire-and-forget.** Send curl, check exit code, move on.
+- **Interactive timeout = auto-proceed.** Don't hang forever waiting for a reply.
+- **Respect `AUTO_PROCEED`**: In interactive mode, if the user doesn't reply within timeout, use the same auto-proceed logic as the calling skill.
+- **No secrets in notifications.** Never include API keys, tokens, or passwords in Feishu messages.
+

package/skills/skills-codex/figure-description/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: figure-description
+description: "Process user-provided patent figures and generate formal drawing descriptions. Use when user says \"附图处理\", \"figure description\", \"附图说明\", \"drawings description\", or wants to describe patent figures with reference numerals."
+argument-hint: "[figure-directory-or-figure-list]"
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch
+---
+
+# Figure Description for Patents
+
+Process patent figures and generate drawing descriptions based on: **$ARGUMENTS**
+
+Unlike `/paper-figure` which generates data plots, this skill processes user-provided technical diagrams and assigns reference numerals.
+
+## Constants
+
+- `FIGURE_DIR = "patent/figures/"` — Output directory for figure descriptions
+- `REFERENCE_NUMERAL_PREFIX = 100` — Starting numeral for first figure's components
+- `NUMERAL_SERIES = 100` — Each figure uses a separate 100-series (Fig 1: 100-199, Fig 2: 200-299, etc.)
+
+## Inputs
+
+1. User-provided figures (PNG, JPG, SVG, PDF) — search for them in the project directory
+2. `patent/INVENTION_DISCLOSURE.md` — for understanding what components to identify
+3. `patent/CLAIMS.md` — for mapping numerals to claim elements
+
+## Workflow
+
+### Step 1: Discover Figures
+
+1. Search the project directory for figure files:
+   - Check `patent/figures/`, `figures/`, root directory
+   - Look for PNG, JPG, SVG, PDF files
+   - Check INVENTION_BRIEF.md or INVENTION_DISCLOSURE.md for figure references
+2. List all discovered figures with their paths
+3. If figures are missing that claims require, note them as `[MISSING: description needed]`
+
+### Step 2: Analyze Each Figure
+
+For each figure found:
+
+1. **Read the image** using the Read tool (supports image files)
+2. **Identify components**: What labeled or visually distinct components are shown?
+3. **Identify connections**: How do components relate to each other?
+4. **Identify flow**: If it's a flowchart or sequence, what is the step order?
+
+### Step 3: Assign Reference Numerals
+
+For each figure, assign numerals using the series convention:
+
+| Figure | Numeral Range |
+|--------|-------------|
+| FIG. 1 | 100-199 |
+| FIG. 2 | 200-299 |
+| FIG. 3 | 300-399 |
+
+For each identified component:
+- Assign the next available numeral in the series
+- Cross-reference to the claim elements it supports
+- Note if a component appears in multiple figures (use same numeral across figures)
+
+### Step 4: Generate Drawing Descriptions
+
+Write formal drawing descriptions (附图说明):
+
+**For CN jurisdiction (Chinese)**:
+```
+图1是[发明名称]的系统结构示意图；
+图2是[发明名称]的方法流程图；
+图3是[具体组件]的详细结构示意图；
+```
+
+**For US/EP jurisdiction (English)**:
+```
+FIG. 1 is a block diagram illustrating the system architecture according to one embodiment;
+FIG. 2 is a flowchart illustrating the method steps according to one embodiment;
+FIG. 3 is a detailed view of the processing module of FIG. 1;
+```
+
+### Step 5: Generate Reference Numeral Index
+
+Create a complete mapping:
+
+```markdown
+## Reference Numeral Index
+
+| Numeral | Component Name | Figure(s) | Claim Element |
+|---------|---------------|-----------|---------------|
+| 100 | System | FIG. 1 | Claim X preamble |
+| 102 | Processor | FIG. 1 | Claim X, element 1 |
+| 104 | Memory | FIG. 1 | Claim X, element 2 |
+| 106 | Communication bus | FIG. 1 | Claim X, element 3 |
+| 200 | Method | FIG. 2 | Claim 1 preamble |
+| 202 | Receiving step | FIG. 2 | Claim 1, step 1 |
+| 204 | Processing step | FIG. 2 | Claim 1, step 2 |
+```
+
+### Step 6: Cross-Reference to Claims
+
+Verify that every claim element has at least one reference numeral:
+
+| Claim Element | Figure | Numeral | Status |
+|---------------|--------|---------|--------|
+| [element] | [which fig] | [numeral] | Covered / [MISSING] |
+
+If any claim element has no corresponding figure or numeral, flag it:
+- `[MISSING FIGURE: Need a diagram showing {element description}]`
+- `[MISSING NUMERAL: Component {name} in figure {X} needs a numeral]`
+
+### Step 7: Output
+
+Write `patent/figures/figure_descriptions.md`:
+```markdown
+## Figure Descriptions
+
+### FIG. 1 — [Description]
+[Formal one-paragraph description with all reference numerals]
+
+### FIG. 2 — [Description]
+[Formal one-paragraph description with all reference numerals]
+...
+```
+
+Write `patent/figures/numeral_index.md`:
+```markdown
+## Reference Numeral Index
+
+[Complete table of all numerals, components, figures, and claim mappings]
+```
+
+## Key Rules
+
+- Every component in every figure must have a reference numeral.
+- Every reference numeral must be explained in the specification.
+- Numeral series must be consistent: 100-series for FIG. 1, 200-series for FIG. 2.
+- If the same component appears in multiple figures, use the SAME numeral.
+- Do NOT modify user-provided figures -- only describe them.
+- Flag missing figures that the claims require but the user has not provided.
+- Drawing descriptions are one sentence each, in a consistent format.