goatchain-cli-darwin-x64 0.0.73-beta.9 → 0.1.1

package/bin/skills-assets/deep-investigate/references/prompts.md

@@ -0,0 +1,75 @@
+# Agent Prompt Templates
+
+## Explorer
+
+```
+You are a research explorer investigating a specific territory within a larger research effort.
+
+RESEARCH PLAN:
+{plan}
+
+YOUR TERRITORY:
+{assignment}
+
+VERIFIER FEEDBACK FROM LAST ROUND (if any):
+{feedback — read it, decide for yourself how to address the problems}
+
+INSTRUCTIONS:
+- Go as deep as possible on your assigned territory
+- Trace claims to primary sources — don't restate summaries
+- Verify empirically when possible (run code, test APIs, check data, read original documents)
+- Distinguish root causes from surface descriptions
+- Flag claims you couldn't verify as [UNVERIFIED]
+- List new questions and dimensions discovered during exploration
+
+OUTPUT:
+Findings organized by sub-topic. For each:
+- What you found
+- Source (URL, file path, or document reference)
+- Verified? (how) or [UNVERIFIED]
+- New questions this raises
+```
+
+## Verifier
+
+```
+You are a research auditor. Evaluate this investigation's quality with fresh eyes. You have NO prior context — this is deliberate.
+
+RESEARCH PLAN:
+{plan}
+
+WORKING DOCUMENT:
+{document}
+
+CURRENT ROUND: {N} of minimum {min_rounds}
+
+## Evaluate on two axes
+
+BREADTH — is the problem space covered?
+- For each dimension: COVERED / PARTIAL / NOT COVERED
+- Missing dimensions that should exist?
+- Sources per dimension? (1 source = unreliable)
+
+DEPTH — are findings real?
+- For each major finding: DEEP / SURFACE / UNVERIFIED
+- Confident claims that just restate one source?
+- Verifications done or just claimed?
+
+## Failure patterns to detect
+- Lazy: lists without analysis
+- Shallow: WHAT without WHY
+- Blind spots: obvious angles unchecked
+- Fake verification: claims verified but no evidence
+- Low count: fewer findings than domain should yield
+
+## Output
+
+Problem characteristics: {each problem with evidence}
+
+DETERMINATION:
+- Round < min_rounds → GAPS (always)
+- Round >= min_rounds, all COVERED, no critical SURFACE/UNVERIFIED → PASS
+- Otherwise → GAPS
+
+You describe problems. You do NOT prescribe solutions.
+```

package/bin/skills-assets/deep-investigate/references/templates.md

@@ -0,0 +1,73 @@
+# Document Templates
+
+## Research plan (Phase 1 output)
+
+```markdown
+# Research Plan: {title}
+
+> Core question: {one sentence}
+> min_rounds: {N}
+
+## Dimensions
+1. {dimension} — {why it matters}
+
+## Completion criteria
+{Derive from the question. Examples:}
+- [ ] Each dimension covered by ≥2 agents from different angles
+- [ ] Key claims verified empirically
+- [ ] Landscape mapped with concrete examples
+- [ ] Verifier PASS (after min_rounds)
+
+## Scope
+- In: {list}
+- Out: {list with reasons}
+```
+
+## Final document (Phase 4 output)
+
+```markdown
+# {Title}
+
+> Date: {date}
+> Core question: {one sentence}
+> Related docs: {links}
+> Exploration: {K} rounds, {N} verified, {M} unverified
+
+---
+
+## 一、Current state
+{Quantified — numbers, not adjectives}
+
+## 二、Comparison
+{Tables by dimension}
+
+## 三、Gaps
+{Classified by priority, each with: current state → others' approach → suggestion}
+
+## 四、Verification records
+| Claim | Method | Result |
+|-------|--------|--------|
+
+## 五、Priority roadmap
+| Priority | Item | Scope | Effort | Dependency |
+|----------|------|-------|--------|------------|
+
+## 六、Conclusion
+{3-5 concrete next steps}
+
+## 七、Blind spots
+{What not covered, why}
+```
+
+## Handoff document (optional, for large efforts)
+
+```markdown
+# Handoff: {title}
+
+## Why — original motivation
+## How — methods, sources, classification
+## What — top 5 findings
+## Progress — done vs remaining
+## Continue — next steps for whoever picks this up
+## Blind spots — deliberately not covered, why
+```

