Project

General

Profile

Actions
Copy link

Support #105

open
RG RG

Learning Claude

Support #105: Learning Claude

Added by Rajesh Gotur 22 days ago.

Status:
New
Priority:
Normal
Assignee:
Rajesh Gotur
Target version:
Canofy Process Standardization & Refactoring - Sprint 01 (01 Jul - 31Jul)
Start date:
09/28/2026
Due date:
% Done:

30%

Estimated time:
Spent time:
6:00 h

Description

Claude Learning Roadmap

Claude, Claude Code, Connectors, MCP, Skills, Context Management & Artifacts

A structured, hands-on learning guide for learning Claude as a user, developer, and AI-workflow builder.

This guide is designed to take you from using Claude effectively to building reusable Claude workflows, including:

  • Claude fundamentals
  • Claude Code
  • Prompting and agentic workflows
  • CLAUDE.md and persistent project context
  • Context-window management
  • Projects and project knowledge
  • Connectors
  • Model Context Protocol (MCP)
  • Claude Skills
  • Custom skill creation
  • Skill packaging and testing
  • Artifacts
  • Claude Docs / Design / Slides workflows
  • Files and code execution
  • Subagents and multi-agent workflows
  • Permissions and safe execution
  • Automation-oriented workflows
  • A final capstone project

The terminology and feature descriptions in this guide are based primarily on Anthropic's official documentation and Claude Help Center material available as of September 30, 2026.

1. What You Are Actually Learning

Claude is easier to understand when its capabilities are separated into layers.

                           CLAUDE ECOSYSTEM
                                  |
        ┌─────────────────────────┼─────────────────────────┐
        |                         |                         |
        v                         v                         v
   Claude Chat               Claude Code                Claude API
        |                         |                         |
        |                         |                         |
        v                         v                         v
   Projects                 CLAUDE.md                    Tools
   Skills                   Skills                       MCP
   Connectors               MCP                          Agents
   Artifacts                Subagents                    Applications
   Files                    Permissions
        |                         |
        └──────────────┬──────────┘
                       |
                       v
              Context + Tools + Procedures
                       |
                       v
              Reliable AI Workflows

The most important conceptual distinction is:

Knowledge       = information Claude can use
Instructions    = rules Claude should follow
Tools           = capabilities Claude can invoke
Connectors/MCP  = access to external systems
Skills          = reusable procedures
Artifacts       = reusable outputs
Memory/Context  = information retained or supplied across work

2. The Learning Path

Do not try to learn everything simultaneously.

Use this sequence:

LEVEL 1
Claude Fundamentals
        |
        v
LEVEL 2
Prompt Engineering
        |
        v
LEVEL 3
Files + Projects + Context
        |
        v
LEVEL 4
Claude Code
        |
        v
LEVEL 5
CLAUDE.md + Memory
        |
        v
LEVEL 6
MCP + Connectors
        |
        v
LEVEL 7
Skills
        |
        v
LEVEL 8
Artifacts
        |
        v
LEVEL 9
Agents + Subagents + Automation
        |
        v
LEVEL 10
Capstone: Build Your Own Claude Workflow

3. Learning Objectives

By the end of this roadmap, you should be able to:

  • write strong prompts for Claude;
  • provide the right context without overloading the model;
  • organize a project using Claude Projects;
  • understand the difference between project knowledge and conversation context;
  • use Claude Code to inspect and modify a real repository;
  • create and maintain CLAUDE.md;
  • manage context across long coding sessions;
  • connect Claude to external applications;
  • understand MCP as the protocol behind tool/data connections;
  • configure MCP servers in Claude Code;
  • understand the difference between connectors, MCP and skills;
  • create a custom Claude Skill;
  • design a good skill.md;
  • use progressive disclosure in a Skill;
  • add reference files and scripts to a Skill;
  • package and test a Skill;
  • create and iterate on Artifacts;
  • build documents, code, dashboards and interactive outputs;
  • combine Skills + MCP + Projects + Artifacts;
  • design safer agentic workflows;
  • create a complete reusable Claude development workflow.

4. The Core Mental Model

A useful model is:

                    ┌──────────────────┐
                    │      Claude      │
                    └────────┬─────────┘
                             |
        ┌────────────────────┼────────────────────┐
        |                    |                    |
        v                    v                    v
     Context              Tools              Procedures
        |                    |                    |
        v                    v                    v
  Projects / Files       MCP / Connectors       Skills
  CLAUDE.md              APIs / Services        Workflows
  Conversation           External systems       Instructions
        |                    |                    |
        └────────────────────┼────────────────────┘
                             |
                             v
                         Output
                             |
                             v
                         Artifact

Think of Claude as the reasoning layer.

The other capabilities determine:

  • what Claude knows;
  • what Claude can access;
  • what Claude is allowed to do;
  • how Claude should perform a recurring task;
  • what Claude produces for reuse.

5. LEVEL 1 — Claude Fundamentals

5.1 Start With Normal Claude Chat

Before learning Claude Code, understand how Claude responds to:

  • direct questions;
  • structured instructions;
  • files;
  • long documents;
  • iterative corrections;
  • multi-step tasks.

Start with simple prompts.

Exercise 1

Ask:

Explain REST APIs to me as if I am a Python developer.

Then ask:

Now explain the same concept using a real Frappe example.

Then:

Now give me a small implementation exercise.

Observe how the conversation becomes progressively more contextual.

6. Prompt Engineering

A useful prompt structure is:

ROLE
What should Claude act as?

CONTEXT
What does Claude need to know?

TASK
What exactly should Claude do?

CONSTRAINTS
What must it and must it not do?

INPUT
What files/data should it use?

