Skip to main content

​
Ownership Model

​
Introduction

The vibeflow architecture has a clear ownership model that separates responsibilities between:
  • Infrastructure Team - Maintains architectural integrity, core framework
  • Marketing Architects - Builds brand strategy, team structure, execution capabilities
This isn’t just documentation—it’s the governance model that enables:
  • Architectural consistency across all marketing architects
  • Flexibility for marketing architects to customize their system
  • Scalability through clear boundaries
  • Evolvability without breaking core patterns
Key insight: Infrastructure team owns the “how it works,” marketing architects own the “what it does.”

​
The Ownership Matrix

​
Complete Component Ownership

ComponentOwnerCustomizable by Marketing Architects?Why This Ownership?
claude.mdInfrastructure❌ NoDefines architectural rules (must be consistent)
Output StylesInfrastructure❌ NoPrimary agent behavior (ensures compliance)
Meta CommandsInfrastructure❌ NoSystem-level workflows (architectural integrity)
Core SkillsInfrastructure❌ NoOrchestration, project management (framework capabilities)
.claude/ StructureInfrastructure❌ NoFile organization conventions (navigability)
Validation ToolingInfrastructure❌ NoContradiction detection (quality enforcement)
DocumentationInfrastructure❌ NoArchitecture principles, patterns (shared understanding)
Brand Bible (/strategy/)Marketing Architects✅ YesBrand-specific (no two brands are the same)
Research Domains (/research/)Marketing Architects✅ YesCompany-specific insights (temporal, unique)
Sub-agent DefinitionsMarketing Architects✅ YesTeam structure (varies by needs)
Domain CommandsMarketing Architects✅ YesWorkflows (specific to their processes)
Domain SkillsMarketing Architects✅ YesCapabilities (unique to their domain)
Tool/MCP SelectionMarketing Architects✅ YesIntegrations (choose what’s needed)
Work ArtifactsMarketing Architects✅ YesPLAN.md, TODO.md, outputs (their work)

​
Infrastructure Team Responsibilities

​
What Infrastructure Team Owns

1. Core Architecture claude.md:
  • Purpose: Project-level instructions defining architectural rules
  • Why locked: Ensures all marketing architects work within consistent framework
  • Contains: Org chart model, component definitions, working principles
  • Updates: When architecture evolves (rare, deliberate)
Output Styles (.claude/output-styles/):
  • Purpose: System prompt for Operations Manager (primary agent)
  • Why locked: Ensures architectural compliance is non-negotiable
  • Contains: Orchestration behavior, delegation rules, compliance checks
  • Marketing architects interact with this behavior but cannot modify it
Meta Commands:
  • Purpose: Higher-order functions for systematic work
  • Why locked: Define HOW to work consistently across all users
  • Examples: plan (create PLAN.md), implement (execute plan, track TODO.md)
  • Future: Meta commands for skill creation, agent definition, validation
2. Core Skills .claude/skills/orchestrating-projects/:
  • Purpose: How Operations Manager coordinates complex work
  • Why locked: Ensures consistent project management patterns
  • Contains: Plan/implement workflow, delegation logic, progress tracking
Future core skills:
  • Validation workflows
  • Skill generation
  • Agent creation
  • Architecture compliance checking
3. Framework & Tooling Validation tooling:
  • Contradiction detection (strategy files)
  • Architectural compliance checks
  • Dependency analysis
  • Build-time validation
.claude/ folder conventions:
  • Directory structure rules
  • File naming patterns
  • Maximum hierarchy depth (3 levels)
  • Progressive disclosure patterns
4. Documentation Architecture documentation (/docs/):
  • Principles, patterns, workflows
  • Component interactions
  • Ownership model (this document)
  • Contribution guidelines
Why these are locked: Infrastructure enables consistency, scalability, and architectural integrity. Marketing architects have free reign within these boundaries, but the boundaries themselves are non-negotiable.

​
Infrastructure Team Responsibilities

