Preflight a Beauty and Wellness Intake Form with Claude Code: Stop Consent and Contraindication Gaps

A first-visit form says “sensitive skin,” “pregnant,” or “taking medication,” but the exported CSV buries that line inside a generic note column. The appointment is accepted, the guest arrives, and only then does the staff member discover a condition that needs a different menu, more explanation, a cancellation policy discussion, or a new date. Beauty salons, wellness studios, relaxation services, and personal training gyms often need this small input failure fixed before they need a bigger landing page.

The answer is not to make the form endlessly long. Too many questions increase abandonment, and collecting information without a clear reviewer creates a second problem. The practical goal is to separate booking fields, consent fields, contraindication categories, and staff-only details before any AI-assisted review happens. A contraindication here means a condition such as health status, medication, pregnancy, skin condition, or age that may affect whether staff should pause, change, or decline a service.

This article builds a local preflight workflow for a beauty and wellness intake form with Claude Code. It is deliberately scoped as a preflight and contract check, not a live integration. It does not connect to a form service, booking system, customer database, or email sender. Primary sources checked for current claims include Claude Code permissions, Claude Code settings and sandboxing, Japan’s Personal Information Protection Commission personal information resources, Japan MHLW hygiene guidance for beauty establishments, and Japan Consumer Affairs Agency material on beauty-medical caution. This is not legal, medical, or operational advice for one specific shop.

Key Takeaways

• Split the first-visit form into booking fields, staff-review fields, and fields that should never enter the AI working CSV.
• Let Claude Code read only fictional or redacted local CSV data, then check consent, contraindication categories, reviewer flags, and draft messages.
• People decide service eligibility, health handling, consent wording, personal data treatment, minor consent, refunds, and cancellation rules.
• The three use cases are form-field inventory, CSV-column preflight, and staff confirmation message drafts.
• The single primary CTA points to product templates for readers who want reusable beginner prompt patterns.

Workflow: Separate the Form Before AI Review

Start by separating folders and records. intake-raw/ holds originals: name, phone, email, skin and body notes, medication details, pregnancy details, minor consent, photo permission, and payment-related context. intake-ai-work/ holds the AI working copy: fictional ID, requested menu, visit purpose, consent status, contraindication category, and whether staff review is required. intake-approved/ holds the staff-approved checklist and message.

Material	AI working copy	Staff-only material
Booking form	Requested menu, visit purpose, first/repeat visit	Name, phone, email, address
Intake questions	Contraindication category, caution category	Diagnosis, medication name, detailed condition
Consent text	Consent present, date, required/optional	Final legal and operational wording
CSV export	Column names, blanks, staff-review flag	Identifying data and raw free text
Staff checklist	Reviewer, stop condition, timing	Service eligibility, menu change, refund decision

flowchart TD
  A[intake-raw originals] --> B[Classify columns]
  B --> C[Redact into AI CSV]
  C --> D[Node.js preflight]
  D --> E[Claude Code gap review]
  E --> F[Staff review]
  F --> G[intake-approved checklist]

The important habit is to avoid asking Claude Code to read everything and decide. Reduce the columns first. Free-text intake notes often include names, health details, or family context, so the AI file should use a flag such as sensitive_note_present: true. Staff open the original separately when judgment is needed.

What Claude Code Handles and What People Decide

Claude Code handles missing form fields, risky CSV column names, missing consent flags, missing staff-review flags, and draft wording for staff or guest follow-up. It is suitable for checks like “does the first-visit form include photo permission and cancellation consent?” or “does every row with a contraindication category have staff_review set?”

People decide whether the service should proceed, which menu should change, how health or medication notes should be handled, whether a minor has proper consent, refunds, cancellations, advertising language, and personal-data handling. A Claude Code output that says “no obvious gap” is not a service decision. In beauty and wellness, reassuring language can easily become an overclaim, so final approval stays human.

