zed/assets/prompts/operations.md

Your task is to map a step from the conversation above to operations on symbols inside the provided source files.

Guidelines:

• There's no need to describe what to do, just where to do it.
• If creating a file, assume any subsequent updates are included at the time of creation.
• Don't create and then update a file.
• We'll create it in one shot.
• Prefer updating symbols lower in the syntax tree if possible.
• Never include operations on a parent symbol and one of its children in the same block.
• Never nest an operation with another operation or include CDATA or other content. All operations are leaf nodes.
• Include a description attribute for each operation with a brief, one-line description of the change to perform.
• Descriptions are required for all operations except delete.
• When generating multiple operations, ensure the descriptions are specific to each individual operation.
• Avoid referring to the location in the description. Focus on the change to be made, not the location where it's made. That's implicit with the symbol you provide.
• Don't generate multiple operations at the same location. Instead, combine them together in a single operation with a succinct combined description.

The available operation types are:

1. : Modify an existing symbol in a file.
2. <create_file>: Create a new file.
3. <insert_sibling_after>: Add a new symbol as sibling after an existing symbol in a file.
4. <append_child>: Add a new symbol as the last child of an existing symbol in a file.
5. <prepend_child>: Add a new symbol as the first child of an existing symbol in a file.
6. : Remove an existing symbol from a file. The description attribute is invalid for delete, but required for other ops.

All operations require a path. Operations that require a symbol: , <insert_sibling_after>, Operations that don't allow a symbol: Operations that have an optional symbol: <prepend_child>, <append_child>

Example 1:

User:

struct Rectangle {
    width: f64,
    height: f64,
}

impl Rectangle {
    fn new(width: f64, height: f64) -> Self {
        Rectangle { width, height }
    }
}

Symbols for src/rectangle.rs:

• struct Rectangle
• impl Rectangle
• impl Rectangle fn new

Add new methods 'calculate_area' and 'calculate_perimeter' to the Rectangle struct Implement the 'Display' trait for the Rectangle struct

What are the operations for the step: Add a new method 'calculate_area' to the Rectangle struct

Assistant (wrong): <append_child path="src/shapes.rs" symbol="impl Rectangle" description="Add calculate_area method" /> <append_child path="src/shapes.rs" symbol="impl Rectangle" description="Add calculate_perimeter method" />

This demonstrates what NOT to do. NEVER append multiple children at the same location.

Assistant (corrected): <append_child path="src/shapes.rs" symbol="impl Rectangle" description="Add calculate area and perimeter methods" />

User: What are the operations for the step: Implement the 'Display' trait for the Rectangle struct

Assistant: <insert_sibling_after path="src/shapes.rs" symbol="impl Rectangle" description="Implement Display trait for Rectangle"/>

Example 2:

User:

struct User {
    pub name: String,
    age: u32,
    email: String,
}

impl User {
    fn new(name: String, age: u32, email: String) -> Self {
        User { name, age, email }
    }

    pub fn print_info(&self) {
        println!("Name: {}, Age: {}, Email: {}", self.name, self.age, self.email);
    }
}

Symbols for src/user.rs:

• struct User
• struct User pub name
• struct User age
• struct User email
• impl User
• impl User fn new
• impl User pub fn print_info

Update the 'print_info' method to use formatted output Remove the 'email' field from the User struct

What are the operations for the step: Update the 'print_info' method to use formatted output

Assistant:

User: What are the operations for the step: Remove the 'email' field from the User struct

Assistant:

Example 3:

User:

struct Vehicle {
    make: String,
    model: String,
    year: u32,
}

impl Vehicle {
    fn new(make: String, model: String, year: u32) -> Self {
        Vehicle { make, model, year }
    }

    fn print_year(&self) {
        println!("Year: {}", self.year);
    }
}

Symbols for src/vehicle.rs:

• struct Vehicle
• struct Vehicle make
• struct Vehicle model
• struct Vehicle year
• impl Vehicle
• impl Vehicle fn new
• impl Vehicle fn print_year

Add a 'use std::fmt;' statement at the beginning of the file Add a new method 'start_engine' in the Vehicle impl block

What are the operations for the step: Add a 'use std::fmt;' statement at the beginning of the file

Assistant: <prepend_child path="src/vehicle.rs" description="Add 'use std::fmt' statement" />

User: What are the operations for the step: Add a new method 'start_engine' in the Vehicle impl block

Assistant: <insert_sibling_after path="src/vehicle.rs" symbol="impl Vehicle fn new" description="Add start_engine method"/>

Example 4:

User:

struct Employee {
    name: String,
    position: String,
    salary: u32,
    department: String,
}

impl Employee {
    fn new(name: String, position: String, salary: u32, department: String) -> Self {
        Employee { name, position, salary, department }
    }

    fn print_details(&self) {
        println!("Name: {}, Position: {}, Salary: {}, Department: {}",
                  self.name, self.position, self.salary, self.department);
    }

    fn give_raise(&mut self, amount: u32) {
        self.salary += amount;
    }
}

Symbols for src/employee.rs:

• struct Employee
• struct Employee name
• struct Employee position
• struct Employee salary
• struct Employee department
• impl Employee
• impl Employee fn new
• impl Employee fn print_details
• impl Employee fn give_raise

Make salary an f32

What are the operations for the step: Make salary an f32

A (wrong):

This example demonstrates what not to do. struct Employee salary is a child of struct Employee.

A (corrected):

User: What are the correct operations for the step: Remove the 'department' field and update the 'print_details' method

A:

Now generate the operations for the following step. Output only valid XML containing valid operations with their required attributes. NEVER output code or any other text inside tags. If you do, you will replaced with another model. Your response MUST begin with and end with :