OUTPUT
What exact format should it produce?

VALIDATION
How should the result be checked?

Example:

You are a senior Python developer.

Context:
This project is a Frappe application that parses Shipping Bill PDFs.

Task:
Review the parser and identify extraction failures.

Constraints:
- Do not rewrite working logic unnecessarily.
- Preserve existing Frappe field names.
- Do not invent values.
- Test text-based and OCR-based PDFs.

Input:
Use the files in the current project.

Output:
1. Issue list
2. Root cause
3. Proposed fix
4. Regression tests
5. Final verification

The important lesson is that a good prompt gives Claude a working environment, not merely a question.

7. Prompt Iteration

Learn to separate:

Prompt 1 = Understand
Prompt 2 = Plan
Prompt 3 = Implement
Prompt 4 = Test
Prompt 5 = Review
Prompt 6 = Refine

For complex development work, avoid immediately saying:

"Fix everything."

Instead:

1. Inspect the project.
2. Identify the architecture.
3. List the relevant files.
4. Explain the current behaviour.
5. Identify the failure.
6. Propose a minimal fix.
7. Implement it.
8. Run tests.
9. Review the diff.
10. Report remaining risks.

This becomes especially important when using Claude Code.

8. LEVEL 2 — Files and Context

Claude can work with files, documents, spreadsheets and code.

The important skill is not simply uploading files.

The important skill is deciding:

What does Claude actually need?

Bad Context Strategy

Upload everything
       |
       v
Ask one question

This can produce unnecessary context.

Better Context Strategy

Question
   |
   v
Identify required evidence
   |
   v
Provide relevant files
   |
   v
Ask Claude to inspect only what matters
   |
   v
Validate answer against source

9. Context Window

The context window is the working information Claude can use for a task.

Think of it as:

┌─────────────────────────────────────┐
│             CONTEXT                 │
│                                     │
│ System instructions                 │
│ Project instructions                │
│ Conversation                        │
│ Files                               │
│ Tool results                        │
│ MCP results                         │
│ Skill instructions                  │
│ Current task                        │
│                                     │
└─────────────────────────────────────┘

More context is not automatically better.

The goal is:

Maximum relevant context
+
Minimum irrelevant context

10. Context Management

For long tasks, maintain explicit state.

Useful files include:

progress.md
tasks.md
tests.json
decisions.md
README.md

Example:

project/
├── CLAUDE.md
├── progress.md
├── tasks.md
├── tests.json
├── decisions.md
└── src/

progress.md

# Current Progress

## Completed
- Parser architecture reviewed
- OCR detection implemented
- Text extraction regression tests passed

## In Progress
- Duplicate item handling

## Blocked
- One sample PDF has corrupted OCR

## Next
- Test aggregation logic
- Run complete regression suite

tests.json

{
  "tests": [
    {
      "id": "SB-001",
      "description": "Text PDF extraction",
      "status": "passed"
    },
    {
      "id": "SB-002",
      "description": "OCR PDF extraction",
      "status": "in_progress"
    }
  ]
}

Structured state is useful for facts and test status; free-form notes are useful for general progress.

11. Context Across Long Tasks

For long-running development tasks:

Context Window 1
    |
    +--> Understand project
    +--> Build framework
    +--> Create tests
    |
    v
Save state
    |
    v
Context Window 2
    |
    +--> Read state
    +--> Verify existing work
    +--> Continue
    |
    v
Context Window 3
    |
    +--> Regression testing
    +--> Final review

Do not depend entirely on conversation history.

Make important state discoverable in files.

12. LEVEL 3 — Claude Projects

Claude Projects provide a focused workspace containing:

  • project chats;
  • project knowledge;
  • project instructions;
  • project files.

A useful mental model:

Claude Project
│
├── Project Instructions
│
├── Project Knowledge
│   ├── Requirements
│   ├── Manuals
│   ├── Architecture
│   └── Reference files
│
└── Project Chats

Project knowledge is reusable across chats in the project.

Important distinction:

Conversation context
        !=
Project knowledge

Information in one project chat is not automatically shared with another chat unless it is placed into project knowledge.

13. Project Instructions

Use project instructions for stable behaviour.

Example:

This project is a Frappe development project.

Always:
- preserve existing field names;
- avoid unnecessary rewrites;
- inspect existing implementation before modifying;
- test changes;
- report exact files changed;
- distinguish verified facts from assumptions.

Do not put every piece of project information into the instructions.

Use:

Instructions = behaviour
Knowledge     = information

14. Project Knowledge

Good project knowledge:

README.md
architecture.md
requirements.md
API specification
database schema
business rules
reference manuals
sample payloads
test cases

Avoid using project knowledge as a random file dump.

Organize it.

15. LEVEL 4 — Claude Code

Claude Code is the development-oriented environment for working with repositories and the local development environment.

Official installation documentation currently describes supported environments including macOS, Linux and Windows through WSL or Git for Windows, and recommends checking the installation with:

claude doctor

A standard workflow is:

cd your-project
claude

16. First Claude Code Session

After opening a repository:

You are new to this repository.

Do not modify anything yet.

First:
1. Inspect the directory structure.
2. Identify the main application entry points.
3. Identify configuration files.
4. Identify tests.
5. Identify build/run commands.
6. Explain the architecture.
7. Tell me what you need to know before making changes.

This is a better first step than immediately asking Claude to rewrite code.

17. Claude Code Basic Workflow

Open repository
      |
      v
claude
      |
      v
Inspect
      |
      v
Plan
      |
      v
Implement
      |
      v
Test
      |
      v
Review
      |
      v
Commit / Deliver

18. Useful Claude Code Commands

Common command-line patterns include:

claude

