Sorry, but I don’t know what any of that means. I do know that if I do this again I will have to write better prompts.
Ah yes, sorry, I was replying specifically to @Jamespking’s post here on this thread 
In your case the best you can do is going into a dialogue with the AI, explain what you want to achieve and then it will create the relevant files for you for Claude Code, to start the conversion. The important part is that you give it a good language reference, like the DM4 for Inform 6, I am not sure if something like that is existing for Inform 7.
For prompts, what we do a lot at work, we actually tell the AI the outcome we want to achieve and ask the AI then to create the prompt itself.
I would build on this because I think there’s a step hiding inside it that addresses most of what Jim ran into: before the AI writes a line of code, have it write a plan and review that plan with it.
The analogy I would use is outline versus manuscript. If a collaborator handed you a finished 400-page draft built on a wrong assumption, you would (likely) have to read the whole thing to find the problem. If they handed you a two-page outline first, you would (likely) catch it in five minutes. Most of the issues in the first post here (every property declared on every object, the wilderness of “Instead of doing something” rules, numbered globals) were decisions about approach. They’re arguably cheap to correct in an outline and pretty darn expensive to correct in a huge source file.
In practice, the conversation I encourage my teams to have when using AI for coding looks something like this (repurposed to the context here):
(1) State the outcome, not the steps. “I want a port of this game to Inform 7 that behaves identically and that a human I7 author could read and maintain.”
(2) Give it the reference. On Stefan’s question: for I7, that would be Writing with Inform, the Recipe Book, and your own Inform Handbook as an excellent style guide.
(3) Ask it to interview you first. “Before you plan anything, ask me whatever questions you need answered.” This is where things like “I6 default messages or I7 ones?” come up at the start rather than at the end.
(4) Ask for a written plan in small steps, each with a way to check it. For example, one region at a time, with the transcript compared against the original after each one. A bug like your Travel Agency exit shows up when that region is done, not in a final run-through.
(5) Then go one step at a time, and have it tick off the plan as it goes.
One thing that makes step 4 work: in a port, you already have a perfect answer key: the original game! Whatever Ballerina does is the right answer. So, before any I7 gets written, have the AI build acceptance scripts from the original. These are lists of commands for each region, including the confused and malicious inputs a beta tester would try, with the original responses recorded. A step in the plan is finished when the port gives the same transcript for that script, not when the AI says it is. (I’ve been doing lots of acceptance tests with Rezrov, for example. Different context, but the logic applies.)
With that in mind, the plan I mentioned above should list the differences you specifically want, such as keeping I7’s nicer default messages. Then anything else that differs is a bug by definition.
I’m actually using Opus 5.5.
Also: thanks for the advice on the usage.
Considering my understanding is that the game in question was written in Inform 6 and the original source is lost, I wonder if it would make more sense to decompile to Inform 6 and then port the decompile to Inform 7 instead of trying to decompile/port straight to Inform 7 as a single project. I understand Inform 6 and 7 are essentially completely different languages with only a name, developer, and some core functionality in common, and I can’t help wondering if that introduces extra room for the resulting code to compile to something significantly different from the input story file that could be reduced by targeting decompilation to the original language and attempting the port after the decompile compiles to something close enough to the original story file.
Also, kind of off topic, but thinking about decompiling games written of the Zmachine and other IF VMs got me wondering: does there exist a Zmachine Assembly language?
Thanks, Jeff. That’s a great summary of an effective working method. I might even try doing the project again using your approach. Or decompiling to I6. Or both. I would add only that the sentence quoted above is not quite right. There are at least two bugs in Ballerina, including a run-time error that can crash the VM.
It would be interesting to see if Claude can decompile and reassemble the game in I6, because (IIRC) the original game came very close to the size limit of a .z8 game. Claude might easily produce something that’s almost the same but that would have to be compiled to glulx. Another issue is that the game was written for I6/9, but I6/12 is now current. There may be differences.
Another issue is that I would never ask anyone to beta-test the newly assembled version(s), because it’s an old game. It would be a waste of anybody’s time, unless perhaps they had always meant to play Ballerina and never got around to it. So any remaining bugs or newly introduced bugs would likely remain in perpetuity.
Update: The developing is still far from finished, but using Jeff Nyman’s excellent suggestions, I now have Claude producing very reasonable human-readable code. We’re proceeding step by step. Claude has spotted and fixed several heretofore unreported bugs in the original game. When the process is finished, I’ll be able to maintain the game if more are found.
I’m also adding a few handy I7 Extensions to make the game more user-friendly. Claude is testing to make sure these don’t break anything. Exit Lister by Eric Eve, for instance, makes some assumptions about the game map that are not applicable to the mazes in Ballerina. Those situations have to be handled manually.