code .gemini/

{
  "theme": "GitHub",
  "selectedAuthType": "oauth-personal",
  "preferredEditor": "vscode"
  
}

brew install uv

ghq get https://github.com/oraios/serena.git  

❯ uv run serena config edit
Using CPython 3.11.11 interpreter at: /opt/homebrew/opt/python@3.11/bin/python3.11
Creating virtual environment at: .venv
      Built serena-agent @ file:///Users/watanabetsubasa/src/github.com/oraios/seren
Installed 55 packages in 99ms

~/src/github.com/oraios/serena main 9s
❯ . .venv/bin/activate

~/src/github.com/oraios/serena main
.venv ❯ python --version            
Python 3.11.11

~/src/github.com/oraios/serena main
.venv ❯

uv run serena start-mcp-server

{
    "mcpServers": {
        "serena": {
            "command": "/abs/path/to/uv",
            "args": ["run", "--directory", "/abs/path/to/serena", "serena", "start-mcp-server"]
        }
    }
}

❯ which uv  
/opt/homebrew/bin/uv

 ███            █████████  ██████████ ██████   ██████ █████ ██████   █████ █████
░░░███         ███░░░░░███░░███░░░░░█░░██████ ██████ ░░███ ░░██████ ░░███ ░░███
  ░░░███      ███     ░░░  ░███  █ ░  ░███░█████░███  ░███  ░███░███ ░███  ░███
    ░░░███   ░███          ░██████    ░███░░███ ░███  ░███  ░███░░███░███  ░███
     ███░    ░███    █████ ░███░░█    ░███ ░░░  ░███  ░███  ░███ ░░██████  ░███
   ███░      ░░███  ░░███  ░███ ░   █ ░███      ░███  ░███  ░███  ░░█████  ░███
 ███░         ░░█████████  ██████████ █████     █████ █████ █████  ░░█████ █████
░░░            ░░░░░░░░░  ░░░░░░░░░░ ░░░░░     ░░░░░ ░░░░░ ░░░░░    ░░░░░ ░░░░░

Tips for getting started:
1. Ask questions, edit files, or run commands.
2. Be specific for the best results.
3. Create GEMINI.md files to customize your interactions with Gemini.
4. /help for more information.

╭────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│  > serenaを使って、現在のディレクトリ内のファイルを解析して、どのようなプロジェクトかを分析して下さい  │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ はい、承知いたしました。現在のディレクトリ内のファイルを分析し、プロジェクトの概要を説明します。

  まず、プロジェクトの基本的な設定が記述されているpackage.jsonを読み込みます。
 ╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  ReadFile package.json                                                                                      │
 ╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ package.jsonの情報を分析しました。

  このプロジェクトは、Remixフレームワークを使用したWebアプリケーションです。UIの構築にはReactとTailwind 
  CSSが利用されており、TypeScriptで開発されています。

  また、Cloudflare Workersへのデプロイが想定されており、wranglerコマンドが用意されています。

  要約すると、これはRemix on Cloudflare Workersの構成のプロジェクトです。

  次に、アプリケーションのエントリーポイントであるapp/routes/_index.tsxの内容を確認し、どのような初期ページが設定
  されているかを把握します。
 ╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  ReadFile app/routes/_index.tsx                                                                             │
 ╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ app/routes/_index.tsx の内容を確認しました。

  このファイルは、Remixのデフォルトのトップページです。Remixのロゴと、ドキュメントやコミュニティへのリンクが表示
  されるようになっています。

  分析結果のまとめ

  以上の分析から、このプロジェクトはRemixフレームワークを利用して新規に作成されたWebアプリケーションであり、Cloud
  flare Workers上での動作を前提としていることが分かりました。UIはReactとTailwind 
  CSSで構築され、開発言語はTypeScriptです。

  現時点では、Remixの初期テンプレートの状態から大きな変更は加えられていないようです。

  何か他に知りたいことはありますか？

╭───────────────╮
│  > /mcp desc  │
╰───────────────╯

