Skills vs Agents

gistfile1.md

Skills vs Agents: Architecture Guide

Skills vs Agents: Different Purposes

/engineer Skill (Role-based session)

Best for:

• Full engineering sessions with iterative work
• Multiple related tasks that build on each other
• Maintaining conversation context across tasks
• When you want consistent engineering constraints throughout

How it works:

• Loads a prompt that modifies behavior for the entire session
• You work with one continuous context
• Each task has access to previous work
• Simpler user experience - no context switching

Example flow:

User: /engineer
User: Fix the authentication bug
[Agent fixes it with full context]
User: Now add tests for that
[Agent knows exactly what was just fixed]
User: And update the documentation
[Agent references the changes made]

@engineer Agent (Task-based subprocess)

Best for:

• Bounded, specific engineering tasks
• Running multiple tasks in parallel
• Isolating context for focused work
• When you don't need previous conversation history

How it works:

• Separate subprocess with its own context
• Does one specific thing and returns
• Doesn't pollute main conversation
• Can run in background or parallel

Example flow:

User: [in main session]
Assistant: [launches @engineer agent to implement feature]
Assistant: [launches another @engineer for different feature]
[Both run in parallel, return results]

Your Current Pattern (Which Makes Sense)

Looking at what you've built:

Skills (session roles):

• /analyst - Planning/documentation sessions
• /engineer - Implementation sessions
• /devops - Infrastructure sessions

Agents (specific tasks):

• @route-auditor - Audit routes
• @rust-patterns - Review backend code
• @blog-writer - Draft blog posts
• @migration-reviewer - Review migrations
• @issue-drafter - Create GitHub issues

Recommendation

Keep your current architecture:

1. Use /engineer skill when:

   • User explicitly wants to work in engineering mode
   • Multiple related implementation tasks
   • Iterative development that builds context
   • Teaching/explaining while implementing

2. Use task-specific agents when:

   • Proactive checks (route auditing after route changes)
   • Parallel execution (review migration + check routes)
   • Focused reviews (rust patterns, scope checking)
   • Specialized knowledge domains (blog writing)

3. Don't create @engineer agent because:

   • Engineering work is usually iterative and context-dependent
   • You'd lose the benefit of conversation history
   • Skills already provide the role-based constraints you need
   • The task-specific agents (rust-patterns, route-auditor) already cover focused engineering reviews

When You Might Want @engineer Agent

The only case I can think of:

• Running multiple independent engineering tasks in parallel
• "Implement feature A and feature B simultaneously"
• But this is rare and could cause merge conflicts

TL;DR

Skills = "I want to be an engineer/analyst for this whole session" Agents = "Do this specific specialized task and report back"

Your current setup is correct. The /engineer skill provides role-based session behavior, while task-specific agents (@rust-patterns, @route-auditor) provide focused reviews. No need for an @engineer agent.