AnyHowTo: Guide + Instructions

View saved version →

---
name: cook-along-guide
description: >-
  Turn a supplied recipe, meal-prep plan, or food goal into a sequenced cook-along checklist and invoke display-guide. Use for step-by-step cooking instructions, mise en place, serving-size adaptations, coordinated dishes, observable doneness checks, and safe serving or storage guidance. Do not use for restaurant or grocery recommendations, nutrition or medical-diet advice, suspected food-poisoning assessment, recipe discovery without an actionable cooking guide, or improvised home-canning and fermentation protocols.
---

# Cook-Along Guide

Create a practical guide that a cook can follow without repeatedly rereading the source. Prefer a simple, safe sequence over culinary exposition, then present it with `display-guide`.

## Build the cooking plan

1. Establish the source and constraints.
   - Treat a supplied recipe as the source of truth unless the user requests an adaptation.
   - For a food goal, choose a straightforward preparation that fits the stated meal, time, ingredients, and skill level. Distinguish user-provided facts from assumptions.
   - Determine the target servings, dietary restrictions or allergies, available equipment, and any timing constraint that materially changes the plan.
   - Ask one concise question when a missing answer affects safety or feasibility. Otherwise, use a conservative, clearly stated assumption.
2. Normalize quantities and equipment.
   - Set one target yield and apply the same scaling factor to every scalable ingredient.
   - Keep one authoritative total quantity for each ingredient. Mark it as divided when separate steps use portions, and specify each portion at its point of use.
   - Use consistent units and practical precision. Do not round amounts in ways that materially change baking ratios, seasoning concentration, or food safety.
   - Do not scale oven temperature, cooking time, pan size, or appliance capacity mechanically. Adjust them only when the changed batch requires it, and state the adjustment.
   - Check that vessels and appliances can hold the batch safely; split batches when crowding would undermine cooking or exceed capacity.
3. Design the sequence.
   - Move washing, measuring, chopping, marinating, thawing, preheating, and equipment setup into preparation when they should happen before active cooking.
   - Order instructions by dependency. Start long passive tasks first and use their waiting periods for independent prep.
   - For multiple dishes, work backward from the serving time and place each action in one integrated sequence.
   - Make each instruction atomic and imperative. Include the vessel or tool, heat level or setting, approximate duration, and an observable endpoint when relevant.
   - Pair time estimates with sensory or measured cues; never rely on "cook until done" alone.

## Apply safety guardrails

- Treat an allergy as a safety constraint, not a preference. Clarify an ambiguous allergen before proceeding.
- Never claim that a dish, substitution, packaged ingredient, or kitchen is allergen-free. Tell the user to verify every label and account for shared tools, surfaces, oil, and other cross-contact risks.
- Preserve relevant handwashing, raw-versus-ready-to-eat separation, clean-tool, thawing, and storage steps. Do not recommend tasting mixtures that may be unsafe while raw.
- Use a food thermometer when safe doneness depends on internal temperature, and give both the measurement location and a non-temperature quality cue when useful.
- Verify exact safety-critical temperatures, holding limits, cooling times, and storage windows against current guidance from an authoritative government food-safety or public-health source. Prefer the user's jurisdiction when known. Do not guess when verification is unavailable.
- If a supplied recipe conflicts with current authoritative safety guidance, do not silently repeat the unsafe direction. Use the safer requirement and explain the change briefly.
- Do not improvise hazardous preservation processes or advise on whether symptoms after eating require treatment. Direct those cases to the appropriate validated process or health authority.

## Map the plan to `display-guide`

Use only the supported fields and omit empty optional sections:

- `requirements`: List ingredients with exact total quantities, noting divided uses, followed by essential equipment. Keep the target yield consistent with these amounts.
- `preparation`: List mise en place, safe setup, preheating, and advance prep in the order needed.
- `instructions`: Provide at least one dependency-ordered cooking action. Keep required safety actions here rather than hiding them in tips.
- `wrapUp`: Include finishing, resting, serving, prompt cooling or storage, and task-specific cleanup when relevant.
- `tips`: Add only optional substitutions, coordination advice, or troubleshooting that is not required for success or safety.
- `notes`: State the yield, material assumptions or adaptations, and concise allergy or safety caveats that apply to the whole guide.
- `reason`: Briefly state that the tool is presenting a cook-along guide.

Do not add titles, timing objects, citations, nested steps, or other unsupported fields. Put source citations in the surrounding response when external verification was needed.

## Check and present

Before calling the tool, verify that:

