complexity-assessment

name	complexity-assessment
description	AI-based complexity assessment for task analysis. Use when determining the appropriate workflow, phases, and validation depth for a task.
version	1.1.0
model	sonnet
invoked_by	both
user_invocable	true
tools	["Read","Glob","Grep"]
best_practices	["Be conservative - when in doubt, go higher complexity","Flag research needs for unfamiliar technologies","Consider hidden complexity in optional features"]
error_handling	graceful
streaming	supported
source	community
verified	true
lastVerifiedAt	"2026-02-22T00:00:00.000Z"
trust_score	100
provenance_sha	7652f9aa7a58db3f

Complexity Assessment Skill

Overview

Analyze a task description and determine its true complexity to ensure the right workflow and validation depth are selected. Accuracy over speed - wrong complexity means wrong workflow means failed implementation.

Core principle: Accuracy over speed. Wrong complexity = wrong workflow = failed implementation.

When to Use

Always:

• Before planning any new task
• When requirements are gathered but approach unclear
• When determining validation depth for QA

Exceptions:

• Obvious simple fixes (typos, color changes)
• Tasks where complexity is explicitly specified

Iron Laws

1. NEVER begin planning without complexity assessment — wrong complexity tier = wrong workflow = failed implementation; always assess first, then select the appropriate workflow phases and validation depth.
2. ALWAYS be conservative when uncertain — go higher — underestimating complexity is more dangerous than overestimating; a COMPLEX task mis-classified as STANDARD skips security review, architecture design, and comprehensive testing.
3. ALWAYS count affected files before assigning a tier — gut-feel estimates are unreliable; scan the codebase to count files actually touched by the change before assigning SIMPLE/STANDARD/COMPLEX/EPIC.
4. ALWAYS flag unfamiliar technologies for research — unknown tech has hidden complexity; mark any unfamiliar framework, library, or service as requiring research before proceeding with the complexity estimate.
5. NEVER let the user's casual language lower the tier — "just a quick fix" or "small change" reflects the user's perception, not the actual technical scope; assess objectively regardless of how it is described.

Workflow Types

Determine the type of work being requested:

FEATURE

• Adding new functionality to the codebase
• Enhancing existing features with new capabilities
• Building new UI components, API endpoints, or services
• Examples: "Add screenshot paste", "Build user dashboard", "Create new API endpoint"

REFACTOR

• Replacing existing functionality with a new implementation
• Migrating from one system/pattern to another
• Reorganizing code structure while preserving behavior
• Examples: "Migrate auth from sessions to JWT", "Refactor cache layer"

INVESTIGATION

• Debugging unknown issues