Prompt Complexity Scorer

This skill evaluates user prompts to determine if they require planning before implementation.

Scoring Criteria

Score each prompt on a 1-10 scale based on these factors:

Score Calculation

1. Evaluate each factor independently
2. Average the factor scores
3. Round to nearest integer

Behavior by Score

Score 1-4: Continue Normally

Do not mention the scoring. Proceed with the request immediately.

Score 5-10: Suggest Project

Pause and ask the user:

This request scores [X]/10 on complexity. I suggest creating a project to track this work properly.

Would you like me to create `projects/<date>-<suggested-name>/` with a brief.md?

Where <date> is today’s date in YYYY-MM-DD format and <suggested-name> is a kebab-case name derived from the request (e.g., “2026-01-24-add-websockets”, “2026-01-24-refactor-auth-system”).

Project Setup

When creating a project, create the directory structure and brief.md:

# Get today's date
DATE=$(date +%Y-%m-%d)
mkdir -p projects/${DATE}-<suggested-name>/tasks

# <Title derived from prompt>

## Original Request

<User's exact prompt/request>

## Goals

<Bullet points summarizing what needs to be accomplished>

## Notes

<Any additional context or constraints mentioned>

After creating the project, inform the user:

Project created at `projects/<date>-<suggested-name>/`.

You can now:
- Run `/project:bootstrap @projects/<date>-<suggested-name>` for full research and planning
- Or continue with the request and tasks will be tracked in this project

IMPORTANT: After creating the project, set the active project context by creating a marker file:

echo "${DATE}-<suggested-name>" > .claude-active-project

This enables automatic task syncing to the project directory.

Examples

Example 1: Simple Request (Score 1)

Prompt: “Fix the typo in the error message on line 45 of user.service.ts”

Factors:

• Scope: 1 (single line)
• Clarity: 1 (exact location specified)
• Dependencies: 1 (none)
• Unknowns: 1 (none)
• Risk: 1 (trivial change)

Score: 1 → Continue normally

Example 2: Complex Request (Score 7)

Prompt: “Add WebSocket support to this project”

Factors:

• Scope: 8 (new system, multiple files)
• Clarity: 6 (what kind of WebSocket? real-time features?)
• Dependencies: 7 (infrastructure, client changes)
• Unknowns: 7 (architecture decisions needed)
• Risk: 7 (architectural change)

Score: 7 → Suggest creating projects/YYYY-MM-DD-add-websockets/

Example 3: Medium Request (Score 3)

Prompt: “Add a new field ‘nickname’ to the User entity”

Factors:

• Scope: 4 (entity, migration, possibly resolvers)
• Clarity: 2 (clear requirement)
• Dependencies: 3 (migration, schema)
• Unknowns: 2 (standard pattern)
• Risk: 3 (database change but reversible)

Score: 3 → Continue normally

Example 4: Nebulous Request (Score 8)

Prompt: “Make the app faster”

Factors:

• Scope: 9 (entire application)
• Clarity: 9 (completely vague)
• Dependencies: 8 (unknown until investigated)
• Unknowns: 9 (what’s slow? why?)
• Risk: 6 (depends on changes)

Score: 8 → Suggest creating projects/YYYY-MM-DD-performance-optimization/

Important Notes

• This evaluation should be quick and silent for low-complexity requests
• Never mention the scoring system for scores 1-4
• For borderline cases (score 4-5), lean toward continuing normally
• The goal is to catch truly complex/nebulous requests that benefit from planning