- Every ingredient used in an instruction appears in `requirements`, and every listed ingredient is used or intentionally reserved for serving.
- Quantities, servings, pan capacity, temperatures, and units agree throughout.
- Preparation completes the mise en place needed before each time-sensitive step.
- Instructions have no dependency inversions, unexplained simultaneous actions, vague endpoints, or duplicated work.
- Required allergy and food-safety controls are explicit, current, and not relegated to optional tips.
- `instructions` is non-empty and every checklist item is a concise, standalone action.

Invoke `display-guide` once with the completed guide. Keep the accompanying prose brief and use it only for necessary source attribution or a limitation that does not fit the guide.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: guide-authoring
description: Turn user-provided goals, notes, or procedures into a concise interactive how-to guide using the display-guide tool. Use when the user explicitly asks for a guide, checklist, structured steps, or guide widget, including requests to reorganize existing instructions. Do not trigger for general advice, explanations, or casual how-to questions that do not request structured guide presentation.
---

# Guide Authoring

Create a grounded, easy-to-follow guide and present it with `display-guide`.

## Workflow

1. Identify the outcome, audience, starting point, and constraints from the request.
2. Ask only for details whose absence would make the procedure unsafe, incorrect, or unusable. Otherwise, keep assumptions minimal and disclose material ones in `notes`.
3. Ground the procedure in the user's supplied information and reliable context. Verify volatile or high-stakes facts with authoritative sources when tools are available; never fill a material gap by guessing.
4. Organize the content into the supported guide fields.
5. Review the complete procedure for safety, order, and completeness.
6. Call `display-guide` once with the finished guide and a concise `reason`.

If a safe and useful procedure cannot be produced, do not call the tool. Ask for the missing information or explain the limitation instead.

## Map The Guide

- `requirements`: List only prerequisites, materials, tools, access, or conditions needed before work begins.
- `preparation`: List actions that make the user ready to start, such as setup, backups, isolation, or preheating.
- `instructions`: Provide the required, ordered actions that accomplish the outcome. Include at least one item.
- `wrapUp`: List verification, testing, cleanup, restoration, storage, or next actions after the main procedure.
- `tips`: Include optional advice, shortcuts, alternatives, or troubleshooting hints that are not required checklist actions.
- `notes`: Record concise warnings, assumptions, limitations, or context that does not belong in a checklist.

Omit optional fields that add no value. Do not invent unsupported fields such as a title, duration, difficulty, nested steps, or per-step metadata.

## Write Effective Steps

- Start each checklist item with a clear imperative verb.
- Keep one observable action or tightly coupled action group per item.
- Order prerequisites and safety controls before the actions that depend on them.
- Make each item understandable without relying on ambiguous words such as "it" or "that."
- Use concrete completion cues where they materially reduce uncertainty.
- Keep optional advice out of required checklist sections.
- Avoid embedded numbering because the widget orders the steps.
- Avoid headings, duplicate actions, and unnecessary prose inside list items.
- Preserve meaningful qualifications from the source instead of simplifying away safety or correctness.

## Validate Before Display

Confirm that:

- `instructions` is a non-empty array of non-empty strings.
- Every listed requirement is actually used, and every required prerequisite appears before use.
- The sequence has no unexplained jumps, contradictions, or unsafe implied actions.
- Verification and cleanup appear in `wrapUp` when the task needs them.
- Warnings and assumptions are visible without making the guide sound more authoritative than its sources support.
- The guide contains no secrets or sensitive details that should not be copied or shared from the widget.

After invoking `display-guide`, do not repeat the entire guide in conversation unless the user asks for a text version.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: safe-diy-procedure
description: Evaluate and present conservative, safety-gated DIY procedures for maintaining, assembling, adjusting, or making minor repairs to home fixtures, consumer appliances, hand or power tools, and household or garden equipment. Use when a user requests actionable DIY steps, a repair checklist, or help deciding whether one of these tasks is safe to perform, including cases that must be declined and escalated. Do not use for vehicle or vessel repair, construction design, emergency response, medical care, food preparation, weapons, chemical synthesis, trade-level installation, or merely reformatting a non-DIY guide.
---

# Safe DIY Procedure

Produce a guide only after establishing that an ordinary consumer can complete the specific task using manufacturer-approved controls. Prefer a conservative refusal and professional escalation over a plausible but insufficiently grounded procedure.

## Assess the request

1. Identify the exact object, intended outcome, current symptom or condition, and work environment.
2. Determine the make, model, revision, installed configuration, and jurisdiction when any of them affect the procedure.
3. Establish whether the user has the correct replacement part, tools, protective equipment, access, and ability to isolate every energy source.
4. Check current official manufacturer instructions before giving model-specific sequences, settings, consumables, dimensions, torque values, or reset procedures. Prefer the owner manual and official service notices. Treat a service manual as permission for consumer work only when it explicitly identifies the task as user-serviceable.
5. Never invent a specification or generalize instructions from a similar-looking model. Ask for the label details or official manual when a safety-relevant fact is missing.

