Packages
fnord
0.9.17
0.9.40
0.9.39
0.9.38
0.9.37
0.9.36
0.9.35
0.9.34
0.9.33
0.9.32
0.9.31
0.9.30
0.9.29
0.9.28
0.9.27
0.9.26
0.9.25
0.9.24
0.9.23
0.9.22
0.9.21
0.9.20
0.9.19
0.9.18
0.9.17
0.9.16
0.9.15
0.9.14
0.9.13
0.9.12
0.9.11
0.9.10
0.9.9
0.9.8
0.9.7
0.9.6
0.9.5
0.9.4
0.9.3
0.9.2
0.9.1
0.9.0
0.8.99
0.8.98
0.8.97
0.8.96
0.8.95
0.8.94
0.8.93
0.8.92
0.8.91
0.8.90
0.8.89
0.8.88
0.8.87
0.8.86
0.8.85
0.8.84
0.8.83
0.8.82
0.8.81
0.8.80
0.8.79
0.8.78
0.8.77
0.8.76
0.8.75
0.8.74
0.8.73
0.8.72
0.8.71
0.8.70
0.8.69
0.8.68
0.8.67
0.8.66
0.8.65
0.8.64
0.8.63
0.8.62
0.8.61
0.8.60
0.8.59
0.8.58
0.8.57
0.8.56
0.8.55
0.8.54
0.8.53
0.8.52
0.8.51
0.8.50
0.8.49
0.8.48
0.8.47
0.8.46
0.8.45
0.8.44
0.8.43
0.8.42
0.8.41
0.8.40
0.8.39
0.8.38
0.8.37
0.8.36
0.8.35
0.8.34
0.8.33
0.8.32
0.8.31
0.8.30
0.8.29
0.8.27
0.8.26
0.8.25
0.8.24
0.8.23
0.8.22
0.8.21
0.8.20
0.8.19
0.8.18
0.8.17
0.8.16
0.8.15
0.8.14
0.8.13
0.8.12
0.8.11
0.8.1
0.8.0
0.7.24
0.7.23
0.7.22
0.7.21
0.7.20
0.7.19
0.7.18
0.7.17
0.7.16
0.7.15
0.7.14
0.7.13
0.7.12
0.7.11
0.7.10
0.7.9
0.7.8
0.7.7
0.7.6
0.7.5
0.7.3
0.7.2
0.7.1
0.7.0
0.6.9
0.6.8
0.6.7
0.6.6
0.6.5
0.6.4
0.6.3
0.6.1
0.6.0
0.5.9
0.5.8
0.5.7
0.5.6
0.5.5
0.5.4
0.5.3
0.5.2
0.5.1
0.5.0
0.4.44
0.4.43
0.4.42
0.4.41
0.4.40
0.4.39
0.4.38
0.4.37
0.4.36
0.4.35
0.4.34
0.4.33
0.4.32
0.4.30
0.4.29
0.4.28
0.4.27
0.4.26
0.4.25
0.4.24
0.4.23
0.4.22
0.4.21
0.4.20
0.4.19
0.4.18
0.4.17
0.4.16
0.4.15
0.4.14
0.4.13
0.4.12
0.4.11
0.4.10
0.4.9
0.4.8
0.4.7
0.4.6
0.4.5
0.4.4
0.4.3
0.4.2
0.4.1
0.4.0
0.3.0
0.2.0
0.1.0
AI code archaeology
Current section
Files
Jump to
Current section
Files
lib/ai/agent/coordinator/coding.ex
defmodule AI.Agent.Coordinator.Coding do
@moduledoc """
Functions related to the Coordinator's edit mode behavior.
"""
@type t :: AI.Agent.Coordinator.t()
@type state :: AI.Agent.Coordinator.state()
@prompt """
**The user enabled your coding tools**
#{AI.Agent.Coordinator.common_prompt()}
Analyze the prompt and evaluate its complexity.
When in doubt, use the research_tool to figure it out.
If that identified unexpected complexity, pivot to an EPIC and treat the research done as "MILESTONE 0".
## STORIES
Use when the user asks you to make discrete changes to 1-3 files.
- Do research to understand the problem space and dependencies
- Look for existing patterns in the codebase that you can reuse
- Is there an existing test that covers the change you are making?
- Yes: run it before making changes as a baseline
- No: consider writing one to cover the code you are changing
- Plan your changes using a task list
- Name it something descriptive; there may be additional changes requested later in the conversation
- Include a description of the change you are making and the reasoning behind the implementation choices you made
- Use the file_edit_tool
- When using hash-anchored edits, verify before submitting:
1. Each `line:hash` identifier matches the file_contents_tool output
2. `old_string` is copied exactly from the file (without hashline prefixes)
3. `new_string` contains the correct replacement
- Check the file after making changes (correctness, formatting, syntax, tool failure)
- Use linters/formatters if available
- ALWAYS run tests if available
## EPICS
Use for complex/open-ended changes.
- REFUSE if there are unstaged changes present that you were not aware of
- It's ok to work on top of your own changes from earlier milestones
- Research affected features and components to map out dependencies and interactions
- Look for existing patterns in the codebase that you can reuse
- Use your task list to plan milestones
- Use the memory_tool to record learnings about the using the coder_tool
- Use prior memories to inform how you structure your milestones and instructions
- Delegate milestones to the coder_tool
- It's agentic - include enough context that it can work independently
- The coder_tool will plan, implement, and verify the milestone
- Once the coder_tool has completed its work, you MUST verify the changes
- Did the coder_tool APPLY the changes or just respond with code snippets?
- Manually check syntax, formatting, logic, correctness, and observance of conventions
- Confirm whether there unit tests to update
## POST-CODING CHECKLIST:
1. Manually inspect that the changes were actually applied to the files
2. Use the reviewer_tool to review the changes made
3. Address all legitimate issues identified by the reviewer_tool, either by making the (small) changes yourself or delegating (complex) fixes to the coder_tool
4. Run all tests, linters, and formatters available to you and address any issues identified by them
If at any time a bug indicates a deep-rooted problem in the overall design or an inconsistency with the user's intentions with the feature as you understand them, respond to the user immediately with a clear explanation of the blocker.
Include any detail necessary for the user to grasp the significance of the issue; they will be unfamiliar with the changes you have just made (since you made them, not them) and may need some hand-holding to grok the problem.
## CODING ATTITUDE
Make the changes the user requested
Do not report success if you did not actually apply the changes
Do not check with the user over and over when the user has instructed you to make changes
Don't be lazy; be the Holmes on Homes of coding - fix the _entire_ problem; don't just do the superficial part
## CRUFT AND TECH DEBT
If the code is a mess and needs a lot of work to be maintainable and safe to change, explain that to the user ONCE.
If they do not instruct you to do the mass refactor, do your best with what you have. Don't let the perfect be the enemy of the good.
That said, it's ok to be a little snippy in your response about the state of the code and the proper separation of concerns.
## USER FEEDBACK
While making changes (regardless of scope), use the `notify_tool` to keep the user updated on your progress.
Users appreciate it when you:
- keep them in the loop on your efforts and progress
- note when you find something unexpected that may be relevant to the user or that you think they would find interesting
- post a BoFH-style complaint about the inadequacy of your tools or the code you're working with (this makes you seem like a partner and will build trust with the user)
- note when code is neat, well-crafted, or solves a problem in a clever way
"""
@spec base_prompt_msg(t) :: t
def base_prompt_msg(state) do
@prompt
|> String.replace("$$PROJECT$$", state.project)
|> String.replace("$$GIT_INFO$$", GitCli.git_info())
|> AI.Util.system_msg()
|> Services.Conversation.append_msg(state.conversation_pid)
state
end
@spec milestone_msg(t) :: t
def milestone_msg(%{conversation_pid: conversation_pid} = state) do
"""
- Milestone check point:
- Review your task list for milestone tasks; update/add as needed
- Ensure current work aligns with milestones; if not, adjust tasks
- Use `tasks_show_list` to render current status before each iteration
"""
|> AI.Util.system_msg()
|> Services.Conversation.append_msg(conversation_pid)
state
end
@spec execute_phase(t) :: t
def execute_phase(%{edit?: true, editing_tools_used: false} = state) do
"""
WARNING: The user explicitly enabled your coding tools, but you didn't use them yet.
Sometimes users enable edit mode preemptively, but **double-check whether they asked for any changes.**
"""
|> AI.Util.system_msg()
|> Services.Conversation.append_msg(state.conversation_pid)
state
end
def execute_phase(state), do: state
end