Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Workflow for reverse-engineering a codebase into grounded architecture docs, requirements capture, etc.
tags
["workflow"]
baseSchema
docs/schemas/workflow.md
<code_analysis_flow>
<description_and_purpose>
Problem: Code analysis degrades into transcription, drifts into suggestions/refactors, or stalls when codebase exceeds single-agent context; assumptions and unknowns are silently adopted.
Solution: Thin, sequential workflow that classifies SMALL vs LARGE codebase, delegates analysis to the reverse-engineering skill, must partition LARGE codebases via large-workspace-handling, gates critical/high unknowns through questioning, and optionally extracts requirements via requirements-authoring. Grounded by links, HITL at unknowns and final review.
Validation: Output files exist under docs/<feature>/; every claim traces to code/docs; no generated or suggested implementation; open questions and assumptions are documented; state file reflects phase evidence.
</description_and_purpose>
<workflow_phases>
All Rosetta prep steps MUST be FULLY completed
USE SKILL load-project-context, orchestration, hitl
MUST ALWAYS use todo tasks ledger, ASAP. Phases are sequential. Independent tasks can run in parallel. Module analysis in LARGE codebases runs in parallel via SKILL .
large-workspace-handling
No rush, take your time, MUST FOLLOW WORKFLOW ENTIRELY, no skipping
Orchestrator trusts skills to own execution internals; coordinates sequence, artifacts, state, and approvals only.
State file: agents/TEMP/<FEATURE>/code-analysis-flow-state.md updated after each phase.
Documentation principle: ground with links; no code generation, no suggestions, no speculation. See best_practices for sizing and diagram rules.
If /goal is set repeat phases 4-8 until goal is met.
If task is to extract/document/reverse engineer requirements or specifications from existing app/code:
This is much more intense per subagent: reclassify SMALL if < 10 source files, otherwise LARGE and MUST USE large-workspace-handling.
Both orchestrator and subagents MUST USE SKILL requirements-authoring
Spawn MULTIPLE subagents with each handling one unit of analysis (one module, one community, one screen, one controller, one endpoint, etc) to effectively prevent hallucinations by narrowing scope down for phases requirements_branch and review (more agents - less scope each).
Read all lines of docs/CONTEXT.md, docs/ARCHITECTURE.md, agents/IMPLEMENTATION.md; grep headers of docs/CODEMAP.md, docs/TECHSTACK.md, docs/DEPENDENCIES.md if present.
Precondition: user explicitly requested requirements reverse-engineering (e.g., "extract requirements", "generate SRS", "generate specifications", "from existing code", "produce EARS/NFRs from code"). If absent, skip this phase entirely.
Use reverse-engineering skill to distill intent, then requirements-authoring skill to produce atomic, testable functional and non-functional requirements with SMART, MECE, acceptance criteria, EARS phrasing, priority (MoSCoW), and predecessors.
Input: scope + context. Output: docs/REQUIREMENTS/ per requirements-authoring layout, with HITL per-unit approval owned by that skill.
Partition workspace USING SKILL large-workspace-handling (Summarization & Indexing strategy): every file belongs to exactly one scope; subagents analyze per-module in parallel.
Ensure it is possible to rewrite using requirements only completely from scratch without old code present.
</requirements_branch>
<analyze_small phase="5" applies="SMALL" subagent="architect" role="Senior systems analyst producing a single grounded analysis document" subagent_required_model="claude-opus-4-8, gpt-5.5-high, gemini-3.1-pro-high, gpt-5.6-sol">
Produce one grounded analysis document covering: components, data models, patterns, logic flow as conceptual algorithm (no line-by-line), boundary and edge cases, unhandled edges, sequence and dependency diagrams in Mermaid, external dependencies with purpose.
Reference specific files and line ranges; keep code snippets ≤3 lines.
Partition workspace USING SKILL large-workspace-handling (Summarization & Indexing strategy): every file belongs to exactly one scope; subagents analyze per-module in parallel.
Per module produce: business logic overview, architecture overview, component analysis (with subcomponents, interface definitions, and major features), identified design patterns and anti-patterns, data architecture with exact contracts (fields, types, purpose), integration patterns, quality observations, engineering insights. Aim 100–200 lines; diagrams in Mermaid with explicit light/dark colors.
Input: module-list + scope + context. Output: docs/<feature>/module-<module>.md per module.
Read ALL per-module documents in full (no limit/offset), decompose into canonical sections, combine corresponding sections across modules, and produce a unified view.
Produce docs/<feature>/summary.md with: Business context (processes/scenarios with involved components and Mermaid diagrams), Domain description (data models with business purpose and cross-repo physical references), Detailed analysis (per repository/component: tech stack, features, dependencies), Architecture insights (patterns and conventions), Dependency map (Mermaid at component and subcomponent level).
Flag components where information is missing.
Input: all module-<module>.md documents. Output: docs/<feature>/summary.md.
Required skills: reverse-engineering
Update code-analysis-flow-state.md.
Inspect outputs for groundedness (every claim linked), accuracy, coverage of scope, absence of generated/suggested code, assumption/unknown documentation, and Mermaid diagram legibility in light and dark themes.
If reverse engineering: MUST validate there are NO hallucinations or made-up requirements - this is a contract!
<user_review phase="9" applies="ALL" type="HITL">
Present final artifacts and review findings. User MUST approve: "Yes, I reviewed the analysis" or "Approve, the analysis was reviewed".
Strict approval; anything else = feedback, iterate on the phase that owns the affected artifact (analyze_small, analyze_large_parallel, summarize, or requirements_branch).
</user_review>
Update IMPLEMENTATION.md with a brief pointer to produced analysis artifacts.
Mark code-analysis-flow-state.md complete with phase evidence and artifact paths.
</workflow_phases>
<best_practices>
Ground every claim with file and line references; fall back to anecdotal references only with explicit call-out.
Prioritize accuracy over speed; use grep, search, and navigation tools to protect context.
Distinguish domain intent from implementation accident per reverse-engineering pitfalls.
Preserve domain terminology; collapse duplicate terms into one before writing.
Diagrams define explicit colors for nodes, text, and edges to remain readable in both light and dark themes.
</best_practices>
<validation_checklist>
Size classification recorded and matches produced layout (SMALL → single analysis.md; LARGE → module-*.md + summary.md).
Every analysis claim has file and line reference; no generated code, no refactor suggestions.
Critical/high assumptions and unknowns are documented (resolved and unresolved).
Mermaid diagrams render in both themes (explicit colors set).