1. Maintain architectural integrity
  • Ensure one-way dependencies
  • Prevent circular references
  • Enforce progressive disclosure limits
  • Validate structural patterns
2. Evolve core framework
  • Add new meta commands (based on user needs)
  • Improve core skills (orchestration, project management)
  • Enhance validation tooling
  • Refine documentation
3. Enable marketing architects
  • Provide clear guidelines for contribution
  • Review structural compliance (not content quality)
  • Support meta command usage
  • Unblock architectural issues
4. Version management
  • Release new framework versions
  • Communicate breaking changes
  • Provide migration paths
  • Maintain backward compatibility when possible

​
Marketing Architect Responsibilities

​
What Marketing Architects Own

1. Brand Strategy (/strategy/) Everything in /strategy/ is theirs:
  • Brand narrative, positioning, values
  • Voice guidelines (tone, vocabulary, banned words)
  • Messaging frameworks (pillars, value props, themes)
  • Audience definitions (personas, psychographics)
  • Content frameworks (blog, email, social structures)
Full creative control:
  • Define brand voice however they want
  • Create messaging pillars aligned with their strategy
  • Build content frameworks specific to their needs
  • No infrastructure review of content/quality
Why this ownership: No two brands are the same. Marketing architects are the experts on their brand. 2. Research Domains (/research/) Define research domains:
  • What to research (customer insight, competitor landscape, category trends)
  • How to organize data (transcripts, surveys, reports)
  • When to run research (periodic, event-driven, iterative)
  • How to export deliverables (reports, presentations, summaries)
Execute temporal research:
  • Date-stamped execution runs
  • Comparison over time
  • Institutional memory
  • Audit trails to strategy
Why this ownership: Research is company-specific, temporal, and strategic. Marketing architects know what insights they need. 3. Team Structure (.claude/agents/) Define sub-agents:
  • Which roles exist (Brand Analyst, Content Writer, Campaign Strategist)
  • What each role does (responsibilities, behaviors)
  • How they communicate (tone, style)
  • Which skills each agent has access to
Example agent definition: 
# .claude/agents/brand-analyst.md

Role: Brand Analyst
Purpose: Conduct research and analyze market/customer insights

Skills:
  - Conducting Market Research
  - Analyzing Qualitative Data
  - Competitive Analysis

Tone: Analytical, objective, data-driven
Responsibilities:
  - Market research
  - Customer interviews analysis
  - Competitor positioning
Why this ownership: Team structure varies by company size, needs, and complexity. Marketing architects design their “org chart.” 4. Domain Commands (.claude/commands/) Create workflow triggers:
  • Organized by domain (DDD pattern)
  • Reusable workflows
  • Expected behaviors and outputs
  • Orchestration instructions
Example: 
.claude/commands/onboarding/build-messaging.md

Triggers multi-step workflow:
  1. Research customer language
  2. Identify key themes
  3. Draft messaging pillars
  4. Create value propositions
  5. Export to /strategy/messaging/
Why this ownership: Workflows are company-specific. Marketing architects know their processes. 5. Domain Skills (.claude/skills/) Create specialized capabilities:
  • Marketing-specific methodologies
  • Content generation frameworks
  • Research approaches
  • Analysis techniques
Must follow:
  • Progressive disclosure pattern (SKILL.md < 500 lines)
  • One-way dependencies (can reference tools, not agents)
  • Infrastructure-defined structure
Freedom within constraints:
  • Define whatever capabilities they need
  • Organize however makes sense
  • Use any tools/integrations
Why this ownership: Domain expertise lives with marketing architects. They know what capabilities they need. 6. Tool/MCP Selection Choose integrations:
  • Which external APIs to use (Perplexity, Firecrawl, Replicate, etc.)
  • How to configure them
  • Which skills leverage which tools
  • API keys and credentials
Configuration: 
.mcp.json:
{
  "perplexity": { ... },
  "firecrawl": { ... },
  "replicate": { ... }
}
Why this ownership: Marketing architects know which tools they need for their workflows. 7. Work Artifacts Everything generated during work:
  • PLAN.md files (research plans, campaign plans)
  • TODO.md files (progress tracking)
  • Content outputs (blog posts, social content, emails)
  • Research reports (exports)
  • Campaign materials