package/bin/skills-assets/deep-investigate/references/thinking-tools.md

@@ -0,0 +1,36 @@
+# Thinking Tools for Phase 3
+
+Use these during analysis. They are thinking aids, not a checklist — pick what fits.
+
+## Boundary drawing
+
+"What principle determines whether X belongs in our scope?"
+
+Define the principle first, then audit every item against it. Items that fail → explicitly out of scope with documented reason.
+
+Example: "Anything affecting whether a request succeeds → our scope. Anything affecting how data is represented → not our scope."
+
+## Essential difference vs surface similarity
+
+"What is the lifecycle / failure mode / mental model of each thing I'm comparing?"
+
+Things that look alike may be fundamentally different. The analysis that distinguishes them is where real insight lives.
+
+Example: packet loss, connection reset, and route blackhole all look like "request failed" — but their detection, recovery, and design implications are completely different.
+
+## Ecosystem consensus
+
+If the entire ecosystem does it one way and we're different, can we articulate why? If not, reconsider.
+
+Works both ways: consensus validates ("no one combines HTTP+WS+upload → split is right") and consensus challenges ("every client supports cancellation → we must too").
+
+## User-scenario-backward
+
+Start from "who needs what when", not "what can we do". Map 3-5 concrete scenarios, list needed capabilities, compare against what exists. Gaps from scenarios are real gaps.
+
+## Self-interrogation
+
+After reaching a conclusion:
+- "Am I confusing 'we built it' with 'users need it'?"
+- "Is the problem the what or the tempo?"
+- "What would I think seeing this for the first time?"

package/bin/skills-assets/dim-modality/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: dim-modality
+description: Use DimCode multimodal CLI when the user asks the agent to generate or edit images, generate video, synthesize speech, transcribe audio, generate music or sound effects, create 3D assets or motion data, or inspect available multimodal defaults through `dim modality`. This skill teaches when to use the CLI, the main execution path, failure handling, and model-specific notes.
+---
+
+# Dim Modality
+
+Use this skill when media work should go through the DimCode multimodal CLI instead of legacy image tools or ad hoc provider calls.
+
+## When To Use
+
+Use this skill for requests that involve:
+
+- Generating, editing, enhancing, upscaling, or restoring images.
+- Generating video from text, or generating video from an input image.
+- Text-to-speech or speech-to-text.
+- Music, sound effects, ambient audio, or audio extraction.
+- 3D assets or motion data.
+- Checking which multimodal defaults are configured.
+- Debugging why a multimodal command failed.
+
+Do not look for the old image-generation tool for these tasks. Do not add a native agent tool for each modality. The normal path is `exec` running `dim ... --json`.
+
+## Main Path
+
+1. Inspect configured multimodal defaults first:
+
+```bash
+dim modality list --json
+```
+
+2. Map the user request to a capability:
+
+| User goal | Capability | CLI entry |
+|---|---|---|
+| Generate an image | `image.generate` | `dim image generate` |
+| Edit an image | `image.edit` | `dim image edit` |
+| Enhance an image | `image.enhance` | `dim image enhance` |
+| Generate a video | `video.generate` | `dim video generate` |
+| Synthesize speech | `speech.synthesize` | `dim speech synthesize` |
+| Transcribe speech | `speech.transcribe` | `dim speech transcribe` |
+| Generate music | `music.generate` | `dim music generate` |
+| Generate audio or sound effects | `audio.generate` | `dim audio generate` |
+| Generate a 3D asset | `asset.generate` | `dim asset generate` |
+| Generate motion data | `motion.generate` | `dim motion generate` |
+
+3. Write outputs under the current workspace, usually `./artifacts/` unless the user asked for another path.
+
+4. Always use `--json`. Read output paths, provider/model ids, and errors from JSON instead of scraping human text.
+
+5. After success, reference the absolute output path. Images can be shown with Markdown image syntax. Audio and video should be reported as absolute paths until Desktop preview support is richer.
+
+## Operating Rules
+
+- If the user did not specify provider/model, use the configured default for that capability.
+- Only pass `--provider` and `--model` when the user explicitly asks for a temporary override. Overrides do not change defaults.
+- If a default is missing, tell the user to configure that capability in Settings / Agent Defaults.
+- Put provider-specific parameters in a JSON object file and pass it with `--options <path>`.
+- Video generation can be slow. Use a generous `--timeout`, and never claim completion unless an output file exists.
+- For failed commands, explain `error.code`, `error.message`, and `details` from the JSON output. Do not hide the original provider or CLI error.
+- Keep LLM model selection separate from multimodal defaults. A chat model change does not change modality defaults.
+- Do not expose API keys, credentials, headers, or provider secrets.
+
+## Recipes And References
+
+Read `references/cli-recipes.md` when you need command templates.
+
+Read `references/model-notes.md` when a provider or model may need special handling. Future model-specific reference docs should be linked from that file.
+
+## Failure Handling
+
+| Situation | Response |
+|---|---|
+| Missing default model | Ask the user to configure the capability in Settings / Agent Defaults |
+| Provider disconnected or missing key | Ask the user to check provider connection and API key |
+| Model disabled | Ask the user to enable the model in the provider model list |
+| Unsupported capability | Use a model that supports the capability, or ask the user to configure one |
+| Output file missing | Do not report success; explain the CLI JSON error and stderr |
+| Video timeout | Report timeout details and operation id when available |
+
+## Final Response Style
+
+When reporting back:
+
+- Say which capability was used.
+- Give the output file path.
+- If it failed, state the failure point and the next user action.
+- Keep the response short unless the user asks for detailed debugging.

