I configured these systems for travel planning and structured comparisons. Instructions, knowledge files, and memory rules give each one a defined job and a consistent output. The details below show how those pieces work together inside the hosted LLM, including the limits of relying on a model to follow its own rules.
01
Planning across conflicting constraints
Parker Family Travel Agent
I built a travel-planning system that checks family fit, transport, and dietary requirements before recommending an itinerary. Fourteen Claude Project files hold the reusable rules, current trip details, and trusted vendor knowledge. I review the resulting brief and make the bookings.
The prompt and knowledge files form the application boundary.
Fourteen modular Markdown files form the application layer. The collection separates traveler profiles, intake rules, destination research, dietary requirements, operator vetting, transport risk, traveler engagement requirements, message templates, emergency protocols, trip state, and durable vendor knowledge.
Decision flow
01
Load traveler profiles and the current journey overlay
02
Evaluate family fit
03
Evaluate traveler engagement requirements
04
Evaluate transport and operator risk
05
Evaluate dietary suitability and confidence
06
Verify time-sensitive facts and produce the planning brief
State and memory
Files 01 through 12 hold reusable profiles and rules. File 13 is the current-journey overlay. File 14 is the trusted-vendor register. Promotion rules control when a trip-specific observation becomes durable knowledge.
Reliability and verification
Options that fail engagement, transport, or dietary requirements stop before the final brief. Time-sensitive logistics require live verification or an explicit confidence label. Any exception must be named and justified in the output.
Resulting output
The system returns an executive planning brief with vetted options, confidence labels, reusable vendor messages, and enough decision context for a person to approve the itinerary and complete bookings.
Operating boundary
The same hosted model applies the gates and generates the answer. There is no separate API, database, scheduler, or independent validator. Prompt compliance remains probabilistic, and a person retains every booking and safety decision.
02
Reliable tables from conversational input
Pokédex Reviewer
I designed a review system that turns a Pokémon list into a consistent comparison of battle roles, movesets, and investment priorities. Its instructions require premise checks and a fixed nine-column table that can be reused in a spreadsheet.
It defines the reviewer role, the evaluation sequence, tier rules, the nine-column Markdown contract, sorting behavior, formatting bans, and the required order of calculation and response.
Decision flow
01
Accept a Pokémon list and primary evaluation focus
02
Normalize the requested entities and intent
03
Recalculate numerical or factual premises
04
Classify PvE and PvP use cases and tiers
05
Sort by the selected focus
06
Render the fixed Markdown comparison table
State and memory
Each run receives the entity list and primary focus from the user. There is no external state store. Domain facts come from the model context, so current game data must be checked when freshness matters.
Reliability and verification
The prompt requires independent calculation before confirming a user premise. Negative directives remove meta-announcements, conversational openings, labeled conclusions, and unnecessary LaTeX that would interfere with direct reuse.
Resulting output
Each row contains Pokémon, primary use case, typing, PvE rating, optimal PvE moveset, best PvP league, PvP rating, optimal PvP moveset, and investment priority. The result is ready for direct comparison or spreadsheet transfer.
Operating boundary
The schema is enforced through instructions rather than application code. No API ingestion, batch runner, external validator, or automated freshness check is verified. Human review remains necessary for current game mechanics and investment decisions.