Here are the two finalized prompts. These are designed to be "Deterministic," meaning they force the models to act like compilers rather than creative writers.
- The Shared "Contract" (CRITICAL)
You must copy and paste this section into BOTH Model A's and Model B's prompt window. This is the only way they stay in sync.
PROJECT SPECIFICATION & STYLE GUIDE
- Data Schema (Constructor Inputs) The Gladiator class must accept exactly these three arguments in this order:
identity (String): Name of the fighter.
resilience (Integer): Health points.
power (Integer): Attack damage.
- Strict Formatting Rule (PEP 8)
All function and variable names must be snake_case (lowercase words separated by underscores).
Example: correct_function_name
Forbidden: camelCase, PascalCase, runonwords.
- Naming Grammar (The Lookup Table) Construct function names using exactly three parts: [VERB][NOUN][SUFFIX].
Step A (Verb):
If it changes a number -> Use modify
If it returns True/False -> Use validate
If it runs the main action -> Use execute
Step B (Noun):
Refers to Health/Life -> Use vitality
Refers to Life State (Alive/Dead) -> Use survival
Refers to the Fight -> Use combat
Step C (Suffix):
Is it a math calculation? -> Use metric
Is it a status check? -> Use condition
Is it a complex procedure? -> Use protocol
- Prompt for Model A (The Backend)
Paste this to the first model.
System Role: You are the Backend Developer. Task: Write the Python file gladiator_simulation.py.
Instructions:
Read the PROJECT SPECIFICATION (pasted above) carefully.
Implement the Gladiator class.
Implement init: strictly following the Data Schema.
Implement the 3 Required Methods:
Method 1: Reduces resilience by a given amount. (Construct the name using: Change Number + Health + Calculation).
Method 2: Returns True if resilience > 0. (Construct the name using: Return Bool + Life State + Check).
Method 3: Attacks an opponent.
Name: (Run Action + Fight + Procedure).
Logic: Import random. Generate an integer between 1 and self.power. Call the Method 1 of the target instance to apply damage.
Return: Return a formatted string describing the event (e.g., "X hit Y for Z damage").
Constraint: Output only the code. Do not write a main execution block.
- Prompt for Model B (The Frontend)
Paste this to the second model.
System Role: You are the Frontend Integration Developer. Task: Write the Python file main.py.
Instructions:
Read the PROJECT SPECIFICATION (pasted above) carefully.
Import Gladiator from gladiator_simulation.
Instantiation: Create two instances using the Data Schema variables:
"Spartacus" (Resilience: 100, Power: 20).
"Crixus" (Resilience: 100, Power: 20).
The Game Loop:
Write a while loop that runs as long as both gladiators are alive.
To check if they are alive, you must derive the function name from the Grammar Table: (Return Bool + Life State + Check).
Inside the loop, make Spartacus attack Crixus. Derive the function name: (Run Action + Fight + Procedure).
Print the result of the attack (the method returns a string).
Check if Crixus died. If so, break.
Repeat the attack for Crixus attacking Spartacus.
Constraint: You must guess the function names based strictly on the Grammar Table and Formatting Rules. Do not invent new names. Output only the code.
Why this works now
The prompts now act like a "checksum."
If Model A thinks "Health" is health, but the table says vitality, it is forced to use vitality.
If Model B thinks "Alive" is is_alive, but the table says validate..., it is forced to use validate.
The snake_case rule prevents the CamelCase crash.