Navie is your AI partner for code understanding, generation, and review. It uses the runtime context from AppMap and the code context from your project to provide intelligent assistance directly in your IDE.
Navie has two primary ways of understanding the code you want to discuss:
1. By Name (The Common Method)
You can directly reference classes, methods, or functions by their name in your prompt. Navie will search your project to find the relevant code.
> @explain the OwnerController class.
2. By Manual Context (For Specific Cases)
For more complex situations, you can manually provide context using the "Add Content..." button in the Navie chat panel. This is most useful when:
- The code you're working on is new and unsaved.
- A class or function name is ambiguous (exists in multiple files).
- You want to focus on a specific code snippet from a very large file.
When tackling a new feature or fixing a bug, follow this powerful three-step workflow:
Start by asking Navie to explain the relevant code by name. This is your discovery phase to understand the existing landscape.
> @explain the processFindForm method in OwnerController.
Once you understand the "as-is," outline your changes. Use @plan to generate a step-by-step implementation strategy.
> @plan how to add a new 'telephone' field to the Owner entity.
With a solid plan in place, you can simply respond with @generate. Navie remembers the plan it just created and will begin implementing the steps, one by one.
> @generate
Use @explain to understand how code works. Reference a class or method by name, and Navie will provide a natural language description of its purpose, logic, and interactions.
When to Use It:
- When you encounter a file or function for the first time.
- To quickly get up to speed on a complex piece of business logic.
- To create documentation or comments for existing code.
Example Prompts:
@explain the OwnerRepository class.@explain the logic in the processPayment method.@explain what the Vets.html template does.
Use @plan to create a step-by-step implementation guide for a new feature or refactor. This command sets the context for the @generate command that follows.
When to Use It:
- At the beginning of a new development task.
- To break down a complex problem into smaller, manageable steps.
- To ensure you've considered all the files that need to be changed.
Example Prompts:
@plan how to add a new REST endpoint for user profiles to the UserController.@plan the steps to refactor the VisitController to use a service class.@plan how to fix a bug in processFindForm where it can return too many results.
Use @generate to write new code based on your instructions. Its most powerful use is to execute the active plan created by @plan.
When to Use It:
- To implement the active plan created by
@plan(most common). - To write specific, one-off functions or classes when you don't need a full plan.
- To boilerplate new methods or configuration.
Example Prompts:
@generate(After using@plan, this will begin implementing the plan.)@generate a new method in OwnerController called deactivateOwner that takes an ownerId.@generate a constructor for the Pet class that initializes all its fields.
Use @test to create unit or integration tests for your code by referencing a class or method.
When to Use It:
- To quickly add test coverage for new or existing code.
- To generate boilerplate test files and mocks.
- To get ideas for edge cases you should test.
Example Prompts:
@test generate a unit test for the isValidEmail function in the Validator class.@test create a test class for OwnerService.@test generate test cases for the calculateDiscount method.
Note: This command is different. It does not use the chat context. Instead, @review gets its context directly from git by analyzing the difference (diff) between your current code and a base branch.
Use it to get an AI-powered code review on your local changes to identify potential bugs, performance issues, and suggest improvements.
When to Use It:
- Before you commit your code.
- When you want a second opinion on your changes.
- To automatically check for common issues.
By default, @review compares your current HEAD (including uncommitted changes) against the main branch. You can change this behavior using the /base parameter.
- Review all changes since the
mainbranch (default):@review - Review only uncommitted changes:
@review /base=HEAD - Review all changes made on your feature branch since it was created from
develop:@review /base=develop - Review changes since a specific commit or tag:
(Note: The specified base must be an ancestor commit of your current@review /base=v1.2.0HEAD.)