| name | legacy-discovery |
| description | Use at the start of a legacy renovation to build a BA-style current-state analysis — inventory every screen, feature, data flow, and system integration (DB2DB / TCP / API), and record concrete pain points before proposing any change. |
Legacy Discovery
Business-Analyst-style reconnaissance of the current system. Produce a factual
inventory and a ranked pain-point list. Do not propose solutions yet — that is
requirements-grilling and later phases.
When to use
- First substantive phase after
renovate-orchestrator.
- Whenever the current system is not yet documented.
Method
Work bottom-up from evidence (code, DB schema, configs, logs), not from memory.
- Screen & feature inventory — every screen, its purpose, inputs, and the
step-by-step flow. Flag screens reached only via scroll/popup and multi-hop
flows (e.g. author → review → approve → result across separate screens).
- Data inventory — key entities and their sources (recipient data, send
reports, system-status, approval history).
- Integration inventory — every inbound/outbound link and its style:
DB2DB, TCP, API — note where styles are mixed and why.
- Manual-work inventory — steps humans do that the system could: manual send
scheduling, manual message registration for bulk sends, VM-console checks for
process/session state.
- Pain-point inventory — for each pain, record: symptom, who it hurts,
frequency, and current workaround. Rank by operational cost.
Output
Write docs/renovation/01-current-state.md:
# Current State: <system>
## Screens & flows (table: screen | purpose | inputs | flow steps)
## Data (table: entity | source | consumer)
## Integrations (table: link | style DB2DB/TCP/API | direction | notes)
## Manual operations (table: task | trigger | cost)
## Pain points (ranked) (table: pain | who | frequency | workaround)
## Baseline metrics (table: metric | current value | how measured | confidence)
## Open questions (feed these into requirements-grilling)
The Baseline metrics section is required so impact-measurement has comparable
before/after data. Capture measurable values now: screen transitions per task,
manual send-scheduling effort, time-to-detect send failures, operator-inquiry
volume, VM-console checks, statistics-only lag. Record the value and how it was
measured, even if approximate — an approximate baseline is far better than none.
Staged goals (30 / 60 / 100)
- 30: full inventory + ranked pain points complete. This is the minimum bar.
- 60 / 100: same inventory; depth of integration/data tracing increases to
support actual re-implementation.
Transition
Next is architecture-recovery — the technical counterpart that reverse-engineers
how the system is built. Hand it this functional inventory (screens, data,
integrations, pain points) and the Open questions list. requirements-grilling
runs after both, challenging the target design against functional and architectural
reality. Do not start design decisions until grilling closes.
Output template and helper script
- Korean template: OUTPUT_TEMPLATE.md
- Scaffold script:
scripts/create-current-state.sh <repo-root> <target-name>
