scriptoriumadmin/Roo-Code
1
0
Fork 0
mirror of https://github.com/RooVetGit/Roo-Code.git synced 2026-08-28 05:27:24 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

feat: add AI Code Generator mode with comprehensive guidelines and patterns

Browse source
This commit is contained in:
Roo Code 2025-07-18 03:21:10 +00:00
parent 38d8edf05a
commit d5f94685de
6 changed files with 1221 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

125
.roo/rules-ai-code-generator/1_workflow.xml Normal file
View file

@ -0,0 +1,125 @@
<ai_code_generation_workflow>
<overview>
This workflow guides AI-assisted code generation following Google GenAI best practices,
ensuring high-quality, maintainable, and well-tested code output.
</overview>
<initialization_steps>
<step number="1">
<title>Understand Requirements</title>
<description>
Thoroughly analyze the user's request to understand the complete scope
</description>
<actions>
<action>Parse the user's input to identify the core functionality needed</action>
<action>Identify any constraints, performance requirements, or dependencies</action>
<action>Determine the target programming language and framework</action>
<action>Understand the integration points with existing code</action>
</actions>
<validation>
<criterion>All functional requirements are clearly understood</criterion>
<criterion>Non-functional requirements (performance, security) are identified</criterion>
<criterion>Integration points and dependencies are mapped</criterion>
</validation>
</step>
<step number="2">
<title>Analyze Existing Codebase</title>
<description>
Examine the current codebase to understand patterns and conventions
</description>
<tools>
<tool>search_files - Find similar implementations and patterns</tool>
<tool>list_code_definition_names - Understand project structure</tool>
<tool>read_file - Examine existing code for patterns and conventions</tool>
</tools>
<analysis_points>
<point>Coding style and naming conventions</point>
<point>Error handling patterns</point>
<point>Testing approaches and frameworks</point>
<point>Documentation standards</point>
<point>Architectural patterns in use</point>
</analysis_points>
</step>
</initialization_steps>
<main_workflow>
<phase name="planning">
<description>Plan the implementation approach</description>
<steps>
<step>Design the API and interface contracts</step>
<step>Identify reusable components and utilities</step>
<step>Plan the testing strategy</step>
<step>Consider error handling and edge cases</step>
<step>Design for maintainability and extensibility</step>
</steps>
</phase>
<phase name="implementation">
<description>Generate the code following best practices</description>
<steps>
<step>Create well-structured, modular code</step>
<step>Implement comprehensive error handling</step>
<step>Add meaningful documentation and comments</step>
<step>Follow established patterns and conventions</step>
<step>Ensure proper input validation and sanitization</step>
</steps>
</phase>
<phase name="testing">
<description>Generate comprehensive test coverage</description>
<steps>
<step>Create unit tests for all public methods</step>
<step>Add integration tests for complex workflows</step>
<step>Test error conditions and edge cases</step>
<step>Verify performance requirements are met</step>
<step>Ensure security requirements are validated</step>
</steps>
</phase>
<phase name="validation">
<description>Verify the implementation meets all requirements</description>
<steps>
<step>Run all tests to ensure functionality</step>
<step>Verify code follows project conventions</step>
<step>Check for potential security vulnerabilities</step>
<step>Validate performance characteristics</step>
<step>Ensure proper documentation is in place</step>
</steps>
</phase>
</main_workflow>
<completion_criteria>
<criterion>All functional requirements are implemented and tested</criterion>
<criterion>Code follows established patterns and conventions</criterion>
<criterion>Comprehensive test coverage is provided</criterion>
<criterion>Error handling covers all identified edge cases</criterion>
<criterion>Documentation is clear and complete</criterion>
<criterion>Security best practices are followed</criterion>
<criterion>Performance requirements are met</criterion>
</completion_criteria>
<quality_gates>
<gate name="code_review">
<description>Self-review generated code for quality</description>
<checklist>
<item>Code is readable and well-structured</item>
<item>Variable and function names are meaningful</item>
<item>Complex logic is properly documented</item>
<item>Error handling is comprehensive</item>
<item>Security considerations are addressed</item>
</checklist>
</gate>
<gate name="testing">
<description>Ensure comprehensive test coverage</description>
<checklist>
<item>All public methods have unit tests</item>
<item>Edge cases and error conditions are tested</item>
<item>Integration points are validated</item>
<item>Performance tests are included where relevant</item>
<item>Tests are maintainable and well-documented</item>
</checklist>
</gate>
</quality_gates>
</ai_code_generation_workflow>

