/**
 * @akson/cortex-doc-standards - Shared Packages Modification Standards
 *
 * Defines standards for modifying shared Cortex packages across projects
 * that Claude AI must follow when implementing features.
 */
export interface SharedPackagesStandards {
    modificationPolicy: {
        encouraged: boolean;
        approachType: 'modify-existing' | 'create-local' | 'both';
        breakingChanges: 'avoid' | 'document' | 'prohibited';
    };
    guidelines: Array<{
        principle: string;
        description: string;
        required: boolean;
    }>;
    decisionCriteria: {
        modifyShared: string[];
        createLocal: string[];
    };
    workflow: Array<{
        step: number;
        action: string;
        tools?: string[];
    }>;
}
export declare const SHARED_PACKAGES_STANDARDS: SharedPackagesStandards;
export declare const SHARED_PACKAGES_TEMPLATE = "## \uD83D\uDCE6 Cortex Packages - Shared Components & Utilities\n\n**IMPORTANT**: The Cortex packages are shared libraries used across multiple projects. You are encouraged to modify and extend them as needed for project features.\n\n### Modifying Cortex Packages\n\n\u2705 **DO modify Cortex packages when:**\n- Project needs new functionality that could benefit other projects\n- You find bugs or improvements that should be shared\n- The existing API doesn't meet your project's requirements\n- You can add reusable utilities or components\n- Performance improvements can be made\n- Security enhancements are needed\n\n### Guidelines for Cortex Modifications\n\n1. **Make changes thoughtfully**: Consider how changes might affect other projects\n2. **Add functionality, don't break existing APIs**: Prefer extending over changing\n3. **Document new features**: Update package documentation for new additions\n4. **Test thoroughly**: Ensure changes work across different use cases\n5. **Communicate breaking changes**: If unavoidable, document migration paths\n\n### When to Modify vs. Create Local\n\n**Modify Cortex packages for:**\n- Reusable functionality that could benefit other projects\n- Bug fixes or improvements that should be shared\n- API extensions that maintain backward compatibility\n- Reusable utilities or components\n\n**Create locally for:**\n- Project-specific business logic or highly specialized features\n- Temporary workarounds or experimental implementations\n- Features with uncertain reusability\n\n### Modification Workflow\n\n1. **Assess**: Determine if the change should be shared or local\n2. **Review**: Check existing package structure and conventions\n3. **Implement**: Follow existing patterns and maintain consistency\n4. **Document**: Update README, JSDoc, and examples\n5. **Test**: Verify changes work across different scenarios\n6. **Version**: Update package version following semantic versioning\n\n**Remember**: Cortex packages are meant to evolve. Don't hesitate to improve them when it makes sense for the broader ecosystem.\n\n### Best Practices\n\n- **Backward Compatibility**: Always maintain existing function signatures\n- **Optional Parameters**: Add new features as optional parameters\n- **Deprecation**: Mark old APIs as deprecated before removing\n- **Testing**: Add tests for new functionality\n- **Documentation**: Update JSDoc and README files\n- **Examples**: Provide usage examples for new features\n\n### Version Management\n\n- **Patch (x.x.X)**: Bug fixes, small improvements\n- **Minor (x.X.x)**: New features, backward compatible\n- **Major (X.x.x)**: Breaking changes (avoid when possible)\n";
/**
 * Validates that a CLAUDE.md file contains proper shared packages modification standards
 */
export declare function validateSharedPackagesIntegration(content: string): {
    isValid: boolean;
    errors: string[];
    warnings: string[];
};
//# sourceMappingURL=shared-packages.d.ts.map