towry · towry · Oct 14, 2025 · Oct 12, 2025 · Oct 12, 2025 · Oct 12, 2025
diff --git a/.claude/settings.local.json b/.claude/settings.local.json
@@ -1,7 +1,8 @@
 {
   "permissions": {
     "allow": [
-      "mcp__datetime__get-current-time"
+      "mcp__datetime__get-current-time",
+      "mcp__grep-code__searchGitHub"
     ],
     "deny": [],
     "ask": []

diff --git a/.prettierignore b/.prettierignore
@@ -1,6 +1,7 @@
 # Ghostty 配置文件
 conf/ghostty/config
 *.md
+*.hbs
 
 # 依赖目录
 node_modules/

diff --git a/conf/bash/scripts/jj-diff-window.sh b/conf/bash/scripts/jj-diff-window.sh
@@ -0,0 +1,29 @@
+#!/bin/bash
+
+# Create a temporary directory in user's home to avoid /T/ path issues
+temp_dir="/tmp/jj-diffs"
+mkdir -p "$temp_dir"
+
+# Create a temporary file for the diff output
+tempfile="$temp_dir/jj_diff_$(date +%s)_$$.diff"
+touch $tempfile
+chmod 600 $tempfile
+
+# Check if temporary file was created successfully
+if [ ! -f "$tempfile" ]; then
+    echo "Error: Failed to create temporary file"
+    exit 1
+fi
+
+# Generate the diff and save to temporary file
+if ! jj diff -r @ --no-pager --git > "$tempfile" 2>/dev/null; then
+    echo "Error: Failed to generate diff"
+    rm -f "$tempfile"
+    exit 1
+fi
+
+# Open a new Ghostty window with nvim editing the diff file
+# Do not contains "/T/", ghostty will ask for permission to execute this Faile
+# strange
+echo "$tempfile"
+ghostty -e nvim "$tempfile"
diff --git a/conf/fish/funcs/jj-fork.fish b/conf/fish/funcs/jj-fork.fish
@@ -83,7 +83,7 @@ function jj-fork --description "Fork from a bookmark or revision"
     or return
 
     set -l date_now (date +%m%d%H)
-    set -l bookmark_name "$bookmark_name-$date_now"
+    set -l 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
@@ -13,8 +13,7 @@ top_p: 0.4
 3. 用连字符(-)分隔单词
 4. 移除特殊字符和空格
 5. 分支名称应该简洁易懂通顺，尽量修改错别单词
-6. 使用 `towry/` 作为前缀
-7. 根据 commit message 的类型，添加适当的前缀：
+6. 根据 commit message 的类型，添加适当的前缀：
    - `feat-`: 新功能
    - `fix-`: 修复
    - `chore-`: 维护
@@ -23,7 +22,7 @@ top_p: 0.4
    - `refactor-`: 重构
    - `perf-`: 性能优化
    - `test-`: 测试
-8. 分支名称长度不应过长，减少不必要的动词来控制长度，最好控制在50个字符以内
-9. 重要: 只返回一个分支名称，不要包含任何解释或其他文本以及换行符号
+7. 分支名称长度不应过长，减少不必要的动词来控制长度，最好控制在50个字符以内
+8. 重要: 只返回一个分支名称，不要包含任何解释或其他文本以及换行符号
 
-一个完整的分支名称示例：towry/feat-add-dark-mode-support
+一个完整的分支名称示例：feat-add-dark-mode-support
diff --git a/conf/llm/docs/coding-rules.md b/conf/llm/docs/coding-rules.md
@@ -1,34 +1,33 @@
-# Critical and general rules
+# Core Principles
 
 Avoid over-engineering. Prefer simple, correct, and maintainable solutions.
 
-1. Be Organized: Use numbered lists for options, steps, or requirements
-2. Be Transparent: Use FIXME, TODO, NOTE when relevant
-3. Be Clear: Document assumptions and requirements briefly in comments
-4. Gather Context: Ask for missing info before implementing
-5. Explicit over Implicit: If the intent is unclear, provide a list of guessed options and allow the user to make a selection
-6. Separation of Concerns: Keep boundaries clear; confirm before crossing layers
-7. Be Humble: Recognize your limitations and seek assistance when facing challenges
-8. Seek user approval for your implementation plan before proceeding
-9. Correct user's English grammar and spelling mistakes, ensuring not to alter any quoted or copied content such as code snippets, by starting with "Let's rephrase for clarity: "
+- use existing fd, rg modern command tools, do not use find, grep that are not installed.
+- When search files, grep for file content, use `fd` and `rg` instead of `find` and `grep`, `find` or `grep` is not installed.
+- Prioritize project conventions over general best practices
+- *Maintainability*: Long-term convenience over short-term hacks
+- Avoid over-engineering and unnecessary complexity
+- *Pragmatic Solutions*: Favor obviously correct code over clever tricks
+- Ensuring every abstraction justifies
+- Complexity is only introduced when it solves real problems
+- Be Organized: Use numbered items format when providing options or steps
+- Gather Context: Ask for missing info before implementing
+- Explicit over Implicit: If the intent is unclear, provide a list of guessed options and allow the user to make a selection
+- Separation of Concerns: Keep boundaries clear; confirm before crossing layers
+- Be Humble: Recognize your limitations and seek assistance when facing challenges, use `brightdata` mcp tool when you lacking knowledge in a specific area, or you not familiar with the latest trends and best practices, tool uses, libraries, or frameworks.
+- Ask user approval after plan is approved with "Do you want me to proceed with the implementation?"
+- Correct user's English grammar and spelling mistakes, ensuring not to alter any quoted or copied content such as code snippets, by starting with "Let's rephrase for clarity: "
 
 # When implementing and fixing
 
 - Clarify Requirements: Ask questions when tasks are unclear
 - Validate Requirements: Identify key specifications and edge cases
 - Break Down Tasks: Split complex tasks into small, verifiable steps for better clarity and manageability
-- Consider Scope: Check impact on surrounding code
-- Avoid integrating _mock code_ into intermediate layers. Ensure that the foundational implementation is finalized, and contain all mocking behavior in the highest layer.
+- Consider Scope: check impact on surrounding code
+- Avoid integrating _mock code_ or _demo code_ into intermediate layers. Ensure that the foundational implementation(components, modules) is finalized, and contain all mocking/demo behavior in the highest layer.
 - Use annotations like FIXME, TODO, and NOTE to highlight areas that require attention, further improvement, or documentation for future reference
-- Write helpful comments for “why”, prefer self-documenting code for “what”
-- Prioritize correctness and clarity over micro-optimizations
-- Follow DRY pragmatically: apply SOLID principles when they improve readability
-  and maintainability; avoid unnecessary abstractions that do not solve a clear
-  problem.
 - Use descriptive constants instead of magic numbers (e.g., const MAX_RETRIES =
   3).
-- Preserve existing structure and style unless they contradict project standards
-  or cause readability/maintainability issues.
 - Prefer dependency injection and localized state over globals: allow direct
   access in small standalone scripts or configuration files where DI overhead
   outweighs its benefit.
@@ -39,7 +38,6 @@ Avoid over-engineering. Prefer simple, correct, and maintainable solutions.
 - Prefer simple solutions that minimize side effects and blast radius
 - **Fail Fast, Don't Hide Bugs**: Avoid using try-catch blocks, optional chaining (`?.`), or other defensive coding techniques to silence errors that indicate a contract violation. Instead, prefer fail-fast and allow the system to quickly detect and report errors. If an object is expected to have a certain method or property, its absence is a bug that should be surfaced immediately. Hiding such errors leads to deferred failures that are much harder to debug.
 
-
 **Good function signature design**
 
 - Pass only needed primitives, not entire objects
@@ -72,13 +70,24 @@ Good: `downloadResume(candidateId, candidateName, authToken)`
 3. Ask user to commit current changes before running lint/format to avoid unexpected
    diffs
 
-# When researching code
-
-1. *Shell* Utilize `fd` to find files and `rg` to search within file contents
-2. *MCP tools* When using MCP tools, provide absolute file paths
-3. Package Managers: Detect the correct one (npm/pnpm/yarn)
-4. *Shell* Kill process that owning a port: `killport <port>`
-5. *Shell* Running shell commands: Use shell commands in fish shell
-6. *Git* View file changed vs main in git repo: `jj df-file-base <file-path>`
-7. *Git* View file changed vs previous commit in git repo: `jj df-file-prev <file-path>`
-8. Use brightdata mcp tool to fetch latest context from the web, like version, framework tools, documentation.
+# When researching/refactoring code
+
+Your bash environment has access to some useful non-default tools:
+
+- *MCP tools* When using MCP tools, provide absolute file paths
+- Package Managers: Detect the correct one (npm/pnpm/yarn)
+- *killport*: Kill process that owning a port: `killport <port>`
+- *fish*: the default shell is fish
+- *Git* View file changed vs main in git repo: `jj df-file-base <file-path>`
+- *Git* View file changed vs previous commit in git repo: `jj df-file-prev <file-path>`
+- *brightdata* mcp tool to fetch latest context from the web, like version, framework tools, documentation.
+- "fd" is a simple, fast and user-friendly alternative to "find". 
+- "rg" (ripgrep) is a line-oriented search tool that recursively searches the current directory for a regex pattern. It is similar to "grep", but faster and more user-friendly.
+- `ast-grep`. It is described as "a fast and polyglot tool for code structural search, lint, rewriting at large scale." More info at https://ast-grep.github.io/llms.txt
+- `fastmod` is a code modification tool forked from codemod. Very useful for large refactors or refactoring code. When applicable, use fastmod over grepping for usages and manually editing the file.
+- `concurrently` is a tool to run multiple commands concurrently. Useful for starting dev server and running tests/watchers in parallel.
+- `jq` is a lightweight and flexible command-line JSON processor. Useful for parsing and manipulating JSON data in shell scripts or command line.
+- `bun` and `bunx` are modern JavaScript runtimes and package managers. They are designed to be fast and efficient, with a focus on performance and developer experience.
+- `pnpm` is a fast, disk space efficient package manager. It is an alternative to npm and yarn, and is designed to be faster and more efficient.
+- `watchexec` is a tool to run commands when files change. Useful for running tests or linters when code changes.
+- `scc` is a tool to count lines of code. Useful for getting a quick overview of the size of a codebase.
diff --git a/conf/llm/opencode/agent/designer.md b/conf/llm/opencode/agent/designer.md