Task-to-Config Analyzer Skill

Purpose

Analyze a set of implementation tasks (from

ai-state/active/tasks.yaml

) and identify opportunities to create master configuration files using the

core:generate-config

command. This skill bridges planning and documentation by automatically detecting when a group of tasks represents a cohesive feature that would benefit from a configuration document.

When to Use

Invoke this skill when:

• ✅ You have a

  tasks.yaml

  file with multiple related tasks
• ✅ You want to identify which features need configuration documentation
• ✅ Before executing tasks, to plan what configs should be created
• ✅ After brainstorming, to determine documentation needs
• ✅ When tasks span multiple components/files (backend, frontend, database)

Input

The skill analyzes

ai-state/active/tasks.yaml

which contains structured tasks like:

epic: taskflow-prototype
phase: prototype
sprint: sprint-1
milestone: milestone-1-working-api

tasks:
  - task:
      id: task-001-fastapi-setup
      context: backend
      where: main.py
      what: Create FastAPI app with basic structure

  - task:
      id: task-002-task-model
      context: backend
      where: models.py
      what: Create Task Pydantic model

  - task:
      id: task-003-crud-endpoints
      context: backend
      where: routes/tasks.py
      what: Implement CRUD endpoints

Analysis Process

Step 1: Read tasks.yaml

1. Load

   ai-state/active/tasks.yaml

2. Extract metadata: epic, phase, sprint, milestone
3. Parse all tasks

Step 2: Group Related Tasks

Identify task groups that share:

• Context clustering - Tasks with same

  context

  value (backend, frontend, test, etc.)
• Feature clustering - Tasks with related

  what

  descriptions (e.g., all about "authentication")
• File clustering - Tasks affecting related files (e.g., all in

  api/auth/

  )
• Dependency chains - Tasks that reference each other in

  when

  field

Step 3: Identify Config Opportunities

For each cluster, determine if it warrants a config file based on:

High Priority (definitely create config):

• 3+ tasks affecting multiple file types (backend + frontend + database)
• Tasks implementing a complete user-facing feature
• Tasks touching 5+ different files
• Tasks with complex dependencies (task A → B → C)

Medium Priority (consider config):

• 2+ tasks in same context affecting 3+ files
• Tasks implementing a cohesive backend API
• Tasks implementing a UI component with state management

Low Priority (skip config):

• Single isolated task
• Simple file modifications
• Test-only tasks
• Deployment/infrastructure tasks (unless complex multi-step)

Step 4: Extract Config Parameters

For each identified config opportunity, extract:

Use Case Information:

• name

  - Derived from task IDs and

  what

  descriptions

• description

  - Synthesized from task goals

• entry_points

  - Extracted from

  where

  fields (API endpoints, UI routes)

• user_role

  - Inferred from context and feature type

• success_criteria

  - Combined from task

  goal

  and

  close

  fields

Code Components:

• path

  - From task

  where

  fields

• type

  - Inferred from file extension and context

  • .py

    in backend → "api-endpoint" or "model"

  • .tsx/.jsx

    → "component"

  • .ts

    in services → "service"
  • Database files → "schema"

• purpose

  - From task

  what

  field

• dependencies

  - Extracted from task

  when

  dependencies

User Interaction:

• steps

  - Ordered list from task execution order

• action

  - From task

  what

  descriptions

• triggers

  - API endpoints from

  where

  fields

• ui_components

  - Frontend files from

  where

  fields

Step 5: Generate Recommendations Document

Create a document at

ai-state/config/config-opportunities.md

with:

IMPORTANT: When referencing generated config files in the "Next Steps" section, always use the full path format

ai-state/config/{name}-config.md

in markdown links, NOT the relative path. This ensures the sprint completion script can detect and validate configs properly.

Example:

## Next Steps

1. ✅ Review generated high-priority config: [ai-state/config/task-api-crud-config.md](ai-state/config/task-api-crud-config.md)

# Configuration Opportunities

**Generated from:** ai-state/active/tasks.yaml
**Epic:** [epic-name]
**Phase:** [phase]
**Generated:** [timestamp]

## High Priority Configs

### 1. [Feature Name]

**Why:** [Reasoning - e.g., "Involves backend API, frontend UI, and database changes across 8 files"]

**Affected Tasks:**
- task-001-[name]
- task-002-[name]
- task-005-[name]

**Suggested Config Name:** `[feature-name]-config.md`

**Recommended Input for core:generate-config:**