203
.roo/rules-ai-code-generator/2_best_practices.xml Normal file
View file

@ -0,0 +1,203 @@
<ai_code_generation_best_practices>
<overview>
Best practices for AI-assisted code generation based on Google GenAI guidelines
and industry standards for producing high-quality, maintainable code.
</overview>
<general_principles>
<principle priority="critical">
<name>Code Clarity and Readability</name>
<description>Generate code that is self-documenting and easy to understand</description>
<rationale>Clear code reduces maintenance burden and improves team productivity</rationale>
<guidelines>
<guideline>Use descriptive variable and function names</guideline>
<guideline>Keep functions focused on a single responsibility</guideline>
<guideline>Add comments for complex business logic</guideline>
<guideline>Follow consistent formatting and style conventions</guideline>
</guidelines>
</principle>
<principle priority="critical">
<name>Defensive Programming</name>
<description>Generate code that handles errors gracefully and validates inputs</description>
<rationale>Robust error handling prevents runtime failures and improves user experience</rationale>
<guidelines>
<guideline>Validate all inputs at function boundaries</guideline>
<guideline>Use appropriate error handling mechanisms for the language</guideline>
<guideline>Provide meaningful error messages</guideline>
<guideline>Handle edge cases explicitly</guideline>
</guidelines>
</principle>
<principle priority="high">
<name>Test-Driven Development</name>
<description>Generate comprehensive tests alongside implementation code</description>
<rationale>Tests ensure correctness and enable safe refactoring</rationale>
<guidelines>
<guideline>Write tests for all public interfaces</guideline>
<guideline>Test both success and failure scenarios</guideline>
<guideline>Use meaningful test descriptions</guideline>
<guideline>Ensure tests are deterministic and isolated</guideline>
</guidelines>
</principle>
</general_principles>
<code_quality_standards>
<standard category="naming">
<rule>Use clear, descriptive names that express intent</rule>
<examples>
<good>calculateTotalPrice(items: Item[])</good>
<good>isValidEmailAddress(email: string)</good>
<bad>calc(x: any[])</bad>
<bad>check(s: string)</bad>
</examples>
</standard>
<standard category="functions">
<rule>Keep functions small and focused on a single responsibility</rule>
<guidelines>
<guideline>Aim for functions under 20-30 lines</guideline>
<guideline>Extract complex logic into helper functions</guideline>
<guideline>Use pure functions when possible</guideline>
<guideline>Minimize side effects</guideline>
</guidelines>
</standard>
<standard category="error_handling">
<rule>Implement comprehensive error handling</rule>
<patterns>
<pattern language="typescript">
<description>Use Result types for operations that can fail</description>
<example><![CDATA[
type Result<T, E> = { success: true; data: T } | { success: false; error: E };
function parseJson<T>(json: string): Result<T, string> {
try {
const data = JSON.parse(json) as T;
return { success: true, data };
} catch (error) {
return { success: false, error: error.message };
}
}
]]></example>
</pattern>
</patterns>
</standard>
<standard category="documentation">
<rule>Provide clear documentation for public APIs</rule>
<requirements>
<requirement>Document function parameters and return values</requirement>
<requirement>Explain complex algorithms or business logic</requirement>
<requirement>Provide usage examples for non-trivial functions</requirement>
<requirement>Document any side effects or preconditions</requirement>
</requirements>
</standard>
</code_quality_standards>
<security_guidelines>
<guideline priority="critical">
<rule>Validate and sanitize all user inputs</rule>
<rationale>Prevents injection attacks and data corruption</rationale>
<implementation>
<step>Use type-safe validation libraries</step>
<step>Sanitize inputs before processing</step>
<step>Use parameterized queries for database operations</step>
<step>Escape output when rendering to prevent XSS</step>
</implementation>
</guideline>
<guideline priority="high">
<rule>Follow principle of least privilege</rule>
<rationale>Minimizes potential damage from security breaches</rationale>
<implementation>
<step>Grant minimal necessary permissions</step>
<step>Use role-based access control</step>
<step>Validate authorization at each access point</step>
<step>Log security-relevant events</step>
</implementation>
</guideline>
<guideline priority="high">
<rule>Protect sensitive data</rule>
<rationale>Prevents data breaches and maintains user privacy</rationale>
<implementation>
<step>Encrypt sensitive data at rest and in transit</step>
<step>Use secure random number generation</step>
<step>Implement proper session management</step>
<step>Avoid logging sensitive information</step>
</implementation>
</guideline>
</security_guidelines>
<performance_considerations>
<consideration category="algorithmic_efficiency">
<rule>Choose appropriate algorithms and data structures</rule>
<guidelines>
<guideline>Understand time and space complexity</guideline>
<guideline>Use efficient data structures for the use case</guideline>
<guideline>Avoid premature optimization</guideline>
<guideline>Profile before optimizing</guideline>
</guidelines>
</consideration>
<consideration category="resource_management">
<rule>Manage resources efficiently</rule>
<guidelines>
<guideline>Close resources properly (files, connections, etc.)</guideline>
<guideline>Use connection pooling for database access</guideline>
<guideline>Implement proper caching strategies</guideline>
<guideline>Avoid memory leaks</guideline>
</guidelines>
</consideration>
</performance_considerations>
<common_pitfalls>
<pitfall>
<description>Generating overly complex solutions</description>
<why_problematic>Complex code is harder to understand, test, and maintain</why_problematic>
<correct_approach>Start with simple solutions and refactor when complexity is justified</correct_approach>
</pitfall>
<pitfall>
<description>Ignoring existing codebase patterns</description>
<why_problematic>Inconsistent patterns make the codebase harder to navigate</why_problematic>
<correct_approach>Analyze existing code to understand and follow established patterns</correct_approach>
</pitfall>
<pitfall>
<description>Insufficient error handling</description>
<why_problematic>Unhandled errors lead to poor user experience and debugging difficulties</why_problematic>
<correct_approach>Implement comprehensive error handling for all failure modes</correct_approach>
</pitfall>
<pitfall>
<description>Missing or inadequate tests</description>
<why_problematic>Untested code is prone to bugs and difficult to refactor safely</why_problematic>
<correct_approach>Generate comprehensive test coverage alongside implementation</correct_approach>
</pitfall>
</common_pitfalls>
<quality_checklist>
<category name="before_implementation">
<item>Requirements are clearly understood</item>
<item>Existing patterns and conventions are identified</item>
<item>API design is planned and reviewed</item>
<item>Testing strategy is defined</item>
</category>
<category name="during_implementation">
<item>Code follows established patterns</item>
<item>Error handling is comprehensive</item>
<item>Security considerations are addressed</item>
<item>Performance implications are considered</item>
</category>
<category name="before_completion">
<item>All tests pass</item>
<item>Code is properly documented</item>
<item>Security review is completed</item>
<item>Performance requirements are met</item>
</category>
</quality_checklist>
</ai_code_generation_best_practices>

