Claude-skill-registry box-factory-architecture

Guidance for using Claude Code component architecture and choosing between agents, skills, commands, and hooks. Helps decide which component type fits a use case, understand delegation and isolation, debug cross-component issues, and design cohesive plugin architectures. Use when choosing component types, designing plugins with multiple components, debugging delegation failures, asking about component interaction patterns, or creating Box Factory-compliant components.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/box-factory-architecture" ~/.claude/skills/majiayu000-claude-skill-registry-box-factory-architecture && rm -rf "$T"
manifest: skills/data/box-factory-architecture/SKILL.md
source content

Box Factory Architecture

This meta-skill teaches the Claude Code component and ecosystem architecture - how components interact, when to use each type, and how to design cohesive multi-component solutions. This applies to both Main Claude (choosing what to create) and sub-agents (understanding their role).

Fundamentals

Four foundational principles underpin all Claude Code component design:

Isolation Model

Components operate independently, and have limited access to the user or each other.

These are our RULES (based on spec & best practices):

  • Only Main Claude has user access
  • Sub-agents:
    • CANNOT: ask the user questions, see conversation history, reference Skill files by name
    • CAN: use tools, load skills, reference Skill content by subject
  • Skills:
    • CANNOT: reference any other component (single exception: Box Factory skills can reference Box Factory Architecture as a prerequisite)
    • CAN: Provide information and instruction
  • Commands:
    • CANNOT: execute logic, access user directly
    • CAN: trigger Sub-agents, reference Skills

Return-Based Delegation

Sub-agents return complete results. No mid-execution interaction - agent must have everything upfront.

Progressive Disclosure

Load knowledge only when relevant (this preserves context and saves tokens). Use Skills tosolve selective context loading.

Knowledge Delta Filter

Document only what Claude doesn't know. Skip base knowledge; include user-specific delta.

Design test: If your sub-agent needs to ask questions mid-execution, redesign the delegation pattern.

Deep dive: Core Architectural Concepts - Diagrams, design implications, common misconceptions. Traverse when: debugging delegation issues, need to understand WHY architecture works this way. Skip when: table above answers your question.

Deep dive: Knowledge Delta Filter - Decision framework for content inclusion, examples across component types. Traverse when: writing any component content, reviewing for bloat, unsure what to include/exclude. Skip when: already know the delta principle, content is clearly user-specific.

Instructions

  1. Select a workflow based on your needs from Workflow Selection

Claude Code changes rapidly and is post-training knowledge. Fetch the official documentation when designing components to ensure current specifications.

Workflow Selection