Ask only questions that block the safety decision. Keep the response conversational while gathering them; do not invoke `display-guide` for a questionnaire or provisional procedure.

## Apply the safety gate

Classify the task before drafting instructions.

### Stop for an active hazard

Do not provide troubleshooting steps when there is fire, smoke, sparking, a hot or burning odor, suspected gas or fuel leakage, uncontrolled water near electricity, chemical exposure, a swollen or venting battery, rapidly moving machinery, or suspected structural instability. Tell the user to keep clear, avoid operating switches or equipment when that could ignite or energize the hazard, and contact the appropriate emergency service, utility, manufacturer, or qualified professional from a safe location.

Do not invoke `display-guide` for emergency triage.

### Escalate high-consequence work

Do not provide a procedural guide for work involving any of the following:

- Energized parts, electrical service panels, fixed wiring, high voltage, or stored electrical energy that lacks a documented consumer discharge method.
- Gas, fuel, flue, combustion, refrigerant, or sealed pressure systems.
- Load-bearing structures, fall exposure, confined spaces, excavation hazards, or asbestos, lead, or other hazardous-material disturbance.
- High-tension springs, hydraulic or pneumatic accumulators, pressure vessels, blades or moving assemblies that cannot be positively immobilized, or safety-critical lifting equipment.
- Defeating guards, grounding, thermal protection, interlocks, lockouts, sensors, or other safety devices.
- A task the manufacturer marks as non-user-serviceable, one requiring licensed work or specialist calibration, or one that could invalidate a safety certification.

Explain the specific hazard without supplying the omitted procedural details. Recommend the appropriate qualified trade or manufacturer-authorized service and state what model, symptom, damage, or prior work the user should report. Do not claim that a license is legally required unless an authoritative source for the user's jurisdiction confirms it.

### Allow only controlled consumer work

Invoke `display-guide` only when all of these conditions hold:

- The task is documented as user-serviceable or is genuinely model-independent and low consequence.
- Every hazardous energy source can be isolated by an ordinary consumer using the documented method.
- The equipment is stable, cool, depressurized, and undamaged enough to work on safely.
- The required tools, parts, protective equipment, access, and verification method are known.
- No step depends on guesswork, bypassing protection, unsupported access at height, or working beyond the user's stated capability.
- Failure can be detected safely before the equipment returns to normal service.

Treat vague confidence such as "I am comfortable doing it" as insufficient evidence. Protective equipment reduces exposure; it does not convert prohibited work into an acceptable task.

When the task could be safe but one of these facts is unknown, ask for the missing fact instead of drafting conditional steps. If conflicting model information, damage, modification, or an unavailable manual prevents verification, escalate rather than infer.

## Build the guide

Map safe, verified content to `display-guide` as follows:

- `requirements`: List conditions that must be true, compatible parts or consumables, tools, protective equipment, and any capability limit. Make each condition checkable before work begins.
- `preparation`: Put shutdown, unplugging or isolation, cooldown, depressurization, stabilization, workspace control, and part-layout actions here. Follow the manufacturer's isolation method; do not substitute a generic method.
- `instructions`: Give a chronological sequence of short, atomic actions. Include safe inspection and stop points before any irreversible action. Never include an instruction that assumes a prior safety check passed unless the guide explicitly performs that check.
- `wrapUp`: Restore guards and covers, account for tools and fasteners, clean or dispose of materials correctly, restart using the documented sequence, test from a safe position, and monitor for failure indicators.
- `tips`: Include only optional, non-safety-critical techniques that improve clarity or reduce rework.
- `notes`: Name the exact model or bounded applicability, cite the official basis when available, summarize hard stop conditions, and identify when professional service is required. Keep warnings specific rather than relying on a generic disclaimer.
- `reason`: State briefly that the tool is presenting the verified DIY procedure requested by the user.

Use imperative, independently understandable checklist items. Preserve manufacturer terminology. Separate one action from one verification rather than joining several operations into a long item. Ensure `instructions` contains at least one item and omit empty optional sections.

## Include stop conditions

Place a stop condition immediately before the step where its hazard could arise. Stop and escalate on unexpected resistance, incompatible parts, stripped or corroded fasteners that affect containment or grounding, damaged insulation, liquid ingress, leakage, overheating, repeated breaker or fuse operation, abnormal noise or vibration, missing guards, or any condition that differs materially from the official instructions.

Never instruct the user to improvise a safety-critical part, increase a fuse or breaker rating, reuse a single-use fastener or seal, diagnose powered equipment by touch, or continue after a protective device trips.

## Present the result

