This is cute:
I prompted claude code with:
create an article for the b4x forums covering the major uses i have made of claude in this and recent other related conversations - include major prompt types
... and got the following response:
-----------------------------------------------------------------------------------------
How I have been using Claude Code with B4X
Over recent months I have used Claude Code (Anthropic's AI coding assistant, running in its Windows desktop app) on a fairly large B4X code base. This post covers what I have actually used it for, the kinds of prompt that work, and the ground rules that keep it useful.
The code base: a B4A customer app and its B4i twin, a B4J/ABMaterial web server that offers the same customer journey in a browser, several B4J back-office managers (AWS EC2 hosted), an FTP server, a B4A uploader app, and a large folder of shared modules used across all of them.
The ground rules
- Claude reads, I write. B4X source files (.b4a, .b4i, .b4j, .bas) are plain text, so Claude can read whole projects directly. It never edits them: it gives me paste-ready edits in the chat and I apply them in the IDE. That way I read every change, and nothing fights with an open IDE (the B4i IDE will happily overwrite a file that was changed underneath it).
- IDE line numbers only. The line numbers in the file are not the ones the IDE shows, because the IDE starts counting after the @EndOfDesignText@ line. Once Claude knew this, every edit is addressed by the number I actually see.
- Tag every changed line, comment out rather than delete. Each line Claude proposes carries a trailing 'claude was here, so changes are searchable. Replaced code is commented out, not deleted, so it stays as the anchor when I port the same fix into the B4i copy.
- House rules live in Claude's memory. Comment style, Try/Catch layout, "whitespace is never a finding", "anything that already passed App Store review is not a finding", which test accounts are deliberate. Each rule is a small note it reloads every session, so I only say it once.
What I use it for
1. Whole-module audits
The workhorse. I ask Claude to read a module end to end and audit it three ways: bugs, inline documentation, and consistency with the rest of the project. Findings go into a running Bug audit.md file, one pass per module, so nothing gets lost between sessions. When a pass produces a lot, I ask it to group similar findings and rank the groups.
Real examples it found: the global DateTime format being shared mutable state and locale-sensitive (which led to a pair of Machine_datetime_format / Machine_datetime_parse helpers used everywhere), a list that accumulated duplicates across a slideshow, a malformed back-end record that could crash a whole processing step, and dozens of comments that no longer matched the code.
2. The fix / verify loop
I ask for the exact edit, paste it, then say "done, verify". Claude re-reads the file and checks what actually landed. This catches my mistakes as well as its own. Recently a three-line insert went in as a replacement and deleted a JavaScript const; the ABMaterial page went blank, and the verify step found the cause in seconds.
3. Porting between B4A and B4i
"Port AWS_S3_B4i using AWS_S3_B4A as the model" works well. Claude also keeps track of translator quirks, for example that B4i will not compile a method call on a parenthesised expression, so it uses a local variable instead.
4. App Store submission prep
Before submitting the B4i app I had Claude audit the project and every module against Apple's review guidelines. It then audited the obfuscated build itself: it used the obfuscator's translation table and decrypted the obfuscated string files to rebuild readable source, then compared that line by line with the original. That is how it confirmed the obfuscated build behaves the same, and it also found a missing ITSAppUsesNonExemptEncryption key.
Did the same for the B4A app.
5. Obfuscation gotchas
Two that bit me, now in Claude's memory: the obfuscator's comment stripper treats an apostrophe as the start of a comment even inside #If JAVA / #If OBJC blocks, so an apostrophe in inline Java or Objective-C silently cuts the line; and subs raised by name from inline Java must be on the underscore exclusion list, or the obfuscated build drops them.
Note: I have developed a much more complete obfuscation process than that which comes with the B4X tools.
6. Designing features
I describe the behaviour I want and Claude reads the modules involved before proposing a design and the edits. Recent examples:
- A Paywall control-file parameter for the web server (None, PayPal, Dummy, PayPal&Dummy) that changes what the ABMaterial paywall and subscription pages show, including skipping payment entirely and showing "(no charge)" prices.
- Clicking an account in one B4J manager opens the same account in another, using a flag file plus a relaunch.
- Letting an administrator start a conversation with a customer who has never sent a message, by uploading a dummy message file that the normal import picks up.
7. Explaining code and protocols
"Where does this variable come from?", "Is the statement at IDE 1719 superfluous?", "What is FTP PASV used for?", "What happens if an upload connection drops halfway?" It answers from the actual code, not from general knowledge, which is the point.
8. Debugging from symptoms
"When I get to this page in PayPal&Dummy mode I get a blank screen" (plus the obfuscated module it ran). "When the app goes to the background the edge strips take several seconds to appear." "In landscape on a tablet the toast is wider than the camera panel." Describing what I see and pointing at the files is usually enough.
9. Everything else
A user guide and a laminated A4 quick-reference card for the uploader app (as Word documents), a redrawn share icon, making the B4A IDE line numbers bigger (a FontSize attribute in the theme's .vssettings file does it), and checking whether an email was genuine.
Prompt types that work
Read "read verbatim Show_list - and I mean actually do it" - Long files tempt it to skim. Saying so explicitly gets a full read.
Audit "... for in depth bug, inline doc and consistency audit" - Three passes in one request, findings with IDE numbers.
Group and rank "group all similar findings then give a detailed report on each group, most important one first" - Turns a long list into something you can work through.
Exact edit "give me detailed edits, bottom one first" - Descending IDE order means pasting one edit never shifts the line numbers of the next (higher) one.
Verify "done, verify" - Claude re-reads and checks what you actually pasted.
Log "append the Show_list pass to Bug audit.md" - Keeps a permanent record outside the chat.
Design "when Gen_paywall_mode is none the user is not prompted for a payment option and ..." - Describe behaviour, not code. Let it find where the change goes.
Port "port AWS_S3_B4i using AWS_S3_B4A" - Give it the working version as the model.
Question "is Gen_translator_hit necessary" - Short questions get answers grounded in the real code.
Decline "declined" - Tell it which findings you reject, so it stops raising them.
Rule "stop showing file lines, use IDE lines only" - A correction like this becomes a permanent memory note.
Lessons
- It is fast and usually right, but not always. Review every edit. It once suggested an IDE colour that was already the default, and it can act too quickly on an ambiguous request. I told it so, and now it asks when a request could mean two things.
- Make it read, not skim. Ask for a verbatim read of the whole module before an audit.
- Paste edits bottom-up. Ask for edits in descending IDE order.
- Keep it out of the files. Edits in the chat, applied by me, then verified.
- Remember the caches. After changing an ABMaterial page script, cached translations have to be cleared. Claude now reminds me.
- It does not replace testing on a device. I keep a list of fixes still waiting for a phone test.
- Keep secrets out of the chat. No passwords, keys or customer data in prompts.
-----------------------------------------------------------------------------------------
All pretty accurate...
