dsh-aris-panel 0.1.0

package/skills/skills-codex/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
+---
+
+# 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: Fresh-Agent Review (same-family provisional by default)
+
+Call `REVIEWER_MODEL` via a dedicated Codex reviewer agent at xhigh reasoning:
+
+```text
+spawn_agent:
+  model: gpt-5.6-sol
+  reasoning_effort: xhigh
+  message: |
+    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 reviewer delegation is unavailable in the current Codex host, stop and ask the user to enable Codex agent support before continuing.

package/skills/skills-codex/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/skills-codex/training-check/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: training-check
+description: "Interactively monitor training metrics from the current Codex session, periodically checking WandB or fallback logs for NaN, divergence, plateaus, and broken runs."
+argument-hint: "[wandb-run-or-monitoring-brief]"
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob
+---
+
+# Training Check
+
+You are now in **interactive watch** / 交互式训练监控模式.
+
+Keep the current session open and report directly in the current terminal. The user is watching this terminal for updates. By default, run a training health check every 30 minutes, output a concise but complete analysis report after each check, state the next check time, then continue monitoring.
+
+This skill checks training **quality**, not basic process health. Process health checks such as whether a tmux session exists or whether the GPU is idle can be handled by watchdog-style tooling; this skill focuses on whether the run is still worth continuing.
+
+## Inputs To Establish First
+
+Before the first check, identify or ask for the minimum monitoring context:
+
+- WandB run path or URL, if available.
+- Fallback log path, SSH command, or local command for reading recent training logs.
+- Training target, expected baseline, and key metrics that define success.
+- How the training was launched, so it can be stopped if needed.
+- Project notes path for recording decisions and evidence.
+
+If a source is unavailable, say so clearly and continue with the available source. If both WandB and fallback logs are unreachable, report the connectivity issue, classify the round as `WAIT`, and check again later. Do not infer that training is bad only because data is unreachable.
+
+## Per-Round Check
+
+Every round, read WandB first when configured. If WandB is unreachable, read the fallback logs. Inspect at least:
+
+- Training loss trend over recent checkpoints or steps.
+- Eval metrics and whether they improve, flatten, or degrade against baseline.
+- NaN or Inf in loss, gradients, activations, or logged metrics.
+- Sudden loss spikes, divergence, or repeated failed evaluations.
+- Learning rate schedule behavior.
+- Gradient norm, if logged.
+- Plateau patterns that suggest the run is no longer useful.
+
+Output one report in the current terminal with this structure:
+
+```text
+## Training Check - <local timestamp>
+
+- Data source: wandb_ok | log_fallback | unreachable
+- Run: <wandb run or training identifier>
+- Recent metrics: <loss/eval/lr/grad summary>
+- Anomalies: <NaN/Inf/spike/divergence/plateau findings>
+- Evidence: <WandB URL, log lines, metric values, or files inspected>
+- Decision: CONTINUE | WAIT | STOP
+- Reason: <why this decision is justified>
+- Next check: <local timestamp, normally 30 minutes later unless ending>
+```
+
+Use the decisions as follows:
+
+| Decision | Meaning | Action |
+|----------|---------|--------|
+| `CONTINUE` | Run looks healthy enough to keep training. | Keep monitoring and check again in 30 minutes. |
+| `WAIT` | Evidence is inconclusive, noisy, too early, or temporarily unreachable. | Do not stop training; keep monitoring and check again later. |
+| `STOP` | Training is clearly problematic or no longer worth continuing. | Stop the training task, save evidence, write notes, output final summary, and end monitoring. |
+
+## Stop Behavior
+
+When the decision is `STOP`:
+
+- Stop the training task.
+- If the context contains `stop_command`, run `stop_command` first.
+- If no `stop_command` is available, choose the appropriate stop action from how the training was launched, such as stopping the relevant tmux session, local process, remote process, scheduler job, or notebook job.
+- Save evidence: WandB URL, key metrics, relevant log snippets, files inspected, and the reason for stopping.
+- Append a project note for debugging and future analysis.
+- Output `FINAL_SUMMARY` in the terminal.
+- End the interactive monitoring loop.
+
+Never stop on the first sign of ordinary metric noise. Look for sustained trends, hard failures, or clear divergence. Always preserve enough evidence for a later agent or human to understand why the run was stopped.
+
+## Interactive Loop Guidance
+
+- The normal interval is 30 minutes.
+- If a round is `CONTINUE`, announce the next check time and wait until then.
+- If a round is `WAIT`, explain what evidence is missing or noisy and check again later. Use a shorter interval only when the run looks suspicious but not yet stop-worthy.
+- If an anomaly recovers, say so explicitly and continue monitoring.
+- Keep the user-facing report short enough to read in a terminal, but include concrete metric values and evidence paths.