dsh-aris-panel 0.1.0

package/skills/specification-writing/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: specification-writing
+description: "Write the full patent specification from claims and invention disclosure. Use when user says \"撰写说明书\", \"write specification\", \"写说明书\", \"patent description\", or wants to draft the complete patent specification."
+argument-hint: "[claims-path]"
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, Skill, WebSearch, WebFetch, mcp__codex__codex, mcp__codex__codex-reply
+---
+
+# Specification Writing: Section-by-Section Patent Description
+
+Write the patent specification based on: **$ARGUMENTS**
+
+Adapted from `/paper-write` for patent specifications. The specification supports the claims -- it is not a paper.
+
+## Constants
+
+- `REVIEWER_MODEL = gpt-5.6-sol` — External reviewer for specification quality
+- `JURISDICTION = "auto"` — Inherit from pipeline or detect from args; `CN`, `US`, `EP`, `ALL`
+- `OUTPUT_FORMAT = "markdown"` — Markdown drafts; converted to filing format by `/jurisdiction-format`
+- `OUTPUT_DIR = "patent/"` — Base output directory
+- `LANGUAGE = "auto"` — Auto from jurisdiction: CN->Chinese, US/EP->English
+
+## Inputs
+
+1. `patent/CLAIMS.md` — the drafted claims (primary source)
+2. `patent/INVENTION_DISCLOSURE.md` — invention decomposition
+3. `patent/PRIOR_ART_REPORT.md` — for background section
+4. User-provided figures (if any)
+
+## Shared References
+
+Load `../shared-references/patent-writing-principles.md` for specification writing rules, language guidelines, and reference numeral conventions.
+Load `../shared-references/patent-format-cn.md` or `patent-format-us.md` or `patent-format-ep.md` based on jurisdiction.
+
+## Workflow
+
+### Step 1: Initialize Specification Structure
+
+Create the output directory and section files:
+
+```
+patent/specification/
+├── title.md
+├── technical_field.md
+├── background.md
+├── summary.md
+├── drawings_description.md
+├── detailed_description.md
+└── abstract.md
+```
+
+### Step 2: Write Title (发明名称)
+
+- Must match the broadest claim scope
+- No trademarks, no "improved" or "new" or "novel"
+- CN format: "一种[领域]的[技术主题]" or "[领域]的[技术主题]装置"
+- US/EP format: "[Technical topic] for [purpose]" or "[Technical topic] and method thereof"
+- Keep concise (CN: typically under 25 characters; US: under 500 characters)
+
+### Step 3: Write Technical Field (技术领域)
+
+1-2 paragraphs identifying the technical domain:
+- "The present invention relates to [broad field], and more particularly to [specific area]."
+- CN: "本发明涉及[技术领域]，具体涉及[具体领域]。"
+
+### Step 4: Write Background (背景技术)
+
+This is NOT a literature review. It directly sets up the problem.
+
+Structure:
+1. Describe the closest prior art approaches (2-3 paragraphs)
+2. Identify specific technical deficiencies of each approach
+3. The deficiencies must be technical, not commercial or social
+4. DO NOT admit the prior art is "superior" or "better"
+5. DO NOT cite specific patent numbers unless they are known prior art (citations go in IDS for US, or Background section for CN)
+
+CN format: "背景技术" section describing existing technology and its shortcomings.
+
+### Step 5: Write Summary (发明内容)
+
+Three parts, directly mirroring INVENTION_DISCLOSURE.md:
+
+**Technical Problem (要解决的技术问题)**:
+- State the problem derived from background deficiencies
+- CN: "本发明要解决的技术问题是..."
+
+**Technical Solution (技术方案)**:
+- Describe how the invention solves the problem
+- Must provide support for ALL claim elements
+- Start from the broadest claim and describe the core inventive concept
+- CN: "为解决上述技术问题，本发明采用的技术方案是：..."
+- **NO formulas, NO mathematical derivations, NO circuit models** — these belong in 具体实施方式, not 发明内容
+
+**Advantages (有益效果)**:
+- Benefits derived from the structural/technical features (qualitative reasoning)
+- CN: "本发明的有益效果是：..."
+- **NO specific numerical results** (e.g., "detection limit 70μm", "response time 105ms") — these are experimental findings, not invention properties
+- Frame advantages structurally: "由于采用了...结构，因此具有...效果"
+
+### Step 6: Write Brief Description of Drawings (附图说明)
+
+Invoke `/figure-description` as a sub-skill if user has provided figures:
+```
+/figure-description "patent/figures/"
+```
+
+If no user figures, describe what figures should exist based on the claims.
+
+Format:
+- CN: "图1是...的示意图；图2是...的流程图；"
+- US: "FIG. 1 is a block diagram showing...; FIG. 2 is a flowchart illustrating..."
+
+### Step 7: Write Detailed Description (具体实施方式)
+
+Invoke `/embodiment-description` as a sub-skill:
+```
+/embodiment-description "patent/CLAIMS.md"
+```
+
+This section must:
+- Describe at least one complete embodiment with reference numerals
+- Enable a POSITA to make and use the invention
+- Support every claim element with explicit description
+- Include variations and alternatives for broader claim interpretation
+
+### Step 8: Write Abstract (摘要)
+
+Jurisdiction-specific word limits:
+
+| Jurisdiction | Word Limit | Notes |
+|-------------|-----------|-------|
+| CN | 300 words (Chinese characters) | Include most representative claim reference |
+| US | 150 words (2500 characters) | Enable efficient searching, no legal phrases |
+| EP | ~150 words | No statements on merits or value |
+
+The abstract summarizes:
+1. The technical field
+2. The problem being solved
+3. The technical solution (core features)
+4. Key advantages
+
+### Step 9: Claim Support Verification
+
+Verify every claim element finds support in the specification:
+
+| Claim | Element | Specification Section | Paragraph(s) | Reference Numeral |
+|-------|---------|----------------------|-------------|-------------------|
+| 1 | step a | detailed_description | ¶3 | 202 |
+| 1 | step b | detailed_description | ¶4 | 204 |
+| X | component A | detailed_description | ¶2 | 102 |
+
+If any element lacks support, add the necessary description before proceeding.
+
+### Step 10: Cross-Model Review
+
+Call `REVIEWER_MODEL` via `mcp__codex__codex` with xhigh reasoning:
+
+```
+mcp__codex__codex:
+  model: gpt-5.6-sol
+  config: {"model_reasoning_effort": "xhigh"}
+  prompt: |
+    You are a patent examiner reviewing a specification for completeness.
+    CLAIMS: [all claims]
+    SPECIFICATION: [all specification sections]
+
+    Check for:
+    1. Written description support: Does every claim element have explicit or inherent support?
+    2. Enablement: Can a POSITA practice the invention from this specification?
+    3. Consistency: Do reference numerals match across figures and specification?
+    4. Language quality: Any subjective terms, relative terms without definition, or result-to-be-achieved language?
+    5. Missing embodiments: Are there claim features that need additional embodiments?
+    6. Background deficiencies: Are they technical and specific enough?
+```
+
+### Step 11: Output
+
+All specification sections are in `patent/specification/`.
+
+Summary file: `patent/specification/SPECIFICATION_INDEX.md` with:
+```markdown
+## Patent Specification
+
+### Sections
+| Section | File | Word Count | Status |
+|---------|------|-----------|--------|
+| Title | title.md | | Complete |
+| Technical Field | technical_field.md | | Complete |
+| Background | background.md | | Complete |
+| Summary | summary.md | | Complete |
+| Drawings Description | drawings_description.md | | Complete |
+| Detailed Description | detailed_description.md | | Complete |
+| Abstract | abstract.md | | Complete |
+
+### Claim Support Status
+| Claim | Elements Supported | Elements Missing |
+|-------|-------------------|-----------------|
+| 1 | All | None |
+| X | All | None |
+```
+
+## Key Rules
+
+- The specification supports the claims, not the other way around. Every claim element must have support.
+- Use consistent terminology -- same word for the same concept throughout.
+- DO NOT include experimental results, accuracy metrics, or empirical evaluations.
+- DO NOT use subjective language ("excellent", "surprising", "superior").
+- Reference numerals must be consistent: same component, same numeral, everywhere.
+- Background section describes specific deficiencies, not general "need for improvement."
+- Multiple embodiments strengthen the specification but are not always required.
+- Large file handling: if a Write operation fails, retry with Bash `cat <<'EOF'` heredoc.
+- If `mcp__codex__codex` is not available, skip cross-model review and note it in the output.

