Learn the system before you change it

The goal is to understand what the system does and why without stopping current work. Check the documentation map first, then learn the precise area needed for the nearest task. Do not begin by replacing files with a starter or selecting new hosting.

Complete knowledge of the working system

Compare current pages with the operational-documentation structure. Identify gaps and stale descriptions. Complete areas needed for the change and critical for maintenance immediately; add the remainder to the existing plan with an owner. Investigating the scenario below supplies content for the appropriate Confluence pages. This is part of completing the system documentation.

Walk one scenario from start to finish

Open the feature you need to change. Go through it as a user does: enter data, perform the action, and check the result. Repeat with empty data and a known exception, using data approved for tests. Compare the result with documentation and ask the agent to identify responsible files. If you cannot run the trial, record what blocks it; reading code alone does not confirm behaviour.

1. Name the system version, purpose of the investigation, and available-source scope.
2. Reproduce behaviour: what the user enters, receives, and which exceptions occur. Find evidence in documentation, code, tests, or a safe preview.
3. Ask about domain rules: why they exist, who confirms them, and when they do not apply.
4. Connect the scenario with data, code parts, and the other systems it depends on.

This is reverse engineering: reconstructing behaviour from sources. Reengineering — redesigning a solution — comes only when the goal justifies it.

Give the agent a file to complete

Attach the file to the conversation in the project. The agent starts with read-only inspection. Code shows how something works; on its own, it does not prove why someone designed the system that way.

Let us investigate area [description] needed for task [link]. Allowed sources: [repository and documents]. Read the attached file and complete it from evidence. Show the scenario, rules and exceptions, data, code links, and dependencies. Give source and version. Do not guess historical “why” from code. Separate facts, hypotheses, gaps, and contradictions. Ask for missing information. Identify existing documentation pages that this result must complete. Change nothing in the system or its access; show the result for review.

Check whether knowledge is enough to work

Ask the agent to explain an ordinary case, an exception, and a case with missing data, citing a source for each. For a contradiction, it should show both sources and a question for the domain expert. An explicit “I do not know” is better than an invented rule.

Result: a description of one scenario, its dependencies, and unknowns, checked by someone who knows the system. After agreeing changes, enter confirmed knowledge on the right Confluence pages. Remaining gaps have owners and a continuation in the plan. Now choose: change the way you work with agents, or change the system itself?