Claude workflow placement

Map AI workflow layers to Claude Projects, Project Instructions, Project Knowledge, RAG, Claude Skills, Claude Code, CLAUDE.md, settings, permissions, hooks, MCP, subagents, artifacts, and runtime chat prompts.

Claude configuration map

Start with the workflow layer, then choose the Claude surface

Use this reference to decide whether a workflow belongs in Claude Projects, Project Instructions, Project Knowledge, Claude Skills, Claude Code memory files, settings, permissions, hooks, MCP, subagents, artifacts, or the runtime chat prompt.

Claude setup decision

Choose the right Claude surface first

Start by choosing the surface that matches the workflow scope. Claude Projects, Claude Skills, Claude Code, regular chat, and API-based systems are different implementation environments.

Use a Claude Project for long-running work

Use Projects when the workflow needs project-scoped instructions, uploaded knowledge, focused chats, project context, sharing, or RAG over project knowledge.

Go to Claude Projects →

Use Claude Skills for reusable procedures

Use Skills when the workflow should be packaged as reusable instructions with optional resources, scripts, examples, or repeatable execution steps.

Go to Claude Skills →

Use Claude Code for repository work

Use Claude Code when Claude needs to read a codebase, edit files, run commands, manage permissions, use MCP tools, run hooks, or delegate repo work to subagents.

Go to Claude Code →

Use artifacts and files for outputs or source material

Use Artifacts for substantial outputs. Use uploaded files or Project Knowledge as source material. Do not treat artifacts as instruction storage.

Go to artifacts and files →

Use regular chat only for one-off tasks

Use a normal chat when the task does not need project knowledge, reusable instructions, repo access, persistent configuration, or tool automation.

Go to placement rules →

Use the API for product or backend integration

Use Claude API or internal agent infrastructure when the workflow must run inside a product, backend service, internal tool, CI system, or production automation pipeline.

Open API mapping →

Primary surfaces

Claude surfaces you can configure

These are the main Claude surfaces relevant to workflow placement. Availability can vary by plan, workspace policy, product surface, and rollout state.

Claude Projects
Self-contained workspaces with their own chat histories and knowledge bases. Use for focused work that needs project context, uploaded documents, project instructions, and multiple related chats.
Project Knowledge
Uploaded documents, text, code, or files that Claude should use as project context. This is the reference layer for Claude Projects.
Project Instructions
Project-scoped behavior rules. Use for tone, role, constraints, output format, workflow rules, and verification requirements that should apply inside one project.
Project RAG
Claude can automatically use a project knowledge search tool when project knowledge approaches context limits. Treat RAG as project-reference retrieval, not as instruction storage.
Claude Skills
Reusable workflows packaged as instructions plus optional supporting files, resources, or scripts. Use Skills when a repeatable procedure is too large or procedural for project instructions.
Claude Code
Agentic coding environment for repositories. Use for reading codebases, editing files, running commands, using tools, managing context, and automating developer workflows.
CLAUDE.md
Persistent Claude Code instruction files. Use for coding standards, project architecture, workflows, build/test commands, repository conventions, and durable repo-specific context.
Claude Code settings
Configuration for model, output style, permissions, environment behavior, hooks, MCP, and other local/project/user/managed settings.
Claude Code permissions
Tool access policy. Use allow/ask/deny rules to control file reads, file edits, shell commands, web access, MCP tools, and other actions.
Claude Code hooks
Deterministic automation that runs at Claude Code lifecycle events. Use hooks for formatting, validation, notifications, command checks, or enforcement that should not depend on the model choosing to run it.
Claude Code MCP
External tool/server integration. Use MCP for issue trackers, docs, databases, monitoring systems, design tools, internal APIs, or other controlled tool boundaries.
Claude Code subagents
Specialized assistants with task-specific instructions, tool restrictions, and separate context windows. Use for codebase exploration, planning, review, tests, or delegated repo tasks.
Artifacts
Output surface for substantial standalone content, apps, tools, visualizations, or documents. Use as output/artifact workspace, not as the primary instruction layer.

Claude Projects

