delegate-to-ollama

When to use tunaLlama tools

tuna_* MCP tools delegate coding work to a local/cloud LLM. This is the Opus-with-Sonnet-subagent pattern: a smaller model handles the actual code generation, while you stay the architect.

The local LLM's window is smaller than yours, so the architect's job before delegation is fetching the context the subagent lacks. Use them when:

1. The user asks for code generation and you have clear requirements. Use tuna_generate_code instead of generating the code yourself.

2. The user asks to review or analyze a file. Use tuna_review_file (passing the path) instead of reading the file first. The file content stays out of your context — major token savings.

3. The user asks for refactoring or test writing with a defined scope. Use tuna_refactor_code or tuna_write_tests.

4. The user asks a question about multiple files. Use tuna_analyze_files so file contents bypass your context.

When NOT to delegate

• Tasks requiring deep judgment about architecture or design — keep these yourself.
• Short snippets (< ~10 lines) — overhead exceeds savings.
• Tasks that require knowledge of recent conversation context the local LLM does not have.
• Anything safety-critical or involving the user's intent interpretation.

Standard pattern: context-fetch then delegate then verify

1. Context-fetch (architect's responsibility for the smaller subagent):
   • If the task is non-trivial, call tuna_recall to surface relevant past work in this project. The local LLM doesn't share your conversation context - relevant snippets help it avoid reinventing or contradicting.
   • Load project rules: the MCP resource tunallama://memory/state should auto-attach. If not visible, call tuna_load_memory once per session.
2. Decompose the user's request into clear instructions, including the fetched context that the local LLM lacks.
3. Call the appropriate tuna_* tool.
4. Verify the returned output - catch obvious problems (wrong API, missing edge cases, divergence from project conventions in state.md).
5. If wrong, call tuna_fix_code with a specific error description.
6. Present the verified result to the user.