| name | x-ipe-tool-knowledge-extraction-application-reverse-engineering |
| version | 2.0 |
| description | Orchestrator for application reverse engineering knowledge extraction. Dynamically discovers section-specific sub-skills, coordinates 3-phase execution (Scan โ Tests โ Deep), generates the master index, aggregates quality scores, and validates cross-references. Retains cross-cutting mixin templates (repo-type ร language-type).
|
Knowledge Extraction โ Application Reverse Engineering (Orchestrator)
Purpose
AI Agents follow this skill to orchestrate application reverse engineering extraction:
- Discover section-specific sub-skills dynamically (glob pattern)
- Dispatch extraction work to sub-skills in 3 phases with dependency passing
- Collect results and generate master index.md (LL-001)
- Aggregate quality scores across all sections
- Validate cross-section consistency
- Provide cross-cutting mixin templates (repo-type ร language-type)
Important Notes
BLOCKING: This is an orchestrator skill โ it dispatches to sub-skills, not a monolithic template provider.
CRITICAL: Sub-skills are discovered dynamically via glob. Do NOT hardcode sub-skill names or paths.
CRITICAL: Phase dependencies are strict: Phase 2 receives Phase 1 output; Phase 3 receives Phase 1+2 output.
CRITICAL: Mixin composition order: repo-type first (primary), language-type merged on top (additive, may be multiple).
About
This skill orchestrates the full application reverse engineering extraction by discovering
and dispatching to 8 section-specific sub-skills. The extractor (x-ipe-task-based-application-knowledge-extractor)
invokes this orchestrator, which coordinates the 3-phase execution.
Key Concepts:
- Sub-Skill Discovery โ Glob
.github/skills/x-ipe-tool-rev-eng-*/SKILL.md, parse frontmatter
- 3-Phase Execution โ Phase 1 (Scan: 5, 7) โ Phase 2 (Tests: 8) โ Phase 3 (Deep: 1, 2, 3, 4, 6)
- Context Passing โ Phase 1 feeds Phase 2; Phase 1+2 feed Phase 3
- Master Index โ TOC with quality scores, reading order (LL-001)
- Quality Aggregation โ Weighted scores rolled up into overall score
- Cross-Reference Validation โ Cross-section consistency checks
- Mixin Templates โ Cross-cutting repo-type and language-type overlays
Phases: P1 (โฅ 5,7) โ P2 (8, needs P1) โ P3 (โฅ 1,2,3,4,6, needs P1+P2)
When to Use
triggers:
- "application reverse engineering extraction"
- "category: application-reverse-engineering"
- "reverse engineer source code"
- "extract architecture from codebase"
- "orchestrate reverse engineering"
not_for:
- "Single section extraction" โ invoke sub-skill directly
- "User manual extraction" โ use x-ipe-tool-knowledge-extraction-user-manual
- "Direct README update" โ use x-ipe-tool-readme-updator
Input Parameters
input:
operation: "discover_sub_skills | dispatch_section | orchestrate_phases | get_mixin | generate_index | aggregate_quality | validate_cross_references"
category: "application-reverse-engineering"
section_id: "integer | null"
repo_path: "string"
output_path: "string"
mixin_key: "string | null"
section_context:
phase1_output: "map | null"
phase2_output: "map | null"
config:
max_files_per_section: 30
complexity_gate: { min_files: 10, min_loc: 500, min_dirs: 3 }
Definition of Ready
<definition_of_ready>
<checkpoint required="true">
<name>Valid operation requested</name>
<verification>operation matches one of the 7 defined operations</verification>
</checkpoint>
<checkpoint required="true">
<name>Sub-skills discoverable</name>
<verification>Glob .github/skills/x-ipe-tool-rev-eng-*/SKILL.md returns โฅ1 result</verification>
</checkpoint>
<checkpoint required="true">
<name>Mixin templates exist</name>
<verification>All mixin files in templates/ are present and readable</verification>
</checkpoint>
<checkpoint required="false">
<name>Repo path valid (for extraction operations)</name>
<verification>IF orchestrate_phases or dispatch_section THEN repo_path is a directory</verification>
Operations
Operation: discover_sub_skills
When: First step โ discover available sub-skills before dispatching.
<operation name="discover_sub_skills">
<action>
1. Glob: .github/skills/x-ipe-tool-rev-eng-*/SKILL.md
2. For each matched file:
a. Parse YAML frontmatter (name, description, section_id, phase)
b. Verify the skill has an `extract` operation defined
c. Record: { name, section_id, phase, path, description }
3. Sort by phase (1-Scan, 2-Tests, 3-Deep), then by section_id
4. Validate all 3 phases have at least one sub-skill
5. Return the discovered sub-skill registry
</action>
<constraints>
- BLOCKING: Do NOT hardcode sub-skill names โ always discover via glob
- CRITICAL: Missing sub-skills are warnings, not errors (partial extraction is valid)
</constraints>
<output>
sub_skills: [{ name, section_id, phase, path, description, has_extract: bool }]
</output>
</operation>
Operation: dispatch_section
When: Orchestrator needs to invoke a specific sub-skill for one section.
<operation name="dispatch_section">
<action>
1. Look up section_id in the discovered sub-skill registry
2. IF no sub-skill found for section_id โ return SECTION_NOT_FOUND error
3. Build invocation context:
a. repo_path: path to target repository
b. output_path: {output_path}/section-{nn}-{slug}/
c. phase1_output: paths from Phase 1 results (if available)
d. phase2_output: paths from Phase 2 results (if available)
e. config: complexity_gate, max_files_per_section
4. Invoke the sub-skill's `extract` operation with the built context
5. Collect sub-skill output: { section_path, quality_score, metadata }
6. Return the dispatch result
</action>
<constraints>
- BLOCKING: section_id is required
- CRITICAL: Phase context MUST be passed โ Phase 2 sub-skill needs phase1_output,
Phase 3 sub-skills need phase1_output + phase2_output
- CRITICAL: Create output subfolder before invoking sub-skill
</constraints>
<output>
dispatch_result: { section_id, sub_skill_name, section_path, quality_score, success: bool, errors: [] }
</output>
</operation>
Operation: orchestrate_phases
When: Full extraction requested โ execute all 3 phases in order.
<operation name="orchestrate_phases">
<action>
1. Run discover_sub_skills to build the registry
2. Create output directory: {output_path}/
3. **Phase 1 โ Scan (parallel):**
a. Dispatch sections 5 and 7 in parallel
b. Collect results: phase1_output = { "5": result_5, "7": result_7 }
c. IF any Phase 1 section fails โ log warning, continue with available results
4. **Phase 2 โ Tests (depends on Phase 1):**
a. Dispatch section 8 with phase1_output
b. Collect result: phase2_output = { "8": result_8 }
c. IF Phase 2 fails โ log warning, continue (Phase 3 runs without test context)
5. **Phase 3 โ Deep Analysis (parallel, depends on Phase 1+2):**
a. Dispatch sections 1, 2, 3, 4, 6 in parallel with phase1_output + phase2_output
c. Collect results: phase3_results = { "1": result_1, ... "6": result_6 }
6. Run generate_index with all section results
7. Run aggregate_quality across all sections
8. Run validate_cross_references across all sections
9. Generate extraction_report.md with timing, phase results, quality summary
10. Return orchestration result
</action>
<constraints>
- BLOCKING: repo_path and output_path are required
- CRITICAL: Phase ordering is STRICT โ Phase 2 MUST wait for Phase 1; Phase 3 MUST wait for Phase 1+2
- CRITICAL: Within a phase, sections run in parallel (no inter-section dependencies)
- Partial success is valid: failed sections are logged but don't block others
</constraints>
<output>
orchestration_result: {
phases: { phase1: { sections, status }, phase2: { sections, status }, phase3: { sections, status } },
overall_quality: float,
index_path: string,
report_path: string,
cross_ref_path: string,
errors: []
}
</output>
</operation>
Operation: get_mixin
When: Extractor needs codebase-specific overlays (repo-type or language-type).
<operation name="get_mixin">
<action>
1. Resolve mixin file from mixin_key:
Repo-type: monorepo โ templates/mixin-monorepo.md
multi-module โ templates/mixin-multi-module.md
single-module โ templates/mixin-single-module.md
microservices โ templates/mixin-microservices.md
Language-type: python โ templates/mixin-python.md
java โ templates/mixin-java.md
javascript โ templates/mixin-javascript.md
typescript โ templates/mixin-typescript.md
go โ templates/mixin-go.md
2. Read and return the mixin template content
3. Mixin contains detection signals, additional prompts, and section overlays
</action>
<constraints>
- BLOCKING: mixin_key is required and must be one of the 9 valid keys
- CRITICAL: Composition order โ repo-type first (primary), language-type additive
</constraints>
<output>Mixin markdown content with detection signals and overlay prompts</output>
</operation>
Operation: generate_index
When: After all phases complete โ create the master index.md (LL-001).
<operation name="generate_index">
<action>
1. Scan output_path for section-{nn}-{slug}/ subdirectories
2. For each section subfolder:
a. Read its index.md for description
b. Count total lines across all .md files
c. Retrieve quality score from sub-skill results
3. Build master index.md at {output_path}/index.md with:
- App name and overview
- Section table: number, name (linked), quality score, line count, description
- Reading order: 5 โ 7 โ 1 โ 6 โ 2 โ 3 โ 4 โ 8
- Extraction metadata: overall quality, phases completed, source path
4. Return path to generated index
</action>
<constraints>
- BLOCKING: output_path must contain at least one section subfolder
- CRITICAL: Quality scores must come from actual sub-skill results
</constraints>
<output>index_path: string</output>
</operation>
Operation: aggregate_quality
When: After all phases complete โ compute overall quality score.
<operation name="aggregate_quality">
<action>
1. Collect quality_score from each sub-skill's dispatch result
2. Apply section-group weighting:
- Architecture sections (1, 2, 6): weight 0.15 each = 0.45 total
- Tests section (8): weight 0.15
- Other sections (3, 4, 5, 7): weight 0.10 each = 0.40 total
3. Compute weighted_overall = ฮฃ(section_score ร section_weight)
4. Classify:
- โฅ 0.85 โ HIGH
- โฅ 0.65 โ ACCEPTABLE
- < 0.65 โ LOW
5. Identify weakest sections (below 0.70) with improvement hints
6. Return aggregated result
</action>
<constraints>
- CRITICAL: Missing sections get score 0.0 (they drag the average down)
- CRITICAL: Use sub-skill-reported scores โ do NOT re-evaluate content
</constraints>
<output>
aggregate_result: {
overall_score: float,
classification: "HIGH | ACCEPTABLE | LOW",
section_scores: { section_id: { score, weight, weighted } },
weakest_sections: [{ section_id, score, hints: [] }]
}
</output>
</operation>
Operation: validate_cross_references
When: After all phases complete โ check cross-section consistency.
<operation name="validate_cross_references">
<action>
1. Read all section index.md files from output_path
2. Build reference maps:
a. modules_declared: from section 5 (Code Structure) โ list of modules/directories
b. tech_declared: from section 7 (Tech Stack) โ technologies and versions
c. tests_declared: from section 8 (Tests) โ test files and coverage data
d. arch_claims: from section 1 (Architecture) โ module references, layers
e. pattern_claims: from section 2 (Design Patterns) โ file:line citations
f. api_claims: from section 3 (API Contracts) โ endpoint/module references
g. dep_claims: from section 4 (Dependencies) โ import/call graphs
h. flow_claims: from section 6 (Data Flow) โ module path references
3. Cross-validate:
a. Architecture claims reference modules found in code structure (1 โ 5)
b. Design patterns cite files that exist in code structure (2 โ 5)
c. API contracts reference modules from code structure (3 โ 5)
d. Dependencies match imports found in code structure (4 โ 5)
e. Data flows reference modules from code structure (6 โ 5)
f. Deep sections cite test evidence where available (1,2,3,4,6 โ 8)
g. Tech stack versions match dependency declarations (7 โ 4)
4. Generate cross-reference-validation.md at {output_path}/
5. Return validation summary
</action>
<constraints>
- Missing sections are skipped (validation runs on available sections)
- CRITICAL: Flag inconsistencies but do NOT auto-correct content
</constraints>
<output>
cross_ref_result: {
total_references: int,
valid_references: int,
invalid_references: int,
consistency_score: float,
issues: [{ source_section, target_section, claim, issue, severity }]
}
</output>
</operation>
Output Result
operation_output:
success: true | false
operation: "{one of the 7 operations}"
result:
sub_skills:
dispatch_result:
orchestration_result:
mixin_content:
index_path:
aggregate_result:
cross_ref_result:
errors: []
Output Structure
.intake/{extraction_id}/
โโโ index.md # Master TOC (LL-001) โ generated by orchestrator
โโโ section-01-architecture-recovery/ # From x-ipe-tool-rev-eng-architecture-recovery
โ โโโ index.md
โ โโโ ...
โโโ section-02-design-patterns/ # From x-ipe-tool-rev-eng-design-pattern-detection
โ โโโ ...
โโโ section-03-api-contracts/ # From x-ipe-tool-rev-eng-api-contract-extraction
โ โโโ ...
โโโ section-04-dependency-analysis/ # From x-ipe-tool-rev-eng-dependency-analysis
โ โโโ ...
โโโ section-05-code-structure-analysis/ # From x-ipe-tool-rev-eng-code-structure-analysis
โ โโโ ...
โโโ section-06-data-flow/ # From x-ipe-tool-rev-eng-data-flow-analysis
โ โโโ ...
โโโ section-07-technology-stack/ # From x-ipe-tool-rev-eng-technology-stack
โ โโโ ...
โโโ section-08-source-code-tests/ # From x-ipe-tool-rev-eng-test-analysis
โ โโโ tests/ # Executable test files
โ โโโ ...
โโโ extraction_report.md # Generated by orchestrator
โโโ cross-reference-validation.md # Generated by orchestrator
Definition of Done
<definition_of_done>
<checkpoint required="true">
<name>Operation completed</name>
<verification>operation_output.success is true</verification>
</checkpoint>
<checkpoint required="true">
<name>Sub-skills discovered dynamically</name>
<verification>No hardcoded sub-skill list โ glob pattern used</verification>
</checkpoint>
<checkpoint required="true">
<name>Phase dependencies enforced</name>
<verification>Phase 2 received Phase 1 output; Phase 3 received Phase 1+2 output</verification>
</checkpoint>
<checkpoint required="true">
<name>Master index generated (LL-001)</name>
<verification>index.md exists at output_path with TOC, quality scores, reading order</verification>
Quality aggregated across sections
Overall score computed with section-group weighting
Cross-references validated
cross-reference-validation.md exists with consistency results
Error Handling
| Error | Cause | Resolution |
|---|
INVALID_OPERATION | operation not one of the 7 defined | Check operation name matches exactly |
NO_SUB_SKILLS_FOUND | Glob returned zero results | Verify sub-skill folders exist under .github/skills/x-ipe-tool-rev-eng-*/ |
SECTION_NOT_FOUND | section_id doesn't match any discovered sub-skill | Run discover_sub_skills first; check section_id is 1โ8 |
MISSING_REPO_PATH | repo_path null for orchestrate/dispatch | Provide path to target repository |
MISSING_OUTPUT_PATH | output_path null for orchestrate/generate/validate | Provide .intake/{extraction_id}/ path |
INVALID_MIXIN_KEY | mixin_key not one of the 9 valid keys | Use one of: monorepo, multi-module, single-module, microservices, python, java, javascript, typescript, go |
PHASE_DEPENDENCY_VIOLATED | Phase 2/3 invoked without prior phase results | Run phases in order or supply section_context |
SUB_SKILL_EXTRACT_FAILED | Sub-skill returned error | Check sub-skill logs; partial extraction continues |
BELOW_COMPLEXITY_GATE | Codebase below min thresholds | Skip reverse engineering; document rationale |
Templates
| File | Purpose |
|---|
templates/playbook-template.md | Phase order reference (Scan โ Tests โ Deep) |
templates/mixin-monorepo.md | Repo-type: monorepo structural overlay |
templates/mixin-multi-module.md | Repo-type: multi-module structural overlay |
templates/mixin-single-module.md | Repo-type: single-module structural overlay |
templates/mixin-microservices.md | Repo-type: microservices structural overlay |
templates/mixin-python.md | Language-type: Python analysis overlay |
templates/mixin-java.md | Language-type: Java analysis overlay |
templates/mixin-javascript.md | Language-type: JavaScript analysis overlay |
templates/mixin-typescript.md | Language-type: TypeScript analysis overlay |
templates/mixin-go.md | Language-type: Go analysis overlay |
Examples
See references/examples.md for orchestration flow examples.