Use Projects for ongoing work with project knowledge

A Claude Project is the correct surface when the work needs a shared project context, uploaded source material, project instructions, and focused project chats.

Where to configure this in Claude

Create or open a Project
Use Claude Projects for focused work. Projects are self-contained workspaces with their own chat histories and knowledge bases.
Add reference material
Add documents, text files, code snippets, or other files to Project Knowledge. Claude uses this material as context in chats inside the project.
Add project instructions
Use Set project instructions to define how Claude should behave and respond inside the project. Put workflow rules, output requirements, role, tone, and verification expectations here.
Use RAG when project knowledge is large
When project knowledge approaches context limits, Claude can automatically enable RAG and use a project knowledge search tool to retrieve relevant information from uploaded documents.
Share only when governance allows it
Team and Enterprise users can share projects where enabled. Use Can use for members who should view contents, knowledge, and instructions, and Can edit only for members who should modify instructions, knowledge, or member settings.
Verify setup
Start a new chat inside the Project and ask Claude to identify the active project instructions and the project knowledge it can use. If it ignores a file, check Project Knowledge. If it ignores behavior rules, check Project Instructions.

Claude Skills

Use Skills for reusable Claude workflows

Skills are the right surface when a repeatable procedure should be packaged as reusable instructions with optional supporting files, resources, scripts, examples, or direct invocation.

Where to configure this in Claude / Claude Code

Create a Skill for repeated procedures
Use a Skill when you keep pasting the same instructions, checklist, or multi-step procedure into Claude. In Claude Code, a Skill uses a SKILL.md file and can include supporting files.
Put procedure rules in Skill instructions
Put the repeatable workflow, checklist, invocation criteria, expected output, and verification behavior in the Skill. Do not put large source material into the runtime chat if it belongs in the Skill or Project Knowledge.
Use supporting files only when needed
Add resources, examples, scripts, or templates when the workflow requires them. Keep the Skill scoped so it does not trigger too broadly.
Verify setup
Run a task that should trigger the Skill. If Claude does not use it, check the Skill description, invocation criteria, visibility, and whether the workflow is better suited to Project Instructions or Claude Code configuration.

Claude Code

Use Claude Code for repository and developer workflows

Claude Code is Anthropic’s agentic coding surface. Use it when Claude needs to work inside a repository, inspect project structure, edit files, run commands, use developer tools, connect external systems, or automate engineering workflows from the terminal, IDE, desktop app, browser, or CI environment.

What Claude Code can do

Codebase navigation and explanation
Use Claude Code when the task requires understanding a repository structure, tracing how files connect, explaining implementation details, finding relevant files, or answering questions from the current codebase.
File edits and implementation work
Use Claude Code for scoped code changes, bug fixes, refactors, documentation edits, test updates, merge-conflict work, and multi-file implementation tasks.
Command execution and developer automation
Use Claude Code when the workflow needs local commands, tests, linters, formatters, build checks, scripts, or CI-style validation. Keep risky commands behind permission prompts.
Tool and data integration
Use MCP and connected tools when the workflow needs access to issue trackers, documentation systems, design tools, monitoring systems, databases, or internal APIs. Treat every external tool as a trust boundary.
Delegated engineering workflows
Use Claude Code for repeatable developer workflows such as code review, test generation, architecture exploration, release notes, lint cleanup, migration planning, and repository-specific quality gates.

Where to configure Claude Code

