complexity-assessment

AI-based complexity assessment for task analysis. Use when determining the appropriate workflow, phases, and validation depth for a task.

Jump to install

Repository: oimiragieo/agent-studio
Last source activity: April 21, 2026 at 23:45
Detected SKILL.md language: English
Stars: 36
Forks: 6

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

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

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.
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.
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.
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.
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

# Read the requirements file
cat .claude/context/requirements/[task-name].md

discovery → quick_spec → validation

discovery → requirements → context → spec_writing → planning → validation

discovery → requirements → research → context → spec_writing → planning → validation

discovery → requirements → research → context → spec_writing → self_critique → planning → validation

Risk Level	When to Use	Validation Depth
TRIVIAL	Docs-only, comments, whitespace	Skip validation entirely
LOW	Single area, < 5 files, no DB/API changes	Unit tests only
MEDIUM	Multiple files, 1-2 areas, API changes	Unit + Integration tests
HIGH	Database changes, auth/security, cross-service	Unit + Integration + E2E + Security
CRITICAL	Payments, data deletion, security-critical	All above + Manual review + Staging

# Complexity Assessment: [Task Name]

## Summary

| Dimension     | Assessment                                        |
| ------------- | ------------------------------------------------- |
| Complexity    | [simple/standard/complex]                         |
| Workflow Type | [feature/refactor/investigation/migration/simple] |
| Confidence    | [0.0-1.0]                                         |

## Reasoning

[2-3 sentence explanation]

## Analysis

### Scope

- Estimated files: [number]
- Estimated areas: [number]
- Cross-cutting: [yes/no]
- Notes: [brief explanation]

### Integrations

- External services: [list]
- New dependencies: [list]
- Research needed: [yes/no]
- Notes: [brief explanation]

### Infrastructure

- Docker changes: [yes/no]
- Database changes: [yes/no]
- Config changes: [yes/no]
- Notes: [brief explanation]

### Knowledge

- Patterns exist: [yes/no]
- Research required: [yes/no]
- Unfamiliar tech: [list]
- Notes: [brief explanation]

### Risk

- Level: [low/medium/high]
- Concerns: [list]
- Notes: [brief explanation]

## Recommended Phases

1. [phase1]
2. [phase2]
3. ...

## Validation Recommendations

| Setting          | Value                              |
| ---------------- | ---------------------------------- |
| Risk Level       | [trivial/low/medium/high/critical] |
| Skip Validation  | [yes/no]                           |
| Minimal Mode     | [yes/no]                           |
| Test Types       | [unit, integration, e2e]           |
| Security Scan    | [yes/no]                           |
| Staging Required | [yes/no]                           |

**Reasoning**: [1-2 sentences explaining validation depth]

## Flags

- Needs research: [yes/no]
- Needs self-critique: [yes/no]
- Needs infrastructure setup: [yes/no]

START
  |
  +--> Are there 2+ external integrations OR unfamiliar technologies?
  |     YES -> COMPLEX (needs research + critique)
  |     NO
  |      |
  +--> Are there infrastructure changes (Docker, DB, new services)?
  |     YES -> COMPLEX (needs research + critique)
  |     NO
  |      |
  +--> Is there 1 external integration that needs research?
  |     YES -> STANDARD + research phase
  |     NO
  |      |
  +--> Will this touch 3+ files across 1-2 areas?
  |     YES -> STANDARD
  |     NO
  |      |
  +--> SIMPLE (1-2 files, single area, no integrations)

Anti-Pattern	Why It Fails	Correct Approach
Assigning SIMPLE without file scan	Underestimates actual affected file count	Count affected files before assigning tier
"Quick fix" language lowers tier	User perception ≠ technical scope	Assess objectively; ignore casual user framing
Ignoring integrations and external APIs	External dependencies add risk and complexity	List all external services/APIs in the assessment
Skipping research flag for unknown tech	Unfamiliar tech has invisible complexity	Flag any unfamiliar technology for research
Not considering rollback complexity	COMPLEX/EPIC need recovery plans	Include rollback difficulty in complexity scoring