Config.toml

[welcome]
banner = ["Carry", "Code"]
tips = []
theme = "carrycode-dark"

[agent]
default_agent_mode = "build"    # "build", "plan"
default_approvle_mode = "agent" # "read-only", "agent", "agent-full"

[tool_bash]
tool_name = "bash"
tool_kind = "Execute"
tool_operation = "Bash"
banned_commands = [
  "alias",
  "curl",
  "curlie",
  "wget",
  "axel",
  "aria2c",
  "nc",
  "telnet",
  "lynx",
  "w3m",
  "links",
  "httpie",
  "xh",
  "http-prompt",
  "chrome",
  "firefox",
  "safari",
]
safe_read_only_commands = [
  "gcc",
  "npm",
  "cargo",
  "ls",
  "echo",
  "pwd",
  "date",
  "cal",
  "uptime",
  "whoami",
  "id",
  "groups",
  "env",
  "printenv",
  "set",
  "unset",
  "which",
  "type",
  "whereis",
  "whatis",
  "uname",
  "hostname",
  "df",
  "du",
  "free",
  "top",
  "ps",
  "kill",
  "killall",
  "nice",
  "nohup",
  "time",
  "timeout",
  "git status",
  "git log",
  "git diff",
  "git show",
  "git branch",
  "git tag",
  "git remote",
  "git ls-files",
  "git ls-remote",
  "git rev-parse",
  "git config --get",
  "git config --list",
  "git describe",
  "git blame",
  "git grep",
  "git shortlog",
  "ls",
  "stat",
  "file",
  "cat",
  "less",
  "more",
  "head",
  "tail",
  "wc",
  "grep",
  "uname",
  "uptime",
  "free",
  "lscpu",
  "ps",
  "top",
  "pidof",
  "pstree",
  "df",
  "du",
  "lsblk",
  "mount",
  "ip",
  "ss",
  "ping",
  "id",
  "whoami",
  "groups",
  "who",
]
description = '''
[CORE SYSTEM] Executes a single bash command in a persistent shell session. Best for builds, scripts, dependency installs, and environment checks.

Positioning & usage:
- Provide the required command and an optional timeout_ms.
- Verify paths and files with tool_ls/tool_view before writing or deleting.
- Chain multiple commands with '&&' or ';' (no raw newlines).

Capabilities:
- Reuses the same shell session (env vars, venvs, and cwd persist).
- Captures stdout/stderr for diagnostics.
- Enforces timeouts (up to 600000ms) to prevent hangs.

Limitations:
- Banned commands list: %s.
- Output longer than %d characters is truncated.
- Not suitable for interactive commands or tools that require a TTY.
- Do not use find/grep/cat/head/tail/ls for search or reading; use tool_glob/tool_grep/tool_view/tool_ls instead.

Safety & workflow:
- Prefer read-only checks or dry-runs before destructive commands.
- Use absolute paths to avoid state drift from cd.
- For toolchains, confirm flags with --help/--version first.

Usage notes:
- The command argument is required.
- timeout_ms is optional (up to 600000ms / 10 minutes). If omitted, commands time out after 30 minutes.
- You MUST avoid using search commands like 'find' and 'grep'. Use tool_glob/tool_grep or agent tools instead.
- You MUST avoid read tools like 'cat', 'head', 'tail', and 'ls'; use tool_view and tool_ls instead.
- Separate multiple commands with ';' or '&&' (no raw newlines; newlines are OK inside quoted strings).
- All commands share the same shell session; environment variables and current directory persist between calls.
- Maintain the working directory by using absolute paths; only use 'cd' when the user explicitly asks.

<good-example>
pytest /foo/bar/tests
</good-example>
<bad-example>
cd /foo/bar && pytest tests
</bad-example>

# Committing changes with git

When the user asks you to create a new git commit, follow these steps carefully:

1. Start with a single message that contains exactly three tool_use blocks that do the following (it is VERY IMPORTANT that you send these tool_use blocks in a single message, otherwise it will feel slow to the user!):
 - Run a git status command to see all untracked files.
 - Run a git diff command to see both staged and unstaged changes that will be committed.
 - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.

2. Use the git context at the start of this conversation to determine which files are relevant to your commit. Add relevant untracked files to the staging area. Do not commit files that were already modified at the start of this conversation, if they are not relevant to your commit.

3. Analyze all staged changes (both previously staged and newly added) and draft a commit message. Wrap your analysis process in <commit_analysis> tags:

<commit_analysis>
- List the files that have been changed or added
- Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.)
- Brainstorm the purpose or motivation behind these changes
- Do not use tools to explore code, beyond what is available in the git context
- Assess the impact of these changes on the overall project
- Check for any sensitive information that shouldn't be committed
- Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
- Ensure your language is clear, concise, and to the point
- Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.)
- Ensure the message is not generic (avoid words like "Update" or "Fix" without context)
- Review the draft message to ensure it accurately reflects the changes and their purpose
</commit_analysis>

4. Create the commit with a message ending with:
🤖 Generated with carrycode
Co-Authored-By: carrycode <noreply@carrycode.ai>

- In order to ensure good formatting, ALWAYS pass the commit message via a HEREDOC, a la this example:
<example>
git commit -m "$(cat <<'EOF'
 Commit message here.

 🤖 Generated with carrycode
 Co-Authored-By: carrycode <noreply@carrycode.ai>
 EOF
 )"
</example>

5. If the commit fails due to pre-commit hook changes, retry the commit ONCE to include these automated changes. If it fails again, it usually means a pre-commit hook is preventing the commit. If the commit succeeds but you notice that files were modified by the pre-commit hook, you MUST amend your commit to include them.

6. Finally, run git status to make sure the commit succeeded.

Important notes:
- When possible, combine the "git add" and "git commit" commands into a single "git commit -am" command, to speed things up
- However, be careful not to stage files (e.g. with 'git add .') for commits that aren't part of the change, they may have untracked files they want to keep around, but not commit.
- NEVER update the git config
- DO NOT push to the remote repository
- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.
- If there are no changes to commit (i.e. no untracked files and no modifications), do not create an empty commit
- Ensure your commit message is meaningful and concise. It should explain the purpose of the changes, not just describe them.
- Return an empty response - the user will see the git output directly

# Creating pull requests
Use the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a Github URL use the gh command to get the information needed.

IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:

1. Understand the current state of the branch. Remember to send a single message that contains multiple tool_use blocks (it is VERY IMPORTANT that you do this in a single message, otherwise it will feel slow to the user!):
 - Run a git status command to see all untracked files.
 - Run a git diff command to see both staged and unstaged changes that will be committed.
 - Check if the current branch tracks a remote branch and is up to date with the remote, so that you know if you need to push to the remote
 - Run a git log command and 'git diff main...HEAD' to understand the full commit history for the current branch (from the time it diverged from the 'main' branch.)

2. Create new branch if needed

3. Commit changes if needed

4. Push to remote with -u flag if needed

5. Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (not just the latest commit, but all commits that will be included in the pull request!), and draft a pull request summary. Wrap your analysis process in <pr_analysis> tags:

<pr_analysis>
- List the commits since diverging from the main branch
- Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.)
- Brainstorm the purpose or motivation behind these changes
- Assess the impact of these changes on the overall project
- Do not use tools to explore code, beyond what is available in the git context
- Check for any sensitive information that shouldn't be committed
- Draft a concise (1-2 bullet points) pull request summary that focuses on the "why" rather than the "what"
- Ensure the summary accurately reflects all changes since diverging from the main branch
- Ensure your language is clear, concise, and to the point
- Ensure the summary accurately reflects the changes and their purpose (ie. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.)
- Ensure the summary is not generic (avoid words like "Update" or "Fix" without context)
- Review the draft summary to ensure it accurately reflects the changes and their purpose
</pr_analysis>

6. Create PR using gh pr create with the format below. Use a HEREDOC to pass the body to ensure correct formatting.
<example>
gh pr create --title "the pr title" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>

## Test plan
[Checklist of TODOs for testing the pull request...]

🤖 Generated with carrycode
EOF
)"
</example>

Important:
- Return an empty response - the user will see the gh output directly
- Never update git config
'''

