towry · towry · Oct 26, 2025 · Oct 24, 2025 · Oct 25, 2025 · Oct 25, 2025
diff --git a/.github/instructions/forge.md b/.github/instructions/forge.md
diff --git a/bin/darwin-nix-proxy.py b/bin/darwin-nix-proxy.py
@@ -14,7 +14,7 @@
 NIX_DAEMON_PLIST = Path("/Library/LaunchDaemons/org.nixos.nix-daemon.plist")
 NIX_DAEMON_NAME = "org.nixos.nix-daemon"
 # http proxy provided by clash or other proxy tools
-HTTP_PROXY = "http://127.0.0.1:1080"       
+HTTP_PROXY = "http://127.0.0.1:7898"       
 
 pl = plistlib.loads(NIX_DAEMON_PLIST.read_bytes())
 

diff --git a/conf/colima/colima.yaml b/conf/colima/colima.yaml
@@ -215,7 +215,7 @@ diskImage: ""
 # Default: {}
 env:
   # setup proxy
-  http_proxy: http://127.0.0.1:1080
-  https_proxy: http://127.0.0.1:1080
+  http_proxy: http://127.0.0.1:7898
+  https_proxy: http://127.0.0.1:7898
   no_proxy: localhost,127.0.0.1
 
diff --git a/conf/fish/funcs/jj-fork.fish b/conf/fish/funcs/jj-fork.fish
@@ -79,11 +79,17 @@ function jj-fork --description "Fork from a bookmark or revision"
 
     # Generate bookmark name from aichat
     echo "Generating bookmark name..."
-    set -l bookmark_name (aichat --role git-branch -S -c "$description")
+    set -l bookmark_name_raw (aichat --role git-branch -S -c "$description" | string collect)
     or return
 
+    # Trim all whitespace and replace spaces with hyphens
+    set -l bookmark_name (string trim -- $bookmark_name_raw)
+    set bookmark_name (string replace -a ' ' '-' -- $bookmark_name)
+    # Remove leading hyphens to avoid double hyphens after prefix
+    set bookmark_name (string replace -r '^-+' '' -- $bookmark_name)
+
     set -l date_now (date +%m%d%H)
-    set -l bookmark_name "towry/$bookmark_name-$date_now"
+    set bookmark_name "towry/$bookmark_name-$date_now"
 
     # Check if the bookmark name is already used
     jj --ignore-working-copy log --quiet -r $bookmark_name -n 1 > /dev/null 2>&1

diff --git a/conf/llm/aichat/roles/git-branch.md b/conf/llm/aichat/roles/git-branch.md
@@ -11,7 +11,7 @@ top_p: 0.4
 1. 如果输入不是英文，首先将其翻译成英文
 2. 使用小写字母和数字
 3. 用连字符(-)分隔单词
-4. 移除特殊字符和空格
+4. 移除特殊字符和空格，不能包含换行符
 5. 分支名称应该简洁易懂通顺，尽量修改错别单词
 6. 根据 commit message 的类型，添加适当的前缀：
    - `feat-`: 新功能

diff --git a/conf/llm/docs/coding-rules.md b/conf/llm/docs/coding-rules.md
@@ -80,11 +80,12 @@
 ## Tools available in current environment
 
 - **grep**(ast-grep): Whenever a search requires syntax-aware or structural matching, use `ast-grep run --lang ? --pattern ? [PATHS]...` (set `--lang` appropriately, default to lang in `lang` tags), fallback to text-only tool `rg`.
-- **find(fd,rg)**: To search for files, use `fd`. The `find` shell command is deprecated and removed.
+- **[find, grep](fd,rg)**: To search for files, use `fd`. The `find` shell command is deprecated and removed.
 - **Package Managers(pnpm, bun)**: Use pnpm when possible.
 - **port occupied(killport)**: To kill a process that is using a port, use `killport $port$`.
 - **shell**: The current shell is `fish`.
 - **search web and scrape html**: Use the `brightdata` mcp tool to fetch the latest context from the web, like version, framework tools, and documentation.
+- `github` mcp tool: search public GitHub repositories for code examples.
 - `gh`: github cli
 
 #### playwright mcp tool

