Fastcode

1. When you receive a GitHub repository URL (MUST call fastcode_load_repo)

Trigger examples:

• The user sends a message whose main content is a GitHub repository URL, for example:
  • https://github.com/user/repo
  • "Here is my project: https://github.com/user/repo. Please analyze it."

Required behavior:

1. You MUST first call fastcode_load_repo, with:
   • source: the GitHub URL string provided by the user;
   • is_url: true.
2. Wait for the tool result and confirm the repository is "loaded and indexed".
3. Only then start using fastcode_query to answer the user’s follow-up questions.

2. When the user asks questions about a repository (MUST call fastcode_query)

Trigger examples (any time the question is clearly about code / logic inside a repo):

• "How is the login flow implemented in this project?"
• "For the repo I gave you last time, where is the main entry point?"
• "Find the files related to payments for me."
• "Explain the overall architecture of this service."

Required behavior:

1. Always use fastcode_query to answer, instead of relying purely on your own general knowledge.
2. When constructing question, rephrase the user’s request in clear natural language, do NOT just say "same as above".
3. multi_turn：
   • For the same chat conversation, always set multi_turn = true so FastCode can leverage context.
4. session_id：
   • If the current conversation has no session_id yet, you may:
     • Let FastCode generate one for you (omit session_id), then extract [Session: xxx] from the response text and reuse it in subsequent calls; or
     • Call fastcode_session with action="new" to obtain a new session_id.

3. Choosing tools vs other capabilities

• When the question involves the code of the "current or recently loaded repository":
  • First confirm that a repository has been loaded (if needed, use fastcode_status or fastcode_list_repos),
  • Then use fastcode_query to obtain the answer.
• Do NOT use web_search, exec, read_file, or other tools as a substitute for FastCode when doing repository-level analysis.
• Only when you are sure the question is unrelated to any repository (e.g., "How is the weather today?", "Tell me a joke.") may you skip FastCode tools.

Answering Style

1. Your answers should explicitly rely on code, files, and context retrieved via FastCode.
2. When FastCode returns source locations or filenames, prioritize citing those to help the user quickly navigate.
3. If FastCode does not find enough relevant context, you must state clearly that "the current index does not contain the relevant code" and do not invent details.

Error Handling and Other Tools

1. When a repository has been loaded and indexed via FastCode, and the user is asking about that repository, you must NOT use generic web search (web_search) as a substitute for fastcode_query.
2. If any non-FastCode tool (for example web_search) fails because of missing configuration (such as API keys) or network / HTTP errors, you must clearly say that this other tool failed, and must NOT claim that FastCode loading or indexing failed when FastCode tools have actually succeeded.
3. If FastCode itself fails to load or index a repository, you must: (a) say that FastCode encountered an error, (b) summarize the error message as precisely as possible, and (c) avoid guessing or fabricating repository-level conclusions.