443
.roo/rules-ai-code-generator/3_common_patterns.xml Normal file
View file

@ -0,0 +1,443 @@
<ai_code_generation_patterns>
<overview>
Common code patterns and templates for AI-assisted code generation,
providing reusable solutions for frequent programming scenarios.
</overview>
<architectural_patterns>
<pattern name="factory_pattern">
<description>Create objects without specifying exact classes</description>
<use_cases>
<use_case>Creating different types of objects based on configuration</use_case>
<use_case>Abstracting object creation logic</use_case>
<use_case>Supporting plugin architectures</use_case>
</use_cases>
<implementation language="typescript"><![CDATA[
interface Product {
operation(): string;
}
class ConcreteProductA implements Product {
operation(): string {
return 'Result of ConcreteProductA';
}
}
class ConcreteProductB implements Product {
operation(): string {
return 'Result of ConcreteProductB';
}
}
abstract class Creator {
abstract factoryMethod(): Product;
someOperation(): string {
const product = this.factoryMethod();
return `Creator: ${product.operation()}`;
}
}
class ConcreteCreatorA extends Creator {
factoryMethod(): Product {
return new ConcreteProductA();
}
}
]]></implementation>
</pattern>
<pattern name="repository_pattern">
<description>Encapsulate data access logic and provide a uniform interface</description>
<use_cases>
<use_case>Abstracting database operations</use_case>
<use_case>Supporting multiple data sources</use_case>
<use_case>Facilitating unit testing with mock repositories</use_case>
</use_cases>
<implementation language="typescript"><![CDATA[
interface User {
id: string;
name: string;
email: string;
}
interface UserRepository {
findById(id: string): Promise<User | null>;
findByEmail(email: string): Promise<User | null>;
save(user: User): Promise<User>;
delete(id: string): Promise<void>;
}
class DatabaseUserRepository implements UserRepository {
constructor(private db: Database) {}
async findById(id: string): Promise<User | null> {
try {
const result = await this.db.query('SELECT * FROM users WHERE id = ?', [id]);
return result.rows[0] || null;
} catch (error) {
throw new Error(`Failed to find user by id: ${error.message}`);
}
}
async save(user: User): Promise<User> {
try {
const result = await this.db.query(
'INSERT INTO users (id, name, email) VALUES (?, ?, ?) ON CONFLICT (id) DO UPDATE SET name = ?, email = ?',
[user.id, user.name, user.email, user.name, user.email]
);
return user;
} catch (error) {
throw new Error(`Failed to save user: ${error.message}`);
}
}
}
]]></implementation>
</pattern>
</architectural_patterns>
<error_handling_patterns>
<pattern name="result_type">
<description>Type-safe error handling without exceptions</description>
<benefits>
<benefit>Explicit error handling in function signatures</benefit>
<benefit>Compile-time error checking</benefit>
<benefit>Composable error handling</benefit>
</benefits>
<implementation language="typescript"><![CDATA[
type Result<T, E = Error> =
| { success: true; data: T }
| { success: false; error: E };
function ok<T>(data: T): Result<T, never> {
return { success: true, data };
}
function err<E>(error: E): Result<never, E> {
return { success: false, error };
}
// Usage example
async function fetchUser(id: string): Promise<Result<User, string>> {
try {
const user = await userRepository.findById(id);
if (!user) {
return err('User not found');
}
return ok(user);
} catch (error) {
return err(`Database error: ${error.message}`);
}
}
// Chaining operations
function processUser(result: Result<User, string>): Result<ProcessedUser, string> {
if (!result.success) {
return result; // Propagate error
}
try {
const processed = processUserData(result.data);
return ok(processed);
} catch (error) {
return err(`Processing failed: ${error.message}`);
}
}
]]></implementation>
</pattern>
<pattern name="error_boundary">
<description>Centralized error handling for application boundaries</description>
<use_cases>
<use_case>API endpoint error handling</use_case>
<use_case>React component error boundaries</use_case>
<use_case>Service layer error handling</use_case>
</use_cases>
<implementation language="typescript"><![CDATA[
interface ErrorHandler {
handle(error: Error, context?: string): void;
}
class LoggingErrorHandler implements ErrorHandler {
constructor(private logger: Logger) {}
handle(error: Error, context = 'Unknown'): void {
this.logger.error(`Error in ${context}:`, {
message: error.message,
stack: error.stack,
timestamp: new Date().toISOString(),
});
}
}
function withErrorBoundary<T extends any[], R>(
fn: (...args: T) => Promise<R>,
errorHandler: ErrorHandler,
context?: string
) {
return async (...args: T): Promise<R | null> => {
try {
return await fn(...args);
} catch (error) {
errorHandler.handle(error, context);
return null;
}
};
}
// Usage
const safeUserFetch = withErrorBoundary(
fetchUser,
new LoggingErrorHandler(logger),
'UserService.fetchUser'
);
]]></implementation>
</pattern>
</error_handling_patterns>
<validation_patterns>
<pattern name="schema_validation">
<description>Type-safe input validation with detailed error reporting</description>
<implementation language="typescript"><![CDATA[
interface ValidationResult<T> {
success: boolean;
data?: T;
errors?: ValidationError[];
}
interface ValidationError {
field: string;
message: string;
value?: any;
}
class Validator<T> {
private rules: ValidationRule<T>[] = [];
rule(rule: ValidationRule<T>): this {
this.rules.push(rule);
return this;
}
validate(data: any): ValidationResult<T> {
const errors: ValidationError[] = [];
for (const rule of this.rules) {
const result = rule.validate(data);
if (!result.valid) {
errors.push({
field: rule.field,
message: result.message,
value: data[rule.field],
});
}
}
if (errors.length > 0) {
return { success: false, errors };
}
return { success: true, data: data as T };
}
}
interface ValidationRule<T> {
field: keyof T;
validate(data: any): { valid: boolean; message: string };
}
// Usage example
const userValidator = new Validator<User>()
.rule({
field: 'email',
validate: (data) => ({
valid: /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(data.email),
message: 'Invalid email format',
}),
})
.rule({
field: 'name',
validate: (data) => ({
valid: typeof data.name === 'string' && data.name.length > 0,
message: 'Name is required and must be a non-empty string',
}),
});
]]></implementation>
</pattern>
</validation_patterns>
<testing_patterns>
<pattern name="test_builder">
<description>Builder pattern for creating test data</description>
<benefits>
<benefit>Readable test setup</benefit>
<benefit>Reusable test data creation</benefit>
<benefit>Easy to modify test scenarios</benefit>
</benefits>
<implementation language="typescript"><![CDATA[
class UserBuilder {
private user: Partial<User> = {};
withId(id: string): this {
this.user.id = id;
return this;
}
withName(name: string): this {
this.user.name = name;
return this;
}
withEmail(email: string): this {
this.user.email = email;
return this;
}
build(): User {
return {
id: this.user.id || 'default-id',
name: this.user.name || 'Default Name',
email: this.user.email || 'default@example.com',
};
}
}
// Usage in tests
describe('UserService', () => {
it('should create user with valid data', async () => {
const user = new UserBuilder()
.withName('John Doe')
.withEmail('john@example.com')
.build();
const result = await userService.createUser(user);
expect(result.success).toBe(true);
expect(result.data?.name).toBe('John Doe');
});
});
]]></implementation>
</pattern>
<pattern name="mock_factory">
<description>Factory for creating consistent mocks</description>
<implementation language="typescript"><![CDATA[
class MockFactory {
static createUserRepository(): jest.Mocked<UserRepository> {
return {
findById: jest.fn(),
findByEmail: jest.fn(),
save: jest.fn(),
delete: jest.fn(),
};
}
static createUser(overrides: Partial<User> = {}): User {
return {
id: 'test-id',
name: 'Test User',
email: 'test@example.com',
...overrides,
};
}
}
// Usage in tests
describe('UserService', () => {
let userRepository: jest.Mocked<UserRepository>;
let userService: UserService;
beforeEach(() => {
userRepository = MockFactory.createUserRepository();
userService = new UserService(userRepository);
});
it('should return user when found', async () => {
const user = MockFactory.createUser({ name: 'John Doe' });
userRepository.findById.mockResolvedValue(user);
const result = await userService.getUser('test-id');
expect(result.success).toBe(true);
expect(result.data?.name).toBe('John Doe');
});
});
]]></implementation>
</pattern>
</testing_patterns>
<async_patterns>
<pattern name="promise_wrapper">
<description>Wrap callback-based APIs in promises</description>
<implementation language="typescript"><![CDATA[
function promisify<T>(
fn: (callback: (error: Error | null, result?: T) => void) => void
): Promise<T> {
return new Promise((resolve, reject) => {
fn((error, result) => {
if (error) {
reject(error);
} else {
resolve(result!);
}
});
});
}
// Usage
const readFileAsync = (filename: string): Promise<string> =>
promisify<string>((callback) => fs.readFile(filename, 'utf8', callback));
]]></implementation>
</pattern>
<pattern name="retry_mechanism">
<description>Automatic retry with exponential backoff</description>
<implementation language="typescript"><![CDATA[
interface RetryOptions {
maxAttempts: number;
baseDelay: number;
maxDelay: number;
backoffFactor: number;
}
async function withRetry<T>(
operation: () => Promise<T>,
options: RetryOptions
): Promise<T> {
let lastError: Error;
for (let attempt = 1; attempt <= options.maxAttempts; attempt++) {
try {
return await operation();
} catch (error) {
lastError = error;
if (attempt === options.maxAttempts) {
throw lastError;
}
const delay = Math.min(
options.baseDelay * Math.pow(options.backoffFactor, attempt - 1),
options.maxDelay
);
await new Promise(resolve => setTimeout(resolve, delay));
}
}
throw lastError!;
}
// Usage
const result = await withRetry(
() => fetchDataFromAPI(),
{
maxAttempts: 3,
baseDelay: 1000,
maxDelay: 10000,
backoffFactor: 2,
}
);
]]></implementation>
</pattern>
</async_patterns>
</ai_code_generation_patterns>

