Trip Guide PDF Lodging

Research, plan, revise, and deliver lodging-anchored travel guides as HTML/PDF with verified route data, hotel selection, fallback hotel swaps, curated scree...

Security Scan

The skill is mostly coherent for creating lodging‑anchored travel guides, but it references an undeclared external data source and relies on agent file-sharing behavior that could expose data — these gaps deserve clarification before installing.

Purpose & Capability

Name, description, and instructions consistently describe producing HTML/PDF lodging‑anchored travel guides; required capabilities (research, recompute routes, screenshots, QA) match the stated purpose.

Instruction Scope

Instructions stay within the stated domain (research, route verification, lodging-driven itinerary, QA, screenshot handling). However the doc tells the agent to use a source named `cn-review-sites-cdp` when Chinese review sites are weak — this external data source is referenced but not explained or declared, which could cause unexpected network calls or require undisclosed credentials. The guidance to send local files via OpenClaw messaging (MEDIA:./...) is platform-specific and implies the skill will upload local artifacts; users should verify what gets transmitted and stored.

Install Mechanism

Instruction-only skill with no install spec and no code files — lowest install risk (nothing written to disk by an installer).

Credentials

The skill declares no required environment variables or credentials (proportionate). But the `cn-review-sites-cdp` reference suggests potential reliance on an external/internal data pipeline which may need credentials or access not declared in the manifest — request clarification from the author.

Persistence & Privilege

always:false (default) and no modifications to other skills or system config. The skill asks the agent to send files via platform messaging, which is normal behavior but means uploaded files and screenshots could be shared — not a privilege escalation but worth reviewing platform upload policies.

What to consider before installing

This skill appears to do what it says, but two things need clarification before you install or run it: (1) it mentions an external data source (`cn-review-sites-cdp`) without declaring credentials or explaining where that data comes from — ask the publisher whether this triggers network calls or requires special API keys or internal access; (2) the skill explicitly instructs the agent to send local files/screenshots via OpenClaw messaging (relative MEDIA paths) — confirm what files will be uploaded, where they are stored, and whether screenshots may include PII (hotel confirmations, addresses, reservation numbers). If you rely on private data, request an explicit list of endpoints the agent will contact and whether any credentials will be required or stored. If the author cannot clarify the `cn-review-sites-cdp` dependency or file upload behavior, treat the skill as higher risk and avoid giving it access to sensitive files or credentials.

Build the guide in HTML first. Export PDF only after route logic, lodging choice, and screenshots are stable.

Treat the hotel or lodging as the nightly anchor. Design each day around where the user sleeps, not around scenic spots alone.

Core rules

1. Verify every hard number before writing it.
2. Separate hard data from soft signal.
   • Hard data: driving time, distance, tolls, hotel address, phone, opening hours, scenic latest entry.
   • Soft signal: renovation quality, noise risk, dining feel, queue risk, convenience impressions.
3. If lodging changes, recompute all dependent legs instead of text-replacing the hotel name.
4. Keep screenshots sparse and purposeful.
5. Use formal, compact copy unless the user explicitly wants casual tone.

Workflow

1) Lock the planning frame

Extract:

• dates / trip length
• departure city
• trip style: self-drive, hiking, family, solo, etc.
• preference weights: scenery, comfort, food, crowd avoidance, budget
• output target: quick answer or polished HTML/PDF

If the user already gave enough constraints, start researching immediately.

2) Choose the lodging strategy first

Before writing the day plan, determine:

• single hotel vs multi-hotel
• town-center convenience vs scenic proximity
• parking requirement
• breakfast requirement if it changes departure time
• fallback lodging in case of sellout or price spike

The day plan should follow the lodging choice, not the other way around.

3) Choose sources by job

Read references/source-selection.md when deciding what to trust.

Default split:

• maps / official scenic pages / structured listings for hard numbers
• review sites and social posts for soft signal
• if Chinese travel/review sites are involved and normal search/fetch is weak, use cn-review-sites-cdp

4) Verify hard data before drafting

Check the numbers that decide feasibility:

• origin → lodging
• lodging → main scenic spot
• lodging → secondary scenic spot
• lodging → dinner / breakfast anchors when they matter in the final guide
• scenic opening hours / latest entry
• hotel phone / rating / address if shown

Re-run this step after every lodging change.

5) Design the itinerary from the lodging anchor

For each day, choose the nightly lodging first, then build:

• arrival window
• check-in / rest buffer
• meal window
• scenic entry window
• return buffer
• holiday congestion buffer

If the hotel moves from old town to new town, update the walking radius and dinner logic. Do not assume Day 1 still works unchanged.

6) Draft HTML first

Good structure:

• cover / conclusion box
• route overview
• day-by-day plan
• lodging section
• dining section
• risk notes / contingency

The top conclusion should tell the user:

• which lodging won
• why it won
• what fallback exists
• what tradeoff changed after the lodging decision

7) Use screenshots as evidence, not decoration

Keep only screenshots that support a decision:

• scenic proof image
• hotel listing / hotel note if it materially affects the recommendation
• restaurant listing snippet if it justifies a recommendation

Reject screenshots that are blank, QR-heavy, cluttered, or mostly irrelevant UI.

8) Run the QA gate before PDF export

Read references/qa-checklist.md and clear it.

Minimum gate:

• route numbers consistent with latest lodging choice
• time logic feasible
• screenshots clean
• tone formal enough
• filenames and variant names clear

9) Deliver and version clearly

Prefer scenario-specific filenames over destructive overwrites.

Examples:

• *_final.html
• *_revision.html
• *_hotel-swap.html
• *_quanji.html

When sending local files through OpenClaw messaging, prefer relative MEDIA:./... paths instead of absolute MEDIA:/abs/path paths.

Revision logic

• Visual-only feedback: rework screenshots, typography, and tone.
• Hotel change: recompute every dependent leg and rewrite the daily structure affected by that hotel.
• Budget pressure: rerank hotels and surface tradeoffs explicitly.
• Feasibility issue: re-verify with maps / official sources and rebuild affected days.

Read these references when needed

• references/source-selection.md — which source to trust for which data type
• references/qa-checklist.md — pre-export checklist for lodging-based guides