Start an interactive session.

claude "explain this project"

Start with an initial prompt.

claude -p "explain this function"

Run a non-interactive query.

claude -c

Continue the most recent conversation.

claude --continue

Continue the most recent session.

claude --resume <session-id>

Resume a specific session.

claude mcp

Manage MCP servers.

claude doctor

Diagnose installation/configuration issues.

The exact available commands/options can change, so use the current Claude Code CLI reference when working from the latest installation.

19. Claude Code Permissions

Claude Code can interact with the local environment.

That means permission management matters.

Think:

Read
 |
 +--> Safe inspection

Write
 |
 +--> Code changes

Execute
 |
 +--> Tests / scripts / commands

External system
 |
 +--> Potentially irreversible action

Do not automatically grant unrestricted permissions.

For destructive or external operations:

Inspect
   |
   v
Explain intended action
   |
   v
Confirm
   |
   v
Execute
   |
   v
Verify

20. CLAUDE.md

CLAUDE.md is one of the most important concepts to learn in Claude Code.

It acts as project-level memory/instructions.

Think of it as:

"How should Claude work in this repository?"

Example:

# Project Instructions

## Project
Frappe Shipping Bill Parser

## Architecture
- Python parser
- Frappe integration
- OCR fallback

## Rules
- Do not change Frappe field names.
- Preserve working extraction logic.
- Never invent PDF values.
- Add regression tests for parser changes.

## Commands
Run tests with:
python -m pytest

Run application:
bench start

21. Where CLAUDE.md Can Live

Claude Code can use memory at different scopes.

Conceptually:

~/.claude/CLAUDE.md
        |
        v
Personal instructions across projects

repo/CLAUDE.md
        |
        v
Project instructions

repo/subdirectory/CLAUDE.md
        |
        v
More specific instructions

More specific project context can apply when Claude works in that part of the repository.

Use /memory in Claude Code to inspect/manage memory files.

Use:

/init

to have Claude inspect a repository and draft an initial CLAUDE.md.

22. CLAUDE.md vs Prompt

Use a prompt for:

What I want now

Use CLAUDE.md for:

How this project should always be handled

Example:

Prompt

Fix the invoice parser.

CLAUDE.md

Never modify invoice field names.
Always run parser regression tests.
Do not replace working extraction logic without verification.

23. CLAUDE.md vs Project Knowledge

A useful distinction:

Feature Best Used For
Prompt Current task
CLAUDE.md Persistent coding/project instructions
Project knowledge Reference information
Conversation Current reasoning/context
Skill Repeatable specialized procedure
MCP/Connector External tools/data
Artifact Reusable output

24. LEVEL 5 — Context Management in Claude Code

For long tasks, ask Claude to maintain explicit state.

Example:

Before making changes:
1. Read CLAUDE.md.
2. Read progress.md.
3. Read tests.json.
4. Inspect git status.
5. Summarize current state.
6. Continue from the existing state.

When approaching a context boundary:

Before continuing:
1. Save current progress.
2. Update tests.json.
3. Update progress.md.
4. Record important decisions.
5. Record unresolved issues.
6. Then continue implementation.

This creates a persistent external state layer.

25. Context Compaction

Long Claude Code tasks can span context windows.

The important principle is:

Do not stop because the current context is getting large.

Save important state externally.
Then continue from the saved state.

A strong long-running project might maintain:

CLAUDE.md
progress.md
tests.json
decisions.md

This gives Claude a recovery point.

26. Context-Efficient Prompting

Instead of:

Read everything and fix the project.

Use:

First inspect:
- src/parser.py
- tests/test_parser.py
- README.md

Then identify the smallest set of additional files required.
Do not load unrelated files.

This improves signal-to-noise.

27. LEVEL 6 — Connectors

Connectors allow Claude to access external applications and services.

Examples can include services such as:

  • Google Drive;
  • Slack;
  • Linear;
  • Notion;
  • GitHub;
  • project-management systems;
  • other supported applications.

The key concept is:

Claude
   |
   v
Connector
   |
   v
External Application

The connector gives Claude access to data/actions provided by that service.

28. Connector Permissions

A crucial rule:

Claude does not become more privileged than you.

Connectors inherit the user's permissions from the connected service.

If you cannot access a file in the source system, the connector should not give Claude access to it.

Therefore:

Your permission
      |
      v
Connected service
      |
      v
Connector
      |
      v
Claude

This is fundamentally different from simply uploading a file.

29. Connectors vs File Uploads

File Upload

You
 |
 v
Upload file
 |
 v
Claude context

Connector

You
 |
 v
Connected application
 |
 v
Connector
 |
 v
Claude

Connector data can be retrieved through supported tools rather than manually uploading every source.

30. LEVEL 7 — MCP

MCP stands for:

Model Context Protocol

Anthropic describes MCP as an open protocol that standardizes how applications provide context to LLMs.

A useful analogy:

USB-C
  |
  +--> Standard connection between devices

MCP
  |
  +--> Standard connection between AI systems and tools/data

31. MCP Architecture

┌─────────────────┐
│     Claude      │
│     Client      │
└────────┬────────┘
         |
         | MCP
         v
┌─────────────────┐
│   MCP Server    │
└────────┬────────┘
         |
         +----> Database
         |
         +----> API
         |
         +----> Files
         |
         +----> SaaS application
         |
         +----> Internal system

MCP can expose:

  • tools;
  • resources;
  • prompts;
  • other structured capabilities depending on the server/client implementation.

32. Connector vs MCP

These concepts are related but not identical.

Connector
    =
A product-level integration that lets Claude access a service.

MCP
    =
A protocol for connecting AI applications to tools/context providers.