Install / launch surface
Claude Code can run from the terminal and is also available through IDE, desktop, browser, and related developer surfaces. Use the terminal or IDE when repository access, file edits, and command execution are required.
Repository memory: CLAUDE.md
Put durable repository guidance in CLAUDE.md or .claude/CLAUDE.md: architecture notes, coding standards, test commands, review rules, project conventions, branch rules, and expected verification steps.
Enterprise / user / project / local memory
Claude Code loads memory from multiple scopes. Use organization-managed memory for non-overridable standards, user memory for personal defaults, project memory for repository guidance, and local memory for machine-specific or private overrides.
Memory imports
Use imports when memory should be split across files. Keep imported files reviewable and scoped. Do not hide critical behavior rules inside unrelated imported notes.
Settings files
Use settings files for configuration that affects Claude Code behavior: permissions, environment variables, tool behavior, hooks, MCP servers, plugins, output style, and team-shared project settings.
Settings scopes
Use managed settings for organization policy, project settings for team-shared repository configuration, user settings for personal defaults, and local settings for machine-specific overrides that should not be committed.
Permissions
Use permission rules to control what Claude Code can do. Keep read-only exploration permissive where appropriate, but put file edits, shell commands, network access, MCP tools, and sensitive paths behind explicit allow/ask/deny rules.
Permission modes
Use stricter modes for review and exploration, and more permissive modes only after the workflow is trusted. Do not use broad bypass modes as a default for repository, CI, production, or sensitive-data workflows.
Hooks
Use hooks for deterministic lifecycle automation: checks before tool use, checks after tool use, prompt-submit validation, stop-time validation, notifications, formatting, linting, and policy enforcement.
MCP servers
Use MCP servers for external systems and developer tooling. Configure server access intentionally and restrict tools to the minimum needed for the workflow.
Slash commands
Use slash commands for repeatable local operations or workflow shortcuts. They are useful when a task should be invoked consistently without retyping the full instruction.
Subagents
Use subagents for specialized work with separate prompts, separate context, and restricted tools. Good candidates include code reviewers, test analysts, architecture explorers, documentation reviewers, dependency auditors, and migration planners.
Skills inside Claude Code
Use Skills when a reusable coding workflow is larger than a short repository instruction. Skills can package instructions with supporting resources and load when relevant.
SDK / automation
Use the SDK or non-interactive Claude Code runs when the workflow needs scripting, automation, CI integration, or repeatable developer tasks outside an interactive session.

Claude Code placement map

Workflow need Best Claude Code surface What to put there Do not put there
Repository-wide rules CLAUDE.md / .claude/CLAUDE.md Architecture, commands, conventions, test strategy, review policy, expected workflow. Secrets, one-off task input, temporary notes, or machine-specific paths.
Team-shared tool behavior .claude/settings.json Permissions, hooks, MCP servers, plugins, and shared project behavior. Private user tokens or local-only machine settings.
Personal defaults ~/.claude/settings.json / user memory Personal editor preferences, personal global tools, personal defaults. Team policy or repository-specific requirements.
Local machine overrides .claude/settings.local.json / CLAUDE.local.md Local paths, local test overrides, temporary experiments, private machine context. Rules that teammates must inherit.
External tools MCP servers Issue tracker access, docs lookup, design tools, internal APIs, databases, monitoring systems. Unrestricted access to sensitive systems without permissions and audit controls.
Deterministic checks Hooks / scripts / CI Formatting, linting, tests, policy checks, command blocks, notifications, prompt-submit checks. Judgment-heavy review that requires source-aware reasoning without a review process.
Specialized review work Subagents Code review, test review, architecture mapping, migration analysis, documentation review. General instructions that should apply to the whole repository.
Reusable engineering procedure Claude Code Skill Repeatable workflows, examples, supporting resources, scripts, and stable output contracts. One-off prompts or repository-wide rules better suited to CLAUDE.md.

Verification checklist

  • Run Claude Code from the repository root or the intended working directory.
  • Ask which memory files are loaded before relying on repository instructions.
  • Check which settings scope is active before changing permissions, hooks, MCP, or plugins.
  • Test risky workflows first with read-only exploration before allowing edits or shell commands.
  • Use hooks or CI for deterministic checks instead of relying only on the model to remember them.
  • Use subagents only when the task benefits from separate context, specialized instructions, or narrower tool permissions.
  • Review MCP server trust and permissions before connecting external systems.
  • Keep secrets, credentials, private tokens, and privileged environment values outside prompts, memory files, and committed settings.

Artifacts and files

Separate outputs from source material

Uploaded files, Project Knowledge, created files, and Artifacts serve different purposes. Do not use one surface as a substitute for another.