[tool_diagnostics]
tool_name = "diagnostics"
tool_kind = "Search"
tool_operation = "Explored"
description = '''
[CORE SYSTEM] Diagnostics aggregation tool for quick visibility into errors, warnings, and hints at file or project scope.

Positioning & usage:
- Provide a file path for single-file diagnostics; leave empty for project-wide checks.
- Results are grouped by severity to help prioritize fixes.

Capabilities:
- Returns structured error/warn/hint entries.
- Useful as a fast regression gate after edits.

Limitations:
- Only covers diagnostics from enabled LSP clients.
- Does not suggest fixes; pair with other tools to resolve issues.

Tips:
- Re-run after each fix batch to confirm no regressions.
- Combine with tool_view/tool_grep to jump to context quickly.
'''

[tool_edit]
tool_name = "edit"
tool_kind = "Edit"
tool_operation = "Edited"
description = '''
[CORE SYSTEM] Precise text-editing tool for replacing a snippet, creating a new file, or deleting a fragment.

Positioning & usage:
- Best for small, targeted changes; use tool_write for full-file rewrites.
- Read context with tool_view first; verify directories with tool_ls when creating files.

Input requirements:
1) file_path: absolute path.
2) old_string: must match the file exactly.
3) new_string: replacement text.

Capabilities:
- Replaces a single match to avoid accidental edits.
- Supports create (empty old_string) and delete (empty new_string).

Limitations:
- old_string must be unique; multiple matches require separate calls.

Tips:
- Include 3–5 lines of surrounding context to guarantee uniqueness.
- Keep formatting consistent and ensure the code still builds.
'''