A prebuilt Claude connector may use MCP-based infrastructure, while Claude Code can also connect directly to MCP servers.

33. MCP in Claude Code

Claude Code can configure MCP servers.

Example pattern:

claude mcp add --transport http server-name https://example.com/mcp

A project-scoped MCP server can be represented through:

.mcp.json

Project-scoped MCP configuration is useful when a repository needs the same tools across team members.

Claude Code requests approval before using project-scoped servers from project configuration.

34. MCP Scopes

Think about scope as:

Local
  |
  +--> Only this project/session environment

Project
  |
  +--> Shared with a project/repository configuration

User
  |
  +--> Available across your projects

Use project scope when the repository depends on a particular MCP service.

Use user scope for personal tools that should be available across projects.

35. MCP Practical Exercise

Create a small mental model first.

Imagine:

Internal Inventory API

You want Claude to answer:

How many laptops are currently in stock?

Without MCP:

Claude
  |
  X
Cannot directly access inventory

With MCP:

Claude
  |
  v
inventory MCP server
  |
  v
Inventory API
  |
  v
Stock result

The AI reasons about the question; the MCP server provides the controlled capability.

36. LEVEL 8 — Skills

A Skill is a reusable package of:

  • instructions;
  • reference material;
  • scripts;
  • resources;
  • sometimes dependencies.

Claude Skills use progressive disclosure.

Claude does not need to load every detail of every skill into context immediately.

Instead:

Available Skills
      |
      v
Task arrives
      |
      v
Which Skill is relevant?
      |
      v
Load relevant Skill
      |
      v
Load additional resources if required
      |
      v
Execute workflow

37. Skills vs Projects

This distinction is extremely important.

Projects Skills
Persistent workspace Reusable procedure
Project knowledge Specialized workflow
Background information How to perform a task
Usually tied to a project Can work across projects
Static context Dynamically activated
"Know this project" "Perform this task this way"

Example:

Project

Shipping Bill Parser Project

contains:

architecture
requirements
PDF samples
field mappings
business rules

Skill

Shipping Bill Parser Review Skill

contains:

Inspect parser
Check text extraction
Check OCR extraction
Compare against expected fields
Run regression tests
Report failures

38. Skills vs MCP

Another critical distinction:

Skill
=
How to perform a workflow.

MCP
=
How Claude accesses a tool/service.

They work well together.

Example:

Skill:
"Create a Jira story according to our company standard."

        +

MCP:
"Provides Jira access."

        =

Claude can follow the company's story-writing procedure
while using Jira tools to create the issue.

39. Skill Structure

A minimal custom Skill contains:

my-skill/
└── skill.md

The skill.md must begin with YAML frontmatter containing:

---
name: My Skill
description: What the skill does and when Claude should use it.
---

The description is especially important because Claude uses it to determine when the Skill is relevant.

40. Skill Metadata

Required:

---
name: Professional README Generator
description: Generate structured project README files from source code, requirements, and project discussions.
---

Optional metadata can include dependencies.

Example:

---
name: Data Analysis Skill
description: Analyze CSV datasets and create validated summaries and charts.
dependencies: python>=3.10, pandas>=2.0
---

41. Skill Progressive Disclosure

Do not put everything into skill.md.

Instead:

my-skill/
│
├── skill.md
│
├── references/
│   ├── style-guide.md
│   ├── examples.md
│   └── schema.md
│
└── scripts/
    ├── validate.py
    └── generate.py

The main Skill tells Claude:

What this Skill does
When to use it
How to execute the workflow
Where additional resources are

Detailed reference material can live separately.

42. Good Skill Design

A good Skill should:

  • solve a specific repeatable problem;
  • have clear instructions;
  • explain when it should be used;
  • include examples when useful;
  • avoid unrelated workflows;
  • use progressive disclosure;
  • keep skill.md focused.

Bad Skill:

Do everything related to software development.

Better:

Generate a Jira story and project README from a completed development conversation.

43. Skill Design Pattern

Use this structure:

---
name: ...
description: ...
---

# Purpose

...

# When to Use

...

# Inputs

...

# Workflow

## 1. Inspect
## 2. Analyze
## 3. Plan
## 4. Generate
## 5. Validate
## 6. Deliver

# Rules

...

# Output Format

...

# References

See:
- references/...

# Scripts

Use:
- scripts/...

44. Your README/Jira Skill Example

A useful personal Skill based on the kind of workflow you are learning could be:

project-documentation-generator/
│
├── skill.md
│
├── references/
│   ├── jira-format.md
│   ├── readme-format.md
│   ├── diagrams.md
│   └── quality-checklist.md
│
└── scripts/
    └── validate_markdown.py

The Skill could instruct Claude to:

1. Read the complete project discussion.
2. Inspect supplied files.
3. Identify project purpose.
4. Decide whether one or multiple stories are required.
5. Extract actual implementation details.
6. Separate implemented vs planned behaviour.
7. Generate Jira story.
8. Generate README.
9. Add diagrams.
10. Validate the Markdown.

This is exactly the type of repeatable workflow that Skills are intended to capture.

45. Creating Your First Skill

Step 1 — Choose One Repetitive Task

Do not start with:

"My AI assistant Skill"

Start with:

"Generate professional Jira stories from completed project work."

Step 2 — Define Trigger

Example:

Use this Skill when the user asks for a Jira story or README based on an existing project implementation or conversation.

Step 3 — Define Inputs

- conversation
- source files
- project documentation
- requirements
- test results

Step 4 — Define Workflow

Inspect
→ Analyze
→ Classify
→ Generate
→ Validate

Step 5 — Add Reference Files

Move detailed formatting rules into:

references/

Step 6 — Add Validation

