Agent-Skills.md

Agent Skills: Workflow Guide

Helps choose between solo, small team, and full team workflow modes

UncategorizedID: mhylle/claude-skills-collection/workflow-guide
12

Install this agent skill to your local

pnpm dlx add-skill https://github.com/mhylle/claude-skills-collection/tree/HEAD/skills/workflow-guide

Skill Files

Browse the full folder contents for workflow-guide.

Download Skill

Loading file tree…

skills/workflow-guide/SKILL.md

Skill Metadata

Name
workflow-guide
Description
Recommend which workflow mode fits the task at hand — solo (implement-plan), small team (team-implement-plan with Implementer + Reviewer), full team (team-implement-plan-full with parallel per-phase implementers + shared Reviewer), or a dynamic workflow (the Workflow tool — deterministic parallel fan-out across tens-to-hundreds of background agents for large read/analyze/audit/research jobs, e.g. /tt-workflow-audit). Factors in task complexity, risk, parallelism, work shape (analyze vs implement), and token budget. Use when the user asks which workflow to pick, is unsure whether to go solo or team-based, mentions "which mode should I use", asks "solo or team for this", "should I use a workflow", "parallel audit", or is about to kick off execution without having chosen a mode. Triggers on "/workflow-guide", "which workflow mode", "solo or team", "pick a workflow", "dynamic workflow or team".

Workflow Guide

A lightweight decision skill that recommends the appropriate workflow mode based on your task characteristics.

Overview

The skills collection offers three team-shaped workflow modes for the ideation → planning → implementation pipeline, plus a fourth dynamic-workflow lane on a different axis (deterministic parallel fan-out for analyze/audit/research work).

| Mode | Ideation | Planning | Implementation | Best for | |------|----------|----------|---------------|----------| | Solo | /brainstorm | /create-plan | /implement-plan | Sequential, focused work | | Small team | /team-brainstorm | /team-create-plan | /team-implement-plan | Adversarial review, moderate scope | | Full team | /team-brainstorm | /team-create-plan | /team-implement-plan-full | Parallel phases + live cross-phase review | | Dynamic workflow | — | — | /tt-workflow-audit (and future tt-workflow-*) | Large, parallel, read/analyze/audit/research fan-out with aggregable output |

The first three vary on the same axis (scope × stakes × parallelism, for implementing a plan). Dynamic workflow is a different axis — it's about work shape: a job that is embarrassingly parallel, mostly read/analyze, with aggregable per-unit output, and benefits from deterministic resumable orchestration. Decide work shape FIRST (Question 0), then — if it's an implement-the-plan job — pick solo/small/full team.

Initial Response

When invoked, respond:

"I'll help you pick the right workflow mode. Let me ask a few quick questions about your task."

Assessment Questions

Ask these questions in order. After the user answers, you may have enough information to recommend immediately — do not ask unnecessary questions.

Question 0: Work shape (ask first)

"Is this about building/changing something (implement a plan), or analyzing across many units (audit, research, classify a backlog, scan every file/component)?"

  • A) Implement — write/change code toward a goal → continue to Question 1 (solo / small / full team).
  • B) Analyze-at-scale — a large, parallel, read/analyze-heavy job with aggregable per-unit output (audit the whole repo, find all duplicates/drift, research N sources, generate per-phase briefs) → Dynamic Workflow (skip Q1–Q3). For tasktracker projects, route to /tt-workflow-audit (or another tt-workflow-*).

If B, recommend Dynamic Workflow and read the caveats below before kicking it off. If A, proceed:

Question 1: Scope

"How would you describe the scope of this work?"

  • A) Small — A single feature, bug fix, or focused change (1-2 files, clear requirements)
  • B) Moderate — Multiple related changes across several files (3-10 files, some design decisions needed)
  • C) Large — A system-level change, new subsystem, or multi-phase project (10+ files, architectural decisions required)

Question 2: Stakes

"How critical is quality for this change?"

  • A) Low — Internal tooling, prototype, or experiment. Speed matters more than perfection
  • B) Medium — Production code, but well-tested area. Standard quality expectations
  • C) High — Security-sensitive, user-facing, or high-risk area. Adversarial review needed

Question 3: Parallelism Potential

Only ask this if Scope is Moderate or Large:

"Can parts of this work be done independently and in parallel?"

  • A) No — Each step depends on the previous one
  • B) Somewhat — Some parts are independent, but there are key dependencies
  • C) Yes — Multiple phases could proceed simultaneously with clear boundaries

Recommendation Logic

Use the answers to recommend a mode:

Solo Mode

Recommend when:

  • Scope is Small (regardless of other answers)
  • Scope is Moderate AND Stakes are Low
  • Scope is Moderate AND Parallelism is No

Why: Minimal overhead, fastest for focused work. The orchestrator + subagent pattern handles sequential implementation efficiently.

Token cost: ~30-40K per phase

Small Team Mode

Recommend when:

  • Scope is Moderate AND Stakes are Medium or High
  • Scope is Moderate AND Parallelism is Somewhat
  • Scope is Large AND Parallelism is No
  • Scope is Large AND Stakes are Medium (and phases are sequential)