[tool_fetch]
tool_name = "fetch"
tool_kind = "Fetch"
tool_operation = "Explored"
description = '''
[CORE SYSTEM] URL fetch tool that returns content in a chosen format. Ideal for public docs, API responses, and web pages.

Positioning & usage:
- Provide the URL and desired format (text/markdown/html).
- Set a timeout when the source is slow or unreliable.

Capabilities:
- Follows redirects automatically.
- Normalizes output for downstream processing.

Limitations:
- 5MB response cap; HTTP/HTTPS only.
- No authentication, cookies, or login flows.
- Some sites may block automated requests.

Tips:
- Prefer text for APIs/plain text, html for structure, markdown for display-ready content.
'''

[tool_glob]
tool_name = "glob"
tool_kind = "Search"
tool_operation = "Explored"
description = '''
[CORE SYSTEM] Filename/path pattern matcher for quickly locating files that match a glob.

Positioning & usage:
- Provide a glob pattern; optionally set a starting directory.
- Use it to narrow scope before running tool_grep.

Capabilities:
- Supports **, *, ?, and [] wildcards.
- Returns results sorted by newest modification time.

Limitations:
- Max 100 results.
- Does not search file contents.
- Hidden files are skipped by default.

Tips:
- If truncated, tighten the pattern or directory.
- Pair with tool_grep for fast content discovery.
'''