ℹ Configured MCP servers:
 
  🟢 serena - Ready (32 tools)
    Tools:
    - activate_project:
        Activates the project with the given name.
    - check_onboarding_performed:
        Checks whether project onboarding was already performed.
        You should always call this tool before beginning to actually work on the project/after activating a 
  project,
        but after calling the initial instructions tool.
    - create_text_file:
        Write a new file (or overwrite an existing file). For existing files, it is strongly recommended
        to use symbolic operations like replace_symbol_body or insert_after_symbol/insert_before_symbol, if 
  possible.
        You can also use insert_at_line to insert content at a specific line for existing files if the symbolic 
  operations
        are not the right choice for what you want to do.
        
        If ever used on an existing file, the content has to be the complete content of that file (so it
        may never end with something like "The remaining content of the file is left unchanged.").
        For operations that just replace a part of a file, use the replace_lines or the symbolic editing tools 
  instead. Returns a message indicating success or failure.
    - delete_lines:
        Deletes the given lines in the file.
        Requires that the same range of lines was previously read using the `read_file` tool to verify 
  correctness
        of the operation.
    - delete_memory:
        Delete a memory file. Should only happen if a user asks for it explicitly,
        for example by saying that the information retrieved from a memory file is no longer correct
        or no longer relevant for the project.
    - execute_shell_command:
        Execute a shell command and return its output.
        
        IMPORTANT: you should always consider the memory about suggested shell commands before using this tool.
        If this memory was not loaded in the current conversation, you should load it using the `read_memory` 
  tool
        before using this tool.
        
        You should have at least once looked at the suggested shell commands from the corresponding memory
        created during the onboarding process before using this tool.
        Never execute unsafe shell commands like `rm -rf /` or similar! Generally be very careful with deletions.
   Returns a JSON object containing the command's stdout and optionally stderr output.
    - find_file:
        Finds non-gitignored files matching the given file mask within the given relative path. Returns a JSON 
  object with the list of matching files.
    - find_referencing_symbols:
        Finds symbols that reference the symbol at the given `name_path`. The result will contain metadata about 
  the referencing symbols
        as well as a short code snippet around the reference (unless `include_body` is True, then the short 
  snippet will be omitted).
        Note that among other kinds of references, this function can be used to find (direct) subclasses of a 
  class,
        as subclasses are referencing symbols that have the kind class. Returns a list of JSON objects with the 
  symbols referencing the requested symbol.
    - find_symbol:
        Retrieves information on all symbols/code entities (classes, methods, etc.) based on the given 
  `name_path`,
        which represents a pattern for the symbol's path within the symbol tree of a single file.
        The returned symbol location can be used for edits or further queries.
        Specify `depth > 0` to retrieve children (e.g., methods of a class).
        
        The matching behavior is determined by the structure of `name_path`, which can
        either be a simple name (e.g. "method") or a name path like "class/method" (relative name path)
        or "/class/method" (absolute name path). Note that the name path is not a path in the file system
        but rather a path in the symbol tree **within a single file**. Thus, file or directory names should never
        be included in the `name_path`. For restricting the search to a single file or directory,
        the `within_relative_path` parameter should be used instead. The retrieved symbols' `name_path` attribute
        will always be composed of symbol names, never file or directory names.
        
        Key aspects of the name path matching behavior:
        - Trailing slashes in `name_path` play no role and are ignored.
        - The name of the retrieved symbols will match (either exactly or as a substring)
          the last segment of `name_path`, while other segments will restrict the search to symbols that
          have a desired sequence of ancestors.
        - If there is no starting or intermediate slash in `name_path`, there is no
          restriction on the ancestor symbols. For example, passing `method` will match
          against symbols with name paths like `method`, `class/method`, `class/nested_class/method`, etc.
        - If `name_path` contains a `/` but doesn't start with a `/`, the matching is restricted to symbols
          with the same ancestors as the last segment of `name_path`. For example, passing `class/method` will 
  match against
          `class/method` as well as `nested_class/class/method` but not `method`.
        - If `name_path` starts with a `/`, it will be treated as an absolute name path pattern, meaning
          that the first segment of it must match the first segment of the symbol's name path.
          For example, passing `/class` will match only against top-level symbols like `class` but not against 
  `nested_class/class`.
          Passing `/class/method` will match against `class/method` but not `nested_class/class/method` or 
  `method`. Returns JSON string: a list of symbols (with locations) matching the name.
    - get_current_config:
        Print the current configuration of the agent, including the active and available projects, tools, 
  contexts, and modes.
    - get_symbols_overview:
        Gets an overview of the given file or directory.
        For each analyzed file, we list the top-level symbols in the file (name_path, kind).
        Use this tool to get a high-level understanding of the code symbols.
        Calling this is often a good idea before more targeted reading, searching or editing operations on the 
  code symbols.
        Before requesting a symbol overview, it is usually a good idea to narrow down the scope of the overview
        by first understanding the basic directory structure of the repository that you can get from memories
        or by using the `list_dir` and `find_file` tools (or similar). Returns a JSON object mapping relative 
  paths of all contained files to info about top-level symbols in the file (name_path, kind).
    - insert_after_symbol:
        Inserts the given body/content after the end of the definition of the given symbol (via the symbol's 
  location).
        A typical use case is to insert a new class, function, method, field or variable assignment.
    - insert_at_line:
        Inserts the given content at the given line in the file, pushing existing content of the line down.
        In general, symbolic insert operations like insert_after_symbol or insert_before_symbol should be 
  preferred if you know which
        symbol you are looking for.
        However, this can also be useful for small targeted edits of the body of a longer symbol (without 
  replacing the entire body).
    - insert_before_symbol:
        Inserts the given body/content before the beginning of the definition of the given symbol (via the 
  symbol's location).
        A typical use case is to insert a new class, function, method, field or variable assignment.
        It also can be used to insert a new import statement before the first symbol in the file.
    - list_dir:
        Lists all non-gitignored files and directories in the given directory (optionally with recursion). 
  Returns a JSON object with the names of directories and files within the given directory.
    - list_memories:
        List available memories. Any memory can be read using the `read_memory` tool.
    - onboarding:
        Call this tool if onboarding was not performed yet.
        You will call this tool at most once per conversation. Returns instructions on how to create the 
  onboarding information.
    - prepare_for_new_conversation:
        Instructions for preparing for a new conversation. This tool should only be called on explicit user 
  request.
    - serena__read_file:
        Reads the given file or a chunk of it. Generally, symbolic operations
        like find_symbol or find_referencing_symbols should be preferred if you know which symbols you are 
  looking for.
        Reading the entire file is only recommended if there is no other way to get the content required for the 
  task. Returns the full text of the file at the given relative path.
    - read_memory:
        Read the content of a memory file. This tool should only be used if the information
        is relevant to the current task. You can infer whether the information
        is relevant from the memory file name.
        You should not read the same memory file multiple times in the same conversation.
    - remove_project:
        Removes a project from the Serena configuration.
    - replace_lines:
        Replaces the given range of lines in the given file.
        Requires that the same range of lines was previously read using the `read_file` tool to verify 
  correctness
        of the operation.
    - replace_regex:
        Replaces one or more occurrences of the given regular expression.
        This is the preferred way to replace content in a file whenever the symbol-level
        tools are not appropriate.
        Even large sections of code can be replaced by providing a concise regular expression of
        the form "beginning.*?end-of-text-to-be-replaced".
        Always try to use wildcards to avoid specifying the exact content of the code to be replaced,
        especially if it spans several lines.
        
        IMPORTANT: REMEMBER TO USE WILDCARDS WHEN APPROPRIATE! I WILL BE VERY UNHAPPY IF YOU WRITE LONG REGEXES 
  WITHOUT USING WILDCARDS INSTEAD!.
    - replace_symbol_body:
        Replaces the body of the symbol with the given `name_path`.
    - restart_language_server:
        Use this tool only on explicit user request or after confirmation.
        It may be necessary to restart the language server if the user performs edits
        not through Serena, so the language server state becomes outdated and further editing attempts lead to 
  errors.
        
        If such editing errors happen, you should suggest using this tool.
    - search_for_pattern:
        Offers a flexible search for arbitrary patterns in the codebase, including the
        possibility to search in non-code files.
        Generally, symbolic operations like find_symbol or find_referencing_symbols
        should be preferred if you know which symbols you are looking for.
        
        Pattern Matching Logic:
            For each match, the returned result will contain the full lines where the
            substring pattern is found, as well as optionally some lines before and after it. The pattern will be
   compiled with
            DOTALL, meaning that the dot will match all characters including newlines.
            This also means that it never makes sense to have .* at the beginning or end of the pattern,
            but it may make sense to have it in the middle for complex patterns.
            If a pattern matches multiple lines, all those lines will be part of the match.
            Be careful to not use greedy quantifiers unnecessarily, it is usually better to use non-greedy 
  quantifiers like .*? to avoid
            matching too much content.
        
        File Selection Logic:
            The files in which the search is performed can be restricted very flexibly.
            Using `restrict_search_to_code_files` is useful if you are only interested in code symbols (i.e., 
  those
            symbols that can be manipulated with symbolic tools like find_symbol).
            You can also restrict the search to a specific file or directory,
            and provide glob patterns to include or exclude certain files on top of that.
            The globs are matched against relative file paths from the project root (not to the `relative_path` 
  parameter that
            is used to further restrict the search).
            Smartly combining the various restrictions allows you to perform very targeted searches. Returns A 
  JSON object mapping file paths to lists of matched consecutive lines (with context, if requested).
    - summarize_changes:
        Summarize the changes you have made to the codebase.
        This tool should always be called after you have fully completed any non-trivial coding task,
        but only after the think_about_whether_you_are_done call.
    - switch_modes:
        Activates the desired modes, like ["editing", "interactive"] or ["planning", "one-shot"].
    - think_about_collected_information:
        Think about the collected information and whether it is sufficient and relevant.
        This tool should ALWAYS be called after you have completed a non-trivial sequence of searching steps like
        find_symbol, find_referencing_symbols, search_files_for_pattern, read_file, etc.
    - think_about_task_adherence:
        Think about the task at hand and whether you are still on track.
        Especially important if the conversation has been going on for a while and there
        has been a lot of back and forth.
        
        This tool should ALWAYS be called before you insert, replace, or delete code.
    - think_about_whether_you_are_done:
        Whenever you feel that you are done with what the user has asked for, it is important to call this tool.
    - write_memory:
        Write some information about this project that can be useful for future tasks to a memory.
        Use markdown formatting for the content.
        The information should be short and to the point.
        The memory name should be meaningful, such that from the name you can infer what the information is 
  about.
        It is better to have multiple small memories than to have a single large one because
        memories will be read one by one and we only ever want to read relevant memories.
        
        This tool is either called during the onboarding process or when you have identified
        something worth remembering about the project from the past conversation.






Using: 1 MCP server (ctrl+t to toggle)

╭────────────────────────────────────────╮
│  > read Serena's initial instructions  │
╰────────────────────────────────────────╯

description = "Token-efficient Serena MCP command for structured app development and problem-solving."

prompt = """
You are an expert app developer and problem solver using Serena MCP.

You will receive a command describing a problem or task: {{args}}

Based on the command, choose the appropriate approach automatically (Debug, Design, Implement, Optimize, Review) by keywords.

Use Serena MCP tools to:
- perform analysis, debugging, design, or implementation planning
- research relevant documentation using Context7 MCP if needed
- synthesize actionable solutions with clear next steps
- create implementation todos if requested

You can apply these command options in your process:
- -q for quick mode (3-5 steps)
- -d for deep mode (10-15 steps)
- -c for code-focused analysis
- -s for step-by-step implementation with todos
- -v for verbose output showing thought process
- -r to include research phase
- -t to create implementation todos

Here are typical usage patterns:
- Debug: error, bug, issue, broken, failing → 5-8 thought steps
- Design: architecture, system, plan → 8-12 thought steps
- Implement: build, create, add feature → 6-10 thought steps
- Optimize: performance, slow, improve, refactor → 4-7 thought steps
- Review: analyze, check, evaluate → 4-7 thought steps

Structure your response clearly and concisely. Consider security, performance, and maintainability.

Respond ONLY with the solution or plan as instructed.
"""

description = "Initializes the Serena project by reading initial instructions and creating .serena/project.yml."

prompt = """
You are a project assistant specialized in Serena MCP.

When invoked, perform the following steps:

1. Read the initial instructions for the project thoroughly.
2. Based on the instructions, generate or initialize the configuration file at .serena/project.yml.
3. Confirm the successful creation of the project configuration.
4. Provide a brief summary of the initialization results.

Do not proceed to other tasks until the initialization is confirmed complete.

Your output should be clear and concise, focusing only on the initialization process.
"""

description = "Initializes the Serena project by reading initial instructions and creating .serena/"

prompt = """
You are a project assistant specialized in Serena MCP.

When invoked, perform the following steps:

1. activate: activate the root directory
2. onboarding: read Serena's initial instructions

Do not proceed to other tasks until the initialization is confirmed complete.

Your output should be clear and concise, focusing only on the initialization process.
"""