Why: Adds adversarial review without the overhead of parallel execution. The Implementer/Reviewer dynamic catches issues that automated checks miss.

Token cost: ~60-80K per phase

Full Team Mode

Recommend when:

  • Scope is Large AND Parallelism is Somewhat or Yes
  • Scope is Large AND Stakes are High
  • Any combination where the plan has 4+ phases with independent work streams

Why: Parallel execution across phases with cross-phase review. Worth the coordination cost when you have genuinely independent work streams.

Token cost: ~100-150K per wave

Dynamic Workflow Mode (mechanism C — the Workflow tool)

Recommend when (from Question 0 = B):

  • The job is large, embarrassingly parallel, and read/analyze-heavy with aggregable per-unit output — audit every file/component, find all duplicates or architecture drift, research N sources, generate per-phase briefs, classify a backlog.
  • You want deterministic, resumable orchestration over tens-to-hundreds of units, governed by a shared token budget, that survives a crash/rate-limit and resumes without re-running completed units.

Why: code-driven (not model-driven) fan-out with schema-checked per-agent output and journaled resume — strictly better than Agent Teams for throughput when units don't need to negotiate live. For tasktracker projects, use /tt-workflow-audit (more tt-workflow-* skills as they land).

Don't use it for: sequential dependent work, anything that must branch on results mid-run (a deterministic script can't), or live debate between a few agents (that's Full/Small Team). The parallel-write implement variant waits on the work-lease registry — until then, write-heavy parallel implementation stays Full Team.

Token cost: scales with fan-out; governed by the shared token budget (set a target like +500k to bound it).

⚠️ TaskTracker caveats (read before running): the workflow script orchestrates and the parent / main loop performs all tasktracker writes — parallel agents are read-only and return schema output the parent applies serially (single global active-task pointer; agents can't each hold one). Background workflow agents can reach the tasktracker MCP (API-key stdio, probe-verified) but must not call setActiveTask or any write tool. Full rules: ~/.claude/skills/tt-workflow-audit/references/workflow-tasktracker-contract.md.

Decision Matrix

First apply Question 0: if the work is analyze-at-scale (audit / research / classify / scan-everything), recommend Dynamic Workflow (/tt-workflow-audit) and skip this matrix. The matrix below is for implement-the-plan work only.

| Scope | Stakes | Parallelism | Recommendation | |-------|--------|-------------|---------------| | Small | Any | N/A | Solo | | Moderate | Low | Any | Solo | | Moderate | Medium | No | Solo | | Moderate | Medium | Somewhat/Yes | Small Team | | Moderate | High | Any | Small Team | | Large | Low | No | Solo | | Large | Low | Somewhat/Yes | Small Team | | Large | Medium | No | Small Team | | Large | Medium | Somewhat/Yes | Full Team | | Large | High | No | Small Team | | Large | High | Somewhat/Yes | Full Team |

Output Format

After assessment, present the recommendation:

## Recommendation: [Mode Name]

**Your answers:** Scope: [answer] | Stakes: [answer] | Parallelism: [answer]

### Why this mode?
[1-2 sentences explaining the fit]

### What to do next

| Stage | Command |
|-------|---------|
| Ideation (if needed) | `/{command}` |
| Planning | `/{command}` |
| Implementation | `/{command}` |

### Alternative to consider
[If the recommendation is borderline, mention the adjacent mode and when to switch]

Examples

Example 1: Small bug fix

User: "I need to fix a date formatting bug in the dashboard."

Assessment: Scope: Small. No further questions needed.

Recommendation: Solo mode. Use /create-plan then /implement-plan.

Example 2: New authentication system

User: "I want to add OAuth2 support with Google and GitHub providers."

Assessment: Scope: Large (new subsystem, multiple integration points). Stakes: High (security-sensitive). Parallelism: Somewhat (Google and GitHub providers are independent, but share auth infrastructure).

Recommendation: Full Team mode. Use /team-brainstorm to explore the design, /team-create-plan for adversarial planning, /team-implement-plan-full for parallel provider implementation with shared review.

Example 3: Refactoring a module

User: "I want to refactor the data processing module to use the new streaming API."

Assessment: Scope: Moderate (multiple files, design decisions). Stakes: Medium (production code). Parallelism: No (sequential refactoring).

Recommendation: Solo mode. The refactoring is sequential by nature. Use /create-plan then /implement-plan. Consider Small Team if you want adversarial review of the refactoring approach during planning (/team-create-plan).

Example 4: Audit an inherited codebase

User: "I need to find all the architecture drift, duplicate tasks, and risky modules across this whole repo."

Assessment: Question 0 = B (analyze-at-scale) — embarrassingly parallel, read/analyze-heavy, aggregable per-unit output, large scope.

Recommendation: Dynamic Workflow. Use /tt-workflow-audit — it partitions the repo/backlog/components, fans out one read-only agent per partition, aggregates a risk register, and (with your OK) writes fix tasks back under a Bug Fix phase from the parent. Resumable if it's interrupted. No team mode needed — the units don't negotiate, they just report.