Use scripts where deterministic checks are useful.

46. Testing a Skill

Before uploading:

1. Review skill.md
2. Check YAML frontmatter
3. Verify description
4. Verify referenced files
5. Run validation
6. Test example prompts

After adding the Skill to Claude:

1. Enable Skill
2. Test a matching request
3. Test a non-matching request
4. Check whether Claude activates it appropriately
5. Inspect output quality
6. Improve description/instructions

Test both:

Positive trigger

and:

Negative trigger

A good Skill should not activate for unrelated tasks.

47. Skill Packaging

A Skill can be packaged as a ZIP.

Expected structure:

my-skill.zip
└── my-skill/
    ├── skill.md
    ├── references/
    └── scripts/

Do not create:

my-skill.zip
├── skill.md
├── references/
└── scripts/

when the expected package requires the Skill folder as the ZIP root.

48. Skill Dependencies

Advanced Skills can contain executable scripts.

For example:

scripts/
├── validate.py
├── parse.py
└── generate.py

Dependencies can be documented in Skill metadata.

Claude/Claude Code can work with standard Python/npm dependencies depending on the execution environment and product.

49. LEVEL 9 — Artifacts

Artifacts are reusable outputs Claude creates.

Examples:

  • documents;
  • code;
  • dashboards;
  • diagrams;
  • interactive tools;
  • designs;
  • presentations.

A useful mental model:

Conversation
     |
     v
Claude creates output
     |
     v
Artifact
     |
     +--> Edit
     +--> Iterate
     +--> Reuse
     +--> Share
     +--> Publish where supported

Artifacts are different from ordinary chat text because they are designed to stand on their own and be revisited.

50. When Should Claude Create an Artifact?

Ask for an Artifact when the result is:

Significant
+
Self-contained
+
Reusable
+
Likely to be edited

Examples:

"Create a project dashboard."
"Create a reusable HTML calculator."
"Create a professional project specification."
"Create an interactive tracker."
"Create a presentation."

51. Artifact Workflow

flowchart LR
    A["Conversation"] --> B["Request Artifact"]
    B --> C["Claude Creates Artifact"]
    C --> D["Review"]
    D --> E{"Needs Changes?"}
    E -->|Yes| F["Edit with Claude"]
    F --> D
    E -->|No| G["Reuse / Share / Export"]

52. Artifacts vs Markdown Response

Normal response

Claude
  |
  v
Chat message

Artifact

Claude
  |
  v
Self-contained output
  |
  +--> Edit
  +--> Iterate
  +--> Save
  +--> Share

For large reusable outputs, an Artifact is often a better mental model than a long chat response.

53. Artifact Storage

Current Claude documentation describes an Artifacts area where created artifacts can be found again.

This makes Artifacts useful as a personal collection of:

documents
dashboards
tools
designs
presentations
code outputs

54. Artifacts + Connectors

Artifacts can connect to supported connected applications on eligible plans.

Conceptually:

Artifact
   |
   v
Connector
   |
   v
External Application
   |
   v
Live / retrieved data

This creates a powerful combination:

Artifact
+
Connector
=
Interactive output using external data

For example:

Slack data
   |
   v
Connector
   |
   v
Claude
   |
   v
Interactive project dashboard Artifact

55. Artifacts + Storage

Current Claude documentation also describes data storage for eligible new Artifacts.

Examples:

Personal tracker
Shared leaderboard
Journal
Inventory tracker
Small application

Important:

Personal storage
     !=
Shared storage

Before using an Artifact with sensitive information, understand whether the data is personal or shared.

56. Claude Docs

Claude Docs are a newer Artifact-oriented document workflow.

You can ask Claude to create a living document and then:

  • edit it;
  • ask Claude for revisions;
  • add comments;
  • share it;
  • export it.

A useful workflow is:

Conversation
   |
   v
Draft
   |
   v
Claude Doc
   |
   +--> Human edits
   |
   +--> Claude edits
   |
   +--> Review
   |
   v
Final document

57. LEVEL 10 — Combining Everything

The real value appears when these capabilities are combined.

Example:

AI Project Documentation System

Git Repository
      |
      v
Claude Code
      |
      +--> CLAUDE.md
      |
      +--> Project files
      |
      +--> MCP / GitHub
      |
      v
Analyze implementation
      |
      v
Documentation Skill
      |
      +--> Jira format
      +--> README format
      +--> diagrams
      |
      v
Artifact / Markdown
      |
      v
Jira / Confluence Connector
      |
      v
Published documentation

Each capability has a different job.

58. Skills + MCP Example

Suppose you create:

jira-story-generator

Skill:

How to analyze a development task and write the story.

MCP:

How Claude accesses Jira.

Combined:

User:
Create a Jira story for the completed parser feature.

Claude
 |
 +--> Skill
 |      |
 |      +--> Analyze requirements
 |      +--> Determine story structure
 |      +--> Generate acceptance criteria
 |
 +--> Jira MCP
        |
        +--> Find project
        +--> Create issue
        +--> Attach documentation

The Skill controls the procedure.

The MCP server provides the capability.

59. Projects + Skills + MCP

A professional Claude workspace can look like:

PROJECT
│
├── Project Knowledge
│   ├── Architecture
│   ├── Requirements
│   └── Reference docs
│
├── Project Instructions
│   └── CLAUDE.md-like behavioural rules
│
├── Skills
│   ├── Documentation
│   ├── Testing
│   └── Release Notes
│
└── MCP
    ├── GitHub
    ├── Jira
    └── Database

Then:

Claude
  |
  +--> Project context
  |
  +--> Relevant Skill
  |
  +--> MCP tools
  |
  +--> Current conversation
  |
  v
