Skip to main content
Pro Workflow is built on a three-layer architecture that separates concerns and enables powerful orchestration patterns. Each layer has a single responsibility and clear boundaries.

​
The Three Layers

Command (entry point, user-facing)
  └── Agent (execution, constrained tools)
        └── Skill (domain knowledge, preloaded)

Commands

Handle user interaction and parameter collection

Agents

Execute workflows with constrained tool access

Skills

Provide domain-specific knowledge and procedures

​
Layer Responsibilities

​
Commands: Entry Points

Commands are user-facing entry points that:
  • Accept user input via $ARGUMENTS
  • Substitute dynamic context with !\command“
  • Delegate to agents or execute workflows directly
  • Define tool whitelists and model overrides
Example: The /develop command 
---
description: Build a feature using Research > Plan > Implement phases
argument-hint: <feature description>
---

Build features through structured phases with validation gates.

Feature: $ARGUMENTS

Current branch: !\`git branch --show-current\`

​
Agents: Execution Engines

Agents are specialized workers with:
  • Constrained tool access (whitelist or blacklist)
  • Preloaded skills for domain knowledge
  • Persistent memory (user/project/local scopes)
  • Background execution and worktree isolation options
Example: The orchestrator agent 
---
name: orchestrator
description: Multi-phase development agent. Use PROACTIVELY when building features
tools: ["Read", "Glob", "Grep", "Bash", "Edit", "Write"]
skills: ["pro-workflow"]
model: opus
memory: project
---
Agents with PROACTIVELY in their description can be auto-invoked by Claude when appropriate.

​
Skills: Domain Knowledge

Skills provide specialized knowledge in two modes: Preloaded (Agent Skills)
  • Full content injected at agent startup
  • Always available, no invocation needed
  • Use for knowledge the agent always needs
  • Cost: uses context tokens
On-Demand (Invoked Skills)
  • Loaded only when called via /skill-name
  • Use context: fork for isolated execution
  • Use for procedures run occasionally
  • Keeps main context lean

​
System Diagram

Pro Workflow Architecture

The diagram shows:
  1. User interacts via commands (/develop, /commit, etc.)
  2. Commands delegate to specialized agents
  3. Agents execute with preloaded skills and constrained tools
  4. Skills provide domain knowledge and procedures
  5. Hooks observe and intervene at 18 lifecycle events
  6. Memory persists learnings across sessions

​
Component Relationships

​
Commands → Agents

Commands delegate to agents for execution: 
# In /develop command
Delegate to orchestrator agent:
- Research the codebase
- Score confidence
- Present plan

​
Agents → Skills

Agents load skills at startup for domain knowledge: 
# In orchestrator.md
skills: ["pro-workflow", "project-patterns"]

​
Skills → Tools

Skills can constrain available tools: 
# In skill frontmatter
allowed-tools: ["Read", "Grep"]
context: fork  # Isolated execution

​
Configuration Hierarchy

1

Enterprise Policies

Managed policies take highest precedence (enterprise deployments)
2

User Settings

Global settings in ~/.claude/settings.json
3

Project Settings

Project-specific in .claude/settings.local.json
4

Component Frontmatter

Command, agent, and skill-specific overrides
Settings cascade down the hierarchy, with lower levels overriding higher ones.

​
Memory Architecture

Multiple memory systems work together:
SystemScopeManaged ByWhen Loaded
CLAUDE.mdProjectYouEvery session (ancestors), lazy (descendants)
CLAUDE.local.mdPersonalYouEvery session (gitignored)
Auto MemoryUserClaudeSession start (first 200 lines)
Agent MemoryPer-agentAgentAgent invocation
Pro-Workflow DBUserHooksSession start (via SessionStart hook)
Keep root CLAUDE.md under 150 lines. It loads every session regardless of where you work.

​
Tool Access Patterns

​
Read-Only Agents

For planning and exploration: 
tools: ["Read", "Glob", "Grep"]

​
Full-Access Agents

For implementation: 
tools: ["Read", "Glob", "Grep", "Bash", "Edit", "Write"]

​
Selective Blocking

Block dangerous operations: 
tools: ["*"]  # All tools
disallowedTools: ["Bash"]  # Except Bash

​
Model Selection by Layer

Different layers can use different models:
LayerTypical ModelReasoning
CommandsDefaultSimple delegation
Planner AgentOpus 4.6Deep reasoning needed
Implementer AgentSonnet 4.6Balanced speed/quality
Scout AgentHaiku 4.5Fast read-only exploration
Opus 4.6 and Sonnet 4.6 auto-calibrate reasoning depth—no need to toggle thinking mode manually.

​
Best Practices

​
Do

Use read-only agents for planning phases
Preload frequently-needed skills into agents
Use context: fork for heavy, isolated procedures
Set background: true for long-running exploration
Use memory: project for agents that should learn patterns

​
Don’t

​
Extension Points

The architecture provides multiple extension points:
Create slash commands in ~/.claude/commands/ or .claude/commands/
---
description: Your custom command
argument-hint: <input>
---

Your command logic here
Define specialized agents in ~/.claude/agents/ or .claude/agents/
---
name: your-agent
description: What it does (include PROACTIVELY for auto-invoke)
tools: ["Read", "Edit"]
skills: ["domain-knowledge"]
---

Agent system prompt
Add domain knowledge in ~/.claude/skills/ or .claude/skills/
---
name: your-skill
description: When to invoke
user-invocable: true
---

Skill content with procedures and knowledge
React to 18 lifecycle events in settings.json
{
  "hooks": {
    "SessionStart": "Load custom data",
    "PreToolUse": "Validate before edits",
    "PostToolUse": "Check after changes"
  }
}

​
Next Steps

Orchestration Patterns

Learn how to wire Commands, Agents, and Skills together

Multi-Phase Development

Understand Research > Plan > Implement workflows

Build docs developers (and LLMs) love

Get started for freeTalk to us