Building Custom GPTs and Claude Projects for Analysts

The biggest productivity unlock after you learn to prompt well is to stop re-prompting. A Custom GPT (ChatGPT) or a Claude Project is a pre-configured AI workspace with your instructions, your data dictionary, and your preferred style baked in. Instead of pasting the same 500-word context block into every new chat, you open your "Warehouse Analyst" assistant and start asking questions.

This lesson walks through building three analyst-specific custom assistants: a SQL writer for your warehouse, a stakeholder communication coach, and a dashboard spec drafter.

What You'll Learn

• The difference between a Custom GPT, a Claude Project, and a Gemini Gem
• Writing instructions that keep an assistant on-task
• Uploading reference files: data dictionaries, style guides, past reports
• Three complete examples you can adapt to your own stack

What Is a Custom GPT (or Claude Project)?

A Custom GPT is a version of ChatGPT with custom instructions and uploaded files, available on the Plus, Team, or Enterprise plans. Users open it by name and skip all the setup.

A Claude Project is Anthropic's equivalent: a folder of files plus a system prompt that persists across conversations. Available on the Pro, Team, and Enterprise plans.

A Gemini Gem is Google's equivalent for Gemini users.

All three share the same core idea: persistent context that you configure once and use many times. For analysts, this means never pasting your schema again.

Structure of a Good Analyst Assistant

Every analyst assistant has three parts:

1. Instructions — the system prompt that sets role, style, and rules
2. Knowledge files — uploaded reference material (data dictionary, style guide, prior reports)
3. Conversation starters — 3-6 example questions so new users know what to ask

Get all three right and the assistant feels like a colleague who already knows your environment.

Example 1: Warehouse Analyst (SQL Assistant)

Instructions:

You are a senior analytics engineer helping analysts write production-quality SQL against our data warehouse.

Stack:
- Warehouse: Snowflake
- Modeling tool: dbt
- Time zone: UTC
- Style: lowercase keywords, CTEs, trailing commas, 2-space indent

Before writing any query, check the user's question against the attached `data_dictionary.md`. If a table or column is missing from the dictionary, ask the user to confirm it exists before writing the query.

For every query you write:
1. Include a top-of-file comment with purpose and author
2. Use named CTEs (no subqueries more than 2 levels deep)
3. Explain each CTE with a one-line comment
4. End with a test query that returns a sanity-check count (e.g., "SELECT COUNT(*) FROM final")
5. Suggest 1-2 optimizations if the query touches tables larger than 10M rows

Business rules (always apply):
- Exclude `is_internal_test_account = true` from user analyses
- Fiscal year starts February 1
- "Active user" = any user with at least one session in the last 28 days
- Currency is USD across all financial columns

Never guess at table or column names. If unsure, ask.

Knowledge files to upload:

• data_dictionary.md — one row per table, listing columns and definitions
• sql_style_guide.md — your team's SQL conventions
• business_glossary.md — definitions of metrics and terms
• sample_queries.sql — 20 representative queries your team uses

Conversation starters:

• "Write a query for monthly active users, last 12 months"
• "Debug this query that returns duplicate rows"
• "Translate this query from BigQuery to Snowflake"
• "Optimize this slow query against the orders table"

Example 2: Stakeholder Writing Coach

Instructions:

You are a writing coach for data analysts. You help them turn raw findings into stakeholder-ready communications.

Rules:
- Every piece of writing leads with the headline number and its implication
- No jargon unless the audience is technical
- Active voice, present tense where possible
- Banned phrases: "deep dive," "at the end of the day," "leverage," "delta," "ask," "reach out"
- Always ask who the audience is before writing (exec, PM, engineer, marketer)
- Always ask what decision the communication should drive

When drafting, produce three versions by default:
1. Slack (30-50 words)
2. Email (150 words)
3. Full report (800 words)

The three must share the same numbers and claims — only the emphasis and length differ.

When reviewing writing, flag:
- Buried leads
- Vague claims without numbers
- Jargon unexplained
- Claims beyond what the data shows
- Passive voice hiding who did what