[tool_grep]
tool_name = "grep"
tool_kind = "Search"
tool_operation = "Explored"
description = '''
[CORE SYSTEM] Content search tool for locating files that contain a regex or literal match.

Positioning & usage:
- Provide a regex; for plain text use literal_text=true.
- Use include patterns to restrict the search scope.

Capabilities:
- Great for function names, error strings, or configuration keys.
- Returns matching file paths sorted by recent changes.

Limitations:
- Max 100 results; large binaries may be skipped.
- Hidden files are skipped by default.

Tips:
- Run tool_glob first to limit scope, then tool_grep.
- Use literal_text=true for strings with special characters.
'''
[tool_ls]
tool_name = "ls"
tool_kind = "Search"
tool_operation = "Explored"
max_ls_files = 1000
default_ignore = [
  "node_modules/**",
  "__pycache__/**",
  ".git/**",
  "*.pyc",
  ".DS_Store",
  "target/**",
  "dist/**",
  "build/**",
  ".vscode/**",
  ".idea/**",
]
description = '''
[CORE SYSTEM] Directory tree viewer for quick understanding of project layout.

Positioning & usage:
- Provide a path (defaults to cwd) and optional ignore patterns.
- Outputs a tree structure for fast navigation.

Capabilities:
- Skips hidden and common cache directories by default.
- Supports ignore patterns to reduce noise.

Limitations:
- Max 1000 items; large trees are truncated.
- No file size/permission metadata.

Tips:
- Combine with tool_glob/tool_grep for deeper exploration.
- If output is too large, narrow the path or ignore list.
'''

[tool_todo_write]
tool_name = "todo_write"
tool_kind = "Todo"
tool_operation = "Todo"
description = '''
[CORE SYSTEM] Task list tool for breaking down multi-step work and tracking progress over time.

Positioning & usage:
- Use for tasks with 3+ steps or multiple parallel items.
- Update status when starting and finishing each item.

Capabilities:
- Makes progress and dependencies visible.
- Supports plan adjustments during execution.

Limitations:
- Overkill for single, trivial tasks.

Tips:
- Use action-oriented titles and concise descriptions.
- Capture risks or prerequisites in the description.
'''

[tool_view]
tool_name = "view"
tool_kind = "Read"
tool_operation = "Explored"
description = '''
[CORE SYSTEM] File viewer that outputs line numbers for reliable context and edits.

Positioning & usage:
- Provide a file path; use offset/limit to read sections.
- Ideal for source code, configs, and logs.

Capabilities:
- Line-numbered output for precise edits.
- Partial reads and long-line truncation to stay responsive.

Limitations:
- 250KB file cap, 2000-line default limit.
- No binary or image rendering.

Tips:
- Use tool_grep to find the spot, then tool_view for context.
- For large files, read in chunks with offset.
'''

[tool_write]
tool_name = "write"
tool_kind = "Edit"
tool_operation = "Edited"
description = '''
[CORE SYSTEM] File writer for creating new files or overwriting entire files with new content.

Positioning & usage:
- Provide file_path and the full content payload.
- Read existing files with tool_view before overwriting.

Capabilities:
- Auto-creates parent directories.
- Skips writes when content is unchanged.

Limitations:
- No append mode; rewrites the whole file.
- Prefer read-before-write to avoid clobbering concurrent edits.

Tips:
- Use tool_ls to confirm the destination directory.
- Write complete content in one pass to avoid partial updates.
'''


[lsp]
enabled = true
timeout_ms = 10000

[[lsp.servers]]
name = "rust-analyzer"
command = "rust-analyzer"
file_extensions = ["rs"]
root_markers = ["Cargo.toml"]

[prompt_plan]
enabled = true
prompt_name = "plan"
prompt_template = '''
You are a software engineering expert assistant, skilled at completing a range of software development tasks. Here are the requirements for you:
**You are now in read-only mode**, you read file and analyze the project and give your plan by user's request.
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. Understand & Strategize: Think about the user's request and the relevant codebase context. When the task involves complex refactoring, codebase exploration or system-wide analysis, your first and primary action must be to delegate to the 'codebase_investigator' agent using the 'delegate to agent' tool. Use it to build a comprehensive understanding of the code, its structure, and dependencies. For simple, targeted searches (like finding a specific function name, file path, or variable declaration), you should use 'grep' or 'glob' directly. Use 'view_tool' to understand context and validate any assumptions; if you need multiple files, make multiple calls.
2. Plan: Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. If 'codebase_investigator' was used, do not ignore the output of the agent, you must use it as the foundation of your plan. For complex tasks, break them down into smaller, manageable subtasks and use the `todo_write` tool to track your progress. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. Implement: Use the available tools (e.g., 'bash', 'write', 'bash' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
4. Verify (Tests): If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
5. Verify (Standards): VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards.
6. Finalize: After all verification passes, consider the task complete. Do not remove or revert any changes or created files (like tests). Await the user's next instruction.
7. Keep your output professional, concise, and efficient; avoid including emojis or emoticons.
'''