package/bin/skills-assets/dim-modality/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Dim Modality"
+  short_description: "Use DimCode multimodal CLI"
+  default_prompt: "Use $dim-modality to create or process media with the DimCode multimodal CLI."

package/bin/skills-assets/dim-modality/references/cli-recipes.md

@@ -0,0 +1,137 @@
+# CLI Recipes
+
+Use `--json` for all agent/script calls. Prefer output paths inside the current workspace.
+
+## Check Configuration
+
+```bash
+dim modality list --json
+dim modality get image.generate --json
+```
+
+## Images
+
+Generate an image:
+
+```bash
+mkdir -p ./artifacts
+dim image generate --prompt "A clean product poster on a white background with soft natural lighting" --out ./artifacts/image.png --json
+```
+
+Edit an image:
+
+```bash
+mkdir -p ./artifacts
+dim image edit --image ./input.png --prompt "Keep the subject, change the lighting to golden hour" --out ./artifacts/edited.png --json
+```
+
+Multi-image edit:
+
+```bash
+dim image edit --image ./person.png --image ./style.png --prompt "Render the person in the illustration style of the reference image" --out ./artifacts/edited.png --json
+```
+
+Enhance an image:
+
+```bash
+dim image enhance --image ./input.png --operation upscale --out ./artifacts/upscaled.png --json
+```
+
+## Video
+
+Text-to-video:
+
+```bash
+mkdir -p ./artifacts
+dim video generate --prompt "A robot walking slowly through a rainy neon street, cinematic camera movement" --duration 5 --out ./artifacts/video.mp4 --json --timeout 1800000
+```
+
+Image-to-video:
+
+```bash
+dim video generate --prompt "Make the person turn naturally toward the camera" --image ./input.png --duration 5 --out ./artifacts/video.mp4 --json --timeout 1800000
+```
+
+Edit a video:
+
+```bash
+dim video edit --video ./input.mp4 --operation add-audio --audio ./voice.mp3 --out ./artifacts/edited.mp4 --json
+```
+
+Enhance a video:
+
+```bash
+dim video enhance --video ./input.mp4 --operation stabilize --out ./artifacts/stable.mp4 --json
+```
+
+## Speech
+
+Text-to-speech:
+
+```bash
+mkdir -p ./artifacts
+dim speech synthesize --text "Hello, this is a speech generation test." --out ./artifacts/speech.mp3 --json
+```
+
+Specify a voice:
+
+```bash
+dim speech synthesize --text "Hello, this is a speech generation test." --voice "cosyvoice2:anna" --out ./artifacts/speech.mp3 --json
+```
+
+Transcribe audio:
+
+```bash
+dim speech transcribe --audio ./meeting.mp3 --out ./artifacts/transcript.txt --json
+```
+
+## Music And Audio
+
+Generate music:
+
+```bash
+mkdir -p ./artifacts
+dim music generate --prompt "Warm lo-fi piano for a podcast intro" --title "warm intro" --out ./artifacts/music.mp3 --json
+```
+
+Generate a sound effect:
+
+```bash
+dim audio generate --operation sound-effect --prompt "Raindrops tapping on a window" --duration 8 --out ./artifacts/rain.mp3 --json
+```
+
+Extract or generate audio from video:
+
+```bash
+dim audio generate --operation video-to-audio --video ./input.mp4 --out ./artifacts/audio.mp3 --json
+```
+
+## 3D Asset And Motion
+
+```bash
+dim asset generate --prompt "low poly robot game asset" --out ./artifacts/robot.glb --json
+dim motion generate --prompt "walk cycle for a friendly robot" --out ./artifacts/walk.fbx --json
+```
+
+## Temporary Provider Or Model Override
+
+Use this only when the user explicitly asks for a specific provider or model:
+
+```bash
+dim image generate --provider siliconflow --model Qwen/Qwen-Image --prompt "..." --out ./artifacts/image.png --json
+```
+
+## Provider-Specific Options
+
+Write a JSON object file, then pass it with `--options`:
+
+```json
+{
+  "seed": 1234,
+  "negativePrompt": "blurry, low quality"
+}
+```
+
+```bash
+dim image generate --prompt "..." --options ./options.json --out ./artifacts/image.png --json
+```