Project Knowledge
Use as source/reference material for project chats.
Uploaded files in chat
Use for run-specific source material or document analysis. If the file should be reused across the project, add it to Project Knowledge instead.
Artifacts
Use for substantial standalone outputs such as content, tools, apps, visualizations, or documents. Artifacts are output containers, not instruction storage.
Claude-created files
Use when Claude creates downloadable or editable files in conversation. Verify generated files before use.

Layer placement map

Where each workflow layer belongs in Claude

Use this table after classifying the workflow layer. The goal is correct placement, not feature listing.

Workflow layer What belongs here Best Claude placement Do not use for
Instruction layer Stable rules, role, workflow behavior, output format, coding standards, verification requirements. Project Instructions, Claude Skill instructions, CLAUDE.md, .claude/rules/, Claude Code settings where relevant. Source documents, credentials, one-off requests, or generated outputs.
Reference / source material layer Documents, code references, policies, examples, specs, source files, research files. Project Knowledge, uploaded chat files, Claude Code repository files, Skill resources, MCP-connected sources. Behavior rules that must apply consistently; those belong in instruction surfaces.
Reusable workflow layer Repeatable procedures, review gates, code workflows, content workflows, checklists. Claude Skills, Claude Project workflow, Claude Code Skills, hooks for deterministic automation. One-off chat prompts that must be reconstructed every time.
Runtime prompt layer The current question, current document, current code diff, current task constraints. Current Claude chat message, Project chat, or Claude Code session prompt. Permanent rules, reusable source material, or workflow policy.
Tool / code execution layer Repo reads, file edits, shell commands, MCP tools, scripts, validation commands, external systems. Claude Code permissions, MCP, hooks, subagents, Skills, API/internal systems. Uncontrolled writes, sensitive shell commands, or production side effects without approval and validation.
Verification layer Checklist review, source alignment, test/lint validation, policy checks, output acceptance criteria. Project Instructions, Skill instructions, Claude Code hooks, test commands, CI, final verification prompt. Informal “looks good” review for code changes, publication, client delivery, or production operations.

Placement rules

Use the smallest stable Claude surface that matches the scope

The same instruction can be correct or incorrect depending on whether it is project-scoped, repo-scoped, workflow-scoped, tool-scoped, or run-specific.

If the rule applies to one Claude Project
Put it in Project Instructions. Put reusable source material in Project Knowledge.
If the rule applies to a repeatable workflow
Put it in a Skill when it should be reusable and loaded only when relevant.
If the rule applies to a repository
Put it in CLAUDE.md or .claude/rules/. Use Claude Code settings and permissions for tool behavior.
If the workflow requires deterministic automation
Use hooks, scripts, tests, or CI. Do not rely only on Claude deciding to run the check.
If the workflow requires external systems
Use MCP, API/tool integration, or an internal agent system. Treat external systems as trust boundaries.
If the task is one-off
Keep it in the current chat prompt. Do not promote it into Project Instructions, Skills, or CLAUDE.md unless it will recur.

Misplacement guardrails

What not to put in the wrong Claude surface

Most Claude workflow failures come from mixing instruction rules, source material, runtime input, and tool execution.

  • Do not put reusable source material only in a runtime chat when it belongs in Project Knowledge.
  • Do not put project-specific behavior only in a regular chat prompt when it should persist across the Project.
  • Do not put repository rules only in a Claude Project if the workflow runs through Claude Code in a repo.
  • Do not treat CLAUDE.md or auto memory as a security boundary; use permissions, hooks, and application-side controls for enforcement.
  • Do not allow broad shell commands, file edits, or MCP access without explicit permission rules.
  • Do not use hooks for judgment-heavy decisions unless they call an appropriate review process; use deterministic hooks for deterministic checks.
  • Do not store secrets, API keys, private tokens, or privileged credentials in Project Knowledge, CLAUDE.md, prompts, or Skill files.
  • Do not treat Artifacts as source governance or instruction storage; they are output workspaces.
  • Do not assume a feature is available to every user. Plan, workspace policy, product surface, and rollout state can change availability.

Official source check

Official Anthropic references used for this mapping

Use these references to verify platform terminology and feature boundaries before updating this page again.