I think I found a better way. It took some trial and error, though, and I didn’t actually create the thing I set out to create, but i think i know how. I’ve included most of the conversation with Claude, mostly because it’s fun to watch him come around to the idea. I am really impressed with AI, but even more so with claude in particular. I was able to complete a $500 diagnosis and repair on an air conditioning unit at one of my properties quickly and efficiently ( for about $50) with Claude’s help- Could I have done it without claude? Definitely- I’d done this before on other units. But Claude’s ability to look at a schematic and use that knowledge when looking at a photograph of the unit’s interior was truly mind-blowing. I think this may be the unpredicted killer app for AI, bringing more tasks into the realm of the skilled generalist and away from experienced specialists. (OH yay lol) Anyway, here’s a short conversation. I was going to send it directly to RAmeeti, but maybe others will like it too. (also, this lives in my instance of Claude only. So other claude users can’t see it.
How well do you know the programming language for Panorama, by Provue.com?
Not well. I have some general awareness that Panorama is ProVue’s database application for Mac, and that it has its own procedural scripting/programming language (historically called “PPL” or similar, with commands like statements for field manipulation, window control, etc.), but I don’t have deep, reliable knowledge of its syntax, current command set, or the specifics of Panorama X’s language.
If you’re trying to write or debug Panorama code with me, I’d likely get details wrong rather than being genuinely useful — better to check ProVue’s own documentation or forums for anything syntax-specific. If you paste code or docs, I can work with those directly and reason about them accurately.
What are you trying to do with it?
Is it useful to pointy you at the (very comprehensive) website for documentation or will that just exhaust my credits?
Weighed practicality of comprehensive documentation approach.
Mixed answer, honestly:
Useful, if done right: Pointing me at specific pages when you have a concrete question (“here’s the docs page for the SQL command, write me a query that does X”) works well. I can fetch and use that content accurately in the moment.
Not useful, if done wrong: Asking me to “crawl the whole site and learn Panorama” won’t work the way you want. I don’t retain anything between conversations from a crawl — I’d burn a lot of tool calls/credits fetching pages, and then it’s gone once this chat ends. There’s no persistent “training” happening.
Best approach:
- For a single conversation/project: fetch relevant docs pages as needed per question, rather than trying to ingest everything upfront.
- If you’re doing sustained work, better to keep a Claude Project with key doc pages saved as project knowledge — that persists and I can reference it every time without re-fetching.
- If you just have a syntax question, paste the actual doc snippet in your message — fastest and cheapest, no tool calls needed.
So: don’t dump the whole site on me speculatively. Bring me specific pages tied to specific questions, or use a Project for anything ongoing.
What if iI know that some number o f people want to use you to help write Panorama code? When does it make sense to feed you the whole shebang?
Weighed architectural options for documentation integration strategies.
It makes sense once you’re past “one person asking occasional questions” and into “recurring, shared need.” A few thresholds:
Feed it as a Project (not a one-off crawl) when:
- Multiple people will be asking Panorama questions repeatedly, and you want consistent answers
- The docs are stable enough that re-uploading isn’t a constant chore
- You curate rather than dump — a full site crawl is noisy; a maintained set of key reference pages (language reference, common patterns, gotchas) is what actually helps
Better than a Project: build a Skill — since you’re clearly in a position to invest effort here, a proper Skill (structured markdown with the language reference, idioms, common mistakes, maybe example snippets) beats a pile of raw docs. It’s reusable, versionable, and each person doesn’t need to reconstruct context every session. I have a skill-creator tool available if you want to go this route — happy to help build it.
What I’d avoid regardless of scale: raw-dumping the entire site as “context” and hoping for the best. Comprehensive ≠ well-organized for an LLM. A giant HTML dump full of nav chrome, changelogs, and marketing copy wastes context and can actually degrade answer quality versus a curated, distilled reference.
Bottom line: the investment (curating/structuring the docs into a Skill or Project knowledge base) only pays off if there’s ongoing, repeated demand. For one or two people asking occasionally, just fetch relevant pages per-question — cheaper and just as accurate.
How many people, roughly, and is this a one-time push or ongoing?
[so, here i tried another tack, using panorama itself to supply the data]
Ran 2 commands, read a file
This is genuinely useful — this is Panorama X’s own internal Help database bundle (not the website, the actual .pandb package that drives Panorama’s built-in help system). data.plist confirms it: RecordCount: 2451, and OpenWindows references FORM:Help. This could be a much better path than scraping the website page-by-page — if I can parse data.archive, I get all ~2451 help records directly.
Let me dig in.
Ran 3 commands
This is much better than I expected — this isn’t just data, it’s the actual raw content database that powers Panorama X’s built-in Help system. data.plist confirms it (2451 records, FORM:Help), and running a text extraction on data.archive pulls out full markdown source for every single help page — including tag/breadcrumb metadata used to auto-build the very TOC we looked at on the website.
Let me check if I can also cleanly split it into individual records, and look at the other archives.
Ran 4 commands
This is even better than expected — decoding fieldconfig.archive reveals the exact schema of the help database: Page, PageHeader, Filename, Title, PageType, Tags, Breadcrumb, Description, Parameters, Result, Body, Errors, SeeAlso, History, PageCount, PageTOC, Created, Modified. That confirms exactly what’s inside data.archive’s 2451 records — full markdown page bodies, tags, breadcrumbs, etc. Let me check procedures.archive too (it should hold real Panorama source code) before packaging everything up.
Ran 4 commands, read a file, shared files
Yes — and it turned out to be much more interesting than the website. What you uploaded isn’t just “a database,” it’s the actual .pandb bundle Panorama X uses internally to power its own built-in Help window — 2451 records of raw content, plus the real ProVue source code that renders it.
What I extracted:
help_content_raw_text.txt — full text pulled from data.archive (the proprietary binary record store). Every page’s title, tags, breadcrumb, and full markdown body, for all 2451 help records. data.archive isn’t a standard plist, so this is a text-run extraction rather than a byte-perfect field parse — but it recovers essentially all the readable content in one file, richer than what the website exposes (raw markdown with @pages{} / @{...}@ template macros ProVue uses to auto-generate the TOC).help_database_schema.json — decoded fieldconfig.archive, which is a real NSKeyedArchiver binary plist. This gave the exact field structure of the help database: Page, PageHeader, Filename, Title, PageType, Tags, Breadcrumb, Description, Parameters, Result, Body, Errors, SeeAlso, History, PageCount, PageTOC, Created, Modified.help_database_procedures_source.txt — decoded procedures.archive and pulled out actual working Panorama X source code: all 40 procedures ProVue wrote to run the Help window itself (markdown→HTML rendering, tag search, breadcrumb search, TOC click handling, etc.). This is real, idiomatic Panorama code straight from the vendor — genuinely better raw material for a Skill than anything I’d get scraping doc pages.
I didn’t touch variables.archive, forms.archive, or printinfo.archive — those are UI layout/window state, lower value for a language reference. Say the word if you want those too, or want the raw text turned into a clean per-page JSON/CSV instead of one flat dump.
Help content raw text
TXT
Help database schema
Code·JSON
Help database procedures source
TXT
I don’t have visibility into your account or billing status — that lives in Anthropic’s systems, not in this conversation. I can’t see plan type, payment status, or anything like that from my side.
Best way to confirm: check Settings in the app (usually shows your current plan under account/billing), or look for a confirmation email from the upgrade.
ok I will be back in the morning to finish this. Or maybe tomorrow after work.
Sounds good — I’ll be here whenever you get to it. See you then.
and takes my advice. He learns the way I like to work and he follows my methods. Yes sometimes I have to remind him of some things, but he apologizes again and is good for a good period of time.