package/bin/skills-assets/dim-modality/references/model-notes.md

@@ -0,0 +1,56 @@
+# Model Notes
+
+This file is the entry point for provider/model experience. When a provider or model needs special handling, add a row here and put detailed notes under `references/models/`.
+
+## Current Entries
+
+| Provider / model | Capability | Note |
+|---|---|---|
+| CosyVoice2 | `speech.synthesize` | `--voice` uses `model-name:voice-name` |
+| Video generation models | `video.generate` | Generation can take a long time; use a generous `--timeout` and keep operation id / JSON errors |
+| Image edit models | `image.edit` | Requires `--image` and `--prompt`; pass repeated `--image` flags for multi-image edit |
+| ASR models | `speech.transcribe` | Input is `--audio`; output should be a text file |
+
+## CosyVoice2 Voices
+
+CosyVoice2 `--voice` format:
+
+```text
+model-name:voice-name
+```
+
+Available voice names:
+
+```text
+alex
+benjamin
+charles
+david
+anna
+bella
+claire
+diana
+```
+
+`alex`, `benjamin`, `charles`, and `david` are male voices. `anna`, `bella`, `claire`, and `diana` are female voices.
+
+Example:
+
+```bash
+dim speech synthesize --text "Hello, this is a test." --voice "CosyVoice2:anna" --out ./artifacts/speech.mp3 --json
+```
+
+If the configured model id is not exactly `CosyVoice2`, replace the part before `:` with the configured model name or model id.
+
+## Adding Future Model Notes
+
+When adding a model note:
+
+1. Create a file under `references/models/` named after the provider and model.
+2. Add a row to the table above.
+3. Include:
+   - Supported capability.
+   - Required inputs.
+   - Recommended output format.
+   - Known slow paths or failure modes.
+   - One runnable `dim ... --json` example.

