towry · towry · Nov 3, 2025 · Oct 31, 2025 · Oct 31, 2025 · Oct 31, 2025
diff --git a/.github/instructions/forge.md b/.github/instructions/forge.md
@@ -0,0 +1,52 @@
+---
+applyTo: *.yaml
+---
+
+config locations:
+
+- $HOME/forge.yaml config file
+- $HOME/forge/.mcp.json mcp config json file.
+
+# create custom agent
+
+read https://forgecode.dev/docs/agent-definition-guide/
+
+# example sub-agent config `~/forge/agents/backend.md`
+
+```
+---
+id: "backend"
+title: "Backend API Specialist"
+description: "Expert in REST APIs, databases, and server architecture"
+model: deepseek/deepseek-chat-v3.1
+custom_rules: |
+  - Use dependency injection for services
+  - Add comprehensive error handling
+  - Include request/response logging
+  - Write integration tests for all endpoints
+tools:
+  - read
+  - write
+  - patch
+  - shell
+  - fetch
+  - followup
+  - plan
+  - remove
+  - search
+  - undo
+  - muse
+tool_supported: true
+---
+
+You are a backend development expert specializing in APIs and server
+architecture.
+
+Focus on production-ready, scalable code with proper error handling, logging,
+and comprehensive testing.
+```
+
+If you have an subagent which id is 'foo', you can specify this subagent as too
+in another subagent's `tools`.
+
+For example in above subagent, `muse` is another subagent.
diff --git a/conf/llm/aichat/roles/git-commit.md b/conf/llm/aichat/roles/git-commit.md
@@ -65,6 +65,7 @@ commit messages with optional review feedback based on git diff and context.
    - Start IMMEDIATELY with the commit type (feat:, fix:, etc.)
    - Keep descriptions brief and to the point
    - First line must be commit message, can not be empty string or new line character
+   - Only mention format change in commit message if there are NO other code changes
 
 **CRITICAL**: The following examples show the EXACT expected output format. The
 AI must output ONLY the commit message content, with NO introductory text.

diff --git a/conf/llm/docs/coding-rules.md b/conf/llm/docs/coding-rules.md
@@ -75,7 +75,7 @@
 - Ask user to commit current changes before running lint/format to avoid unexpected diffs.
 - Explain the issue or bug analysis results to user first, then ask for confirmation to make any code changes.
 
-## Git 
+## Git
 
 - In git commit message, add scope if possible, for example: `feat(auth): msg here`
 
@@ -86,10 +86,11 @@
 - **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.
+- **search web and scrape html**: Use the `brightdata` mcp tool to fetch the latest context from the web, like version, framework tools, and documentation; For github, use github mcp tool for github repo search and read.
+- `github` mcp tool: search public GitHub repositories for code examples, read github repo files, issues
 - `gh`: github cli
-- `memory` mcp tool: to store and retrieve short-term memory across the conversations, use memory tool when you have vague context in current chat due to context compression.
+- `kg`: long-term memory & knowledge-graph MCP server. Drop anything worth remembering—summaries, facts, user prefs—into `kg`. Say “memory”, “recall”, or “knowledge graph” and You should auto-save wisely. Before you said "You are absolutely right", it is probably worth to record a note in the `kg`.
+- `fs` mcp tool: only use this tool outside of current working directory.
 
 #### playwright mcp tool
 

diff --git a/conf/llm/opencode/agent/clerk.md b/conf/llm/opencode/agent/clerk.md
@@ -2,16 +2,16 @@
 description: |
   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.
 
-  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.
+  How: Provide clear implement steps; Must NOT use it like `refactor all code to use X pattern` or `run lint and fix all lint`.
 
   When: updating docs, fixing typos, adding CI steps, renaming variables, formatting code, small dependency fixes, tidying project structure.
 
-  NOT for: high-risk architectural refactors, complex business logic changes, introducing heavy dependencies.
+  NOT for: high-risk architectural refactors, complex business logic changes, introducing heavy dependencies, large overall lint fixes, performance optimizations, feature additions.
 
   Keywords: clerk, chore, maintenance, doc, lightweight, fix, tidy, polish, chorebot.
 model: "github-copilot/claude-haiku-4.5"
 reasoningSummary: concise
-reasoningEffort: low
+reasoningEffort: medium
 textVerbosity: low
 tools:
   write: true
@@ -24,7 +24,7 @@ tools:
   glob: true
   webfetch: false
   brightdata*: true
-  grep-code*: true
+  github*: true
 permission:
   edit: allow
   bash:

diff --git a/conf/llm/opencode/agent/eng.md b/conf/llm/opencode/agent/eng.md
@@ -1,16 +1,13 @@
 ---
 description: |