```yaml
use_case:
  name: "[feature-name]"
  description: "[synthesized description]"
  entry_points: ["[API endpoints]", "[UI routes]"]
  success_criteria: "[combined goals]"

code_components:
  - path: "[file-path]"
    type: "[component-type]"
    purpose: "[what this does]"
  # ... more components

Create with:

/core:generate-config
# Then paste the above YAML when prompted

---

2. [Next Feature Name]

...

Medium Priority Configs

1. [Feature Name]

...

Low Priority / Skip

The following task clusters are too simple for dedicated configs:

• task-010-[name] - Single file update
• task-011-[name] - Test-only task

## Output

The skill creates:

1. **`ai-state/config/config-opportunities.md`** - Main recommendations document
2. **Summary in console** - Quick overview of findings

Example summary:

📊 Task Analysis Complete

Analyzed: 15 tasks from taskflow-prototype Found: 3 config opportunities

High Priority (create now): ✓ user-authentication (tasks 1-5, 8 files) ✓ task-crud-operations (tasks 6-10, 6 files)

Medium Priority (consider): ○ api-error-handling (tasks 11-13, 3 files)

Recommendations saved to: ai-state/config/config-opportunities.md

Next steps:

1. Review recommendations
2. Run /core:generate-config for high priority items
3. Use generated configs to guide task execution

## Analysis Heuristics

### Detecting Feature Clusters

**Authentication/Authorization:**
- Keywords: "login", "register", "auth", "JWT", "token", "permission", "role"
- Files: Contains "auth", "user", "session"
- Context: Backend + Frontend combination

**CRUD Operations:**
- Keywords: "create", "read", "update", "delete", "list", "get", "post", "put", "patch"
- Files: Contains "api", "routes", "endpoints"
- Pattern: Multiple tasks with same resource name (e.g., "task")

**UI Component System:**
- Keywords: "component", "form", "modal", "dialog", "list", "card"
- Files: .tsx, .jsx in components/
- Context: Frontend

**Data Model:**
- Keywords: "model", "schema", "migration", "table"
- Files: models/, schema/, migrations/
- Context: Backend

**State Management:**
- Keywords: "store", "state", "context", "reducer", "action"
- Files: store/, context/, hooks/
- Context: Frontend

## Edge Cases

**Scattered Tasks:**
If tasks don't cluster well:
- Create single "project-overview" config
- Document all major components
- Focus on architecture diagrams

**Many Small Features:**
If 10+ small clusters:
- Combine related clusters
- Create configs only for most complex
- Suggest incremental config creation

**Single Large Feature:**
If all tasks are one cluster:
- Create single comprehensive config
- Suggest breaking into sub-configs (backend, frontend, database)

## Success Criteria

✅ All task clusters identified correctly
✅ Config priorities make sense (complex features = high priority)
✅ Generated YAML is valid and complete
✅ File paths and component types are accurate
✅ Next steps are clear and actionable

## Integration with Framework

**Input From:**
- `ai-state/active/tasks.yaml` - Tasks to analyze
- Current phase from `.khujta/phase.json` - Affects complexity tolerance

**Output To:**
- `ai-state/config/config-opportunities.md` - Recommendations
- Used by developers to decide what to document
- Used as input to `/core:generate-config` command

**Workflow:**

/core:brainstorm (refine idea) ↓ /core:write-plan (create tasks.yaml) ↓ [Use this skill] (identify config needs) ↓ /core:generate-config (create configs) ↓ /core:execute-tasks (implement with configs)

## Phase-Specific Behavior

**Prototype:**
- Higher threshold for creating configs (need 5+ tasks)
- Focus on core happy-path features
- Skip error handling and edge case configs

**MVP:**
- Standard threshold (3+ tasks)
- Include auth/validation features
- Document error handling flows

**Growth:**
- Lower threshold (2+ tasks for complex features)
- Include performance optimization configs
- Document caching and scaling strategies

**Scale:**
- Create configs for all multi-file changes
- Include security and observability
- Document disaster recovery flows

## Example Invocation

**User:** "I have a tasks.yaml with 20 tasks. Which ones need config files?"

**You:**
1. Read `ai-state/active/tasks.yaml`
2. Analyze task clusters using heuristics
3. Extract config parameters for each cluster
4. Generate `config-opportunities.md`
5. Summarize findings for user
6. Recommend running `/core:generate-config` for high-priority items

## Best Practices

1. **Don't over-create** - Not every task needs a config
2. **Combine related clusters** - "user-login" + "user-register" = "user-authentication"
3. **Use actual file paths** - Parse from `where` fields, don't guess
4. **Make it actionable** - Provide ready-to-use YAML for generate-config
5. **Explain reasoning** - Tell user why each config is recommended

## Error Handling

**No tasks.yaml found:**
- Error: "No tasks.yaml found in ai-state/active/"
- Suggest: "Run /core:write-plan first"

**Tasks too simple:**
- Warning: "All tasks are single-file modifications"
- Output: "No config files recommended for this plan"

**Empty/malformed tasks.yaml:**
- Error: "Could not parse tasks.yaml"
- Suggest: "Check YAML syntax"

## Version

**1.0** - Initial release (2025-11-09)

## Maintained By

Khujta Sphere Framework - Core Skills