The official Claude Code permissions page explains that deny, ask, and allow rules are evaluated in that order. The settings page describes sandboxing as a boundary for Bash commands and child processes across filesystem and network access. For intake originals, deny Read(/intake-raw/**) and allow only intake-ai-work/. Treat that as a narrower entry point, not as proof of privacy safety.

Related internal reading: the Claude Code permissions guide and the beauty salon menu explanation workflow pair well with this article. Forms and menu pages should be checked separately because they fail in different places.

Three Use Cases

Use case 1: Inventory first-visit form fields

Input: form field list, required/optional settings, requested menu, consent text, photo permission, cancellation conditions, and questions that require staff review.

Output: booking fields, staff-review fields, fields excluded from AI, short first-visit explanation, and a post-submit caution message.

Human review: service eligibility, contraindication handling, minor consent, photo permission, cancellation/refund conditions, and final consent wording.

The field inventory begins by deciding what to remove. If the first trial form only needs to reserve a slot, deep health questions can move to a staff follow-up. If a condition must always be checked before service, it needs a review flag before the guest arrives.

Use case 2: Check whether risky fields are mixed into the CSV

Input: redacted CSV column names, sample rows, required columns, staff-review flag, and pre-send rules.

Output: allowed columns, blocked columns, blank warnings, rows requiring staff_review, and original fields staff must inspect.

Human review: name, phone, email, address, raw free text, medication, diagnosis, pregnancy, minor status, consent, and photo permission.

CSV exports hide failures better than form screens. A clean form label can become a single note column in export. Before Claude Code reads the file, a local check should stop risky names and simple risky values.

Use case 3: Draft a staff confirmation message

Input: fictional ID, requested menu, review category, appointment date band, staff owner, reply deadline, and the shop’s normal contact channel.

Output: staff confirmation email, guest pre-visit confirmation draft, review checklist, and information that must not be sent.

Human review: recipient, guest name, real health details, service decision, cancellation conditions, refund guidance, and manager approval.

For message drafts, do not ask AI to fill in real personal details. Use “guest A” or “booking B-001,” then let staff check the original before sending. Polite wording is useful only when the decision boundary remains clear.

Copy-Paste Prompt

Use this prompt only after intake-ai-work/intake-redacted.csv has been created. Do not include original forms, customer records, charts, photos, or payment data.

Act as a beauty and wellness first-visit intake form reviewer.
Read only ./intake-ai-work/intake-redacted.csv and output in this order:

1. Columns that may be used by AI and columns that must be stopped
2. Missing consent, photo permission, and cancellation fields
3. Whether rows with contraindication categories have staff_review
4. Fields staff must check in the original record
5. Draft pre-visit confirmation message to the guest
6. Pre-publication checklist

Constraints:
- Do not decide service eligibility, medical issues, or refunds
- Do not infer name, phone, email, address, diagnosis, medication, pregnancy week, or raw free-text notes
- Do not touch intake-raw, customer databases, booking systems, email sending, or external networks
- If you detect personal-data-like values, stop and report only the field name
- End with: "Not sendable before staff review"

Working Check Code

If you introduce this helper, save it as tools/check-beauty-intake-preflight.mjs. This article does not create the file in the repository. The complete contents are below, and the test uses fictional local fixtures only.

const files = [
  {
    path: "intake-ai-work/intake-redacted.csv",
    text: "intake_id,menu,consent,contraindication_category,staff_review\nB-001,trial_facial,true,sensitive_skin,true"
  },
  {
    path: "intake-ai-work/bad.csv",
    text: "name,email,medication_note\nAiko,[email protected],blood pressure medicine"
  }
];

const blockedFields = [
  "name",
  "email",
  "phone",
  "address",
  "birthdate",
  "medication",
  "diagnosis",
  "pregnancy_week",
  "free_note"
];

const valuePatterns = [
  /[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}/,
  /\b\d{2,4}-\d{2,4}-\d{3,4}\b/,
  /\b(?:medicine|diagnosis|pregnant|allergy)\b/i
];

const findings = [];

for (const file of files) {
  const lowerText = file.text.toLowerCase();
  for (const field of blockedFields) {
    if (lowerText.includes(field)) {
      findings.push({ path: file.path, type: "blocked field", field });
    }
  }
  for (const pattern of valuePatterns) {
    if (pattern.test(file.text)) {
      findings.push({ path: file.path, type: "blocked value", pattern: String(pattern) });
    }
  }
}

console.table(findings);
if (findings.length > 0) {
  process.exitCode = 1;
}

This proves only that the local fixed fixtures detect risky field names and simple values. It does not prove PDF handling, image review, handwriting review, re-identification across columns, live form integration, or booking-system behavior.

{
  "permissions": {
    "deny": [
      "Read(/intake-raw/**)",
      "Edit(/intake-raw/**)",
      "Read(/customer-records/**)",
      "Edit(/customer-records/**)",
      "Bash(git push *)"
    ],
    "allow": [
      "Read(/intake-ai-work/**)",
      "Edit(/intake-ai-work/**)",
      "Bash(node tools/check-beauty-intake-preflight.mjs *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./intake-raw", "./customer-records"],
      "denyWrite": ["./intake-raw", "./customer-records"]
    }
  }
}

Pitfall: Common Causes and Concrete Fixes

First cause: making consent one tiny checkbox at the end. Guests cannot tell what they agreed to, and staff cannot track when the text changed. Fix it by separating photo permission, cancellation, health confirmation, and contact method, then exporting the consent text version or update date.

Second cause: collecting contraindications only as free text. Free text looks flexible, but it is hard to search and risky to send to AI. Fix it with category fields and a staff_review flag while keeping details in the original record.

Third cause: assuming a Read deny rule is enough. Bash, child processes, and local helpers can introduce another path to the originals. Fix it by layering Claude Code deny rules, sandbox denyRead and denyWrite, folder operations, and rejection tests with fictional data.

Fourth cause: testing the validator on real booking CSV files. Terminal history and logs can retain values. Fix it by building allow and reject samples with fictional IDs only, and by not printing detected personal values in production logs.

Small ROI Measurement

For the first two weeks, measure only the first-trial intake form. Before the change, record follow-up calls after booking, same-day menu changes, cases stopped by consent explanation, and records staff had to reopen. After the change, record the same numbers and add rows stopped by preflight.

The calculation can stay simple: cases × (confirmation minutes + same-day rework minutes) next to preflight stops. If bookings rise but same-day changes rise too, the form has not aligned expectations. If pre-visit confirmations increase while same-day cancellations fall, the workflow may be doing useful work. Do not invent results; compare the same fields over the same period.

Frequently Asked Questions

Q. Is it safer to remove every health or medication question?

No. Removing necessary service checks can increase operational risk. The goal is to reduce what AI sees while preserving the fields staff need to review.

Q. Are Claude Code permissions enough for personal-data handling?

Do not treat them as enough alone. Permissions create tool boundaries. Combine them with sandboxing, folder separation, logs that avoid values, and staff review.

Q. Can Claude Code rewrite beauty-medical style claims?

It can draft warnings and review notes, but medical advertising and legal review are outside this article. A person should check any effect claim against primary sources and the shop’s rules.

Q. Which form should we start with?

Start with the form where first-trial booking, photo permission, cancellation terms, and health confirmation collide. The form with the most same-day questions is usually a better first target than the form with the highest traffic.

Product Templates

This preflight can start as a small beginner exercise. Create a fictional CSV, confirm that risky columns stop the process, confirm that missing staff_review is visible, and confirm that the output says it is not sendable before staff review.

If you want to reuse the same pattern for menu explanations, FAQ, reply drafts, and publication checks, use the product templates as the single next step. The related beauty salon menu workflow covers price and duration clarity, while the permissions guide covers the access-control basics.

What Was Actually Tested

For this article, I confirmed that /images/hero/hero-024.webp exists at site/public/images/hero/hero-024.webp. I checked the official Claude Code permissions page, settings and sandboxing page, Japan PPC personal information page, MHLW hygiene guidance, and Consumer Affairs Agency beauty-medical caution page.

The JavaScript block represents fictional intake-ai-work/intake-redacted.csv and intake-ai-work/bad.csv as in-memory arrays. It demonstrates a local fixture boundary for field names and simple values. No form service, booking system, customer database, email sender, or real customer data runtime test was run. Publication checks target this slug, frontmatter, internal links, external links, CTA, code fences, ten locale files, and the Qiita article.