Completed workflow

60. Claude Code + Skill + MCP

A coding workflow can become:

Developer
   |
   v
Claude Code
   |
   +--> CLAUDE.md
   |
   +--> Repository
   |
   +--> Skill
   |      |
   |      +--> Coding workflow
   |      +--> Testing workflow
   |
   +--> MCP
          |
          +--> GitHub
          +--> Jira
          +--> Database
   |
   v
Plan → Code → Test → Review → Deliver

61. Skills vs Slash Commands

Do not confuse every reusable prompt with a Skill.

A useful distinction:

Prompt
  = one-off instruction

Slash command
  = explicit command/invocation

Skill
  = reusable specialized workflow that Claude can load when relevant

MCP prompt
  = prompt exposed by an MCP server

MCP tool
  = external capability exposed to Claude

62. Subagents

For complex Claude Code work, specialized agents can divide work.

Example:

                Main Agent
                    |
       ┌────────────┼────────────┐
       |            |            |
       v            v            v
   Code Agent    Test Agent   Review Agent
       |            |            |
       v            v            v
 Implementation   Tests      Quality review
       |            |            |
       └────────────┼────────────┘
                    v
               Main Agent

Use subagents when tasks are naturally separable.

Do not create agents merely to make a simple task look complex.

63. Agentic Workflow

A reliable agentic workflow is:

Understand
    ↓
Plan
    ↓
Inspect
    ↓
Act
    ↓
Verify
    ↓
Review
    ↓
Deliver

A weak agentic workflow is:

Ask Claude to do everything
       ↓
Hope the result is correct

64. Verification Is a First-Class Step

Always distinguish:

Generated

from:

Verified

For coding:

Code generated
     |
     v
Tests
     |
     v
Lint
     |
     v
Integration test
     |
     v
Verified

For documentation:

README generated
     |
     v
Compare against source
     |
     v
Check missing sections
     |
     v
Verify commands
     |
     v
Verified

65. Safe Agent Design

For actions that can change external systems:

Read
  |
  v
Plan
  |
  v
Preview
  |
  v
Confirm
  |
  v
Write
  |
  v
Verify

Examples:

  • creating Jira tickets;
  • sending messages;
  • modifying repositories;
  • deleting files;
  • changing cloud infrastructure;
  • updating production systems.

Do not treat AI reasoning as authorization.

66. Practical Learning Project #1

Build a README Generator Skill

Goal:

Input:
Project source + conversation

Output:
Professional README.md

Directory:

readme-generator/
├── skill.md
├── references/
│   ├── README_TEMPLATE.md
│   └── QUALITY_CHECKLIST.md
└── scripts/
    └── validate_readme.py

Skills learned:

  • YAML frontmatter;
  • trigger descriptions;
  • progressive disclosure;
  • reference files;
  • executable scripts;
  • validation;
  • packaging.

67. Practical Learning Project #2

Build a Jira Story Skill

Input:

Conversation
+
Project files
+
Requirements

Output:

Jira story
+
Acceptance criteria
+
Technical details
+
Testing

Add a decision step:

One logical feature
      |
      v
One story

Multiple independently deliverable features
      |
      v
Multiple stories

This is an excellent Skill-building exercise because it requires analysis before generation.

68. Practical Learning Project #3

Build an MCP Server

Create a tiny MCP server exposing:

get_project_status()
get_test_results()
get_release_version()

Then connect Claude Code to it.

Workflow:

Claude Code
   |
   v
MCP Server
   |
   +--> Project status
   +--> Tests
   +--> Version

Then ask:

What is the current project status?

Claude can obtain the information through MCP.

69. Practical Learning Project #4

Build a Project Dashboard Artifact

Ask Claude to create:

Project Dashboard

with:

Status
Open Issues
Completed Tasks
Test Results
Release Version

Then connect it to a supported external source where appropriate.

Skills learned:

  • Artifact creation;
  • iterative editing;
  • data representation;
  • connector integration;
  • UI design.

70. Practical Learning Project #5

Build a Claude Code Project Workflow

Repository:

my-project/
├── CLAUDE.md
├── progress.md
├── tests.json
├── decisions.md
├── src/
└── tests/

Workflow:

Claude Code
    |
    +--> Read CLAUDE.md
    |
    +--> Read progress.md
    |
    +--> Inspect source
    |
    +--> Implement
    |
    +--> Run tests
    |
    +--> Update tests.json
    |
    +--> Update progress.md
    |
    +--> Review

This teaches context management in a real environment.

71. Final Capstone

Build a Claude-Powered Project Engineering Assistant

Combine everything.

Inputs

Git repository
Project requirements
Existing documentation
Jira/issue system

Claude capabilities

Claude Code
CLAUDE.md
Skill
MCP
Project context
Artifacts

Workflow

flowchart TD
    A["Developer"] --> B["Claude Code"]

    B --> C["CLAUDE.md"]
    B --> D["Repository"]
    B --> E["Project Context"]

    B --> F["Documentation Skill"]
    B --> G["Testing Skill"]

    B --> H["MCP"]
    H --> I["GitHub / Jira / Other Services"]

    D --> J["Analyze"]
    C --> J
    E --> J
    F --> J
    G --> J
    I --> J

    J --> K["Plan"]
    K --> L["Implement"]
    L --> M["Test"]
    M --> N["Review"]

    N --> O["Artifact / README / Jira Story"]

72. Capstone Requirements

Your final system should be able to:

  1. Inspect a repository.
  2. Read project instructions.
  3. Understand project architecture.
  4. Identify the requested change.
  5. Create a plan.
  6. Modify code.
  7. Run tests.
  8. Record progress.
  9. Use an external service through MCP.
  10. Apply a custom Skill.
  11. Generate documentation.
  12. Create an Artifact.
  13. Produce a final verification report.

