Great work. I personally use the following prompts. They might be useful. Windows-1254 is Turkish codepage. You should change as your country code.
Clarion TXA files use ANSI / Windows-1254 encoding. The encoding must never be changed. It must not be converted to UTF-8 or any other encoding. During file reading, writing, comparison, and saving operations, the existing encoding must always be preserved.
The main/original TXA file must never be modified directly. The existing TXA file should remain in place and must not be overwritten or replaced. The working model should protect the original TXA and generate new TXA files only for the corrected procedures. Therefore, as long as the main/original TXA file remains unchanged, an additional mandatory backup is not required.
Code safety must always be considered. When making risky changes, potential side effects that could disrupt the current behavior must be evaluated. If the data flow, procedure calls, embed order, file relationships, form behavior, or existing business rules may be affected, the safest minimal approach should be preferred.
Unless explicitly requested, the existing code structure must not be modified. Procedure names, variable names, embed points, architectural structure, and the overall flow must be preserved. Refactoring must not be performed. Only the smallest possible intervention that solves the requested problem should be applied.
Clarion embed blocks, existing comments, and developer notes must be preserved. No embed block should be deleted, moved, or reorganized in a way that changes its meaning. Unless absolutely necessary, the line order, spacing, and current layout must remain unchanged.
In corrected code, old lines must not be deleted directly. Modified or removed lines should, when possible, be remarked with !!!! and kept as close as possible to their original location. This allows the previous state to remain traceable within the file and enables easy rollback if needed. Remarked lines must be passive and must not affect compilation. If keeping the old line in place could create syntax or flow risks, the safest alternative method should be chosen and explained in the change summary.
All changes must be applied with the smallest possible scope. Apart from the requested fix, unnecessary formatting, line rearrangement, alignment, or bulk cleanup must not be performed. Only the relevant problem area should be touched.
Unless otherwise specified, user interface texts should be localized. Spelling mistakes, grammatical errors, and awkward sentence structures should be corrected. Existing texts may be improved to become more natural, clear, and user-friendly. However, identifiers, technical constants, procedure references, field names, and data structure names inside the code must not be changed.
For procedures that are edited, internal procedure comments must be reviewed. If explanatory comments describing what the procedure does are missing or insufficient, short and clear explanations may be added in appropriate places. These comments may describe not only the change but also the core logic of the procedure, important control flows, critical conditions, business rules, and, when necessary, the purpose of the data flow. If the existing comments are already sufficient, unnecessary repetition must be avoided. Comments must not clutter the code or reduce readability.
For edited procedures, the COMMON/DESCRIPTION section must also be checked. If the procedure has no description or if the description is incorrect, insufficient, or overly generic (for example, just “Window”), a short and clear description explaining the real function of the procedure should be added or the existing description should be corrected. The existing format and TXA syntax must be preserved; only the description text should be updated.
A comment line including date and time must be added near every code change. If multiple small changes exist within the same block, a single comment line is sufficient. Comments must be short, standardized, and non-repetitive.
Since multiple developers may work on the project, the comment line must also include the computer name where the fix was made. The computer name should preferably be the actual machine name / computer name provided by the operating system. This ensures that interventions made from different machines can be tracked.
Logic explanations, procedure explanations, and workflow explanations added by Codex must be marked as “Codex”.
Comment lines that directly document a code modification — such as added, corrected, remarked, or disabled code — must be marked as “Codex+”. These two types of comments must not be mixed.
The comment format should preferably follow this structure:
! [YYYY-MM-DD HH:MM] Codex [ComputerName]: <procedure logic or short explanatory note>
! [YYYY-MM-DD HH:MM] Codex+ [ComputerName]: <short change description>
In SOURCE procedures, Clarion runtime may not automatically expose the procedure name or it may not appear directly in debug logs. In such cases, the procedure name must be explicitly added at the beginning of debug/log messages so the origin of the message is immediately clear.
The format should follow the existing project standards, and the procedure name should appear at the beginning of the message whenever possible. Example:
<ProcedureName>: message text
or
[<ProcedureName>] message text
For every modified procedure, the MODIFIED field in the TXA procedure header must be updated. The format, order, and syntax of the MODIFIED field must remain unchanged. Only the value should be replaced with the current date and time. If the procedure also contains an existing comment, header line, or metadata field showing the last modification date, it should also be updated consistently without breaking the existing structure. Unnecessary new headers or metadata structures must not be introduced.
Each corrected procedure must be exported as a separate TXA file. Every TXA file must contain only the relevant procedure. The main/original TXA file must remain untouched and preserved in place.
Procedure-based TXA outputs must be written into the @TXA folder under the relevant project directory. If the @TXA folder does not exist, it must be created. File names must clearly include the procedure name and be organized to avoid confusion.
When reporting the performed changes, each change must include both the procedure name and the line number. Line references should correspond as closely as possible to the actual line numbers in the TXA file. If multiple changes exist, each must be listed separately. The preferred format is:
Procedure: <ProcedureName> | Line: <LineNumber or LineRange> | Change: <Short description>
After every change, the solution must remain compatible with the current Clarion version and must compile successfully. In uncertain situations, the safest minimal solution should be preferred instead of making broad assumptions. Syntax, types, scope, and call-chain effects must be carefully verified.
Unrelated parts of the file must not be touched. When fixing a problem, changes to shared structures that may cause side effects in other procedures must be avoided. Unless absolutely necessary, global definitions, MAP structures, INCLUDE order, file definitions, and queue structures must not be modified.
Existing business logic should be preserved unless it is clearly incorrect. In uncertain situations, aggressive improvements must be avoided, and the safest approach that does not alter current behavior should be chosen.
At the end of every task, a short change summary must be provided. The summary must include at least the following information:
- names of the modified procedures
- related line numbers or line ranges
- the reason for the change
- old lines remarked with
!!!!
- updated COMMON/DESCRIPTION fields
- names of the generated procedure-based TXA files
- the
@TXA folder path where they were written
- the computer name used
- any potential risks and screens, reports, or workflows that should be tested.