327
.roo/rules-ai-code-generator/4_tool_usage.xml Normal file
View file

@ -0,0 +1,327 @@
<ai_code_generation_tool_usage>
<overview>
Specific guidance for using tools effectively in AI-assisted code generation,
ensuring optimal workflow and high-quality output.
</overview>
<tool_priorities>
<priority level="1">
<tool>search_files</tool>
<when>Always use first to understand existing codebase patterns</when>
<why>Identifies similar implementations and established conventions</why>
<usage_pattern>Search for similar functionality before implementing new features</usage_pattern>
</priority>
<priority level="2">
<tool>list_code_definition_names</tool>
<when>After identifying relevant files with search_files</when>
<why>Provides structural overview of existing code organization</why>
<usage_pattern>Understand class hierarchies and module organization</usage_pattern>
</priority>
<priority level="3">
<tool>read_file</tool>
<when>After identifying specific files to examine</when>
<why>Get detailed implementation context and patterns</why>
<usage_pattern>Read up to 5 related files simultaneously for efficiency</usage_pattern>
</priority>
</tool_priorities>
<tool_specific_guidance>
<tool name="search_files">
<purpose>Find existing implementations and patterns in the codebase</purpose>
<best_practices>
<practice>Use semantic search terms related to functionality</practice>
<practice>Search for interface definitions and type declarations</practice>
<practice>Look for similar error handling patterns</practice>
<practice>Find existing test patterns for similar functionality</practice>
</best_practices>
<search_strategies>
<strategy name="functionality_search">
<description>Search for similar business logic</description>
<example><![CDATA[
<search_files>
<path>src</path>
<regex>(validate|validation|sanitize|clean).*input</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
]]></example>
</strategy>
<strategy name="pattern_search">
<description>Find architectural patterns</description>
<example><![CDATA[
<search_files>
<path>src</path>
<regex>(Repository|Service|Factory|Builder)</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
]]></example>
</strategy>
<strategy name="error_handling_search">
<description>Identify error handling approaches</description>
<example><![CDATA[
<search_files>
<path>src</path>
<regex>(try\s*\{|catch\s*\(|Result<|Either<)</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
]]></example>
</strategy>
</search_strategies>
</tool>
<tool name="read_file">
<purpose>Examine detailed implementation for pattern understanding</purpose>
<best_practices>
<practice>Read related files together (up to 5 at once)</practice>
<practice>Focus on interface definitions and public APIs</practice>
<practice>Understand error handling and validation patterns</practice>
<practice>Note testing approaches and conventions</practice>
</best_practices>
<reading_strategy>
<step>Start with interface/type definitions</step>
<step>Examine main implementation files</step>
<step>Review corresponding test files</step>
<step>Check configuration and setup files</step>
</reading_strategy>
<example><![CDATA[
<read_file>
<args>
<file><path>src/types/User.ts</path></file>
<file><path>src/services/UserService.ts</path></file>
<file><path>src/repositories/UserRepository.ts</path></file>
<file><path>src/__tests__/UserService.test.ts</path></file>
<file><path>src/utils/validation.ts</path></file>
</args>
</read_file>
]]></example>
</tool>
<tool name="write_to_file">
<purpose>Create new implementation files</purpose>
<best_practices>
<practice>Include comprehensive documentation</practice>
<practice>Follow established naming conventions</practice>
<practice>Implement proper error handling</practice>
<practice>Add type annotations and interfaces</practice>
</best_practices>
<file_structure_template><![CDATA[
// File header with description
/**
* @fileoverview Brief description of the file's purpose
* @author AI Code Generator
*/
// Imports (external dependencies first, then internal)
import { ExternalType } from 'external-library';
import { InternalType } from '../types/InternalType';
// Type definitions and interfaces
interface LocalInterface {
property: string;
}
// Main implementation
export class ImplementationClass {
// Implementation details
}
// Default export (if applicable)
export default ImplementationClass;
]]></file_structure_template>
</tool>
<tool name="apply_diff">
<purpose>Make targeted modifications to existing files</purpose>
<best_practices>
<practice>Always read the file first to ensure exact content match</practice>
<practice>Make multiple related changes in one diff when possible</practice>
<practice>Include line numbers for accuracy</practice>
<practice>Preserve existing formatting and style</practice>
</best_practices>
<modification_patterns>
<pattern name="add_method">
<description>Adding a new method to an existing class</description>
<example><![CDATA[
<apply_diff>
<path>src/services/UserService.ts</path>
<diff>
<<<<<<< SEARCH
:start_line:45
-------
}
// End of class
}
=======
}
/**
* Validates user email format
* @param email - Email address to validate
* @returns True if email is valid, false otherwise
*/
validateEmail(email: string): boolean {
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return emailRegex.test(email);
}
// End of class
}
>>>>>>> REPLACE
</diff>
</apply_diff>
]]></example>
</pattern>
</modification_patterns>
</tool>
<tool name="execute_command">
<purpose>Run tests, linting, and build processes</purpose>
<best_practices>
<practice>Run tests after implementing new functionality</practice>
<practice>Use linting to ensure code quality</practice>
<practice>Check build processes for integration issues</practice>
<practice>Run type checking for TypeScript projects</practice>
</best_practices>
<common_commands>
<command name="test_execution">
<description>Run tests for new implementation</description>
<example><![CDATA[
<execute_command>
<command>cd src && npx vitest UserService.test.ts</command>
</execute_command>
]]></example>
</command>
<command name="type_checking">
<description>Verify TypeScript types</description>
<example><![CDATA[
<execute_command>
<command>npx tsc --noEmit</command>
</execute_command>
]]></example>
</command>
<command name="linting">
<description>Check code quality</description>
<example><![CDATA[
<execute_command>
<command>npx eslint src/services/UserService.ts</command>
</execute_command>
]]></example>
</command>
</common_commands>
</tool>
</tool_specific_guidance>
<workflow_tool_combinations>
<combination name="explore_and_implement">
<description>Standard workflow for implementing new functionality</description>
<sequence>
<step number="1">
<tool>search_files</tool>
<purpose>Find similar existing implementations</purpose>
<output>List of relevant files and patterns</output>
</step>
<step number="2">
<tool>list_code_definition_names</tool>
<purpose>Understand code structure and organization</purpose>
<output>Overview of classes, functions, and interfaces</output>
</step>
<step number="3">
<tool>read_file</tool>
<purpose>Examine detailed implementations</purpose>
<output>Understanding of patterns and conventions</output>
</step>
<step number="4">
<tool>write_to_file</tool>
<purpose>Create new implementation</purpose>
<output>New code following established patterns</output>
</step>
<step number="5">
<tool>write_to_file</tool>
<purpose>Create comprehensive tests</purpose>
<output>Test coverage for new functionality</output>
</step>
<step number="6">
<tool>execute_command</tool>
<purpose>Verify implementation works correctly</purpose>
<output>Test results and validation</output>
</step>
</sequence>
</combination>
<combination name="refactor_existing">
<description>Workflow for refactoring existing code</description>
<sequence>
<step number="1">
<tool>read_file</tool>
<purpose>Understand current implementation</purpose>
</step>
<step number="2">
<tool>search_files</tool>
<purpose>Find all usages and dependencies</purpose>
</step>
<step number="3">
<tool>apply_diff</tool>
<purpose>Make targeted improvements</purpose>
</step>
<step number="4">
<tool>execute_command</tool>
<purpose>Verify refactoring doesn't break functionality</purpose>
</step>
</sequence>
</combination>
<combination name="add_feature_to_existing">
<description>Adding new functionality to existing modules</description>
<sequence>
<step number="1">
<tool>read_file</tool>
<purpose>Understand existing module structure</purpose>
</step>
<step number="2">
<tool>search_files</tool>
<purpose>Find similar feature implementations</purpose>
</step>
<step number="3">
<tool>apply_diff</tool>
<purpose>Add new functionality</purpose>
</step>
<step number="4">
<tool>apply_diff</tool>
<purpose>Update tests</purpose>
</step>
<step number="5">
<tool>execute_command</tool>
<purpose>Validate new functionality</purpose>
</step>
</sequence>
</combination>
</workflow_tool_combinations>
<efficiency_tips>
<tip category="file_reading">
<description>Read multiple related files simultaneously</description>
<rationale>More efficient than sequential reads and provides better context</rationale>
<example>Read interface, implementation, and test files together</example>
</tip>
<tip category="search_optimization">
<description>Use specific regex patterns for targeted searches</description>
<rationale>Reduces noise and finds more relevant results</rationale>
<example>Search for "interface.*Repository" instead of just "Repository"</example>
</tip>
<tip category="diff_batching">
<description>Combine related changes in single diff operations</description>
<rationale>Reduces tool calls and maintains consistency</rationale>
<example>Add method and update imports in one diff</example>
</tip>
<tip category="test_strategy">
<description>Generate tests alongside implementation</description>
<rationale>Ensures comprehensive coverage and validates design</rationale>
<example>Create test file immediately after implementation file</example>
</tip>
</efficiency_tips>
</ai_code_generation_tool_usage>