73. Recommended Personal Claude Folder

For learning, maintain a separate repository:

claude-learning/
│
├── README.md
│
├── notes/
│   ├── prompting.md
│   ├── context-management.md
│   ├── claude-code.md
│   ├── mcp.md
│   ├── connectors.md
│   ├── skills.md
│   └── artifacts.md
│
├── experiments/
│   ├── skill-01/
│   ├── skill-02/
│   ├── mcp-01/
│   └── artifact-01/
│
├── skills/
│   └── my-first-skill/
│
├── mcp/
│   └── my-first-server/
│
└── CLAUDE.md

74. Your Learning CLAUDE.md

A useful starting file:

# Claude Learning Project

## Goal

Learn Claude as:
- a user;
- a coding assistant;
- a tool-using agent;
- a Skill author;
- an MCP user/builder;
- an Artifact creator.

## Rules

- Prefer official Anthropic documentation.
- Record important concepts in notes/.
- Every experiment must include:
  - objective
  - setup
  - prompt
  - result
  - lessons learned
- Do not mark a feature as understood until I have tested it.
- Keep examples reproducible.
- Distinguish Claude.ai features from Claude Code features.
- Distinguish Skills from MCP.
- Record version/date for changing product features.

75. Learning Notebook Template

For every experiment:

# Experiment: <name>

## Objective

What am I learning?

## Official Documentation

Source links.

## Setup

What is required?

## Prompt / Command

```text
...

Result

What happened?

Expected

What should have happened?

Lessons

What did I learn?

Problems

What failed?

Fix

How was it fixed?

Reusable Knowledge

What should go into:

  • CLAUDE.md?
  • Skill?
  • Project knowledge?
  • MCP?

This prevents passive learning.

---

# 76. Decision Matrix

Use this when deciding which Claude capability to use.

| Need | Use |
|---|---|
| Ask a one-time question | Prompt |
| Give Claude project background | Project knowledge |
| Define persistent project behaviour | `CLAUDE.md` |
| Work directly on a repository | Claude Code |
| Access external service | Connector / MCP |
| Define reusable workflow | Skill |
| Create a reusable document/tool | Artifact |
| Persist application data | Artifact storage where supported |
| Connect an external tool to Claude Code | MCP |
| Coordinate long coding task | Claude Code + state files |
| Repeat a specialized process | Skill |
| Execute external action | Tool/MCP/Connector with appropriate permissions |

---

# 77. Common Mistakes to Avoid

## Mistake 1 — Huge Prompt

```text
Here are 500 pages. Understand everything and fix the project.

Better:

Here is the project context.
First inspect the architecture.
Identify relevant files.
Then work only on the requested area.

Mistake 2 — Treating Conversation as Permanent Memory

Do not assume Claude will always remember every detail.

Use:

CLAUDE.md
progress.md
project knowledge
structured state

for important persistent information.

Mistake 3 — Putting Everything in CLAUDE.md

CLAUDE.md should contain instructions and important project conventions.

Large reference material belongs in appropriate files.

Mistake 4 — Making One Giant Skill

Bad:

Ultimate AI Skill

Better:

README Generator
Jira Story Generator
PDF Analysis
Release Notes Generator

Specialized Skills are easier to activate and maintain.

Mistake 5 — Confusing Skills and MCP

Remember:

Skill = procedure
MCP = connection/capability

Mistake 6 — Assuming Connectors Bypass Permissions

They do not.

Connected applications retain their own access controls.

Mistake 7 — Trusting Generated Code Without Verification

Always:

Generate
→ Test
→ Inspect
→ Verify

Mistake 8 — Giving Agents Unnecessary Permissions

Use the minimum required access.

Especially for:

  • file deletion;
  • production systems;
  • external APIs;
  • repositories;
  • communication tools.

78. 30-Day Learning Plan

Week 1 — Claude Fundamentals

Day 1

  • Learn prompting.
  • Test role/context/task/constraints.

Day 2

  • Work with uploaded files.
  • Practice source-grounded answers.

Day 3

  • Learn Projects.
  • Create one learning project.

Day 4

  • Learn project instructions and knowledge.

Day 5

  • Learn context management.

Day 6

  • Practice long-document analysis.

Day 7

  • Build a small reusable workflow manually.

79. Week 2 — Claude Code

Day 8

Install Claude Code.

claude doctor

Day 9

Open a repository and inspect it.

Day 10

Learn file editing and terminal workflows.

Day 11

Create CLAUDE.md.

Day 12

Learn /init and /memory.

Day 13

Practice long-running tasks with progress.md.

Day 14

Build a small coding project entirely with Claude Code.

80. Week 3 — MCP, Connectors and Skills

Day 15

Learn MCP architecture.

Day 16

Connect an MCP server to Claude Code.

Day 17

Learn connector permissions.

Day 18

Create your first skill.md.

Day 19

Add reference files to the Skill.

Day 20

Add a validation script.

Day 21

Package and test the Skill.

81. Week 4 — Artifacts and Agentic Workflows

Day 22

Create a document Artifact.

Day 23

Create an interactive Artifact.

Day 24

Edit an Artifact iteratively.

Day 25

Connect an Artifact to supported external data.

Day 26

Learn subagents / specialized agents.

Day 27

Build a multi-step workflow.

Day 28

Build a Skill + MCP workflow.

Day 29

Complete the capstone.

Day 30

Document everything you learned.

82. Skill-Building Progression

Learn Skills in this order:

Skill 1
Simple instructions
        |
        v
Skill 2
Instructions + examples
        |
        v