package/skills/system-profile/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: system-profile
+description: "Profile a target (script, process, GPU, memory, interconnect) for performance analysis. Use when user says \"profile\", \"benchmark\", \"bottleneck\", or wants performance analysis."
+argument-hint: '<target, e.g. "train.py", "gpu", "pid 1234", "vllm serving">'
+---
+
+# System Profile
+
+Profile the specified target and summarize the results. Target: $ARGUMENTS
+
+## Instructions
+
+You are a profiling assistant. Based on the user's target, choose appropriate profiling strategies, **including writing instrumentation code when needed**, then run profiling, analyze results, and produce a summary.
+
+### Step 1: Determine the profiling target
+
+Parse `$ARGUMENTS` to understand what to profile. Examples:
+- A Python script or module
+- A running process (PID or service name)
+- A specific function or code block
+- An entire framework or system (e.g., "autogen", "vllm serving") — profile its end-to-end execution, identify bottlenecks across components
+- "gpu" / "interconnect" / "memory" for focused profiling
+
+If `$ARGUMENTS` is empty or unclear, ask the user.
+
+### Step 2: Choose profiling methods
+
+Select from external tools and/or code instrumentation as appropriate. Don't limit yourself to the examples below — use whatever makes sense for the target.
+
+**External tools** (check availability first):
+- CPU: `cProfile`, `py-spy`, `line_profiler`, `perf stat`, `/usr/bin/time -v`
+- Memory: `tracemalloc`, `memory_profiler`, `memray`
+- GPU: `nvidia-smi`, `nvidia-smi dmon`, `nvitop`, `torch.profiler`, `nsys`
+- Interconnect: `nvidia-smi topo -m`, `nvidia-smi nvlink`, `NCCL_DEBUG=INFO`
+- System: `strace -c`, `iostat`, `vmstat`
+
+**Code instrumentation** — when external tools are insufficient, write and insert profiling code into the target. Typical scenarios:
+- Timing specific code blocks (wall time vs CPU time)
+- Measuring CPU-GPU or GPU-GPU transfer size, frequency, and bandwidth
+- Tracking memory allocation across CPU and GPU to detect redundancy
+- Wrapping NCCL collectives to measure latency and throughput
+- Adding CUDA event timing around kernels
+
+Design the instrumentation based on what you observe in the code — don't use a fixed template.
+
+### Step 3: Key dimensions to investigate
+
+Depending on the target, focus on some or all of these:
+
+**CPU overhead**
+- Context switching (voluntary / involuntary)
+- CPU utilization: ratio of CPU time to wall time
+- Per-function execution time hotspots
+
+**Memory overhead**
+- CPU and GPU memory usage (allocated vs reserved vs peak)
+- Redundant replication: same data living on both CPU and GPU
+- Per-device allocation balance in multi-GPU setups
+
+**Interconnect & communication**
+- CPU-GPU transfer: frequency, per-transfer size, total volume, bandwidth achieved
+- GPU-GPU transfer: P2P bandwidth, NVLink vs PCIe topology impact
+- NCCL collectives: operation type, message size distribution, latency
+- Communication-to-computation ratio
+
+**GPU compute**
+- SM utilization, kernel launch overhead
+- Memory bandwidth utilization vs peak
+
+### Step 4: Instrumentation guidelines
+
+When inserting code into the target:
+1. Read and understand the target code first
+2. Prefer wrapping (decorator, context manager, standalone runner) over inline edits
+3. If inline edits are necessary, mark them clearly (e.g., `# [PROFILE]` comments)
+4. Minimize observer effect — don't instrument tight inner loops; sample instead
+5. Collect results into a structured log, don't scatter print statements
+
+### Step 5: Run profiling
+
+1. Check available tools and hardware topology
+2. Run the chosen methods, capture all output
+3. Save artifacts (flamegraphs, traces, logs) to `./profile_output/`
+
+### Step 6: Produce the report
+
+**Part A — Profiling results** (structured tables by dimension, as applicable):
+- CPU overhead table
+- Memory overhead table (with redundancy column)
+- Interconnect table (transfer type / frequency / size / latency / bandwidth)
+- Hotspots / bottleneck identification
+- Actionable recommendations ranked by expected impact
+
+**Part B — Instrumentation changelog** (MANDATORY):
+List every file that was modified or created for profiling purposes:
+
+| File | Change type | What was added/modified | Line(s) |
+|------|-------------|------------------------|---------|
+| ... | modified | ... | ... |
+| ... | created | ... | — |
+
+This allows the user to review and revert all instrumentation changes.
+Offer to clean up (remove all instrumentation) when the user is done.