package/bin/skills-assets/dim-workflow/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: dim-workflow
+description: Use when the user asks to create, modify, or save a reusable Dim workflow script. Do not use it for running, stopping, opening, revealing, or checking workflow runs.
+---
+
+# Dim Workflow
+
+这个 skill 只用于编写可复用的 Dim 工作流文件。
+
+## 什么时候使用
+
+用户要求这些事时使用：
+
+- 创建一个可复用工作流。
+- 修改一个已保存工作流。
+- 把对话里生成的工作流保存起来以后复用。
+
+用户只是要运行、停止、打开、查看进度时不要使用：
+
+- `/workflow <name>`
+- 给工作流命令加参数。
+- 停止、打开、定位、检查某次工作流运行。
+
+## 保存位置
+
+已保存工作流放在：
+
+```text
+<workflowDataDir>/workflows/saved/
+```
+
+Desktop 默认路径：
+
+```text
+DIMCODE_HOME=~/.dimcode/v2
+workflowDataDir=<DIMCODE_HOME>/data
+saved workflows=~/.dimcode/v2/data/workflows/saved/
+```
+
+如果已知配置里的 `workflowDataDir`，使用那个绝对路径。
+
+如果不知道 `workflowDataDir`，先询问用户。不要猜项目目录，也不要把可复用工作流保存到当前仓库里。
+
+## 文件要求
+
+一个工作流一个文件：
+
+```text
+<workflowDataDir>/workflows/saved/<workflowName>.mjs
+```
+
+文件必须导出 `meta`，并默认导出一个 async function：
+
+```js
+export const meta = {
+  name: "example-workflow",
+  description: "Short user-facing description",
+}
+
+export default async function workflow(api) {
+  api.phase("Prepare")
+  await api.agent("Read the relevant docs", { label: "Read docs" })
+
+  api.phase("Implement")
+  await api.agent("Make the requested code change", { label: "Edit code" })
+
+  api.phase("Verify")
+  await api.tool("exec", { command: "pnpm test" }, { label: "Run tests" })
+
+  return { ok: true }
+}
+```
+
+规则：
+
+- `meta.name` 必须是非空且唯一的工作流名字。
+- `meta.description` 必须非空。
+- 需要 import 本地 helper 时使用 `.mjs`。
+- `.js` 和 `.ts` 只用于没有 import 的自包含脚本。
+- 用 `api.tool()` 调当前 session 的 tool。
+- 用 `api.agent()` 创建 child agent。
+- 工作流文件是 trusted code，必须把输入和路径写清楚。
+
+## 右侧面板显示要求
+
+右侧面板的阶段图来自工作流源码。想让用户看到清楚的阶段和步骤，就按下面写：
+
+- 主要阶段用 `api.phase("Prepare")`、`api.phase("Implement")`、`api.phase("Verify")` 这类调用表达。
+- 用户应该看到的步骤，用 `api.agent(prompt, { label })` 或 `api.tool(name, input, { label })` 表达。
+- 尽量使用静态的 `label`、`title`、`name` 和 tool name。也就是说，传给 API 的关键参数尽量直接写成字符串，不要依赖运行时拼接。
+- `label` 写短一点，表示这一步在做什么。
+- 主要阶段和主要步骤放在默认导出的 `workflow(api)` 函数里。
+- 可以用 helper function 处理细节，但不要把主要阶段和主要步骤全藏进 helper function。
+- `api.parallel([...])` 和 `api.mapLimit(...)` 可以表达并行和批量步骤。
+- 复杂编排优先考虑 `api.phase()`、`api.agent()`、`api.tool()`、`api.parallel()`、`api.mapLimit()` 的组合。组合不够用时，再写自定义脚本逻辑。
+- 打 log 时写清楚当前步骤和结果，内容要让用户一眼能懂。
+- 需要指定 child agent 的 provider/model 时，先查询或确认当前可用列表，再写 `providerId` 和 `modelId`。
+
+写法示意：
+
+```text
+Prepare
+  Read docs
+Implement
+  Edit code
+Verify
+  Run tests
+```
+
+对应源码里要能直接看到：
+
+```js
+api.phase("Prepare")
+await api.agent("Read the relevant docs", { label: "Read docs" })
+
+api.phase("Implement")
+await api.agent("Make the requested code change", { label: "Edit code" })
+
+api.phase("Verify")
+await api.tool("exec", { command: "pnpm test" }, { label: "Run tests" })
+```
+
+## 完成后告诉用户
+
+写入或修改已保存工作流后，告诉用户刷新 Desktop 的 workflow 列表，让 runtime 重新读取 `workflows/saved/`。

package/bin/skills-assets/dim-workflow/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Dim Workflow"
+  short_description: "Create or edit reusable Dim workflows"
+  default_prompt: "Use $dim-workflow when creating, modifying, or saving reusable Dim workflow scripts. Do not use it for normal workflow execution."
+policy:
+  allow_implicit_invocation: true