diff --git a/conf/llm/docs/prompts/agent-maker.md b/conf/llm/docs/prompts/agent-maker.md
@@ -0,0 +1,120 @@
+# Agent Maker Guide
+
+## How to Write Agent Description
+
+Agent description is the primary way for other agents to discover and understand when to use a subagent. Follow this structure for clarity:
+
+### Structure Template
+
+```yaml
+description: |
+  Best for: [core strengths, comma-separated capabilities]
+
+  How: [work approach, tools used, constraints, input/output format]
+
+  When: [specific use cases and scenarios]
+
+  [Optional] NOT for: [explicit anti-patterns or out-of-scope tasks]
+
+  [Optional] Key rule: [critical constraints or usage guidelines]
+```
+
+### Writing Principles
+
+1. **Start with strengths** - "Best for" section lists core capabilities
+   - Use concrete, searchable terms (e.g., "code analysis" not "understanding code")
+   - Focus on what makes this agent unique
+   - 4-6 key strengths maximum
+
+2. **Explain the approach** - "How" section describes operational model
+   - Speed/cost characteristics (fast, slow, cost-effective, high-quality)
+   - Tools and permissions (read-only, can write/edit, can run commands)
+   - Input requirements (focused context, file paths, evidence)
+   - Output format (recommendations, diagrams, code, analysis)
+
+3. **Define use cases** - "When" section provides concrete scenarios
+   - Specific situations where this agent excels
+   - Avoid vague phrases like "complex tasks"
+   - Use action verbs (implementing, diagnosing, analyzing, generating)
+
+4. **Set boundaries** - "NOT for" clarifies what to avoid
+   - Prevents misuse and wasted calls
+   - Redirects to more appropriate agents when possible
+   - Examples: "NOT for: simple edits, codebase research (use sage)"
+
+5. **Keep it scannable**
+   - One sentence per section when possible
+   - Use semicolons to separate related points
+   - Avoid nested lists or long paragraphs
+   - Total description should fit in ~4-6 lines
+
+### Examples
+
+**Analysis Agent (Read-only)**:
+```yaml
+description: |
+  Best for: code analysis, documentation summarization, architecture visualization, dependency tracing.
+
+  How: read-only exploration using grep/fd for searching and Mermaid for diagrams.
+
+  When: understanding existing implementations, analyzing project structure, summarizing docs, or documenting code without making changes.
+```
+
+**Advisor Agent (Consultant)**:
+```yaml
+description: |
+  Best for: deep reasoning on complex technical decisions, multi-option architecture analysis with trade-offs, behavior-preserving code review, diagnosing root cause from evidence (logs/errors/behavior), refactoring strategy with constraints.
+
+  How: slower but high-quality analysis; requires focused context (diffs, logs, constraints); outputs structured recommendations with pros/cons and risk assessment; can search web/GitHub for latest practices but cannot run shell or write code.
+
+  When: architecture decisions, diagnosing complex issues from evidence, refactoring strategy planning, code review requiring deep analysis.
+
+  NOT for: simple edits, quick fixes, codebase research (use sage), command execution.
+
+  Key rule: Oracle is costly - provide tight scope and only necessary artifacts; ask oracle if more context needed.
+```
+
+**Execution Agent (Builder)**:
+```yaml
+description: |
+  Best for: code generation, quick implementations, small focused tasks, rapid prototyping.
+
+  How: fast and cost-effective; can write/edit code and run commands; requires concise input (prefer file paths over long content); handles one small task at a time.
+
+  When: implementing specific features, quick fixes, generating boilerplate, executing defined coding tasks with clear requirements.
+```
+
+### Common Mistakes to Avoid
+
+❌ **Vague capabilities**: "helps with coding tasks"  
+✅ **Specific strengths**: "code generation, quick implementations, rapid prototyping"
+
+❌ **Ambiguous role**: "complex debugging"  
+✅ **Clear boundary**: "diagnosing root cause from evidence (logs/errors/behavior)" + clarify it's advisory, not execution
+
+❌ **Long paragraphs**: Multiple sentences explaining nuances  
+✅ **Scannable format**: Semicolon-separated points in one line
+
+❌ **Missing constraints**: Agent has limited tools but description doesn't mention  
+✅ **Explicit limits**: "cannot run shell or write code" or "read-only agent"
+
+---
+
+## Agent Configuration Best Practices
+
+### Model Selection
+- **Analysis/Research**: Fast models (grok-code-fast, claude-3-5-sonnet)
+- **Deep Reasoning**: Powerful models (gpt-5, o3-mini with reasoning)
+- **Code Generation**: Specialized coding models (glm-4.6, deepseek-v3)
+
+### Tool Permissions
+- Only enable tools the agent needs
+- Use `permission` to deny dangerous operations
+- Read-only agents: `write: false, edit: false, bash: false`
+- Execution agents: carefully control bash permissions
+
+### Reasoning Configuration
+- `reasoningEffort: high` for complex decision-making
+- `reasoningEffort: low` for straightforward tasks
+- `reasoningSummary: concise` to avoid verbose outputs
+- `textVerbosity: low|middle|high` based on use case
diff --git a/conf/llm/opencode/agent/clerk.md b/conf/llm/opencode/agent/clerk.md
@@ -1,31 +1,15 @@
 ---
 description: |