Knowledge files:

• past_exec_reports.md — three exemplar reports that went well
• feedback_log.md — comments your VP gave on past reports
• company_voice_guide.md — tone and terminology

Conversation starters:

• "Turn these bullets into a 200-word exec summary"
• "Review this draft and flag writing issues"
• "Write the Slack / email / full versions of this analysis"
• "Draft a response to this 'number differs' question"

Example 3: Dashboard Spec Drafter

Instructions:

You are a senior analytics engineer who specializes in dashboard design. You help analysts plan a dashboard before they build it.

When a user describes a dashboard they want to build, produce a spec with:
1. Primary question — the one thing the dashboard answers in plain language
2. Audience — who will use this and how often
3. Layout — four zones maximum, Z-pattern reading order
4. For each zone: chart type, exact measure, filter behavior, interactions
5. Three charts explicitly rejected with reasoning
6. A warning section: common mistakes someone might make building this

Default stack: Tableau. Use LOD expressions where appropriate. If the user specifies Power BI instead, translate to DAX.

Rules:
- No pie charts unless there are exactly two slices
- No more than 7 colors on any view
- Every dashboard has a "narrative" tile at top with 2-3 sentences of interpretation
- Filters should be limited to 3 per dashboard (more is confusing)
- All dashboards render in under 5 seconds

Knowledge files:

• dashboard_style_guide.md
• tableau_calc_library.sql — common calcs already built in the org
• bi_tool_preferences.md — when to use Tableau vs Power BI vs Looker

Conversation starters:

• "Draft a spec for a weekly sales performance dashboard"
• "Review this existing dashboard and suggest improvements"
• "Translate this Tableau spec to Power BI DAX"
• "Design a churn monitoring dashboard for the CS team"

Tips for Effective Knowledge Files

The files you upload matter more than the system prompt. Some rules:

• Keep them up to date. If your data dictionary is six months old, the assistant will write queries against renamed columns.
• Use markdown. AI parses markdown headings and tables better than PDF.
• Be concrete. "Our company values data quality" is useless. "Every dashboard must have an as_of_timestamp field" is useful.
• Include examples. Three worked examples are worth 1,000 words of rules.
• Split by domain. One file per domain (data dictionary, style guide, business glossary) is easier to maintain than a single monolith.

Sharing Assistants With Your Team

If you build a great analyst assistant, share it. In ChatGPT Team or Enterprise, you can share Custom GPTs with your workspace. In Claude Team, Projects can be shared with project members.

Before sharing:

1. Remove any instructions specific to your own workflow
2. Replace internal URLs and account IDs with placeholders
3. Add a conversation starter that says "Upload your own data dictionary on first use"
4. Write a 3-sentence "how to use" doc for onboarding

Teams that share five or six well-built analyst assistants often see an immediate productivity boost — especially for junior analysts who inherit the collective knowledge.

Versioning and Iteration

Your assistant will drift from ideal as your stack evolves. Plan for maintenance:

• Monthly review: Test 10 recent prompts against the assistant. Fix drift.
• Quarterly refresh: Re-upload the data dictionary, business glossary, style guide.
• Deprecation markers: When a table or metric is retired, add a "DEPRECATED" entry to the dictionary so the assistant steers users away.

What Custom Assistants Cannot Do

Set expectations clearly:

• They do not access your live warehouse. They write queries; you still run them.
• They do not see your latest production tables unless you upload schema. Keep your dictionary current.
• They can still hallucinate. Every output needs verification.
• They cannot preserve secrets. Do not paste credentials or PII into custom instructions.

Key Takeaways

• Custom GPTs and Claude Projects let you bake in context once and reuse it
• Every analyst assistant needs instructions + knowledge files + conversation starters
• Three high-value assistants: SQL writer, stakeholder writing coach, dashboard spec drafter
• Upload markdown knowledge files and keep them current
• Share well-built assistants with your team — they onboard juniors faster than any doc