Guidelines
Guidelines Overview
Guidelines are a powerful feature of Tabnine Agents that allow you to define custom behaviors, workflow rules, and system prompts through simple Markdown files. Think of guidelines as “custom instructions” that shape how your agent behaves and operates within your specific development environment.
What are Guidelines?
Guidelines are Markdown files stored in your project’s .tabnine/guidelines/
directory that act as:
Custom System Prompts: Define how the agent should behave
Workflow Rules: Specify procedures and processes to follow
Tool Instructions: Control how and when tools should be used
Team Standards: Encode your team’s coding practices and conventions
Key Benefits
Consistency: Ensure agents follow your team’s practices across all interactions
Automation: Encode complex workflows into reusable guidelines
Customization: Tailor agent behavior to your specific needs
Knowledge Sharing: Document and share best practices across your team
Guidelines Structure
Guidelines are organized in a hierarchical directory structure, as seen in this example:
.tabnine/
└── guidelines/
├── general-behavior.md
├── coding-standards.md
├── tool-instructions.md
├── workflows/
│ ├── feature-development.md
│ ├── bug-fixing.md
│ └── code-review.md
└── team-specific/
├── frontend-guidelines.md
└── backend-guidelines.md
Guideline File Format
Guidelines use standard Markdown (.md
) format with special sections for different types of instructions:
# Guideline Title
## Overview
Brief description of what this guideline covers.
## Instructions
Specific instructions for the agent to follow.
## Tool Permissions
Special section for tool-related permissions and requirements.
## Examples
Example scenarios and expected behaviors.
Types of Guidelines
1. Behavioral Guidelines
Define general agent behavior and personality:
# Code Review Guidelines
## Instructions
When reviewing code, always:
1. Check for security vulnerabilities first
2. Verify adherence to team coding standards
3. Suggest performance improvements where applicable
4. Provide constructive feedback with explanations
5. Highlight both strengths and areas for improvement
## Tone- Be constructive and educational
- Explain the reasoning behind suggestions
- Acknowledge good practices when you see them
2. Workflow Guidelines
Encode specific processes and procedures:
# Feature Development Workflow
## Instructions
When implementing a new feature:
1. Analyze requirements and existing codebase patterns
2. Create feature branch following naming convention: feature/TICKET-brief-description
3. Implement core functionality following TDD principles
4. Add comprehensive unit and integration tests
5. Update documentation and README if needed
6. Create pull request with proper description and test results
3. Tool-Specific Guidelines
Control how agents interact with external tools:
# Database Operations Guidelines
## Instructions
When working with database operations:
1. Always use parameterized queries to prevent SQL injection
2. Include proper error handling and transaction management
3. Add database migration scripts for schema changes
4. Verify performance impact of new queries
## Tool Permissions
1. Before running database migrations, ask for explicit permission
2. Never execute DROP statements without confirmation
3. Always backup data before destructive operations
Creating Guidelines
To add custom guidelines for use by Tabnine Agent, create a new directory called .tabnine
.
This directory will either reside either 1) in your home directory or 2) on a per-project basis within your project directory.
After that, create a /guidelines/
folder in the /.tabnine/
directory either in your Terminal or manually:
.gif)
2. Write Basic Guidelines
Once in the .tabnine/guidelines/
directory, save a markdown file (.md
) with written instructions in natural language. Tabnine Agent will interpret the text.
There is no structural requirement, but it is still a best practice to list the various guidelines in a hierarchical structure for easy interpretation, both by Agents and other users.
Your location will resemble .tabnine/guidelines/appguidelines.md
As noted above, you can save multiple guideline files.
<aside> ☝🏽
Think of these guideline files in a similar fashion to instructing ChatGPT to save your preferences.
</aside>
Here is a common example of a guidelines.md
file:
# Team Coding Standards
## Overview
This guideline defines our team's coding standards and practices for consistent code quality.
## Instructions
### Code Style- Use meaningful variable and function names
- Follow language-specific naming conventions (camelCase for JavaScript, snake_case for Python)
- Keep functions small and focused (max 20-30 lines)
- Add comments for complex business logic
### Error Handling- Always handle errors gracefully
- Use try-catch blocks for operations that might fail
- Log errors with appropriate context
- Provide user-friendly error messages
### Testing- Write unit tests for all new functions
- Maintain minimum 80% code coverage
- Include integration tests for API endpoints
- Use descriptive test names that explain the scenario
## Examples
Good variable naming:
userAuthenticationToken = generateToken(user);
const isValidEmail = validateEmailAddress(email);
Bad variable naming:
const t = generateToken(user); // Too generic
const flag = validateEmailAddress(email); // Unclear purpose
3. Test Your Guideline
Ask your agent to perform a task that should trigger your guideline:
“Review this function and suggest improvements”
Tabnine Agent should now follow your team's coding standards when providing feedback.
Advanced Guideline Patterns
You can get more specific in different ways with your guidelines. Remember to remain clear and even add further clarification for the Agent to interpret your directives.
Conditional Guidelines
Create guidelines that apply in specific situations:
# API Development Guidelines
## Instructions
### When creating REST APIs:
- Use RESTful conventions (GET, POST, PUT, DELETE)
- Return appropriate HTTP status codes
- Include proper request/response validation
- Add rate limiting for public endpoints
### When creating GraphQL APIs:
- Define clear schemas with proper types
- Implement proper error handling
- Add query complexity analysis
- Include proper authentication/authorization
Context-Aware Guidelines
Guidelines can reference project context:
# Frontend Component Guidelines
## Instructions
When working with React components in this project:
- Use TypeScript for all new components
- Follow the existing component structure in `/src/components`- Use the project's design system components from `/src/design-system`- Implement proper prop validation with TypeScript interfaces
- Add Storybook stories for reusable components
## File Organization-
Place components in appropriate subdirectories
- Use index.ts files for clean imports
- Keep styles in co-located .module.css files
Permission-Based Guidelines
Control agent permissions and require confirmations:
# Production Deployment Guidelines
## Instructions
When deploying to production:
1. Verify all tests pass in staging environment
2. Check that database migrations are backwards compatible
3. Ensure proper monitoring and alerting is in place
4. Coordinate with team for deployment window
## Tool Permissions
### Deployment Tools
1. Before deploying to production, ask for explicit confirmation
2. Show deployment plan and affected services
3. Require approval from team lead for major releases
4. Always create rollback plan before deployment
### Database Operations
1. Never run migrations directly in production without review
2. Always backup production data before schema changes
3. Test migrations on staging data first
Guideline Lifecycle
Creating Guidelines
Identify Patterns: Notice repeated instructions or corrections
Document Process: Write down the desired behavior
Create Guideline: Convert to Markdown format
Test Behavior: Verify agent follows the guideline
Iterate: Refine based on real usage
Maintaining Guidelines
Regular Reviews: Periodically review and update guidelines
Team Feedback: Incorporate feedback from team members
Version Control: Track guideline changes in Git
Documentation: Keep guidelines well-documented and organized
Sharing Guidelines
Team Guidelines: Share common guidelines across team projects
Organization Standards: Create organization-wide guidelines
Best Practices: Contribute useful guidelines to community
Real-World Use Cases
1. Perforce Integration
From the Slack conversation mentioned in the requirements:
# Perforce Workflow Guidelines
## Instructions
When suggesting code changes in a Perforce environment:
1. Always pass the current working directory when calling tools
2. Check out files from Perforce using the p4 edit tool with relative file references
3. After successfully applying changes, submit to Perforce with a descriptive changelist
4. Craft changelist descriptions that are no longer than 250 characters
5. If p4 edit reports another workspace has the file checked out, raise this as a severe warning
## Tool Permissions
1. Before running the p4 submit tool, always ask for permission
2. Clearly explain what will be submitted and why
3. Show the proposed changelist description for approval
2. Security-First Development
# Security Guidelines
## Instructions
For all code changes, prioritize security:
1. Validate all user inputs before processing
2. Use parameterized queries for database operations
3. Implement proper authentication and authorization
4. Never log sensitive information (passwords, tokens, PII)
5. Use HTTPS for all external communications
6. Regularly update dependencies to address security vulnerabilities
## Code Review Focus
When reviewing code, specifically check for:
- SQL injection vulnerabilities
- XSS vulnerabilities
- Authentication bypasses
- Insecure data transmission
- Inadequate input validation
3. Performance Optimization
# Performance Guidelines
## Instructions
When implementing features, consider performance:
1. Use efficient algorithms and data structures
2. Implement caching where appropriate
3. Optimize database queries and indexes
4. Minimize API calls and batch operations when possible
5. Use lazy loading for expensive operations
6. Profile code performance for critical paths
## Monitoring
Always include performance monitoring:
- Add timing metrics for critical operations
- Include memory usage tracking for data-heavy processes
- Set up alerts for performance degradation
- Document performance expectations and SLAs
Last updated
Was this helpful?