Implement revolutionary capability inclusion management system with complete documentation ecosystem and automated discovery tools to prevent code duplication and ensure proper separation of concerns. Key accomplishments: - Comprehensive capability documentation ecosystem (5 interconnected files) - Clear separation: internal capabilities (what MarkiTect provides) vs external capabilities (what MarkiTect uses) - Automated discovery tools preventing code duplication (make capability-search) - AI-assistant optimized workflow with quick reference guide - Enhanced project-assistant agent definition with capability inclusion workflow - Updated README.md with clear links to capability documentation - Complete session wrap-up with updated ProjectDiary.md, NEXT.md, and ProjectStatusDigest.md Architecture milestone: Establishes MarkiTect as mature project with enterprise-grade capability management, transforming development from ad-hoc implementation to systematic capability management with automated duplication prevention. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
4.8 KiB
4.8 KiB
Capability Documentation Index
Master index to all capability-related documentation in MarkiTect
📋 Quick Navigation
| Document | Purpose | Scope |
|---|---|---|
| CAPABILITIES.md | Internal Capabilities | What MarkiTect provides to the world |
| CAPABILITY_REGISTRY.md | External Capabilities | What MarkiTect uses from others |
| CLAUDE_CAPABILITY_REFERENCE.md | Quick Reference | Prevent duplication, guide usage |
| CAPABILITY_INCLUSION_GUIDE.md | Architecture Guide | Complete workflow and patterns |
🎯 When to Use Which Document
I want to understand what MarkiTect can do
→ Read: CAPABILITIES.md
- 73+ internal capabilities provided by MarkiTect
- Core processing, CLI, templates, caching, validation
- Extraction candidates and recommendations
I want to see what MarkiTect depends on
→ Read: CAPABILITY_REGISTRY.md
- External capabilities: submodules, local, packages
- Issue management (issue-facade), documentation (wiki)
- Content processing, utilities, dependencies
I'm implementing something and want to avoid duplication
→ Read: CLAUDE_CAPABILITY_REFERENCE.md
- Quick lookup patterns
- "Use X for Y" guidance
- Anti-duplication rules
I want to understand the capability architecture
→ Read: CAPABILITY_INCLUSION_GUIDE.md
- Internal vs external organization
- Inclusion workflow and patterns
- Management operations and best practices
🔍 Discovery and Management Tools
Command-Line Tools
# Generate capability report
make capability-report
# Search for existing functionality
make capability-search TERM=issue_management
# Validate proper capability usage
make capability-validate FILE=my_code.py
Programmatic Discovery
# Run capability discovery tool directly
python tools/capability_discovery.py report
python tools/capability_discovery.py search "function_name"
python tools/capability_discovery.py validate "file_path"
🏗️ Capability Architecture Overview
MarkiTect Repository
├── [Internal Capabilities] # CAPABILITIES.md
│ ├── markitect/database/ # Database operations
│ ├── markitect/template/ # Template processing
│ ├── markitect/cli/ # CLI framework
│ └── ... (70+ more) # Core MarkiTect functionality
│
└── [External Capabilities] # CAPABILITY_REGISTRY.md
├── issue-facade/ # Submodule: Issue tracking
├── wiki/ # Submodule: Documentation
├── capabilities/ # Local extracted capabilities
│ ├── markitect-content/ # Content processing
│ └── markitect-utils/ # Utility functions
└── [Package Dependencies] # click, pytest, etc.
📊 Current Status Summary
Internal Capabilities (PROVIDED BY MarkiTect)
- Total: 73+ documented capabilities
- Categories: Core processing, CLI, templates, validation, export/import
- Test Coverage: 348 tests across 27 test files
- Extraction Pipeline: 2 extracted, 11 candidates identified
External Capabilities (USED BY MarkiTect)
- Submodules: 2 (issue-facade, wiki)
- Local: 2 (markitect-content, markitect-utils)
- Packages: Multiple (click, pytest, sqlalchemy, etc.)
- Management: Automated discovery and validation tools
🎯 Best Practices Quick Reference
For Developers
- Check External First: Always consult
CAPABILITY_REGISTRY.mdbefore implementing - Use Discovery Tools:
make capability-searchbefore coding - Follow Patterns: Use established integration patterns
- Update Documentation: Keep registries current
For Claude
- Registry First: Check
CAPABILITY_REGISTRY.mdbefore any implementation - Quick Lookup: Use
CLAUDE_CAPABILITY_REFERENCE.mdfor instant guidance - Respect Boundaries: Don't duplicate external capability functionality
- Discovery Commands: Use
make capability-search TERM=xyzto find existing
For Architecture
- Clear Separation: Internal (provides) vs External (uses)
- Extraction Pipeline: Internal → Local → Submodule → Package
- Documentation: Keep all four documents synchronized
- Validation: Regular checks for duplication and proper usage
💡 Remember: This index helps you navigate the capability ecosystem efficiently. Start here to find the right documentation for your needs!