towry · towry · Sep 27, 2025 · Sep 20, 2025 · Sep 20, 2025 · Sep 20, 2025
diff --git a/.vscode/settings.json b/.vscode/settings.json
@@ -1,3 +1,11 @@
 {
-    "kiroAgent.configureMCP": "Disabled"
-}
+    "kiroAgent.configureMCP": "Disabled",
+    "files.exclude": {
+        "**/.git": true,
+        "**/.svn": true,
+        "**/.hg": true,
+        "**/.DS_Store": true,
+        "**/Thumbs.db": true,
+        "**/*.tmTheme": true
+    }
+}
diff --git a/conf/bash/scripts/glab-new-pr.sh b/conf/bash/scripts/glab-new-pr.sh
@@ -83,31 +83,17 @@ else
     exit 1
 fi
 
-# URL encode function for special characters
-url_encode() {
-    local string="$1"
-    # Handle common characters that need encoding
-    string=$(echo "$string" | sed 's/ /%20/g')  # space
-    string=$(echo "$string" | sed 's/:/%3A/g')  # colon
-    string=$(echo "$string" | sed 's/\//%2F/g') # forward slash
-    string=$(echo "$string" | sed 's/+/%2B/g')  # plus
-    string=$(echo "$string" | sed 's/&/%26/g')  # ampersand
-    string=$(echo "$string" | sed 's/?/%3F/g')  # question mark
-    string=$(echo "$string" | sed 's/#/%23/g')  # hash
-    echo "$string"
-}
-
-# URL encode the parameters
-ENCODED_BRANCH=$(url_encode "$BRANCH")
-ENCODED_TITLE=$(url_encode "$PR_TITLE")
-ENCODED_TARGET=$(url_encode "$TARGET_BRANCH")
+# NOTE: Avoid manual URL encoding to prevent double-encoding by macOS `open` or browsers
+# Previously we encoded parameter names (merge_request%5B...%5D) and values, which resulted
+# in sequences like %255B and %252F. Use raw bracketed keys and raw values instead and let
+# the system handle proper escaping.
 
 # Construct the PR creation URL
 PR_URL="${WEB_BASE_URL}/merge_requests/new"
-PR_URL="${PR_URL}?merge_request%5Bdescription%5D="
-PR_URL="${PR_URL}&merge_request%5Bsource_branch%5D=${ENCODED_BRANCH}"
-PR_URL="${PR_URL}&merge_request%5Btarget_branch%5D=${ENCODED_TARGET}"
-PR_URL="${PR_URL}&merge_request%5Btitle%5D=${ENCODED_TITLE}"
+PR_URL="${PR_URL}?merge_request[description]="
+PR_URL="${PR_URL}&merge_request[source_branch]=${BRANCH}"
+PR_URL="${PR_URL}&merge_request[target_branch]=${TARGET_BRANCH}"
+PR_URL="${PR_URL}&merge_request[title]=${PR_TITLE}"
 
 # Debug output
 echo "Parsed web URL: $WEB_BASE_URL"

diff --git a/conf/bash/scripts/jj-ai-ci.sh b/conf/bash/scripts/jj-ai-ci.sh
@@ -98,7 +98,7 @@ debug_log "[AI-CI] Step 4/4: Generating AI commit message and applying..."
 # Prepare input for aichat - combine context with extra context if provided
 ai_input="$context_output"
 if [[ -n "$extra_context" ]]; then
-  ai_input=$(printf "%s\n\nAdditional context: %s" "$context_output" "$extra_context")
+  ai_input=$(printf "%s\nUser provided message (do not use directly): %s" "$context_output" "$extra_context")
   debug_log "[AI-CI] Including extra context in AI generation"
 fi
 

