Claude Project: Build Your Personal Documentation Assistant

What This Builds

A persistent AI assistant that knows your company's product, style guide, terminology, and documentation standards — so every conversation starts with full context. Instead of re-explaining your product every time you open Claude, your assistant already knows: what your product does, your preferred terminology, your writing style, and your documentation structure. It becomes your always-available documentation co-writer.

Prerequisites

• Claude Pro subscription ($20/month — Claude Projects requires Pro)
• Your company's style guide (or your key terminology and rules, even if informal)
• Your product description and glossary
• Sample documentation pages you've written (these train the style)
• Cost: Claude Pro $20/month (required for Projects)

The Concept

A Claude Project is like giving a new team member a thorough onboarding package before their first day — they already know the product, the audience, and how you like things written. Every conversation you start in the Project automatically includes all that context, so you don't waste time re-explaining basics.

The Project has two parts: Project Instructions (your standing rules and context) and uploaded Knowledge files (your actual documents). Together, they make every Claude conversation in the project context-aware.

Build It Step by Step

Part 1: Gather Your Materials

Collect these before setting up the Project (30 minutes):

a. Product context (1-2 paragraphs) Write a brief description of your product. Include:

• What the product does (2-3 sentences)
• Who uses it (personas: "end users" vs. "admins" vs. "developers")
• Key terminology specific to your product (what you call things)

Example:

[Product Name] is a SaaS project management tool used by software teams. Primary users are: (1) Team Members — individual contributors completing tasks, (2) Managers — team leads who assign work and track progress, (3) Admins — IT professionals who configure the workspace and manage permissions.

Key terminology: "Workspaces" (not "organizations" or "accounts"), "Tasks" (not "tickets" or "items"), "Boards" (not "projects"), "Members" (not "users" or "team members").

b. Style guide key rules (bullet list) Capture your top 10-15 style rules. Don't try to paste your entire style guide — focus on the rules you enforce most often.

c. 2-3 sample documentation pages Pages you've written that represent your documentation at its best. These show the AI your format, tone, and depth preferences.

d. Your glossary (if you have one) A list of terms and their approved definitions.

Part 2: Create the Claude Project

1. Log in to claude.ai
2. Click Projects in the left sidebar
3. Click + New Project
4. Name it something descriptive: "[Company Name] Documentation Assistant" or "Docs AI"

Part 3: Write Your Project Instructions

Click Project Instructions — this is the most important part. This text is added to every conversation automatically.

Here's a template to customize:

You are a documentation assistant for [Company Name], helping write and review technical documentation.

## Product Context
[Paste your 2-3 paragraph product description here]

## Our Documentation Audiences
1. **End Users**: Non-technical, just want to complete their task. Use plain language, numbered steps, no jargon.
2. **Administrators**: Technically literate, need configuration details, permissions, edge cases.
3. **Developers**: Comfortable with APIs and code. Expect code examples, technical parameters.

## Style Rules
- Use second person ("you") for all instructions
- Active voice for all procedural steps ("Click Save" not "Save should be clicked")
- Present tense throughout ("The button turns green" not "The button will turn green")
- Sentence case for headings except H1 page titles
- Oxford comma always
- Use "click" for mouse interactions, "tap" for mobile, "press" for keyboard shortcuts
- Do not use "simply", "easily", "just" — these imply the task is easy and frustrate users who struggle
- Avoid "please" in instructions — it's filler

## Preferred Terminology
Use → Don't Use
[your product term] → [incorrect/deprecated alternatives]
"user ID" → "username", "user name"
"workspace" → "account", "organization", "team"

## Documentation Structure
User help articles: Title, 1-sentence purpose, Prerequisites checklist, numbered steps, related articles
API reference: Description, endpoint, parameters table, example request, example response, error codes
Release notes: What's New, Improvements, Bug Fixes (present tense, plain language)

## When I ask you to:
- "Draft" — write a first version based on what I give you. Prioritize structure over polish.
- "Review" — check my content for style guide compliance and clarity. Return a numbered list of issues.
- "Rewrite for [audience]" — adapt the content for that audience without changing the facts.
- "Clean up" — light editing only: fix grammar, tighten sentences, nothing structural.

Limit your instructions to 500-600 words. Shorter, clearer instructions work better than long exhaustive ones.

Part 4: Upload Knowledge Files

In your Project, click Add Content:

1. Upload your style guide (as text or paste it in): Focus on the sections about terminology, voice, and structure
2. Upload 2-3 sample help articles you've written: These show Claude your format and tone
3. Upload your product glossary if you have one

Each uploaded file becomes searchable context for every conversation.

Part 5: Test with Real Work

Start a conversation in your Project and test these scenarios:

Test 1 — First draft: "Draft a help article for [describe a feature]. Target audience: end users. Include: what it does, how to enable it, the basic workflow."

Review: Does it match your format? Use your terminology? Sound like your documentation?

Test 2 — Style review: Paste a recently written document and ask: "Review this for style guide compliance."

Review: Does it catch your real terminology issues? Is it flagging the right things?

Test 3 — Audience rewrite: Paste your end-user version of something and ask: "Rewrite this for system administrators."

Review: Does the admin version have the right level of technical detail?

Refine your Project Instructions based on what's wrong in these tests.

Real Example: Using Your Project Daily

Monday morning — new feature to document:

You: "A new feature was shipped: bulk export. Users can select multiple items on the Tasks board and export them as CSV or Excel. The export includes all task fields. Max 500 tasks per export. Draft a help article for end users."

Your assistant (knowing your product, style, and format): Generates a properly structured article using "Tasks" not "items", "workspace" not "account", second person, with a Prerequisites section and numbered steps.

Editing time: 10 minutes to verify accuracy and add specific UI details → publish. Without the Project: 45 minutes of writing, style checking, and terminology review.

What to Do When It Breaks

• Claude uses wrong terminology → Add more examples to your Preferred Terminology section. "Use 'Tasks' not 'items', 'tickets', 'cards', or 'work items'" is clearer than just "Use 'Tasks'."
• Output style drifts over time → Re-upload your sample documentation pages. The samples are the strongest signal for style.
• Claude writes too technically / not technically enough → Add to your instructions: "When I specify an audience, match that audience closely. 'End user' means someone who has never read technical documentation before."
• Project Instructions getting too long → Ruthlessly cut. If a rule only comes up once a month, remove it from instructions — add it to individual prompts when needed.

Variations

Simpler version: Skip the Project entirely and keep a "context file" — a Google Doc with your style guide and product description that you paste into the first message of every Claude conversation. Less automated but free.

Extended version: Add your product's help article library as knowledge files. Claude can then cross-reference existing documentation when drafting new content and suggest: "This new article overlaps with [existing article] — should I reference it or consolidate?"

What to Do Next

• This week: Build the Project with your core instructions and test it on 3 real documentation tasks
• This month: Refine instructions based on what you edit most frequently — that's what to add to the instructions
• Advanced: Add your product's release notes history as a knowledge file — Claude can then maintain consistent tone across releases and reference past deprecations when writing new ones

Advanced guide for technical writer professionals. These techniques use more sophisticated AI features that may require paid subscriptions.