Why this ownership: These are their work products, fully under their control.

​
Collaboration & Gray Areas

​
Skill Creation (Collaborative)

Current state: Manual 
Marketing Architect:
  - Writes skill in plain English (methodology, steps)
  - Creates .claude/skills/{skill-name}/ structure
  - Follows progressive disclosure pattern

Infrastructure Team:
  - Reviews for architectural compliance
  - Checks: progressive disclosure, one-way dependencies, file structure
  - Does NOT review content/methodology quality
Future state: Meta Command 
Marketing Architect:
  "create skill: Analyzing Social Media Sentiment"
  [Describes methodology in conversation]

Meta Command:
  - Generates skill structure
  - Creates SKILL.md with overview
  - Splits into detailed files
  - Ensures progressive disclosure
  - Validates architectural compliance

Result:
  New skill created, architecturally compliant, ready to use
Why collaborative: Marketing architects know the methodology, infrastructure ensures structural compliance.

​
Agent-Skill Mapping (Marketing Architect Decides)

Marketing architects decide:
  • Which agents have access to which skills
  • Defined in agent definition files
Example: 
In .claude/agents/content-writer.md:

Skills:
  - Writing Brand-Consistent Content
  - Structuring Long-Form Content
  - Adapting Tone for Platforms
Infrastructure provides:
  • Pattern for how to specify this
  • Validation that referenced skills exist
Infrastructure does NOT:
  • Decide which skills each agent should have
  • Review if mapping makes sense
Why this ownership: Marketing architects design their team, infrastructure ensures it’s expressed correctly.

​
Quality Standards (Marketing Architect Decides)

Marketing architects own:
  • What “good” content looks like
  • Brand consistency standards
  • Research rigor expectations
  • Deliverable quality bar
Infrastructure provides:
  • Tools to enforce consistency (validation)
  • Patterns to enable quality (audit trails, progressive disclosure)
  • Framework to scale quality (context architecture)
Infrastructure does NOT:
  • Judge if brand voice is “good”
  • Review research methodology quality
  • Approve content outputs
Why this separation: Infrastructure enables quality, marketing architects define quality.

​
Meta Command Extensibility (Request to Infrastructure)

Marketing architects can:
  • Request new meta commands
  • Describe workflows they want to systematize
  • Suggest improvements to existing meta commands
Infrastructure team:
  • Evaluates requests for architectural fit
  • Implements meta commands that benefit all users
  • Ensures consistency with existing patterns
Example: 
Marketing Architect request:
"I want a meta command that creates a new research domain
with the three-folder pattern (data/execution/exports) automatically."

Infrastructure response:
"Great idea. We'll add 'create domain: [name]' meta command
that scaffolds the structure and RESEARCH.md template."
Why this model: Meta commands are infrastructure (systematic, reusable), but marketing architects know what workflows need systematizing.

​
Contribution Workflow

​
How Marketing Architects Add Components

1. Adding a New Sub-agent Steps: 
1. Create file: .claude/agents/{role-name}.md
2. Define:
   - Role and purpose
   - Skills available to this agent
   - Communication style/tone
   - Responsibilities
3. Follow template structure (see existing agents)
4. Reference skills that exist (or create new skills first)
5. No infrastructure approval needed
Example: 
# .claude/agents/campaign-strategist.md

Role: Campaign Strategist
Purpose: Plan and coordinate multi-channel campaigns

Skills:
  - Planning Campaign Sequences
  - Coordinating Multi-Touch Workflows
  - Analyzing Campaign Performance