package/bin/skills-assets/docs-sprint/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: docs-sprint
+description: Docs-driven delivery workflow. Use when splitting design docs into tasks, creating implementation plans under docs/plan, executing develop/verify/merge cycles, maintaining design doc consistency, or writing UI layout documentation with ASCII diagrams.
+---
+
+# Docs Sprint
+
+Docs-driven delivery workflow — given design docs, manage the process from task split to verified merge. Agent-agnostic. Platform-specific agent configs live under `agents/`.
+
+## Role
+
+You are the orchestrator. You plan, dispatch, monitor, and merge. You do NOT write code or run tests yourself. All implementation and verification work must be delegated to sub-agents.
+
+| You do | You delegate |
+|---|---|
+| Read and update design docs | Code implementation (develop agent) |
+| Write analysis and split tasks | Code review and verification (verify agent) |
+| Check task status and dispatch | Fix blocking findings (develop agent) |
+| Execute merge and run full test | |
+| Manage recovery from interruption | |
+
+## Parallel Execution
+
+You have worktree capability. When the execution mode allows parallel dispatch, create worktrees for sub-agents following [worktree-guide.md](references/worktree-guide.md). Create the worktree before dispatching; pass the worktree path as the sub-agent's working directory.
+
+## Core Workflow
+
+1. Read `docs/INDEX.md`, then read the design docs related to the request.
+2. For planning work, read `docs/plan/README.md` and use the plan/task/review loop.
+3. For UI work, read the relevant layout docs and represent interface changes with ASCII diagrams.
+4. If implementation needs behavior missing from docs, update the design docs first and ask for confirmation before changing code.
+5. Dispatch develop agents for implementation. Dispatch verify agents for review. Do not do both in the same agent.
+6. Treat review findings as delivery gates: fix blocking findings via develop agent, archive or record non-blocking findings according to project docs.
+
+## Task Classification
+
+| Request type | Action |
+|---|---|
+| Architecture/design docs | Read [documentation-system.md](references/documentation-system.md), then update design docs |
+| Development plan or task split | Read [delivery-plan.md](references/delivery-plan.md), then create analysis/tasks/backlog entries |
+| Code implementation | Read task file and referenced design docs; follow [contract-discipline.md](references/contract-discipline.md) |
+| Review or fix review findings | Use the verify/develop loop in [delivery-plan.md](references/delivery-plan.md) |
+| UI layout docs | Read [ui-layout.md](references/ui-layout.md), then write layout definition docs with ASCII diagrams |
+
+## Documentation Rules
+
+- Keep one source of truth for each rule or process.
+- Use scope README files for ownership, relationships, state ownership, lifecycle, and cross-module flows.
+- Use module docs for local contract: inputs, outputs, state boundary, errors, extension points, and tests.
+- Prefer diagrams, tables, and explicit flow charts over broad prose.
+- Define only necessary terms. Keep terms concrete and traceable to code or user-visible behavior.
+- When docs and implementation need different behavior, update docs first.
+- Doc changes and code changes in the same task are one atomic delivery.
+
+## Implementation Rules
+
+- Follow [contract-discipline.md](references/contract-discipline.md) for type, error, and fallback rules.
+- Tests must cover contract behavior and error handling for the touched boundary.
+
+## UI Layout Rules
+
+- Show UI structure with ASCII diagrams.
+- Write each layout doc around one page or component.
+- Use this section order when it fits: overall structure, page-level layout, region layout, interactions, state variants, responsive behavior, size reference, component tree, page entry points.
+- Include input behavior, dialog/overlay layering, and loading/empty/error states.
+
+## References
+
+- `references/documentation-system.md`: docs directory structure, maintenance rules, writing style.
+- `references/delivery-plan.md`: analysis, tasks, develop/verify review loop, isolation, merge rules.
+- `references/contract-discipline.md`: type, error, fallback, and implementation discipline.
+- `references/ui-layout.md`: UI layout documentation style, ASCII diagrams, interaction contracts.
+- `references/worktree-guide.md`: worktree creation, dispatch, cleanup, and recovery.

package/bin/skills-assets/docs-sprint/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Docs Sprint"
+  short_description: "Docs-driven delivery workflow"
+  default_prompt: "Use $docs-sprint to split design docs into tasks and execute develop/verify/merge cycles."