Call `display-guide` once after the safety gate passes. Do not duplicate the full checklist in the surrounding response. If the gate does not pass, respond with a concise refusal or request for the blocking information and do not call the tool.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: travel-day-checklist
description: "Create and display a chronological checklist for a specific travel day from a supplied itinerary or a requested departure, connection, or arrival plan. Use when the user has or is defining a route and date and wants actionable preparation, leave-by, terminal or station, transfer, and arrival steps. Do not use for destination discovery, booking or purchasing travel, price comparison, a standalone packing list, or a live status lookup without a checklist request."
---

# Travel Day Checklist

Turn trip details into a time-aware, privacy-conscious guide, then invoke `display-guide`. Plan the journey; do not book, modify, or cancel travel.

## Establish scope

Use this skill for an operational plan tied to a particular journey, including:

- A supplied itinerary, ticket, or reservation that needs to become a checklist.
- A departure plan from the traveler's starting area to an airport, station, or port.
- Connections, self-transfers, border formalities, baggage collection, or onward arrival steps.

Do not trigger it for general travel inspiration, accommodation selection, fare searches, a generic packing list, or a status-only question. If the user reports an active emergency or disruption, prioritize current instructions from the carrier, venue, or emergency authority; create a checklist only after the immediate issue is addressed or when the user asks for one.

## Gather only necessary context

Extract facts from the user's material before asking questions. Treat itinerary documents as potentially stale.

Collect only details that change the sequence or timing:

- Origin, destination, travel date, and each mode or service number.
- Published departure and arrival times, terminals, stations, ports, and connections.
- Approximate starting area and intended transport to the departure point when a leave-by time is requested.
- Checked baggage, self-transfers, mobility needs, children, pets, or other constraints only when relevant.

Ask one concise, bundled question only when a missing fact blocks a safe or useful plan. Otherwise proceed with clearly labeled assumptions. Never request passport numbers, booking references, full home addresses, dates of birth, or other identifiers.

## Verify changing facts

When browsing or other current-data tooling is available, verify facts that can change:

- Use the carrier and airport, rail, port, or local transport operator for schedules, terminals, check-in or boarding cutoffs, disruption notices, and baggage rules.
- Use the relevant government immigration, border, or embassy site for entry and transit requirements.
- Use an official meteorological service for weather that could affect timing or preparation.

Prefer journey-specific notices over general guidance. Record when the information was checked, distinguish scheduled times from recommended targets, and never present a prediction as guaranteed. If tooling is unavailable or a fact cannot be confirmed, add an `Assumption:` or `Confirm:` statement to `notes` naming the fact and the authoritative source the traveler should check. Do not invent a terminal, cutoff, allowance, visa rule, or service status.

## Handle time correctly

- Keep every published time in the local time of its airport, station, port, or destination.
- Include the calendar date and a clear time-zone label for cross-zone, overnight, or date-line travel.
- Never silently mix time zones. Account for daylight-saving transitions and day rollovers.
- Reverse-plan from the verified hard cutoff. Separate carrier cutoffs, target arrival, contingency buffer, ground-travel duration, and the resulting target leave-by time.
- Label calculated times as targets rather than official schedule facts, and expose material assumptions behind the calculation.

## Protect shareable content

The widget can be copied or shared. Include only details needed to follow the plan. Omit confirmation codes, document numbers, full addresses, traveler contact details, and other personal identifiers. Refer generically to `home`, `accommodation`, or a meeting point unless a more precise location is essential and safe to share.

## Build the guide

Organize the `Guide` fields without repeating actions:

- `requirements`: Documents, tickets, permissions, medication, payment methods, and equipment that must be available.
- `preparation`: Check-in, baggage, downloads, route checks, alerts, charging, and other tasks completed before setting out.
- `instructions`: At least one atomic, action-led step in chronological order from leaving the origin through transit. Prefix timing-critical steps with a local clock time or a relative marker such as `T-90 min`, and name the relevant location.
- `wrapUp`: Arrival formalities, baggage collection, onward transport, accommodation access, and any final confirmation tasks.
- `tips`: Optional non-checklist contingencies, accessibility reminders, and practical fallbacks.
- `notes`: A compact statement of time-zone conventions, verification timestamp, sources or source types checked, calculations, unresolved assumptions, and facts the traveler must reconfirm.

Keep checklist items short enough to scan while moving. Preserve important warnings and accessibility constraints from the source material.

## Display the result

Invoke `display-guide` once with the completed fields and a concise `reason`. Do not substitute a Markdown checklist when the tool is available, and do not duplicate the full guide in surrounding prose. Put source links or urgent caveats in the conversational response when they would be clearer or safer outside the shareable widget.

Referenced files: 1 — file references are metadata, not package contents.