Skill 3
Instructions + references
        |
        v
Skill 4
References + scripts
        |
        v
Skill 5
Validation + testing
        |
        v
Skill 6
Skill + MCP
        |
        v
Skill 7
Skill + MCP + Artifact

83. MCP-Building Progression

Learn MCP in this order:

Understand MCP
      |
      v
Use an existing MCP server
      |
      v
Configure MCP in Claude Code
      |
      v
Understand tools/resources/prompts
      |
      v
Build a local MCP server
      |
      v
Connect an external API
      |
      v
Add authentication
      |
      v
Add permission boundaries
      |
      v
Deploy safely

84. Artifact-Building Progression

Simple document
      |
      v
Markdown document
      |
      v
Interactive HTML
      |
      v
Dashboard
      |
      v
Data-driven Artifact
      |
      v
Connector-enabled Artifact
      |
      v
Persistent-data Artifact

85. The Most Important Concepts to Memorize

If you remember only these:

1. Prompt
   = What I want Claude to do now.

2. Project
   = Workspace + knowledge + instructions.

3. CLAUDE.md
   = Persistent Claude Code project instructions.

4. Context
   = Information currently available to Claude.

5. Skill
   = Reusable specialized procedure.

6. MCP
   = Standard protocol for connecting AI to tools/data.

7. Connector
   = Product-level connection to an external service.

8. Artifact
   = Reusable self-contained output.

9. Tool
   = An operation Claude can invoke.

10. Agent
    = Claude reasoning + tools + iterative execution.

11. Permission
    = What Claude is allowed to do.

12. Verification
    = Evidence that the result actually works.

86. Master Architecture

Everything can be represented as:

                         USER
                           |
                           v
                    ┌─────────────┐
                    │   CLAUDE    │
                    └──────┬──────┘
                           |
       ┌───────────────────┼───────────────────┐
       |                   |                   |
       v                   v                   v
    CONTEXT              TOOLS             PROCEDURES
       |                   |                   |
       |                   |                   |
       v                   v                   v
 Projects               MCP               Skills
 Files                  Connectors        Instructions
 CLAUDE.md              APIs              Workflows
 Conversation           Services          Scripts
       |                   |                   |
       └───────────────────┼───────────────────┘
                           |
                           v
                       REASONING
                           |
                           v
                     ACTION / OUTPUT
                           |
            ┌──────────────┼──────────────┐
            |              |              |
            v              v              v
          Code          Artifact       External
                                      System Action

This is the mental model to keep as you progress.

87. Official Sources

The following sources were used to build this learning guide. Prefer these over third-party tutorials when learning current Claude product behaviour.

Claude Documentation

Claude Help Center

88. Official Documentation Notes

Feature availability can depend on:

  • Claude plan;
  • Claude Code availability;
  • organization settings;
  • enabled capabilities;
  • product rollout status;
  • whether a feature is beta;
  • execution environment.

Therefore, treat this document as a learning roadmap rather than a permanent UI manual.

For current product behaviour, check the official documentation before relying on a specific command, UI location, plan entitlement or feature availability.

89. Final Learning Strategy

Do not learn Claude by memorizing every feature.

Learn it by building.

Use this sequence:

USE
 |
 v
UNDERSTAND
 |
 v
EXPERIMENT
 |
 v
BUILD
 |
 v
TEST
 |
 v
PACKAGE
 |
 v
REUSE

A practical progression is:

Prompt
  ↓
Project
  ↓
Files / Context
  ↓
Claude Code
  ↓
CLAUDE.md
  ↓
MCP
  ↓
Connectors
  ↓
Skill
  ↓
Artifact
  ↓
Skill + MCP
  ↓
Claude Code + Skill + MCP
  ↓
Complete AI workflow

The objective is not simply to learn how to "ask Claude questions."

The objective is to learn how to design a reliable AI workspace in which:

Context
+
Instructions
+
Tools
+
Permissions
+
Procedures
+
Verification
=
Reliable AI workflow

90. First 5 Exercises to Complete

Start with these five exercises before moving to advanced agent workflows.

Exercise 1 — Prompting

Ask Claude to analyze a small Python project.

Require:

Architecture
Dependencies
Entry point
Potential issues
Test strategy

Exercise 2 — Claude Code

Open the same project with Claude Code.

Ask:

Do not modify anything.

Inspect the repository and explain:
1. Architecture
2. Entry point
3. Dependencies
4. Tests
5. Commands

Exercise 3 — CLAUDE.md

Create:

CLAUDE.md

Add project conventions.

Then ask Claude Code to modify one file.

Observe whether it follows the instructions.

Exercise 4 — Skill

Create:

my-first-skill/
└── skill.md

Make it:

Professional README Generator

Test it against two different projects.

Exercise 5 — MCP

Connect one MCP server to Claude Code.

Then ask Claude to use it for a real information-retrieval task.

Document:

What Claude could do before MCP
What Claude could do after MCP
What permissions were required
What data crossed the boundary

91. Personal Learning Milestone

You can consider yourself comfortable with Claude when you can look at a requirement and answer:

Where should this capability live?

For example:

"Claude should know our coding standards."
        → CLAUDE.md

"Claude should know our company documents."
        → Project knowledge

"Claude should perform our standard release workflow."
        → Skill

"Claude should access Jira."
        → Connector / MCP

"Claude should work on the repository."
        → Claude Code

"Claude should create a reusable dashboard."
        → Artifact

"Claude should remember structured progress across long work."
        → State files + context management

"Claude should perform a multi-step task."
        → Agentic workflow

That architectural understanding is more valuable than memorizing individual commands.

Actions
Copy link

Also available in: PDF Atom