If you need to...Go to...
Choose a component type (skill vs agent vs command vs hook)Which Component Should I Choose
Debug delegation issues (agent not receiving data, calls failing)Component Communication
Design multi-component workflows (command→agent→skill chains)Design Patterns
Understand isolation model (why agents can't ask questions)Fundamentals
See reference implementations (complete plugin ecosystems)Example Ecosystems
Determine file paths for new components (project vs user vs plugin)Component Paths
Write documentation for components (skills, agents, READMEs)Building Blocks
Get oriented / unsure where to startFundamentals then Component Selection

Design Patterns in Claude Code Components

Most common patterns used in multi-component workflows:

PatternWorkflow
Simple series of steps or tool call
User
->
Command
Complex agent flow triggered by command
User
->
Command
->
Agent
Complex agent flow backed by knowledge base
User
->
Command
->
Agent
->
Skill

Deep dive: Interaction Patterns - 5 detailed patterns (Command→Agent, Agent→Skill, nested delegation, Hook+Agent, shared skills), scope anti-patterns. Traverse when: designing multi-component workflow, debugging component interactions, need pattern examples. Skip when: simple single-component task, workflow table covers your use case.

Component Communication and Delegation

Quick reference for what each component can do:

ComponentCanCannot
Main ClaudeAsk user questions, delegate to agentsN/A (full access)
Sub-agent (aka subagent)Use tools, load skills, return resultsAsk questions, see conversation history
CommandTrigger agents, expand to promptsExecute logic directly, access user
SkillProvide guidance when loadedExecute code, call tools, trigger actions
HookRun scripts, block/modify tool callsAsk questions, use judgment
MCP ServerProvide custom toolsAccess conversation, trigger unprompted

Deep dive: Component Communication & Delegation - CAN/CANNOT lists for each component type with examples and edge cases. Traverse when: need detailed interaction rules, debugging "why can't my agent do X". Skip when: table above answers the question.

Which Component Should I Choose

Users can customize Claude Code using components broken into roughly three categories.

Components used by Claude

Component TypeWhen to UseAvoid When (use instead)
Sub-agent
Complex logic, autonomous delegationGuidance only (Skill), simple repeatable (Command)
Skill
Substantial interpretive guidance across contextsDoing work (Agent), brief context <20 lines (Memory)
Command
Simple repeatable actions, explicit user controlComplex logic (Agent), knowledge only (Skill)
Memory
Project knowledge, behavior shapingSubstantial guidance (Skill), enforcement (Hook)
MCP server
Custom tool integrations, specialized transportsStandard tools suffice (use built-in tools)

Components for the UX of the User

Component TypeWhen to UseAvoid When (use instead)
Hook
Guaranteed enforcement, simple rulesJudgment calls (Agent), guidance (Skill)
Status Line
Custom session metadata displayEnforcement needed (Hook), any Claude action
Output Style
Custom response formats, structured outputsLogic changes (Agent/Skill), enforcement (Hook)

Distribution Wrappers for Components

Component TypeWhen to UseAvoid When (use instead)
Plugin
Bundling multiple components for reuseSingle-project use (project components)
Marketplace
Discovering and sharing pluginsPrivate/internal plugins (direct install)

Deep dive: Choosing the Right Component - Full decision framework with KEY CHARACTERISTIC, CHOOSE IF, DO NOT CHOOSE IF, and Example User Requests for each component. Traverse when: ambiguous component choice, need to map user intent phrases to component type, edge cases not covered by summary. Skip when: summary tables clearly answer the question.

Building Blocks

Reusable documentation patterns that apply across all component types:

PatternPurpose
Navigation TablesRouting tables for progressive discovery
Decision FrameworksStructured formats for documenting choices between options
Reference SectionsAt-a-glance content design for the happy path
Deep Dive LinksCross-reference format with traverse/skip guidance
Quality ChecklistCheckbox validation at end of documents
Anti-Pattern CatalogStructure for documenting common mistakes

Use these patterns when writing documentation for any component type (skills, agents, commands, READMEs).

Claude Code Official Documentation

Claude Code changes rapidly and is post-training knowledge. Fetch these docs when designing components to ensure current specifications:

Example Component Ecosystems

A very simple ecosystem:

CLAUDE.md    # Basic project memory.  Indicates to use code-reviewer agent when reviewing code.
commands/review-code.md    # Command that triggers code review by delegating to code-reviewer agent.
agents/code-reviewer.md    # Code review agent, looks up guidelines from skill.
skills/code-review-guidelines.md    # Skill with guidance on code review best practices.

Deep dive: Example Component Ecosystems - 3 complete ecosystems (Testing, Documentation, Code Quality) with architecture diagrams and interaction flows. Traverse when: need reference implementation, learning multi-component patterns, planning similar ecosystem. Skip when: understanding single component, simple use case.

Anti-Patterns

Common architecture mistakes. See linked design skills for detailed guidance.

PitfallSymptomFixDetails
User interaction in agentsAgent prompt contains "ask the user", "confirm with"Remove - agents are isolated, return complete resultssub-agent-design
Wrong granularityAgent for simple task, skill for 10-line guidanceMatch complexity: Command < Agent < Skill based on scopeComponent Selection
Missing tool permissionsAgent fails silently or can't complete taskAdd required tools (esp. Skill tool if loading skills)sub-agent-design
Vague agent descriptionsMain Claude doesn't delegate when it shouldUse strong triggers: "MUST BE USED when...", "ALWAYS use for..."sub-agent-design
Over-engineeringPlugin for single-project useUse project-level components until reuse is provenplugin-design

Quality Checklist

Before finalizing component architecture:

Fundamentals:

  • Agents have no user interaction language ("ask", "confirm", "clarify")
  • Agents return complete results (not partial or interactive)
  • Progressive disclosure applied (skills for substantial guidance, memory for brief)

Component Selection:

Tool Permissions:

  • Agent tools match responsibilities (Read-only for reviewers, Write for creators)
  • Skill tool included if agent loads skills
  • Task tool included if agent delegates to sub-agents