diff --git a/conf/bash/scripts/jj-commit-context.sh b/conf/bash/scripts/jj-commit-context.sh
@@ -62,13 +62,13 @@ get_revision_changes() {
     echo
 
     # Check if diff is too large
-    local diff_lines=$(jj diff --context 2 -r "$rev" --color=never --no-pager | wc -l | tr -d ' ')
+    local diff_lines=$(jj diff --context 2 -r "$rev" --color=never --no-pager | minimize-git-diff-llm | wc -l | tr -d ' ')
     local exit_code=$?
     if [ $exit_code -ne 0 ]; then
         echo "Error: jj diff | wc -l failed with exit code: $exit_code" >&2
         exit $exit_code
     fi
-    local max_diff_lines=2000  # Conservative limit for token usage
+    local max_diff_lines=5000  # Conservative limit for token usage
     local minimal_threshold=10000  # If diff is huge, use minimal output
 
     if [ "$diff_lines" -gt "$minimal_threshold" ]; then
@@ -89,9 +89,8 @@ get_revision_changes() {
         # NOTE: jj diff returns exit code 3 (not 141) when used in a pipeline with head
         # This is jj's way of handling SIGPIPE when the pipe is closed early by head
         set +o pipefail
-        jj diff --context 2 -r "$rev" --color=never --no-pager | head -n "$max_diff_lines"
+        jj diff --context 2 -r "$rev" --color=never --no-pager | minimize-git-diff-llm
         local jj_exit_code=${PIPESTATUS[0]}  # Get exit code of jj diff
-        local head_exit_code=${PIPESTATUS[1]:-0}  # Get exit code of head, default to 0 if not set
         set -o pipefail
 
         # Ignore SIGPIPE (exit code 141) and jj's exit code 3 which happens when head closes the pipe early
@@ -103,7 +102,7 @@ get_revision_changes() {
         echo "... (diff truncated - $((diff_lines - max_diff_lines)) lines omitted) ..."
     else
         echo "Full diff:"
-        jj diff --context 2 -r "$rev" --color=never --no-pager
+        jj diff --context 2 -r "$rev" --color=never --no-pager | minimize-git-diff-llm
         local exit_code=$?
         if [ $exit_code -ne 0 ]; then
             echo "Error: jj diff (full) failed with exit code: $exit_code" >&2

diff --git a/conf/llm/aichat/roles/git-commit.md b/conf/llm/aichat/roles/git-commit.md
@@ -1,7 +1,7 @@
 ---
-model: openrouter:qwen/qwen3-next-80b-a3b-instruct
+model: openrouter:x-ai/grok-4-fast
 temperature: 0.1
-top_p: 0.1
+top_p: 0.2
 stream: false
 ---
 

diff --git a/conf/llm/docs/coding-rules.md b/conf/llm/docs/coding-rules.md
@@ -6,27 +6,20 @@ Avoid over-engineering. Prefer simple, correct, and maintainable solutions.
 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 intent is unclear, list concise options and let
-   the user choose
+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: Acknowledge limitations and ask for help when stuck
-8. If you encounter a port conflict, it usually means the service is already
-   running, or you can use the `killport <port>` shell command to terminate the
-   process.
-9. Iteratively refine your solution by applying the guidelines below.
-10. DO NOT RUN commands without first explaining the purpose and expected
-    outcome
+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: "
 
 # When implementing and fixing
 
 - Clarify Requirements: Ask questions when tasks are unclear
-- Validate: Identify key requirements and edge cases
-- Break Down: Split into small, verifiable steps
+- 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
-- Do not place _mock code_ within intermediate layers. Ensure the lower-level
-  implementation is complete, and keep all mocking behavior in the topmost
-  layer.
-- Add FIXME, TODO, NOTE for important notices
+- Avoid integrating _mock code_ into intermediate layers. Ensure that the foundational implementation is finalized, and contain all mocking 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
@@ -45,6 +38,7 @@ Avoid over-engineering. Prefer simple, correct, and maintainable solutions.
 - Only modify code relevant to the task: any cross-module or cross-layer changes
   must be documented and justified.
 - Prefer simple solutions that minimize side effects and blast radius
+- Avoid writing extensive try-catch blocks that hide contract violations; instead, prefer fail-fast and allow the system to quickly detect and report errors.
 
 **Good function signature design**
 
@@ -72,21 +66,18 @@ Good: `downloadResume(candidateId, candidateName, authToken)`
 
 # When debugging
 
-1. Ensure no existing debug/dev process is running
+1. Verify that no existing debug or development processes are running
 2. Run shell command `curl -I <dev-server-address>` to check dev server before
    starting a new one
-3. Ask to commit current changes before running lint/format to avoid unexpected
+3. Ask user to commit current changes before running lint/format to avoid unexpected
    diffs
-4. Avoid inserting mock or debug code directly into implementation modules;
-   instead, use top-level scaffolding or dedicated debug modules to manage test
-   data and keep core logic clear.
 
-# When researching
+# When researching code
 
-1. Search Tools: Use `fd` for files, `rg` for content
-2. File Operations: Provide absolute file paths to MCP tools
+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. Kill by port: `killport <port>`
-5. Running shell commands: Detect current shell and use correct syntax
-6. File changed vs main: `jj df-file-base <file-path>`
-7. File changed vs previous commit: `jj df-file-prev <file-path>`
+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>`
diff --git a/conf/llm/windsurf/workflows/analyze-deadcode.md b/conf/llm/windsurf/workflows/analyze-deadcode.md
@@ -0,0 +1,26 @@
+---
+description: Analyze dead code in a codebase
+auto_execution_mode: 1
+---
+
+You are an expert software developer. Your task is to analyze dead code in a codebase. Dead code is any code that is never executed or used in the application. This includes unused functions, variables, classes, and imports.
+
+For user provided code snippets, identify any dead code. Ensure that the analysis is thorough and maintainable. If you need to understand the context of the code, use the 'search' tool to find related files or definitions, include those as well if they are also dead code.
+
+_dead code includes_:
+
+- unused imports
+- unused functions or methods
+- exported entities that are never imported elsewhere
+- variables that are declared but never used
+
+_some cases to not consider as dead code_:
+
+- code that is conditionally used (e.g., based on environment or configuration)
+- code that is part of a public library API and exported for external use
+- code that is referenced in comments or documentation
+- code that is used in dynamic contexts (e.g., via reflection or dynamic imports)
+
+When you identify dead code, provide a brief explanation of why it was identified. If you are unsure about a piece of code, leave it as is and explain your reasoning.
+
+List the modules/files you have analyzed and related files you are uncertain about, ask user for instructions on those.
diff --git a/conf/llm/windsurf/workflows/clear-log.md b/conf/llm/windsurf/workflows/clear-log.md
@@ -0,0 +1,11 @@
+---
+description: Remove debug logs
+auto_execution_mode: 1
+---
+
+Your task is to remove all debug logs from the specified files while ensuring that no other code is altered. 
+
+If the user has not specified which files to edit, ask the user for clarification. 
+
+Once changes are made, provide a list of all the files that were modified and any debug code that you were unsure about removing, marking them with: `--- NOTE: IGNORE ---`.
+
diff --git a/conf/llm/windsurf/workflows/debug-with-playwright.md b/conf/llm/windsurf/workflows/debug-with-playwright.md
@@ -0,0 +1,13 @@
+---
+description: Debug with Playwright
+auto_execution_mode: 1
+---
+
+You are a expert frontend developer, please debug the issue using playwright tool.
+
+- Do not start dev server, ask user to start it.
+- Do not rebuild, ask user to rebuild it.
+- Add logs if it helps debugging.
+- To access vue instance on dom, first select the dom element, then use `el.__vue__` to access the vue instance.
+- Your priority is to find the root cause of the issue, not to fix it.
+- You can write code to fix the issue, but do not commit it.