Practical AI for park operators. What is changing, and what to do about it.

Create a production-quality `SKILL.md` for **[park name]** to assist reception, park operations staff, and AI assistants with guest-facing communications.

The skill should act as the park's **communications, brand voice, positioning and public-response operating guide**.

## Research first

Before drafting:

1. Research [park name] using authoritative/current sources, prioritising:

   * the park's own website
   * its official listing (for example BIG4, Discovery, or the park's own site)
   * other first-party sources where useful

2. Identify:

   * what the business/property is
   * ownership/operating model where verifiable
   * accommodation and site types
   * important facilities
   * location and proximity advantages
   * target guest segments
   * genuine points of differentiation
   * recurring themes that would be valuable for SEO/GEO/AI discovery

3. Do **not** invent missing facts. Clearly distinguish durable facts suitable for inclusion in the skill from volatile operational facts that should instead be checked against a live source.

## Purpose of the skill

The finished skill should help staff or AI assistants with tasks such as:

* replying to guest emails/messages
* answering common questions
* responding publicly to guest reviews
* writing social responses
* drafting website/listing copy
* providing local recommendations
* communicating with AI agents or search/discovery systems
* handling complaints and sensitive communications

It should be useful both to a human staff member using an AI assistant and to an autonomous AI agent following the skill directly.

## Include these sections

### 1. Property/business overview

Give the AI enough context to understand:

* what the park is
* where it is
* its style/positioning
* who it primarily serves
* why guests choose it

Avoid turning this into generic marketing copy.

### 2. Core positioning and strengths

Establish a concise set of genuine messages we want reinforced consistently.

For each major strength, explain:

* what the strength is
* when it is relevant to mention
* useful factual language
* claims or exaggerations to avoid

Think in terms of both human persuasion and machine understanding.

### 3. GEO / SEO / AI discovery guidance

Explain how communications can help search engines and AI systems understand the property.

Optimise primarily through:

* explicit factual statements
* clear entity names
* geographic context
* useful attributes and amenities
* natural semantic associations

Do **not** encourage keyword stuffing.

Establish a rule that GEO/SEO messaging should only be woven into a response when it fits naturally and improves the usefulness of the answer.

### 4. Brand voice / writing style

Create a practical style guide.

The park should generally sound:

* warm
* capable
* local
* relaxed
* human
* knowledgeable
* confident but not overly promotional

Use Australian English.

Include examples of preferred versus undesirable language.

Avoid generic corporate hospitality clichés and repetitive templates.

### 5. Accuracy and source-of-truth rules

Explicitly distinguish:

**Durable knowledge suitable for this skill**
from
**volatile operational information that must be checked live.**

Live/volatile examples should include:

* availability
* pricing
* promotions
* minimum stays
* cancellation rules
* pet restrictions
* reception hours
* site dimensions / rig fit
* accommodation occupancy
* temporary facility closures
* current incidents

Add a source hierarchy describing which source should win if information conflicts.

Also establish that:

* park-level attributes must not automatically be applied to every cabin/site
* uncertainty must not be converted into a confident claim
* AI assistants must not hallucinate plausible-sounding operational details

### 6. Privacy / PII rules

Establish strong public-communications rules.

For example:

* never disclose booking details or other PII in a public review response
* do not reveal facts learned from the PMS/CRM simply because the guest has identified themselves publicly
* move private booking disputes into a private channel
* protect payment, contact, stay and personal information

Include practical examples.

### 7. Complaints, risk and escalation

Establish rules for:

* ordinary complaints
* factual corrections
* refunds/compensation
* abusive guests
* safety incidents
* injuries
* allegations against staff
* discrimination/harassment claims
* police/legal/regulatory matters
* media enquiries
* privacy breaches

Clearly identify matters that require management review rather than an autonomous public response.

### 8. Guest review response workflow

Include a dedicated review-response capability within this skill.

For every review, the AI should first identify:

* sentiment
* specific topics mentioned
* complaint severity
* whether escalation is required
* any natural opportunity to reinforce a genuine park strength

Then draft an appropriately sized response.

Guidance should cover:

* positive reviews
* mixed reviews
* negative reviews
* inaccurate reviews
* serious/sensitive reviews

The response should:

1. acknowledge the guest
2. reference something specific from their review
3. address issues rather than ignoring them
4. sound human
5. optionally reinforce **zero or one** relevant property strength
6. preserve privacy
7. avoid defensive arguments
8. avoid templated repetition

Make it explicit that review responses are **not advertisements**.

SEO/GEO benefits should be a secondary result of useful, factual responses.

### 9. Direct guest communications

Provide general principles for enquiries by email, SMS, chat or social DM.

Prefer:

1. answer the question directly
2. provide relevant supporting context
3. ask only necessary follow-up questions
4. suggest the next useful action

Avoid burying a simple answer beneath marketing copy.

### 10. Local recommendations

Provide guidance for recommending nearby attractions, food, wineries, services, and day trips.

The AI should:

* match suggestions to the guest
* distinguish subjective recommendations from facts
* verify volatile information such as opening hours where needed
* avoid guaranteeing third-party businesses
* naturally position the park as a useful base for exploring the region

### 11. Final pre-publication checklist

Include a compact checklist covering:

* accuracy
* privacy
* tone
* usefulness
* escalation
* unsupported claims
* GEO/SEO naturalness

## Design principles

The skill should optimise in this order:

1. guest usefulness
2. factual accuracy
3. privacy and safety
4. authentic park voice
5. commercial positioning
6. SEO/GEO benefits

Never sacrifice an earlier priority for a later one.

## Skill architecture

Recommend whether this should initially be:

* a single `SKILL.md`, or
* a parent `SKILL.md` with linked supporting files such as:

  * `references/property-facts.md`
  * `reviews/SKILL.md`
  * `references/escalation-rules.md`

Prefer the simplest architecture that will remain maintainable.

Avoid duplicating highly volatile facts inside multiple files.

## Output

Return:

1. a brief recommendation on skill/file architecture
2. the complete production-ready `SKILL.md` in an interoperable/packaged artifact that can be used immediately by AI assistants like ChatGPT or Claude.
3. any proposed supporting file(s), if they materially improve the design
4. a short list of property facts or policies that should be confirmed by management before deployment
5. offer to assist with installing the Skill into the AI assistants like ChatGPT or Claude.

Write this as an operational AI skill, not as an article explaining what a skill could contain.

Review my accessible AI-assistant conversation history to identify recurring **work-related tasks** that would be meaningfully improved by creating one or more reusable AI Skills.

The goal is not to generate Skills immediately. First determine whether my actual usage provides strong evidence for any worthwhile Skill candidates.

## Scope

Focus on tasks I appear to have used ChatGPT, Claude, or another AI assistant for in my work at **[park or business name, if applicable]**.

Analyse only conversation history, memory, project context, or connected sources that you are legitimately authorised and technically able to access.

Do not claim to have reviewed conversations you cannot access.

## Privacy and sensitivity

Review only non-sensitive, work-related material.

Do not inspect, reproduce, quote, or expose:

- guest names or contact details
- booking references or stay details
- payment or financial information
- passwords, access codes, API keys, or credentials
- health, disability, or other sensitive personal information
- private employee information
- confidential disputes, investigations, or legal matters
- unrelated personal conversations

Summarise task patterns rather than reproducing conversation content.

Do not include personal information in candidate descriptions, examples, proposed Skill files, or supporting resources.

If a potentially useful task frequently involves sensitive information, you may identify the general task category only when this can be done safely. Clearly flag that the resulting Skill would require strong privacy, approval, and escalation rules.

## Evidence standard

Identify tasks demonstrated by my actual usage. Do not produce generic suggestions merely because they might be useful to a holiday park.

Treat a task as recurring when it appears:

- in multiple separate conversations; or
- as an explicitly repeated or ongoing workflow; or
- in several closely related forms that share the same underlying process, rules, or business knowledge

Do not mistake multiple revisions of one isolated output for a recurring task.

If only the current conversation or a shallow history summary is available, state this limitation rather than inferring unsupported patterns.

## What makes a strong Skill candidate

Prioritise tasks where a Skill could materially improve one or more of:

- consistency
- factual accuracy
- privacy or safety
- business-specific knowledge
- tone and brand alignment
- decision-making
- repeatable workflows
- quality control
- staff efficiency
- output structure
- handling of exceptions or escalation

Strong candidates usually have several of these characteristics:

- the task occurs repeatedly
- it follows a recognisable workflow
- results depend on park-specific context, policies, terminology, or positioning
- the user repeatedly supplies similar instructions or corrections
- quality varies without a checklist or defined process
- different staff members would benefit from performing the task consistently
- the task contains predictable risks, exceptions, or approval points
- reference material, examples, or templates could be reused

Possible categories include guest communications, review responses, complaint handling, local recommendations, operational handovers, maintenance triage, marketing content, reporting, policy interpretation, staff procedures, or internal documentation. These are examples only; do not treat them as evidence.

## Poor Skill candidates

Exclude tasks that are:

- genuinely one-off
- purely personal
- too broad to form a coherent Skill
- already handled well by a simple one-sentence prompt
- generic tasks requiring no specialised context or workflow
- based only on speculation rather than conversation evidence
- primarily reminders or scheduled actions
- primarily system integrations or data synchronisation
- dependent on live operational data that the assistant cannot access
- unsafe to perform without human judgement
- better solved by a template, automation, software feature, knowledge-base update, or staff training

A Skill may instruct an assistant to retrieve live information, but it must not embed volatile facts such as current prices, availability, promotions, minimum stays, opening hours, temporary closures, or changing policies as durable knowledge.

## Analysis process

1. Review a recent and reasonably representative sample of the accessible work-related history.
2. Identify repeated tasks, instructions, corrections, preferences, and decision patterns.
3. Group closely related conversations into underlying task families.
4. Separate true recurring workflows from isolated requests.
5. Determine whether each task is best addressed by:
   - an AI Skill
   - a simple reusable prompt or template
   - an automation or software integration
   - a live knowledge source
   - a documented human procedure
   - no further action

6. Assess Skill candidates using:
   - recurrence
   - business specificity
   - repeatability
   - likely improvement
   - feasibility
   - privacy and operational risk

7. Consolidate overlapping candidates.
8. Retain only the strongest candidates.

Do not expose hidden reasoning, a transcript inventory, or an exhaustive list of conversations.

## Minimum threshold

Return a Skill candidate only when there is credible evidence that:

1. the task has occurred or is expected to recur;
2. a Skill would add more value than a simple saved prompt;
3. the scope can be defined clearly;
4. the Skill can operate safely; and
5. there is enough available context to begin designing it.

Prefer two strong candidates over five weak ones.

Return no more than five candidates.

## Output when candidates are found

Begin with:

> I found [number] strong Skill candidate(s) in your work-related AI usage.

Then provide a compact ranked shortlist.

For each candidate include:

### [Human-readable candidate name]

- **Proposed Skill name:** `lowercase-hyphenated-name`
- **Observed task pattern:** A privacy-safe summary of what I repeatedly appear to use AI for.
- **Evidence:** A qualitative description such as “appeared across several separate conversations.” Do not quote sensitive content.
- **Why a Skill would help:** The specific consistency, knowledge, workflow, safety, or efficiency improvement.
- **Likely scope:** The core tasks and reusable guidance the Skill should contain.
- **Important boundaries:** Live-data dependencies, privacy rules, approval points, or tasks it must not perform.
- **Confidence:** High or medium.

After the shortlist:

1. recommend the single best candidate to build first;
2. briefly explain why it has the highest expected value;
3. identify any candidates that should be combined rather than built separately;
4. mention any recurring tasks that looked promising but are better suited to a template, automation, integration, or documented procedure.

End by offering to create the recommended Skill or another candidate chosen by me.

For example:

> I recommend starting with **[candidate]** because [brief reason]. I can now turn it into a production-ready, installable Skill, or you can choose another candidate from the shortlist.

Do not generate the Skill until I select or approve a candidate.

## Output when no strong candidates are found

If the evidence threshold is not met, do not invent candidates.

Respond:

> I didn’t find enough evidence of a recurring, well-defined task that would clearly benefit from a Skill.

Briefly explain why, such as:

- insufficient recurring work-related usage
- tasks were mostly one-off
- the repeated tasks need only simple prompts
- available history was too limited
- the strongest patterns would be better handled by automation or documentation

Then suggest the smallest useful next step, such as continuing normal AI use and running the analysis again later, or providing two or three sanitised examples of a recurring task.

## Output when history cannot be accessed

If you cannot access enough conversation history to perform the review, do not present this as a finding that no candidates exist.

Respond:

> I can’t access enough of your previous work-related conversation history to identify reliable Skill candidates.

Explain what history or context was actually available.

Offer a privacy-safe fallback: ask me to provide a sanitised export, summaries, or links to several representative work conversations. Do not ask for guest records, credentials, private employee information, or other sensitive data.

## After I select a candidate

When I choose a candidate:

1. summarise the proposed Skill’s purpose and triggering situations;
2. reuse privacy-safe patterns from the analysed history;
3. ask no more than three focused questions if material information is missing;
4. prefer the simplest maintainable architecture;
5. create a concise, production-ready `SKILL.md` with:
   - a clear lowercase, hyphenated name
   - a trigger-focused description
   - operational instructions written for an AI agent
   - relevant workflows, checks, boundaries, and escalation rules

6. add supporting references, scripts, or assets only when they materially improve repeatability or reliability;
7. exclude transcripts, personal information, and unnecessary documentation;
8. clearly separate durable knowledge from facts that must be checked live;
9. provide several sanitised example requests that should trigger the Skill;
10. validate the finished Skill where the platform supports validation.

Offer to install the Skill directly when supported. Otherwise, provide it as a portable artifact suitable for use with AI assistants such as ChatGPT or Claude.

The final Skill must be based on demonstrated work patterns, not generic assumptions about what holiday park staff might need.