Refactor issue-facade to conform to the new ReusableCapabilitiesArchitecture specification, improving discoverability and establishing consistent patterns for capability integration. Architecture Changes: - Rename .feedback/ → feedback/ (visible user interface) - Rename CAPABILITY.yaml → CAPABILITY-issue-tracking.yaml (explicit family) - Keep .capability/ hidden (evolving implementation infrastructure) File Updates: - Updated all documentation references (.feedback → feedback) - Updated .capability/feedback script paths - Updated Makefile, README.md, CLAUDE.md, examples - Fixed CAPABILITY.yaml → CAPABILITY-issue-tracking.yaml references New Tools: - Created .capability/detach script for clean capability removal - Supports git submodule and directory-based integrations - Generates detachment manifest for re-integration guidance Rationale: - feedback/ is visible: encourages user participation, shows capability identity - .capability/ is hidden: implementation details that will evolve - CAPABILITY-<family>.yaml: explicit family declaration, supports multiple capabilities per repo - Underscore prefix pattern: flatter hierarchy, clear signal of integration This aligns with the principle that capabilities are conceptual units designed for natural language integration by devhumans and devagents, not just technical libraries. See ReusableCapabilitiesArchitecture.md for complete specification. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Capability Bootstrap System
How coding agents discover and integrate the issue-facade capability.
Design Philosophy
Problem: Coding agents might bypass capabilities and use direct API calls, causing:
- Credential management chaos
- Token waste
- Platform lock-in
- Race conditions
- Inconsistent state
Solution: Make capabilities self-describing and easy to discover, so agents naturally prefer them over alternatives.
Architecture
1. Self-Description (Machine-Readable)
File: CAPABILITY-issue-tracking.yaml
Contains machine-readable metadata that agents and tooling can parse:
- What the capability does
- When to use it vs. alternatives
- How to integrate it
- API surface
- Priority score (how critical it is)
Usage:
# Tools can parse this to understand capabilities
yq eval '.purpose.primary' CAPABILITY-issue-tracking.yaml
# Output: "Agent coordination via issue tracking"
2. Agent Context (Human + AI Readable)
File: .capability/agent-context.md
Comprehensive guide for coding agents:
- Quick reference API
- Common patterns
- Critical "DO NOT bypass" warnings
- Error handling
- Examples
Injected into: .claude/capabilities/issue-facade.md in main project
3. Integration Automation
File: .capability/integrate.sh
Interactive script that:
- Installs the capability
- Configures backends
- Injects context into Claude Code
- Creates slash commands
- Verifies setup
Usage:
make integrate
# or
cd capabilities/issue-facade && ./.capability/integrate.sh
4. Integration Checklist
File: .capability/integration-checklist.md
Step-by-step checklist for humans integrating the capability:
- Pre-integration checks
- Installation steps
- Verification tests
- Security review
- Troubleshooting
Integration Flow
For Main Project (One-Time Setup)
Main Project Setup
├── 1. Human runs: cd capabilities/issue-facade && make integrate
├── 2. Script installs capability
├── 3. Script configures backend (prompts for credentials)
├── 4. Script copies agent-context.md → .claude/capabilities/
├── 5. Script creates .claude/commands/use-issues.md
└── 6. Script verifies setup
Result:
issuecommand available system-wide- Backend configured with tokens
- Claude Code knows about capability
- Agents can discover via context files
For Coding Agents (Automatic)
Agent Workflow
├── 1. Agent receives task involving issues
├── 2. Agent checks .claude/capabilities/ for relevant docs
├── 3. Agent finds issue-facade.md with comprehensive guide
├── 4. Agent uses Python API or CLI as documented
└── 5. Agent avoids direct API calls (warned in docs)
Key Files Agent Reads:
.claude/capabilities/issue-facade.md- Complete usage guide.claude/context/capabilities.md- High-level capability list.claude/commands/use-issues.md- Slash command for context injection
Main Project Structure (After Integration)
project-root/
├── capabilities/
│ └── issue-facade/ # Capability code
│ ├── CAPABILITY-issue-tracking.yaml # Machine-readable metadata
│ ├── .capability/
│ │ ├── agent-context.md # Agent guide (source)
│ │ ├── integrate.sh # Integration script
│ │ └── README.md # This file
│ ├── issue_tracker/ # Python package
│ └── ...
│
├── .claude/ # Claude Code configuration
│ ├── capabilities/ # Capability docs for agents
│ │ └── issue-facade.md # Agent guide (copy)
│ │
│ ├── commands/ # Slash commands
│ │ └── use-issues.md # /use-issues command
│ │
│ └── context/ # Always-available context
│ └── capabilities.md # List of all capabilities
│
└── .issue-facade/ # Capability config (gitignored)
├── config.json # Backend configuration
└── issues.db # Local cache/backup
For Agent Developers
How to Make Your Agent Use the Capability
1. Check for capability context:
import os
from pathlib import Path
def has_issue_capability(project_root: Path) -> bool:
"""Check if issue-facade capability is available."""
capability_guide = project_root / ".claude/capabilities/issue-facade.md"
return capability_guide.exists()
if has_issue_capability(Path.cwd()):
# Use capability
from issue_tracker.backends.gitea import GiteaBackend
backend = GiteaBackend()
else:
# Fall back or prompt human
print("Issue capability not available. Please integrate it.")
2. Read the context:
def get_capability_docs(capability_name: str) -> str:
"""Read capability documentation."""
doc_path = Path(f".claude/capabilities/{capability_name}.md")
if doc_path.exists():
return doc_path.read_text()
return None
# Agent can read and understand the guide
docs = get_capability_docs("issue-facade")
# Parse docs for API usage patterns...
3. Use the API as documented:
# Example from agent-context.md
from issue_tracker.backends.gitea import GiteaBackend
from issue_tracker.core.interfaces import IssueFilter
backend = GiteaBackend()
backend.connect(config)
issues = backend.list_issues(IssueFilter(state='open'))
How to Avoid Bypassing
Bad (Bypasses capability):
# ❌ Direct API call
import requests
response = requests.post(
f"{gitea_url}/api/v1/repos/{owner}/{repo}/issues",
json={"title": "Bug"},
headers={"Authorization": f"token {token}"}
)
Good (Uses capability):
# ✅ Uses capability
from issue_tracker.backends.gitea import GiteaBackend
from issue_tracker.core.models import Issue, IssueState
from datetime import datetime, timezone
backend = GiteaBackend()
backend.connect(config)
issue = Issue(
id=None, number=0,
title="Bug",
description="Details",
state=IssueState.OPEN,
created_at=datetime.now(timezone.utc),
updated_at=datetime.now(timezone.utc)
)
backend.create_issue(issue)
For Capability Developers
Adding a New Capability to This System
1. Create capability structure:
capabilities/your-capability/
├── CAPABILITY-issue-tracking.yaml # Metadata
├── .capability/
│ ├── agent-context.md # Agent guide
│ ├── integrate.sh # Integration script
│ ├── integration-checklist.md # Human checklist
│ └── README.md # This doc adapted
└── your_package/ # Implementation
2. Write CAPABILITY-issue-tracking.yaml:
metadata:
name: your-capability
version: 1.0.0
type: tool | library | service
description: What it does
purpose:
primary: Main purpose
problems_solved:
- Problem 1
- Problem 2
usage_rules:
MUST_USE_INSTEAD_OF:
- "Alternative 1 to avoid"
- "Alternative 2 to avoid"
api:
core_operations:
- name: operation_1
python: "from your_package import ..."
cli: "your-command ..."
3. Write agent-context.md:
- Critical warnings (what NOT to do)
- Quick reference API
- Common patterns
- Error handling
- Examples
4. Create integrate.sh:
- Install capability
- Configure if needed
- Copy context to
.claude/capabilities/ - Create slash command
- Verify installation
5. Add to main project:
cd capabilities/your-capability
make integrate
Discovery Mechanisms
Manual Discovery (Human)
- Human sees
capabilities/directory - Reads
CAPABILITY-issue-tracking.yamlto understand what's available - Runs
make integrateto set up for agents
Automatic Discovery (Agent)
- Agent checks
.claude/capabilities/for available capabilities - Reads relevant
.mdfiles for usage guides - Uses capabilities as documented
- Falls back gracefully if capability unavailable
Tool-Assisted Discovery
# Future: Auto-discover all capabilities
make discover-capabilities
# Output:
# Found capabilities:
# - issue-facade (v1.0.0) - Issue tracking coordination
# - ... (other capabilities)
# Auto-integrate all
make integrate-all-capabilities
Priority System
Capabilities have priority scores (0-100) indicating importance:
- 90-100 (Critical): Must always use, bypassing causes major issues
- 70-89 (High): Should prefer over alternatives
- 50-69 (Medium): Use when available
- Below 50 (Low): Optional convenience
issue-facade priority: 95 (Critical)
Agents should check priority when deciding whether to use a capability or fall back to alternatives.
Best Practices
For Capability Authors
- Make it obvious: Clear documentation, examples, warnings
- Make it easy: One-command integration, good defaults
- Make it safe: No tokens in code, proper error handling
- Make it discoverable: Standard structure, machine-readable metadata
- Make it maintainable: Version clearly, document breaking changes
For Project Integrators
- Integrate early: Set up capabilities before agents start work
- Verify integration: Run tests to ensure agents use capabilities
- Monitor usage: Check that agents aren't bypassing capabilities
- Keep updated: Pull capability updates regularly
- Share feedback: Report issues, contribute improvements
For Agent Developers
- Check context: Always look for
.claude/capabilities/ - Read docs: Don't guess the API, read the guide
- Follow warnings: If docs say "DO NOT", don't do it
- Handle errors: Capability might not be available
- Report issues: If capability is confusing, report it
Future Enhancements
v1.1: Auto-Discovery
make list-capabilitiesto show all availablemake integrate-capability NAMEfor specific capability- Auto-detect when capability would be useful
v1.2: MCP Integration
- Capabilities as MCP servers
- Tool-based discovery (no file reading needed)
- Dynamic capability loading
v2.0: Capability Registry
- Central registry of available capabilities
- Version management and updates
- Dependency resolution
FAQ
Q: Why not just document "use issue-facade" in README?
A: Agents often skip general docs. Putting it in .claude/capabilities/ makes it part of their working context.
Q: What if agent bypasses capability anyway? A: 1) Check warnings are in context, 2) Use slash command to re-inject, 3) Review agent's reasoning for bypass.
Q: Can capabilities depend on each other? A: Not yet (v1.0). Planned for v2.0 with dependency resolution.
Q: How do I test integration? A: Run integration script, then test with agent doing actual work. Verify it uses capability API.
Q: What if capability breaks? A: Document rollback in integration checklist. Keep backup configs. Have fallback plan.
Summary
The capability bootstrap system works by:
- Self-description - Capability declares what it does (CAPABILITY-issue-tracking.yaml)
- Context injection - Integration copies docs to
.claude/capabilities/ - Agent discovery - Agents check context before implementing
- Natural preference - Good docs + warnings make capability easier than alternatives
- Verification - Integration script tests that everything works
Result: Agents naturally discover and use capabilities instead of bypassing them.
Example: Issue Tracking Use Case
Without capability:
# Agent bypasses, makes direct API call
response = requests.post(gitea_url + "/issues", ...)
# Problems: Token in code, no caching, platform-specific
With capability (properly integrated):
# Agent checks .claude/capabilities/issue-facade.md
# Reads: "Use this API, don't use direct requests"
# Agent follows documented pattern:
from issue_tracker.backends.gitea import GiteaBackend
backend = GiteaBackend()
backend.connect(config)
backend.create_issue(issue)
# Benefits: Centralized tokens, caching, platform-agnostic
The difference: Integration puts capability docs in agent's context, making it the obvious choice.
For more information:
- Integration Guide:
AGENT_INTEGRATION.md - Development Guide:
CLAUDE.md - Roadmap:
ROADMAP.md - Examples:
examples/agents/