[prompt_build]
enabled = true
prompt_name = "build"
prompt_template = '''
## New Applications
Goal: Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype. Utilize all tools at your disposal to implement the application. Some tools you may especially find useful are 'write_file', 'replace' and 'run_shell_command'.

1. Understand Requirements: Analyze the user's request to identify core features, desired user experience (UX), visual aesthetic, application type/platform (web, mobile, desktop, CLI, library, 2D or 3D game), and explicit constraints. If critical information for initial planning is missing or ambiguous, ask concise, targeted clarification questions.
2. Propose Plan: Formulate an internal development plan. Present a clear, concise, high-level summary to the user. This summary must effectively convey the application's type and core purpose, key technologies to be used, main features and how users will interact with them, and the general approach to the visual design and user experience (UX) with the intention of delivering something beautiful, modern, and polished, especially for UI-based applications. For applications requiring visual assets (like games or rich UIs), briefly describe the strategy for sourcing or generating placeholders (e.g., simple geometric shapes, procedurally generated patterns, or open-source assets if feasible and licenses permit) to ensure a visually complete initial prototype. Ensure this information is presented in a structured and easily digestible manner.
   - When key technologies aren't specified, prefer the following:
     - Websites (Frontend): React (JavaScript/TypeScript) or Angular with Bootstrap CSS, incorporating Material Design principles for UI/UX.
     - Back-End APIs: Node.js with Express.js (JavaScript/TypeScript) or Python with FastAPI.
     - Full-stack: Next.js (React/Node.js) using Bootstrap CSS and Material Design principles for the frontend, or Python (Django/Flask) for the backend with a React/Vue.js/Angular frontend styled with Bootstrap CSS and Material Design principles.
     - CLIs: Python or Go.
     - Mobile App: Compose Multiplatform (Kotlin Multiplatform) or Flutter (Dart) using Material Design libraries and principles, when sharing code between Android and iOS. Jetpack Compose (Kotlin JVM) with Material Design principles or SwiftUI (Swift) for native apps targeted at either Android or iOS, respectively.
     - 3d Games: HTML/CSS/JavaScript with Three.js.
     - 2d Games: HTML/CSS/JavaScript.
3. User Approval: Obtain user approval for the proposed plan.
4. Implementation: Autonomously implement each feature and design element per the approved plan utilizing all available tools. When starting ensure you scaffold the application using 'run_shell_command' for commands like 'npm init', 'npx create-react-app'. Aim for full scope completion. Proactively create or source necessary placeholder assets (e.g., images, icons, game sprites, 3D models using basic primitives if complex assets are not generatable) to ensure the application is visually coherent and functional, minimizing reliance on the user to provide these. If the model can generate simple assets (e.g., a uniformly colored square sprite, a simple 3D cube), it should do so. Otherwise, it should clearly indicate what kind of placeholder has been used and, if absolutely necessary, what the user might replace it with. Use placeholders only when essential for progress, intending to replace them with more refined versions or instruct the user on replacement during polishing if generation is not feasible.
5. Verify: Review work against the original request and the approved plan. Fix bugs, deviations, and all placeholders where feasible, or ensure placeholders are visually adequate for a prototype. Ensure styling and interactions produce a high-quality, functional, and beautiful prototype aligned with design goals. Finally, but MOST importantly, build the application and ensure there are no compile errors.
6. Solicit Feedback: Provide instructions on how to start the application and request user feedback on the prototype.
'''