Map a codebase
Use this when you have the code of an old or homegrown business application and need to know which of its screens, options, rules, reports, and jobs are still needed, for example before a rebuild, a migration, or a replacement.
The skill reads the code and, when you provide it, the database and logs. It lists what users meet, measures how often each part is used, and writes a software map with the questions only people can answer. It then hands each piece of work it found to process discovery.
It does not find dead code. It assesses code that runs and asks whether the work that code carries is needed. It never changes the code or the data.
Before you start
You need three things:
- the path to the code
- the scope: a module, one process, a list of screens, or the whole system
- the reason: a rebuild, a migration, maintenance cost, a new team inheriting the system, or doubt about some of its functions
These improve the result and are optional. Each missing one is recorded as a blind spot in the map.
| Provide | It lets the skill |
|---|---|
| A read-only copy of the database | Measure which parts are used and when they were last used |
| A schema dump | Read fields, choices, and constraints without database access |
| Logs: web access, application, job runs | Measure which screens are opened and which jobs run |
| Report server and scheduler exports | Include reports and jobs defined outside the repository |
| A running test instance | Read labels and options as users see them |
| Manuals, tickets, or wiki pages | Record what people claim the software is for |
Use a copy or replica of the database, never production. Give the skill a read-only login.
Run it
Load the kit, then start the skill.
In Claude Code:
/process-discovery:map-codebase ./path/to/code "order entry module" "rebuild next year"If the desktop app installed the kit, use /map-codebase with the same arguments.
In Codex or another tool, write a request:
We're rewriting our 15-year-old order system. Map what it does and tell me which features the new one needs. The code is in ./path/to/code.What happens
- Intake. The skill confirms the path, scope, and reason, asks what else you can provide, and agrees with you how queries will run:
- the skill runs them against a named copy, with a read-only login
- you run them and return the results
- there is no database, and the measuring step is skipped
- Survey. It lists screens, fields, choices, statuses, rules, outputs, jobs, and repair paths, each under the label users see.
- Measure. It counts how often each part is used.
- Select. It picks the parts that need a closer look.
- Trace. It follows each selected part forward to what it produces and backward to what triggers it.
- Ask. It writes the questions only people can answer and who could answer them.
- Decide. It hands each piece of work to process discovery, which drafts keep, change, stop as a trial, or investigate.
- Record. The software map is saved.
If you are rebuilding, every part in scope gets a disposition, not only the doubtful ones. Otherwise the rebuild inherits everything nobody questioned.
Supported stacks: SQL, Java, .NET, JavaScript and TypeScript, Python, and PHP. For another stack, the skill drafts a profile and asks you to confirm it.
Where the map goes
The skill asks where to write the software map as plain files.
- Inside the assessed repository, for example in
docs/software-map/. The map becomes the documentation the system never had. - Outside the repository. The repository stays untouched.
Save it to a workspace
Connect your AI tool and ask it to save the software map. The project then shows a Software view with the elements and the items they serve. Questions and evidence about an element are attached to it.
Next
Take the open questions to the people who use the system. Run feedback or a workshop on the ones where accounts differ.