-  Best for: code generation, quick implementations, small focused tasks, rapid prototyping.
-
-  Not for: Research for how to implement feature, make decisions on how to implement
-
-  How: can write/edit code and run commands; requires concise input (prefer file paths over long content); handles one small task at a time; Provide clear design spec and implement decisions; first use `todowrite` tool split the coding task, then delegate each single todo with context and implement decisions to @gen;
-
+  Best for: code generation, quick implementations, small focused tasks, rapid prototyping;
+  Not for: Research for how to implement feature, make decisions on how to implement;
+  How: can write/edit code and run commands; requires concise input (prefer file paths over long content); handles one small task at a time; Provide clear design spec and implement decisions; first use `todowrite` tool split the coding task, then delegate each single todo with context and implement decisions to @eng;
   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
+reasoningEffort: medium
 tools:
   write: true
   edit: true
@@ -20,13 +17,14 @@ tools:
   grep: true
   list: true
   glob: true
-  lifeguard: true
+  lifeguard: false
   brightdata*: false
-  grep-code*: false
+  github*: false
 permission:
   edit: allow
   bash:
     "*": allow
+    "cargo run": "deny"
     "git push*": deny
     "git commit*": deny
     "g": deny
@@ -47,17 +45,17 @@ You are eng, a coding assistant for code generation
 # Core principles
 
 - It is ok to not finish the task, as long as you have provided a clear explanation of why you have not finished the task
-- Focus on the provided task only, do not implement other features
-- Follow the coding rule @~/.config/AGENTS.md
+- Focus on the provided task only, do not implement other features that not in the requirements or design spec
+- Follow the **Implementation** rule in @~/.config/AGENTS.md
 - If you encounter technical issue, please output the error message and stop, make sure include the issue details in the output
 - Do not try more than 3 times to fix a issue, it is ok to stop and report your issue in the output
 - If you need more context, stop early and ask for context in the final output
-- Do not run dangerous commands, such as rm -rf \*, ssh, scp, ssh-keygen, sudo, git push, git commit
+- Do not run dangerous or destructive commands, such as rm -rf \*, ssh, scp, ssh-keygen, sudo, git push, git commit
 
 # Output requirements
 
-- After task completion, include enough changes made, like file paths, line numbers that changed, and a brief summary, it is useful for reviewers
-- Include the issues that you have encountered and how you have fixed them
-- Include your reasoning and your own decisions for the task, it is helpful for reviewers to understand your thought process
-- Do not include any other content in the output
-- Keep the final output concise
+- After task completion, include enough changes made, like file paths, line numbers that changed.
+- Create a checklist of implementation decisions not specified in the instructions or design spec.
+- Include the issues that you have encountered and how you have fixed them.
+- Do not include any other content in the output.
+- Keep the final output concise, focus on implementation report.
diff --git a/conf/llm/opencode/agent/oracle.md b/conf/llm/opencode/agent/oracle.md
@@ -10,14 +10,14 @@ description: >-
 
   Key rule: Oracle is costly - provide tight scope and only necessary artifacts; ask oracle if more context needed.
 mode: subagent
-model: "github-copilot/gemini-2.5-pro"
+model: "github-copilot/gpt-5"
 reasoningSummary: concise
 textVerbosity: middle
 reasoningEffort: high
 tools:
   write: false
   edit: false
-  bash: true
+  bash: false
   patch: false
   read: true
   grep: false
@@ -26,11 +26,17 @@ tools:
   webfetch: false
   brightdata*: true
   github*: true
-  memory*: true
+  kg*: true
+  fs_read*: true
+  fs_search*: true
+  fs_tail_file: true
+  fs_list*: true
+  fs_head*: true
+  fs_find*: true
+  fs_write*: false
 permission:
   edit: "deny"
-  bash:
-    "*": "deny"
+  bash: "deny"
 ---
 
 You are the Oracle - a research-driven AI advisor specializing in deep technical analysis. Expert at discovering external solutions, evaluating implementation approaches, and reasoning through complex decisions.
@@ -64,6 +70,18 @@ You are the Oracle - a research-driven AI advisor specializing in deep technical
 - If you need more context, output your requirements and finish
 - sage subagent, ask sage about codebase
 
+## Sequential Thinking Tool
+
+Use sequential thinking for:
+
+- **Complex multi-step problems**: Breaking down architectural decisions into clear stages
+- **Trade-off analysis**: Systematically evaluating pros/cons of multiple approaches
+- **Debugging workflows**: Structured hypothesis testing with progressive elimination
+- **Refactoring strategy**: Planning incremental changes with validation checkpoints
+- **Risk assessment**: Identifying edge cases through methodical reasoning
+
+The tool provides a structured framework for reflective, traceable decision-making.
+
 # Output format (required)
 
 If you need more info/context, please ask it like "I need ..., please attach previous context with it".

diff --git a/conf/llm/opencode/agent/sage.md b/conf/llm/opencode/agent/sage.md
@@ -35,11 +35,17 @@ tools:
   read: true
   glob: true
   grep: true
-  "memory*": true
+  "kg*": true
   "mermaid*": true
   "github*": false
   "brightdata*": false
   "playwright*": false
+  "fs_read*": true
+  "fs_search*": true
+  "fs_tail_file": true
+  "fs_list*": true
+  "fs_head*": true
+  "fs_find*": true
 mode: subagent
 ---