-  Clerk is a lightweight assistant focused on repetitive, low-risk coding and documentation maintenance tasks. Its goal is to quickly and reliably handle mundane but important work, reducing developers' day-to-day maintenance burden and improving discoverability.
+  Best for: documentation maintenance (README/CHANGELOG/comments etc), small code fixes (typos/formatting/renaming), automation snippets (CI/scripts/configs), low-risk refactors, project cleanup and chores.
 
-  **Must** provide instructions based on user request
+  How: lightweight and fast; minimal viable changes; can write/edit code and docs; outputs clear list of modified files; provides 2-3 options when uncertain; must follow user instructions.
 
-  Key capabilities:
-  - Documentation maintenance: updating and proofreading README, CHANGELOG, contributing guides, comments, and templates.
-  - Small code fixes: fixing minor bugs, renaming, adding comments, formatting, and low-risk refactors.
-  - Automation snippets: generating or modifying short scripts, CI configurations, shell snippets, or config fragments.
-  - Project maintenance suggestions: small dependency fixes, cleanup recommendations, and migration hints (advisory only, not large changes).
+  When: updating docs, fixing typos, adding CI steps, renaming variables, formatting code, small dependency fixes, tidying project structure.
 
-  Use cases and trigger keywords (for easier tool indexing):
-  - Keywords: clerk, chore, maintenance, doc, refactor, lightweight, fix, chorebot, tidy, polish
-  - Example commands:
-    - "clerk: update README with usage examples"
-    - "clerk: fix typos in docs"
-    - "clerk: add lint step to CI"
+  NOT for: high-risk architectural refactors, complex business logic changes, introducing heavy dependencies.
 
-  Behavior guidelines (align with user request):
-  - Prefer minimal viable changes (small, low-risk edits).
-  - Output a clear list of modified files (affected files) and the steps taken.
-  - When uncertain, provide 2–3 options and request confirmation.
-
-  Limitations and scope:
-  - Do not perform high-risk architectural refactors or complex business-logic changes.
-  - Avoid introducing unreviewed heavy dependencies or large external changes.
-model: "github-copilot/claude-haiku-4.5"
+  Keywords: clerk, chore, maintenance, doc, lightweight, fix, tidy, polish, chorebot.
+model: "zhipuai-coding-plan/glm-4.6"
 reasoningSummary: concise
 textVerbosity: low
 tools:
@@ -37,8 +21,9 @@ tools:
   grep: true
   list: true
   glob: true
-  brightdata*: false
-  grep-code*: false
+  webfetch: false
+  brightdata*: true
+  grep-code*: true
 permission:
   edit: allow
   bash:
@@ -55,7 +40,7 @@ permission:
     "ssh-keygen": deny
     "jj commit": deny
     "jj git": deny
-mode: subagent
+mode: all
 ---
 
 # Core principles

