Reverse engineer a reference and use what we learn

Starting with a Real Path

In tackling the overnight build system, I began by resolving the real path of our skill directory, which is part of the C:\code\.claude\skills\reverse-engineer\SKILL.md installation. This symlink leads to the .claude documentation repo, the grandparent directory, and ultimately to the code root. It's crucial not to hardcode drive paths or scan the entire workspace, which would be inefficient given our setup.

Leveraging Existing Knowledge

I accessed existing documentation at ../../guides/reverse-engineering/INDEX.md and ../../guides/reverse-engineering/CANDIDATES.md. These resources are invaluable for selecting work and understanding the candidate board. For an unfamiliar acquisition route, the PLAYBOOK.md file was a lifesaver, guiding me through the necessary steps without redundant information.

Choosing the Right Evidence Route

Faced with the task of reverse-engineering, I had several routes to choose from. For our specific need, the best approach was to reuse existing evidence and check for version or coverage updates. This meant I didn't have to start from scratch, allowing me to focus on collecting only missing observations. This method is particularly effective when dealing with a broad "reverse engineer X" scenario.

Practical Application of REA

For claims requiring runtime evidence or decompilation, I utilized the REA (Reverse Engineering Artifact) tools. The historical checkout path, <code-root>/artifacts/rea-research-2026-10-15/rea, was crucial for accessing the necessary data. Using the official morluto/rea sources ensured that I wasn't duplicating efforts with unnecessary cloning or updates.

Keeping the Research Independent

While resolving access dependencies, I continued independent research using available CLI, source, or browser routes. This was essential because MCP tools were absent for this particular task. The playbook recorded the checked 6.5.0 invocation, which guided my actions without needing constant supervision or updates.

Specific Findings

During this process, I discovered that the codebase had been updated to use a newer version of the reverse-engineering tools, which were not yet documented in the reverse-engineer-anything/SKILL.md. This gap highlighted the importance of maintaining up-to-date documentation and ensuring all tools are referenced consistently across our research materials.

In conclusion, reverse engineering isn't just about replicating features—it's about understanding the mechanisms and behaviors that make them work. By following a structured approach, I was able to efficiently extract valuable insights and apply them to our overnight build system without unnecessary duplication of effort.