Menu
Token-efficient retrieval using depth levels (L0-L5) and heading-based sections. Use for any file reads.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | content-retrieval |
| description | Token-efficient retrieval using depth levels (L0-L5) and heading-based sections. Use for any file reads. |
| layer | 4 |
| tech_stack | ["agnostic"] |
| topics | ["retrieval","efficiency","tokens","grep","read","protocol"] |
| depends_on | [] |
| complements | ["knowledge-discovery"] |
| keywords | ["retrieve","read","grep","lookup","tokens","efficient","partial","section"] |
| auto_apply | true |
Token-efficient retrieval system using markdown-native section detection.
Core Principle: Never read a full file when partial content suffices.
Choose retrieval depth by need:
| Level | Need | Method | Lines |
|---|---|---|---|
| L0 | Exists? | Grep(output: files_with_matches) | ~1 |
| L1 | Count? | Grep(output: count) | ~1 |
| L2 | Lookup value | Grep(pattern, -C:2) | ~5 |
| L3 | Overview | Read(limit: 40) | ~40 |
| L4 | Section | Grep heading → Read(offset, limit) | ~50 |
| L5 | Full | Read() - justify first | All |
What do I need?
├─ Does X exist? ──────────► L0: Grep files_with_matches
├─ How many X? ────────────► L1: Grep count
├─ What is X's value? ─────► L2: Grep with context
├─ What does X do? ────────► L3: Read limit:40
├─ How to use X for Y? ────► L4: Section extraction
└─ Implement X fully? ─────► L5: Full read (target only)
| Scenario | Tool | Parameters |
|---|---|---|
| Check skill exists | Grep | output: files_with_matches |
| Count matches | Grep | output: count |
| Get specific row | Grep | pattern, -C: 0-2 |
| Read frontmatter | Read | limit: 25 |
| Read frontmatter+summary | Read | limit: 40 |
| Extract section | Read | offset: N, limit: 50 |
| Full understanding | Read | (no limit) |
Sections are defined by headings and horizontal rules:
## Section A
Content...
--- ← Section A ends here (horizontal rule)
## Section B ← Or section ends at next same-level heading
Content...
No custom markers needed. Standard markdown structure.
1. Grep("^## Section Name$", file) → line 15
2. Grep("^---|^## ", file, offset: 16) → next break at line 30
3. Read(file, offset: 15, limit: 15) → lines 15-30
A section ends at the first of:
--- (horizontal rule)## (same-level heading)# (higher-level heading)# Extract Summary section
Grep("^## Summary$", file) → line 20
Grep("^---|^## ", file, offset: 21) → line 28
Read(file, offset: 20, limit: 8)
# Extract Quick Reference section
Grep("^## Quick Reference$", file) → line 30
Grep("^---|^## ", file, offset: 31) → line 55
Read(file, offset: 30, limit: 25)
WRONG: Read entire SKILL-INDEX.md to find one skill
RIGHT: Grep("skill-name", SKILL-INDEX.md, -C:1)
WRONG: Read 5 skill files to understand what they do
RIGHT: Read each with limit:40 (frontmatter + summary)
WRONG: Read entire agent file to check if it has a skill
RIGHT: Grep("skills:.*skill-name", agent.md)
1. Check index file (SKILL-INDEX.md, AGENT-INDEX.md)
2. Extract needed info via grep
3. Only read source file if index insufficient
All files have metadata in first 20 lines:
---
name: identifier
description: "one-line summary"
layer: 1-4
keywords: [searchable, terms]
---
To get metadata: Read(file, limit: 20)
Standard markdown headings define extractable sections:
## Summary ← Grep target
Brief description.
---
## Quick Reference ← Grep target
| Col | Col |
To extract section: Grep heading → find end → Read range
Full read justified when:
---
name: identifier
description: "One-line (< 100 chars)"
layer: 1-4
keywords: [grep, targets]
---
# Title
## Summary
2-3 sentences. Key purpose.
---
## Quick Reference
| Pattern | Usage |
|---------|-------|
---
## Patterns
### Pattern 1
Content...
### Pattern 2
Content...
---
## Related
- [link](path)
| Heading | Purpose | Required |
|---|---|---|
## Summary | Quick understanding (L3) | Yes |
## Quick Reference | Lookup tables (L2-L3) | Yes |
## Patterns | Implementation details | For skills |
## Scope | Does/Does NOT | For agents |
## Related | Cross-references | Recommended |
---
# Required
name: string # Identifier (grep target)
description: string # One-line (< 100 chars)
layer: number # 1=foundation, 2=framework, 3=feature, 4=workflow
# Recommended
keywords: string[] # Grep targets
depends_on: string[] # Prerequisites
complements: string[] # Often-used-with
# Optional
used_by: string[] # Agents/commands using this
tech_stack: string[] # Technologies
auto_apply: boolean # Auto-trigger on match
---
## Master Index
| Name | L | Keywords | Path |
|------|---|----------|------|
| skill-a | 2 | key1,key2 | skills/skill-a/SKILL.md |
| skill-b | 1 | key3,key4 | skills/skill-b/SKILL.md |
---
## Lookup by Keyword
| Keyword | Skills |
|---------|--------|
| entity | abp-framework, abp-entity, domain-modeling |
Grep usage:
Grep("skill-a", INDEX.md, output: content, -C: 0)
→ | skill-a | 2 | key1,key2 | skills/skill-a/SKILL.md |
Old approach (2,434 lines):
Read(AGENT-QUICK-REF.md) → 127 lines
Read(abp-developer.md) → 144 lines
Read(SKILL-INDEX.md) → 337 lines
Read(3 skill files) → 1,283 lines
Protocol approach (~265 lines):
Read(abp-developer.md) → 108 lines (target)
Grep("abp-developer", AGENT-INDEX.md) → 1 line
Grep(skills from agent, SKILL-INDEX.md) → 11 lines
Read(3 skills, limit:40 each) → 120 lines
Savings: 89%
# L0: Just check existence
Grep("^name: xunit-testing", .claude/skills, output: files_with_matches)
→ .claude/skills/xunit-testing-patterns/SKILL.md
# L4: Section extraction (markdown-native)
Grep("^## Quick Reference$", skill.md) → line 30
Grep("^---|^## ", skill.md, offset: 31) → line 55
Read(skill.md, offset: 30, limit: 25)
→ Just the Quick Reference section
description is one line, under 100 charskeywords include grep targets## Summary section present (2-3 sentences)## Quick Reference has lookup tables--- separators between major sectionsDynamic Playwright E2E testing assistant that adapts to any project type (React, Vue, Angular, Svelte, Next.js, Nuxt, or any web framework). Auto-detects build tools, routing, authentication, and provides tailored setup guidance. **CRITICAL: Never uses hardcoded credentials - always prompts user for valid URLs, environment, and real test credentials before generating login tests.** Use when: (1) setting up Playwright in a new project, (2) configuring Playwright for specific frameworks, (3) debugging framework-specific E2E testing issues, (4) optimizing selectors for React/Vue/Angular components, (5) handling authentication flows in tests (OIDC, JWT, sessions) with proper credential validation.
Generate optimized PostgreSQL queries for Entity Framework Core projects. Automatically discovers domain entities, relationships, and conventions to produce production-ready SQL. Use when: 1. You need complex PostgreSQL queries across multiple related entities 2. Working with ABP Framework and need multi-tenancy/soft delete patterns 3. Querying JSONB fields or need recursive CTEs 4. Building analytics/reporting queries with window functions 5. Optimizing existing queries with proper indexes and joins.
Converts requirements written as user stories (.md or .txt) into a structured API Specification document. Defines REST endpoints, request/response shapes, status codes, and permissions for each user story. Output is a .md api-spec file ready to feed into the api-spec-to-technical-plan skill. Use when you have user stories and want a clear API contract before any technical planning or code generation begins.
Generate ABP Framework data seeder contributors following project conventions. Auto-detects project structure, existing entities, namespaces, permission constants, and seeder patterns from the codebase — no manual configuration needed. Creates IDataSeedContributor implementations with proper dependency injection, logging, and tenant/feature awareness. Use when: (1) creating new seed data for entities, (2) adding initial/reference data, (3) scaffolding data initialization code, (4) maintaining data consistency across environments.
Checks requirements.md against the actual codebase to find ALL four types of gaps — requirements missing from code, requirements partially implemented, code logic not mentioned in requirements, and business rules in code that were never written into requirements. Automatically updates requirements.md in both directions — flags unimplemented requirements AND adds newly discovered code logic back into requirements. Use after code generation to keep requirements fully in sync with what was actually built.
Generate ABP ApplicationService, DTOs, interfaces, and API release documentation from Markdown or OpenAPI/Swagger API specifications. Works with ANY ABP project by auto-detecting existing patterns (response wrappers, error handling, validation, authorization). Use when the user provides an API spec and wants to scaffold services that match their project's conventions and generate release notes.