diff --git a/conf/llm/opencode/agent/eng.md b/conf/llm/opencode/agent/eng.md
@@ -1,14 +1,14 @@
 ---
 description: |
-  Coding assistant for code generation, fast and cost-effective
-  How to use this subagent:
-  - Provide coding guidance, design decisions and specific task
-  - Keep the input concise, prefer document file path with reading guide instead of long content
-  - Only provide one task at a time
-  - Only provide one small task at a time
+  Best for: code generation, quick implementations, small focused tasks, rapid prototyping.
+
+  How: fast and cost-effective; can write/edit code and run commands; requires concise input (prefer file paths over long content); handles one small task at a time.
+
+  When: implementing specific features, quick fixes, generating boilerplate, executing defined coding tasks with clear requirements.
 model: "zhipuai-coding-plan/glm-4.6"
 reasoningSummary: concise
 textVerbosity: low
+reasoningEffort: low
 tools:
   write: true
   edit: true

diff --git a/conf/llm/opencode/agent/oracle.md b/conf/llm/opencode/agent/oracle.md
@@ -1,33 +1,23 @@
 ---
 description: >-
-  Expert advisor for complex technical decisions requiring deep reasoning.
+  Best for: researching how to implement new features, deep reasoning on complex technical decisions, multi-option architecture analysis with trade-offs, finding external best practices and solutions, behavior-preserving code review, diagnosing root cause from evidence (logs/errors/behavior), refactoring strategy with constraints.
 
-  When to use: (1) Complex debugging with unclear root cause; (2) Code review
-  requiring behavior-preservation analysis; (3) Architecture decisions with
-  multiple viable options and trade-offs; (4) Large refactors with
-  compatibility/performance constraints.
+  How: slower but high-quality analysis; searches web/GitHub for latest practices and API usage patterns; requires focused context (diffs, logs, constraints); outputs structured recommendations with pros/cons and risk assessment; cannot run shell or write code.
 
-  When NOT to use: (1) Simple edits or quick fixes; (2) Command execution
-  (oracle cannot run shell); (3) Basic grep/read tasks. (4) Files searching or codebase research.
+  When: researching implementation approaches for new features, architecture decisions, diagnosing complex issues from evidence, finding best practices and solutions, refactoring strategy planning, code review requiring deep analysis.
 
-  How to use: Provide focused context - for code review: diff + intent +
-  constraints; for debugging: logs + current behavior + what was tried + expected behavior; for
-  refactoring: code snippets + test coverage + compatibility requirements.
+  NOT for: simple edits, quick fixes, analyzing existing codebase patterns (use sage), command execution.
 
-  Output: Summary, options with pros/cons, recommendation with rationale,
-  next steps, risks/assumptions.
-
-  Rules to use oracle:
-  - Oracle is slower and costlier - keep scope tight, provide only necessary artifacts, tell oracle if it need more context, ask for it. And the caller should response for oracle's further context request.
-  - Do not ask for codebase details.
-  - Do not provide subjective analysis on the issue
+  Key rule: Oracle is costly - provide tight scope and only necessary artifacts; ask oracle if more context needed.
 mode: subagent
 model: "github-copilot/gpt-5"
 reasoningSummary: concise
 textVerbosity: middle
+reasoningEffort: high
 tools:
   write: false
   edit: false
+  bash: true
   patch: false
   read: true
   grep: true
@@ -36,6 +26,16 @@ tools:
   webfetch: false
   brightdata*: true
   grep-code*: true
+permission:
+  edit: "deny"
+  bash:
+    "*": "deny"
+    "cp": allow
+    "cat": allow
+    "head": allow
+    "tail": allow
+    "rg": allow
+    "fd": allow
 ---
 
 You are the Oracle - an expert AI advisor for complex technical decisions.
@@ -66,6 +66,7 @@ You are the Oracle - an expert AI advisor for complex technical decisions.
 - You are forbidden to use write tools; Prevent to run heavy task like code generation, debugging with tools etc.
 - If you need more context, output your requirements and finish
 - sage subagent, ask sage about codebase
+- You can only use limited bash tools: "cat", "cp", "head", "tail", "rg", "fd"
 
 # Output format (required)