Tone: Strategic, big-picture, collaborative
2. Adding a New Skill Steps: 
1. Create directory: .claude/skills/{skill-name}/
2. Create SKILL.md (entry point, < 500 lines)
3. Create detailed methodology files
4. Ensure progressive disclosure (SKILL.md points to details)
5. Reference tools if needed (downward dependency)
6. Optional: Request infrastructure review for structural compliance
Example: 
.claude/skills/analyzing-social-sentiment/
├── SKILL.md                 ← Entry point (methodology overview)
├── platform-analysis.md     ← Detailed: How to analyze each platform
├── sentiment-scoring.md     ← Detailed: Scoring methodology
└── reporting-framework.md   ← Detailed: How to structure findings
3. Adding a Domain Command Steps: 
1. Create file: .claude/commands/{domain}/{command-name}.md
2. Define:
   - What the command does
   - Which agents to use
   - Which skills to leverage
   - Expected outputs
3. Use domain-driven organization
4. No infrastructure approval needed
Example: 
# .claude/commands/campaigns/launch-sequence.md

## Purpose
Create multi-channel launch campaign for new product/feature

## Workflow
1. Campaign Strategist creates campaign plan (PLAN.md)
2. Content Writer generates assets for each channel
3. Brand Analyst validates messaging consistency
4. Export deliverables to /projects/launch-{date}/

## Expected Outputs
- Campaign strategy doc
- Email sequence (3 emails)
- Social posts (10 posts across platforms)
- Blog post
- Landing page copy
4. Adding Brand Strategy Files Steps: 
1. Create files in /strategy/{domain}/
2. Follow 3-level hierarchy maximum
3. Use progressive disclosure (index.md as entry point)
4. Add frontmatter with metadata
5. Reference research via footnotes
6. No infrastructure approval needed
5. Adding Research Domains Steps: 
1. Create directory: /research/{domain}/
2. Create RESEARCH.md (progressive disclosure entry point)
3. Create three folders:
   - /data/ (input materials)
   - /execution/ (date-stamped runs)
   - /exports/ (final deliverables)
4. Run research using plan/implement pattern
5. Reference in strategy via footnotes

​
When to Ask Infrastructure Team for Help

​
Marketing Architects Should Ask When:

1. Structural questions 
❌ Wrong: "Is my brand voice good?"
   (Infrastructure doesn't judge content quality)

✅ Right: "Should this voice guideline be in index.md or an extension?"
   (Infrastructure helps with structure)
2. Architectural compliance 
❌ Wrong: "Does this research methodology make sense?"
   (Infrastructure doesn't review methodology)

✅ Right: "Is this creating a circular dependency between skill and agent?"
   (Infrastructure ensures one-way dependencies)
3. Meta command usage 
✅ "How do I use the plan/implement pattern for this complex workflow?"
✅ "Is there a meta command for scaffolding research domains?"
✅ "Can I request a new meta command for X workflow?"
4. Validation errors 
✅ "Validation tool flagged a contradiction—how do I fix it?"
✅ "Why is the progressive disclosure check failing?"
✅ "How do I resolve this dependency issue?"
5. System evolution 
✅ "I need a capability that doesn't exist—should this be a meta command?"
✅ "This pattern keeps coming up—should we systematize it?"
✅ "Can the framework support X use case?"

​
Marketing Architects Should NOT Ask When:

❌ Content quality questions 
"Is this brand voice appropriate?"
"Does this research finding make sense?"
"Is this content good enough?"

→ These are marketing decisions, not infrastructure questions
❌ Strategic decisions 
"Which messaging pillars should I use?"
"What should my brand positioning be?"
"How should I organize my research?"

→ Marketing architects own strategy
❌ Tool selection 
"Which research tool should I use?"
"Should I integrate Figma or Canva?"

→ Marketing architects choose their tools

​
Governance Model Summary

​
The Principle

Infrastructure team ensures: “The system works consistently” Marketing architects ensure: “The system produces great marketing”

​
The Boundaries

Infrastructure controls:
  • How components interact (architecture)
  • How work flows (meta commands)
  • How quality is validated (tooling)
  • How the system scales (patterns)
Infrastructure does NOT control:
  • What brand strategy to use
  • What research to conduct
  • What content to create
  • What tools to integrate
Marketing architects control:
  • Brand strategy and voice
  • Research domains and execution
  • Team structure (agents)
  • Workflows (commands)
  • Capabilities (skills)
  • Tool selection
Marketing architects do NOT control:
  • Core architecture rules
  • Meta command behavior
  • Output style (operations manager)
  • Validation patterns

​
The Collaboration

Work together on:
  • Skill creation (MA describes, infra validates structure)
  • Meta command evolution (MA requests, infra implements)
  • Validation tooling (MA provides use cases, infra builds)
  • Documentation (infra writes, MA provides feedback)

​
Review & Approval Gates

​
What Requires Infrastructure Review

Structural compliance (optional but recommended):
  • New skills (ensure progressive disclosure, one-way dependencies)
  • Complex agent definitions (validate no circular references)
  • Custom integrations (ensure they fit architecture)
Review focus:
  • ✅ Does it follow progressive disclosure?
  • ✅ Are dependencies one-way?
  • ✅ Does it fit the 3-level hierarchy?
  • ✅ Is naming consistent?
Review does NOT cover:
  • ❌ Content quality
  • ❌ Methodology rigor
  • ❌ Strategic soundness

​
What Does NOT Require Review

Marketing architects have full autonomy:
  • Brand strategy files (any content, any structure within 3 levels)
  • Research execution (run whenever, however they want)
  • Content outputs (no approval needed)
  • Tool configuration (choose and configure as needed)
  • Work artifacts (PLAN.md, TODO.md, deliverables)

​
Evolution & Contribution

​
How the Framework Evolves

Infrastructure-driven evolution: 
User feedback → Infrastructure team evaluates
  ↓
Architectural improvement identified
  ↓
Meta command, core skill, or validation tool created
  ↓
Released to all users
  ↓
Documentation updated
Marketing architect-driven evolution: 
Marketing architect builds new capability (skill, agent, command)
  ↓
Shares with community (optional)
  ↓
Other marketing architects adapt for their use
  ↓
Infrastructure team sees pattern
  ↓
Consider systematizing via meta command

​
Contribution Flow

1. Individual use 
Marketing architect creates agent/skill/command for their needs
No sharing required, full autonomy
2. Community sharing (future) 
Marketing architect shares skill with community
Other marketing architects can adopt/adapt
Infrastructure team doesn't gate this
3. Framework integration 
Infrastructure team identifies widely useful pattern
Builds into core framework or meta command
Benefits all users systematically

​
Success Criteria

Ownership model is working when: ✅ Infrastructure team focuses on architecture, not content ✅ Marketing architects build freely within structural boundaries ✅ No confusion about who owns what ✅ Collaboration happens on gray areas (skill creation, meta commands) ✅ Reviews focus on structure, not quality ✅ Framework evolves based on user needs ✅ Marketing architects feel empowered (not constrained) ✅ Architectural integrity is maintained Ownership model is failing when: ❌ Infrastructure team reviews content quality ❌ Marketing architects can’t add capabilities without approval ❌ Confusion about boundaries ❌ All changes require infrastructure team ❌ Framework doesn’t evolve based on usage ❌ Marketing architects feel constrained ❌ Architectural integrity is violated

​
Summary

The ownership model creates clear boundaries that enable both flexibility and consistency: Infrastructure team owns:
  • claude.md (architectural rules)
  • Output styles (compliance)
  • Meta commands (systematic workflows)
  • Core skills (orchestration)
  • Framework structure
  • Validation tooling
Marketing architects own:
  • Brand strategy (/strategy/)
  • Research (/research/)
  • Sub-agents (.claude/agents/)
  • Domain commands (.claude/commands/)
  • Domain skills (.claude/skills/)
  • Tool selection (.mcp.json)
Collaborate on:
  • Skill creation (methodology + structure)
  • Meta command evolution (needs + implementation)
  • Quality tooling (use cases + build)
The principle: Infrastructure enables; marketing architects create. This model ensures vibeflow can scale (consistent architecture) while remaining flexible (customizable strategy, team, capabilities).