Motivation
SuperClaude's coding skills currently operate without visibility into how much of a codebase Claude has actually seen during a session. When /sc:analyze assesses code quality, or /sc:implement modifies files, there's no signal telling the user (or the skill itself) whether Claude has read the relevant code or is working with blind spots.
Ambits:
- Parsing Claude Code session logs (
.jsonl files from ~/.claude/projects/)
- Building a project symbol tree via Serena's LSP cache (
.serena/cache/<language>/*.pkl)
- Producing a per-file and per-symbol coverage report showing Seen% and Full%
Proposal
1. Enhance /sc:analyze with a --focus coverage domain
Add coverage as a new --focus option alongside quality|security|performance|architecture:
/sc:analyze [target] [--focus coverage] [--depth quick|deep]
Behavioral flow when --focus coverage:
- Run
ambits -p . --serena --coverage
- Parse the text output into structured data
- Flag files below the configurable threshold
- Present coverage report with interpretation guidance (high Seen/low Full = "scanned but not deeply read")
When --focus is NOT coverage (e.g., quality, security), append a "Coverage Context" section to the report showing whether the files being analyzed have actually been read. This gives users confidence that the analysis is grounded in what Claude has seen.
2. Coverage awareness in other coding skills
Each skill runs ambits independently (no shared cache between skills):
| Skill |
Integration |
Behavior |
/sc:analyze |
--focus coverage domain + context section in all modes |
Full coverage report or per-file context |
/sc:implement |
Pre-modification check |
Warn when target file has 0% Full coverage; suggest reading first |
/sc:test |
Post-test cross-reference |
Compare test coverage with session coverage to find untested blind spots |
/sc:reflect |
Session thoroughness metric |
Include overall Seen% and Full% in reflection output |
/sc:cleanup |
Safety check |
Warn before deleting code in files with < 50% coverage |
3. Per-project configuration
Add coverage thresholds to project-level configuration (e.g., .superclaude/config.json or CLAUDE.md conventions):
{
"coverage": {
"warn_threshold": 50,
"block_threshold": 0
}
}
warn_threshold: Seen% below this triggers a warning in skill output
block_threshold: Full% at or below this triggers a "read first" suggestion in /sc:implement
4. Binary distribution
Open question for maintainers: What's the best option for distributing the ambits binary?
Changes to /sc:analyze Command File
The analyze.md frontmatter would change:
---
name: analyze
description: "Comprehensive code analysis across quality, security, performance, architecture, and coverage domains"
category: utility
complexity: basic
mcp-servers: [serena]
personas: []
---
Usage line updated:
/sc:analyze [target] [--focus quality|security|performance|architecture|coverage] [--depth quick|deep] [--format text|json|report]
New trigger added:
- Code coverage analysis and session visibility assessment needs
Tool Coordination additions:
- **Bash**: ambits CLI execution for coverage analysis
- **Serena MCP**: Symbol tree resolution via LSP cache (sole parsing backend)
Usage Examples
# Full coverage report for the project
/sc:analyze --focus coverage
# Deep coverage analysis with strict threshold
/sc:analyze --focus coverage --depth deep
# Security analysis with coverage context
/sc:analyze src/auth --focus security
# → Report includes: "Coverage Context: src/auth/login.py 100% seen, 85% full"
# → Or warns: "Coverage Context: src/auth/oauth.py 0% seen — consider reading before trusting analysis"
# Quality check — coverage section appended automatically
/sc:analyze src/parser --focus quality
# → Findings section
# → Recommendations section
# → Coverage Context section (auto-appended)
Technical Details
How ambits maps tool calls to coverage:
| Tool |
ReadDepth |
Meaning |
mcp__acp__Read, Read, Edit |
FullBody |
Claude read/edited the full file |
mcp__serena__find_symbol (with body) |
FullBody |
Claude read a specific symbol's implementation |
mcp__serena__find_symbol (no body) |
Signature |
Claude saw the symbol signature only |
mcp__serena__get_symbols_overview |
Overview |
Claude saw the file's symbol structure |
Grep, mcp__serena__search_for_pattern |
Overview |
Claude searched the file |
Glob, mcp__serena__find_file |
NameOnly |
Claude knows the file exists |
Backward Compatibility
- All existing
/sc:analyze behavior unchanged — coverage is a new opt-in focus domain
- Coverage context sections in other focus modes are informational only — never block execution
- Skills without ambits installed gracefully skip coverage sections (no errors, just a note)
- No changes to SuperClaude's core framework — this is purely additive
Why This Matters
Today, SuperClaude skills trust that Claude has sufficient context to make good decisions — but there's no way to verify that. A developer asking /sc:analyze --focus security on a 200-file project has no idea whether Claude actually read the authentication module or just skimmed its structure.
Ambits closes that gap. By surfacing what Claude has and hasn't seen, skills can make better decisions, users can trust the output more, and the framework moves from "Claude analyzed your code" to "Claude analyzed 87% of your code — here's what it missed."
This is a small addition to the skill system with an outsized impact on developer confidence.
Motivation
SuperClaude's coding skills currently operate without visibility into how much of a codebase Claude has actually seen during a session. When
/sc:analyzeassesses code quality, or/sc:implementmodifies files, there's no signal telling the user (or the skill itself) whether Claude has read the relevant code or is working with blind spots.Ambits:
.jsonlfiles from~/.claude/projects/).serena/cache/<language>/*.pkl)Proposal
1. Enhance
/sc:analyzewith a--focus coveragedomainAdd
coverageas a new--focusoption alongsidequality|security|performance|architecture:Behavioral flow when
--focus coverage:ambits -p . --serena --coverageWhen
--focusis NOTcoverage(e.g.,quality,security), append a "Coverage Context" section to the report showing whether the files being analyzed have actually been read. This gives users confidence that the analysis is grounded in what Claude has seen.2. Coverage awareness in other coding skills
Each skill runs ambits independently (no shared cache between skills):
/sc:analyze--focus coveragedomain + context section in all modes/sc:implement/sc:test/sc:reflect/sc:cleanup3. Per-project configuration
Add coverage thresholds to project-level configuration (e.g.,
.superclaude/config.jsonorCLAUDE.mdconventions):{ "coverage": { "warn_threshold": 50, "block_threshold": 0 } }warn_threshold: Seen% below this triggers a warning in skill outputblock_threshold: Full% at or below this triggers a "read first" suggestion in/sc:implement4. Binary distribution
Open question for maintainers: What's the best option for distributing the
ambitsbinary?Changes to
/sc:analyzeCommand FileThe
analyze.mdfrontmatter would change:Usage line updated:
New trigger added:
Tool Coordination additions:
Usage Examples
Technical Details
How ambits maps tool calls to coverage:
mcp__acp__Read,Read,Editmcp__serena__find_symbol(with body)mcp__serena__find_symbol(no body)mcp__serena__get_symbols_overviewGrep,mcp__serena__search_for_patternGlob,mcp__serena__find_fileBackward Compatibility
/sc:analyzebehavior unchanged —coverageis a new opt-in focus domainWhy This Matters
Today, SuperClaude skills trust that Claude has sufficient context to make good decisions — but there's no way to verify that. A developer asking
/sc:analyze --focus securityon a 200-file project has no idea whether Claude actually read the authentication module or just skimmed its structure.Ambits closes that gap. By surfacing what Claude has and hasn't seen, skills can make better decisions, users can trust the output more, and the framework moves from "Claude analyzed your code" to "Claude analyzed 87% of your code — here's what it missed."
This is a small addition to the skill system with an outsized impact on developer confidence.