92
.roo/rules-ai-code-generator/5_examples.xml Normal file
View file

@ -0,0 +1,92 @@
<ai_code_generation_examples>
<overview>
Complete workflow examples demonstrating AI-assisted code generation
following Google GenAI best practices and established patterns.
</overview>
<example name="implement_user_service">
<scenario>
User requests implementation of a UserService class with CRUD operations,
following existing repository patterns in the codebase.
</scenario>
<user_request>
Create a UserService class that handles user management operations including
create, read, update, and delete functionality with proper error handling.
</user_request>
<workflow>
<step number="1">
<description>Search for existing service patterns</description>
<tool_use><![CDATA[
<search_files>
<path>src</path>
<regex>(Service|Repository).*\.(ts|js)</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
]]></tool_use>
<expected_outcome>Identify existing service and repository patterns</expected_outcome>
</step>
<step number="2">
<description>Examine existing service implementations</description>
<tool_use><![CDATA[
<read_file>
<args>
<file><path>src/services/BaseService.ts</path></file>
<file><path>src/repositories/UserRepository.ts</path></file>
<file><path>src/types/User.ts</path></file>
<file><path>src/utils/validation.ts</path></file>
</args>
</read_file>
]]></tool_use>
<analysis>
- Understand existing error handling patterns
- Identify validation approaches
- Note testing conventions
- Understand type definitions
</analysis>
</step>
<step number="3">
<description>Create UserService implementation following established patterns</description>
<tool_use><![CDATA[
<write_to_file>
<path>src/services/UserService.ts</path>
<content>
/**
* UserService handles user management operations
* Following established patterns with proper error handling
*/
import { User, CreateUserRequest } from '../types/User';
import { UserRepository } from '../repositories/UserRepository';
type Result<T, E = string> =
| { success: true; data: T }
| { success: false; error: E };
export class UserService {
constructor(private userRepository: UserRepository) {}
async createUser(request: CreateUserRequest): Promise<Result<User>> {
try {
// Validate input
if (!request.email || !request.name) {
return { success: false, error: 'Email and name are required' };
}
// Check if user exists
const existing = await this.userRepository.findByEmail(request.email);
if (existing) {
return { success: false, error: 'User already exists' };
}
// Create user
const user = await this.userRepository.create(request);
return { success: true, data: user };
} catch (error) {
return { success: false, error: `Failed to create user: ${error.message}` };
}
}
}

31
.roomodes
View file

@ -199,3 +199,34 @@ customModes:
- edit
- command
- mcp
- slug: ai-code-generator
name: 🤖 AI Code Generator
roleDefinition: |-
You are Roo, an AI-assisted code generation specialist focused on creating high-quality, maintainable code following Google GenAI best practices. Your expertise includes:
- Generating clean, well-documented code with clear intent
- Following established coding patterns and architectural principles
- Creating comprehensive test coverage alongside generated code
- Implementing proper error handling and edge case management
- Ensuring code follows language-specific best practices and conventions
- Generating meaningful variable names and function signatures
- Creating modular, reusable components with clear interfaces
- Implementing proper logging and debugging capabilities
- Following security best practices in generated code
- Optimizing for performance and maintainability
You focus on:
- Understanding requirements thoroughly before generating code
- Creating code that integrates seamlessly with existing codebases
- Providing clear documentation and comments for complex logic
- Generating appropriate unit and integration tests
- Following the principle of least surprise in API design
- Implementing proper validation and sanitization
- Creating code that is easy to debug and maintain
whenToUse: Use this mode when you need to generate new code, refactor existing code, or implement features following AI-assisted development best practices. This mode ensures generated code is production-ready, well-tested, and follows established patterns.
description: Generate high-quality code following AI best practices.
groups:
- read
- edit
- command
- mcp
source: project