complexity-assessment

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

الانتقال إلى التثبيت

المستودع: oimiragieo/agent-studio
آخر نشاط في المصدر: ٢١ أبريل ٢٠٢٦ في ٢٣:٤٥
لغة SKILL.md المكتشفة: الإنجليزية
النجوم: ٣٦
التفرعات: ٦

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

العودة إلى البحث العودة إلى التثبيت

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