- Add kaizen-agentic submodule from coulomb/kaizen-agentic repository - Integrate as capabilities/kaizen-agentic/ following capability inclusion pattern - Update CAPABILITY_REGISTRY.md with new AI agent framework capability - Update CAPABILITY_INCLUSION_GUIDE.md directory structure - Update capability metrics: 5 total capabilities, 3 submodules - Establish kaizen-agentic integration pattern: cd capabilities/kaizen-agentic && make [command] Extends capability inclusion architecture with: - Advanced AI agent framework for autonomous development workflows - Agent definitions, workflow automation, development patterns - Clear separation from internal MarkiTect functionality 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
9.3 KiB
Capability Inclusion Guide
Complete guide to understanding and managing capability inclusion in the MarkiTect project
Overview
MarkiTect uses a Capability Inclusion Pattern where functionality is organized into distinct capabilities that can be:
- Internal: Provided by this repository (core MarkiTect functionality)
- External: Used by this repository (submodules, dependencies, extracted capabilities)
This approach enables clear separation of concerns, easy extension/bugfixing, and prevents code duplication.
📋 Documentation Structure
Core Documentation Files
-
CAPABILITIES.md- Internal Capability Inventory- Purpose: Comprehensive analysis of all capabilities provided BY this repository
- Content: 73+ internal capabilities, test coverage, extraction recommendations
- Scope: What MarkiTect provides to the world
-
CAPABILITY_REGISTRY.md- External Capability Registry- Purpose: Registry of all capabilities USED BY this repository
- Content: Submodules, local extracted capabilities, external dependencies
- Scope: What MarkiTect consumes from other sources
-
CLAUDE_CAPABILITY_REFERENCE.md- Quick Usage Reference- Purpose: Prevent code duplication by guiding Claude to existing capabilities
- Content: Quick lookup patterns and anti-duplication rules
- Scope: Operational guidance for development
-
CAPABILITY_INCLUSION_GUIDE.md- This Document- Purpose: Explains the overall capability inclusion architecture
- Content: Workflow, patterns, internal vs external organization
- Scope: Architectural understanding and management
🏗️ Capability Organization Architecture
Internal Capabilities (Provided BY MarkiTect)
Location: Throughout the main codebase
Purpose: Core functionality that MarkiTect provides to the world
Management: Documented in CAPABILITIES.md
Categories:
- Core Processing: AST-based markdown processing, database operations
- CLI Commands: Command-line interface functionality
- Template Engine: Document template processing
- Caching System: Multi-layer performance caching
- Schema Validation: Document structure validation
- Export/Import: Data transformation capabilities
Extraction Candidates:
- Capabilities that could be useful to other projects
- Self-contained functionality with clear boundaries
- Well-tested components (>80% coverage preferred)
Example Internal Capability:
markitect/database/ # Database operations capability
markitect/template/ # Template processing capability
markitect/cli/ # CLI framework capability
External Capabilities (Used BY MarkiTect)
Location: Various inclusion patterns
Purpose: Functionality MarkiTect depends on from external sources
Management: Documented in CAPABILITY_REGISTRY.md
1. Submodule Capabilities (Independent Repositories)
- Pattern: Git submodules pointing to external repositories
- Benefits: Independent versioning, separate development, easy updates
- Examples:
capabilities/issue-facade/,wiki/
2. Local Extracted Capabilities (Previously Internal, Now Separated)
- Pattern: Moved to
capabilities/directory but still in this repo - Benefits: Clear separation, preparation for future extraction
- Examples:
capabilities/markitect-content/,capabilities/markitect-utils/
3. Package Dependencies (Third-Party Libraries)
- Pattern: Standard pip dependencies in
pyproject.toml - Benefits: Mature, maintained, standard integration
- Examples:
click,pytest,sqlalchemy
🔄 Capability Inclusion Workflow
Phase 1: Internal Development
Developer creates functionality → Internal capability (in main codebase)
Phase 2: Extraction Evaluation
Capability matures → Evaluate extraction criteria → Decide extraction pattern
Phase 3: Capability Inclusion
Extract capability → Choose inclusion pattern → Update registries
Inclusion Pattern Decision Tree:
-
Will other projects use this capability?
- Yes → Consider Submodule Capability (extract to separate repo)
- No → Consider Local Capability (move to
capabilities/)
-
Does it need independent versioning/development?
- Yes → Submodule Capability
- No → Local Capability
-
Is it a mature third-party solution?
- Yes → Package Dependency
- No → Custom solution needed
Example Extraction Journey:
Internal → markitect/issues/ (internal issue management)
Evaluation → Self-contained, reusable, independent development needed
Extraction → coulomb/issue-facade (separate repository)
Inclusion → capabilities/issue-facade/ (submodule capability)
Registration → CAPABILITY_REGISTRY.md updated
📊 Current Capability Landscape
Internal Capabilities (73+ documented in CAPABILITIES.md)
markitect/ # Core repository
├── database/ # Database operations
├── template/ # Template processing
├── cli/ # CLI framework
├── packaging/ # Document packaging
├── finance/ # Cost tracking
└── [... 68+ more capabilities]
External Capabilities (5 documented in CAPABILITY_REGISTRY.md)
capabilities/
├── issue-facade/ # Submodule: Universal issue tracking
├── kaizen-agentic/ # Submodule: AI agent framework
├── markitect-content/ # Local: Content processing
└── markitect-utils/ # Local: Utility functions
wiki/ # Submodule: Documentation
[External dependencies: click, pytest, sqlalchemy, ...]
🛠️ Management Operations
Discovery and Validation
# Discover all external capabilities
make capability-report
# Search for existing functionality
make capability-search TERM=issue_management
# Validate proper usage
make capability-validate FILE=my_code.py
Adding New External Capabilities
Submodule Capability:
git submodule add <repo-url> <local-path>
# Update CAPABILITY_REGISTRY.md
Local Capability:
mkdir capabilities/new-capability
# Move code, create README.md
# Update CAPABILITY_REGISTRY.md
Package Dependency:
# Update pyproject.toml
# Update CAPABILITY_REGISTRY.md
Updating Capabilities
Submodules:
git submodule update --remote <submodule-path>
Local Capabilities:
# Direct code updates in capabilities/
Package Dependencies:
pip install --upgrade <package>
# Update pyproject.toml version constraints
🎯 Best Practices
For Internal Capabilities (CAPABILITIES.md):
- Document thoroughly: Clear description, interfaces, test coverage
- Evaluate extraction: Regular review against extraction criteria
- Maintain quality: Adequate test coverage, clear boundaries
- Consider reusability: Could other projects benefit from this?
For External Capabilities (CAPABILITY_REGISTRY.md):
- Registry first: Always check before implementing new functionality
- Respect interfaces: Use documented APIs, don't bypass capabilities
- Update documentation: Keep registry current with capability changes
- Clear boundaries: Don't duplicate external capability functionality
For Claude and Developers:
- Check before code: Always consult
CAPABILITY_REGISTRY.mdfirst - Use discovery tools:
make capability-searchbefore implementing - Follow patterns: Use established integration patterns
- Update registries: Document new capabilities immediately
🔮 Future Evolution
Extraction Pipeline:
Internal Capability → Evaluation → Local Capability → Submodule Capability
Maturity Progression:
- Internal: New functionality developed in main codebase
- Local: Stable functionality moved to
capabilities/for separation - Submodule: Mature functionality extracted to independent repository
- Package: Published capabilities available via pip/pypi
Success Metrics:
- Zero duplication: No accidental reimplementation of existing capabilities
- Clear boundaries: Well-defined interfaces between internal and external
- Easy extension: Simple to enhance or fix external capabilities
- Efficient discovery: Fast identification of existing functionality
📚 Quick Reference
| Need | Check | Use |
|---|---|---|
| Internal MarkiTect functionality | CAPABILITIES.md |
Import from main codebase |
| External functionality | CAPABILITY_REGISTRY.md |
Use documented interface |
| Prevent duplication | CLAUDE_CAPABILITY_REFERENCE.md |
Follow anti-duplication rules |
| Understand architecture | CAPABILITY_INCLUSION_GUIDE.md |
This document |
Remember: Internal capabilities are what MarkiTect provides, external capabilities are what MarkiTect uses.