\r \r

Serena\r

\r Use Serena as the first choice for understanding and editing existing codebases when the necessary tools are available.\r \r

What this skill is for\r

\r Use this skill when another agent needs to integrate Serena into its normal coding workflow instead of treating the repo as a pile of text files.\r \r Aim for this behavior:\r \r

• activate the project once\r
• inspect structure semantically before reading large files\r
• trace references before editing\r
• prefer symbol-scoped edits when possible\r
• fall back to normal file tools only when Serena is missing a capability or fails\r \r For extra examples and trigger patterns, read references/integration-patterns.md.\r \r

Core workflow\r

\r

1. Resolve the target project path.\r
2. Call serena_activate_project.\r
3. Start with structure discovery:\r
   • serena_project_overview\r
   • serena_find_symbol\r
   • serena_list_dir\r
   • serena_find_file\r
   • serena_session_status when you need to inspect active Serena sessions\r
4. Narrow scope with:\r
   • serena_find_references\r
   • serena_search_pattern\r
   • serena_read_symbol\r
   • serena_read_file\r
5. Prefer semantic edits when changing existing code:\r
   • serena_replace_symbol_body\r
   • serena_insert_before_symbol\r
   • serena_insert_after_symbol\r
   • serena_rename_symbol\r
6. Use broader edit tools only when symbol-scoped tools are not a good fit:\r
   • serena_replace_content\r
   • serena_create_text_file\r
7. Use serena_execute_shell_command only as an advanced escape hatch when project-context shell execution is genuinely the right tool.\r
8. Use serena_call_tool only when the normalized surface does not cover the needed Serena capability.\r
9. Fall back to ordinary file tools only when Serena cannot answer safely or reliably.\r \r

When Serena is worth the overhead\r

\r Prefer Serena when:\r \r

• the project spans multiple files\r
• the user asks about references, call chains, or symbol relationships\r
• the user wants a precise edit to an existing class, function, method, or module\r
• reading whole files would be noisy or wasteful\r
• the repo already has real structure and semantic lookup is available\r \r Skip or delay Serena when:\r \r
• the task is a tiny one-file change and the target location is already obvious\r
• you are creating a brand-new file with little dependency on existing code\r
• Serena is unavailable or failing and direct file tools are simpler\r
• the user already provided the exact file region and semantic lookup adds no value\r \r

Tool preference order\r

\r For existing codebases, prefer this order:\r \r

1. serena_activate_project\r
2. serena_project_overview / serena_find_symbol / serena_find_file\r
3. serena_find_references / serena_search_pattern\r
4. serena_read_symbol / serena_read_file\r
5. symbol-scoped edit tools\r
6. broader Serena edit tools\r
7. serena_session_status for session inspection/debugging\r
8. serena_execute_shell_command only when semantic tools are not the right mechanism\r
9. fallback to read, edit, and exec only when needed\r \r

Integration guidance for agent authors\r

\r When you want another agent to use Serena well, instruct it to:\r \r

• activate the project before semantic reads or edits\r
• inspect symbols and references before modifying code\r
• use normalized Serena tools first\r
• keep edits narrow and structured\r
• avoid whole-file rewrites when a symbol-scoped edit is possible\r
• treat passthrough as an escape hatch, not the default workflow\r \r A good instruction pattern is:\r \r

Use Serena on the repo. Start with serena_activate_project, then narrow scope with serena_find_symbol, serena_find_references, and serena_read_symbol before editing.\r \r

Practical usage patterns\r

\r

Understand a repo area\r

\r Use this sequence:\r \r

1. serena_activate_project\r
2. serena_find_file or serena_list_dir\r
3. serena_project_overview\r
4. serena_find_symbol\r
5. serena_read_symbol\r \r

Trace impact before changing code\r

\r Use this sequence:\r \r

1. serena_find_symbol\r
2. serena_find_references\r
3. serena_search_pattern if naming or text-level usage matters\r
4. serena_read_symbol for the most relevant callers/callees\r \r

Make a targeted edit\r

\r Use this sequence:\r \r

1. locate the exact symbol\r
2. read the symbol body\r
3. inspect references if behavior changes could ripple outward\r
4. choose the narrowest valid edit tool\r
5. re-read the changed symbol or nearby references when confidence is low\r \r

Editing rules\r

\r

• Keep edits as narrow as possible.\r
• Prefer symbol-targeted edits over text replacement across a whole file.\r
• Prefer semantic rename over manual multi-file rename logic.\r
• Re-read the relevant symbol or references after a material edit when confidence is low.\r
• If semantic identity is ambiguous, do not guess; disambiguate using path or extra lookup.\r
• In read-only mode, do not attempt mutating Serena tools.\r \r

Safety and fallback behavior\r

\r If Serena fails:\r \r

1. Explain briefly what failed.\r
2. Fall back to standard file-based workflow.\r
3. Keep using the smallest possible read/edit scope.\r
4. Do not pretend the semantic result was confirmed if it was not.\r \r If a raw Serena passthrough tool is available:\r \r

• use it only when the normalized tool surface does not cover the needed capability\r
• prefer stable normalized tools for repeated workflows\r
• avoid passthrough for routine actions that already have a clear normalized tool\r