How Freelancers Can Use Claude Skills to Turn a Client Intake Form Into a Project Kickoff Brief

Warning: Client intake forms often contain sensitive commercial details. Keep the source package narrow and remove anything you do not need for the kickoff brief.

If Claude Skills is new to you

Start with the Claude Skills explainer page in the site's Tools menu before you run this workflow. The short version is that Skills are reusable instruction bundles Claude can load for repeatable work. The public skills repository also makes good reference material when you want to copy the pattern into a private skill for your own team. For curated examples, see the Claude Skills tool hub and the Anthropic Workflows series.

Problem and who this is for

A client intake form usually answers part of the project question, not all of it. The real job is to turn scattered intake answers, email clarifications, and standard project rules into one clean kickoff brief that the freelancer can work from.

This workflow is for freelancers, consultants, and small agencies who need a usable internal brief before they start delivery.

Prerequisites

• Claude with Skills available.
• The client intake form export, whether that is a form result, a DOCX, a PDF, or pasted text.
• Any follow-up emails that clarified scope, timing, or access.
• Your own default project rules, such as review cycles, handoff format, and client responsibilities.

How to gather the source material

1. Export the intake results into one file. If they live in a form tool plus a spreadsheet plus email, collapse them into one source pack first.
2. Copy the key follow-up email answers into a plain text note if you do not want to upload whole threads.
3. Create one short file called delivery-rules.txt with your standard process, revision limits, handoff format, and response-time assumptions.
4. If the client used vague language, add a note called open-items.txt with the questions that still need answers.
5. Save everything as TXT, DOCX, or PDF in one working folder.

Numbered workflow steps

1) Extract the actual kickoff inputs before you write the brief

Use the doc-coauthoring pattern so Claude first gathers the project facts, decisions, constraints, and open items before it tries to write a polished brief.

{
  "task": "Extract a project kickoff structure from an intake form and onboarding notes",
  "input": {
    "client_intake_form": "ATTACH OR PASTE",
    "follow_up_notes": "ATTACH OR PASTE",
    "delivery_rules": "PASTE delivery-rules.txt",
    "open_items": "PASTE open-items.txt IF USED"
  },
  "rules": [
    "Separate confirmed scope from unanswered questions.",
    "List assumptions and dependencies clearly.",
    "Do not write client-facing sales language.",
    "Do not convert vague requests into commitments."
  ],
  "output": {
    "project_goal": "What success looks like",
    "confirmed_scope": "What is clearly included",
    "constraints": "Deadlines, approvals, access, assets, or dependencies",
    "open_items": "Questions that still need answers",
    "working_assumptions": "Assumptions that belong in the brief"
  }
}

2) Review the extracted material before Claude writes the final deliverable

Edit the open-items list before you draft the brief. A kickoff brief is only useful when it shows what you still need, not when it pretends everything is settled.

3) Draft the final deliverable

{
  "task": "Write a freelancer project kickoff brief from a verified intake map",
  "input": {
    "verified_intake_map": "PASTE THE REVIEWED OUTPUT FROM STEP 1"
  },
  "rules": [
    "Write for the internal delivery team, even if that team is one person.",
    "Use headings for goal, scope, constraints, open items, and first actions.",
    "Keep the brief operational and specific.",
    "End with the first three tasks to start the job."
  ],
  "output_format": {
    "type": "briefing"
  }
}

4) Save the output where you actually work

Keep the final deliverable in the same folder as the source package, or paste it into the system you already use. The value here is repeatability. Once your source files and section order are stable, the next run gets much faster.

Tool-specific instructions

Claude Skills is useful here because a kickoff brief should follow the same frame every time. The public doc-coauthoring skill is the best starting pattern because it is built for structured documents that need context gathering before drafting.

Quality checks

1. The brief separates confirmed scope from open items.
2. All deadlines and dependencies are explicit.
3. The first actions are concrete enough to start work.
4. Nothing in the brief quietly promises work that the client only hinted at.

Common failure modes and fixes

The brief is too salesy

Fix: tell Claude the audience is the delivery side, not the client, and remove persuasive language.

Open items disappear

Fix: require a dedicated open-items section and forbid Claude from smoothing it over.

Too many source files

Fix: collapse the key information into one simple source pack before using the skill.

Sources Checked

• Anthropic Claude Help Center: What are Skills? (accessed 2026-03-23) https://support.claude.com/en/articles/12512176-what-are-skills
• Anthropic Claude Help Center: Use Skills in Claude (accessed 2026-03-23) https://support.claude.com/en/articles/12512180-use-skills-in-claude
• Anthropic Claude Help Center: Creating custom Skills (accessed 2026-03-23) https://support.claude.com/en/articles/12512198-creating-custom-skills
• GitHub: elliepetalmedia/skills README (accessed 2026-03-23) https://github.com/elliepetalmedia/skills
• GitHub: doc-coauthoring skill in elliepetalmedia/skills (accessed 2026-03-23) https://github.com/elliepetalmedia/skills/tree/main/skills/doc-coauthoring

Quarterly Refresh Flag

Review on 2026-06-21 to confirm any updates to Claude Skills, Claude Cowork, file handling, plan availability, and setup paths.