package/skills/training-check/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: training-check
+description: Periodically check WandB metrics during training to catch problems early (NaN, loss divergence, idle GPUs). Avoids wasting GPU hours on broken runs. Use when training is running and you want automated health checks.
+argument-hint: "[wandb-run-path]"
+allowed-tools: Bash(*), Read, Grep, Glob, Write, Edit, mcp__codex__codex, mcp__codex__codex-reply
+---
+
+# Training Check
+
+Periodically read WandB metrics during training to catch problems early. Do not wait until training finishes to discover it was a waste of GPU time.
+
+> ⏱ This skill is **correctly** cron-wired (see below): it polls
+> machine-checkable training health (NaN / divergence / idle GPU) — the additive
+> external-wait shape in
+> [`shared-references/external-cadence.md`](../shared-references/external-cadence.md).
+> The occasional Codex call for an ambiguous metric is a **one-shot** check per
+> tick, not a multi-round verdict loop, so it stays additive — it never grows
+> into a wrapped verdict skill.
+
+## Context: $ARGUMENTS
+
+## Constants
+
+- WANDB_ENTITY and WANDB_PROJECT: read from CLAUDE.md or passed as argument (format: `entity/project/run_id`)
+- CHECK_INTERVAL: starts at 10 minutes, then gradually increases if consistently healthy: 10 min → 20 min → 30 min → 60 min (cap)
+- REVIEWER_MODEL = `gpt-5.6-sol` — used via Codex MCP for ambiguous cases only
+
+## When to Use
+
+- After training is confirmed running (session alive, loss decreasing for first few steps)
+- Set up via CronCreate to fire periodically during training
+- **This skill checks training QUALITY, not process HEALTH.** Process health (session alive, GPU utilization) is [watchdog.py](../../tools/watchdog.py)'s job.
+
+## Workflow
+
+### Step 1: Read WandB Metrics
+
+```python
+import wandb
+api = wandb.Api()
+run = api.run("<entity>/<project>/<run_id>")
+history = run.history()
+```
+
+If WandB is unreachable (API error, network issue), fall back to reading the log file directly via SSH:
+```bash
+ssh server "tail -100 /path/to/training.log"
+```
+
+Check these signals:
+- **Loss trend**: Is training loss decreasing over the last N steps?
+- **Eval metrics**: Are evaluation metrics improving (or at least not degrading)?
+- **NaN / Inf**: Any NaN or Inf values in loss or gradients?
+- **Spikes**: Sudden large jumps in loss (>10x normal variance)?
+- **Learning rate**: Is the schedule behaving as expected?
+- **Gradient norm**: Exploding or vanishing?
+
+### Step 2: Judgment
+
+| Signal | Judgment | Action |
+|--------|----------|--------|
+| NaN/Inf in loss | **Clearly bad** | Stop training, investigate |
+| Loss diverging (increasing for >N steps) | **Clearly bad** | Stop training, investigate |
+| Eval metrics significantly worse than baseline | **Clearly bad** | Stop training, investigate |
+| Loss decreasing, metrics improving | **Clearly fine** | Continue, increase check interval |
+| Loss flat but not diverging | **Unsure** | → Step 3 (Codex judgment) |
+| Metrics noisy, can't tell trend | **Unsure** | → Step 3 (Codex judgment) |
+| Slightly worse than baseline but still early | **Unsure** | → Step 3 (Codex judgment) |
+
+### Step 3: Codex Judgment (only when unsure)
+
+Only escalate to Codex when the signal is ambiguous. For clearly good or clearly bad signals, act directly.
+
+```
+mcp__codex__codex:
+  model: gpt-5.6-sol
+  config: {"model_reasoning_effort": "xhigh"}
+  prompt: |
+    TRAINING HEALTH CHECK — need your judgment on ambiguous metrics.
+
+    Run: <entity>/<project>/<run_id>
+    Current epoch/step: X / Y total
+    Training loss (last 10 checkpoints): [values]
+    Eval metrics (last 3 evals): [values]
+    Baseline reference: [numbers from paper/reproduction]
+
+    What I'm unsure about: [specific concern]
+
+    Please respond with exactly one of:
+    - STOP: clearly problematic, should kill training
+    - CONTINUE: looks fine, check again next interval
+    - WAIT: not enough data to judge, check again sooner
+```
+
+### Step 4: Act
+
+| Decision | Action |
+|----------|--------|
+| **Stop** | Kill the training session. Save the WandB run URL, key metrics, and reason for stopping. Log to project notes for debugging. |
+| **Continue** | Do nothing. Will be invoked again at next interval (increase interval if consistently healthy). |
+| **Wait** | Do nothing but keep the current short interval (don't increase). |
+
+## Integration with Watchdog
+
+Training-check and [watchdog.py](../../tools/watchdog.py) operate at different levels:
+
+| Layer | Tool | What it checks | Frequency |
+|-------|------|----------------|-----------|
+| Process health | watchdog.py | Session alive? GPU active? | Every 60s (continuous) |
+| Training quality | training-check | Loss trend? Metrics improving? | Every 10-60 min (periodic) |
+
+Use both together:
+- Watchdog catches crashes and idle GPUs immediately
+- Training-check catches subtle quality issues (loss plateau, metric degradation)
+
+## Rules
+
+- Do not stop training on first sign of noise — some loss spikes are normal. Look at **trends over multiple checkpoints**.
+- When stopping training, always save the WandB run URL and key metrics as evidence.
+- If both WandB and log files are unreachable, report the connectivity issue and try again next interval. Do not assume training is broken.
+- Gradually increase check interval when healthy (10 → 20 → 30 → 60 min). Reset to 10 min after any anomaly.
+- This skill is meant to be automated via CronCreate — do not ask the user whether to set it up. Just set it.
+
+## CronCreate Setup Example
+
+```
+After training is confirmed stable:
+  CronCreate (recurring, every 10 minutes initially):
+    "Run /training-check for wandb run <entity>/<project>/<run_id>"
+```
+
+As the check interval increases, delete the old CronCreate job and create a new one with the longer interval.