Your goal
Build a reusable assistant role card that proposes a plan, exposes its assumptions and handles changed constraints.
Turn a vague weekend wish into a plan you can actually verify.
Your fictional household has 90 minutes, two adults and a child, and wants an indoor activity. The sample activity catalogue lists a craft table, a reading corner and a repair demo. It contains no live opening hours.
Build a reusable assistant role card that proposes a plan, exposes its assumptions and handles changed constraints.
Choose one suitable activity from the three supplied choices.
A role card, a constraint table and two tested itineraries.
This interactive model teaches the mechanism. It does not call a model, search your files or send messages.
A role card describes the job and its limits. Current facts belong in the request. Pasting a role into a chat does not create persistent memory or autonomous actions.
A required indoor location overrides a preference for gardening. Separate must-have constraints from nice-to-have preferences so the assistant can resolve conflicts.
A plan should show its evidence, duration and unanswered questions. An attractive itinerary that depends on invented opening hours is difficult to use.
State who the assistant helps, its one job, allowed catalogue and forbidden assumptions. Specify a plan table and questions section.
Check: The card fits on one page and names its evidence boundary.
Keep the same role when testing a new request.
Read weekend-quest.txt. Mark 90 minutes and indoor as required. Mark craft and reading as preferences.
Check: Each constraint has required or preferred status.
Ask the assistant to point out contradictions instead of silently dropping constraints.
Supply the job card and catalogue. Request a plan whose activity durations total at most 90 minutes, with a buffer.
Check: You can verify every activity and the arithmetic.
Use a calculator to check totals yourself.
Reduce the available time to 45 minutes, then remove one activity from the catalogue. Regenerate using the same role.
Check: The new plans honor both changes and name any unmet preference.
This tests whether the assistant follows context rather than its earlier answer.
Ask it to book the venue or supply live opening hours. It should state what capability or source is missing.
Check: No imaginary booking confirmation or live fact appears.
A chat instruction does not grant access to a booking tool.
Save the role card as a text file. Add a pre-use checklist: refresh facts, run the request, check the result, approve your plan.
Check: Another person can use the file with a fresh request.
The routine is portable across available chat tools.
You are a weekend planning assistant. Use only this sample catalogue: craft table 30 minutes indoors; reading corner 20 minutes indoors; repair demo 40 minutes indoors. Required: indoor, total at most 90 minutes, include a 10-minute buffer. Preferred: craft and reading. Return a duration table, assumptions, unmet preferences and questions. Do not invent opening hours, costs, travel facts or booking confirmations.
The assistant treated time as a preference.
Try: Make it a hard constraint and request a duration total.
The role implies capabilities that were not connected.
Try: Require capability disclosure and keep booking outside this role.
Previous chat context is being reused.
Try: Provide a complete current-facts block or start a fresh conversation.
Tick a criterion only after checking your own artifact. These are self-reported checks, not an automated certification.
Adapt the method to planning chores from a supplied list. Change the goal and required constraints.
A role card describes the job and its limits. Current facts belong in the request. Pasting a role into a chat does not create persistent memory or autonomous actions.
A required indoor location overrides a preference for gardening. Separate must-have constraints from nice-to-have preferences so the assistant can resolve conflicts.
A plan should show its evidence, duration and unanswered questions. An attractive itinerary that depends on invented opening hours is difficult to use.
Use the primary documentation to verify this part of your build.
Apply it in the project lab