giuseppe-trisciuoglio/developer-kit

Comprehensive developer toolkit providing reusable skills for Java/Spring Boot, TypeScript/NestJS/React/Next.js, Python, PHP, AWS CloudFormation, AI/RAG, DevOps, and more.

Quality

90%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

Securityby

Risky

Do not use without reviewing

This version of the tile failed moderation

Moderation pipeline encountered an internal error

description:: Provides capability to manage tasks after generation. Use when needing to add, split, update, or modify tasks in an existing specification.
argument-hint:: --action=[add|split|mark-optional|mark-required|update|regenerate-index|list] [ --task="docs/specs/XXX-feature/tasks/TASK-XXX.md" ] [ --spec="docs/specs/XXX-feature" ]
allowed-tools:: Task, Read, Write, Edit, Bash, Grep, Glob, TodoWrite, AskUserQuestion

Task Management

Name: giuseppe-trisciuoglio/developer-kit
Rating: 90.85333333333334 (1 reviews)
Author: giuseppe-trisciuoglio

Manages tasks after task generation. Use when you need to add, split, update, or modify tasks in an existing specification.

Overview

This command provides task management capabilities after initial task generation by devkit.spec-to-tasks.

Supported Actions:

add - Add a new task to the specification
split - Split a complex task into smaller subtasks
mark-optional - Mark a task as optional
mark-required - Mark a task as required
update - Update task details
regenerate-index - Regenerate the task index
list - List all tasks with complexity

Usage

# Add a new task
/specs:task-manage --action=add --spec=docs/specs/001-feature/ --lang=spring

# Split a complex task
/specs:task-manage --action=split --task=docs/specs/001-feature/tasks/TASK-007.md

# Mark task as optional/required
/specs:task-manage --action=mark-optional --task=docs/specs/001-feature/tasks/TASK-003.md
/specs:task-manage --action=mark-required --task=docs/specs/001-feature/tasks/TASK-003.md

# Update task details
/specs:task-manage --action=update --task=docs/specs/001-feature/tasks/TASK-005.md

# Regenerate task index
/specs:task-manage --action=regenerate-index --spec=docs/specs/001-feature/

# List all tasks
/specs:task-manage --action=list --spec=docs/specs/001-feature/

Arguments

Argument	Required	Description
`--action`	Yes	The management action to perform
`--task`	Conditional	Path to task file (required for task-specific actions)
`--spec`	Conditional	Path to spec folder (required for `add`, `regenerate-index`, `list`)
`--lang`	No	Language/framework hint for new tasks

You are managing existing task files. Follow the appropriate process based on the requested action.

IMPORTANT: When suggesting how to implement a task, ALWAYS use /specs:task-implementation, NEVER use /developer-kit:devkit.feature-development. The correct command is:
/specs:task-implementation --lang=[lang] --task="[task-file-path]"

Action: Add

Adds a new task to an existing specification.

Process

Parse $ARGUMENTS to extract:
- --spec parameter (spec folder path)
- --lang parameter (optional language hint)
Read the existing task index (YYYY-MM-DD--feature-name--tasks.md)
Determine the next task ID (e.g., if last is TASK-007, next is TASK-008)
Ask the user for:
- Task title
- Task description
- Acceptance criteria
- Dependencies (if any)
- Estimated complexity
Create the new task file following the standard task format
Validate dependencies before saving:
- Verify all referenced task IDs exist in the tasks directory
- Check for circular dependencies (TASK-A depends on TASK-B which depends on TASK-A)
- Ensure task ID format matches pattern TASK-XXX
- Warn if dependency points to a superseded task
Update the task index to include the new task
Update the traceability matrix if requirements are affected
- Read traceability-matrix.md and add rows for new REQ-IDs
- Initialize Test Files and Code Files columns with "-"
- Create matrix if it does not exist with header structure

Task File Templates

Choose the appropriate template based on task complexity:

Template A: Simple (Recommended for most tasks)

Use this template for straightforward tasks with clear scope.

---
id: "TASK-XXX"
title: "[Task Title]"
status: "pending"  # pending | in-progress | completed | superseded | optional
description: "[What this task implements]"
acceptance_criteria:
  - "[Criterion 1]"
  - "[Criterion 2]"
definition_of_ready:
  - "[Precondition 1]"
  - "[Precondition 2]"
definition_of_done:
  - "[Completion condition 1]"
  - "[Completion condition 2]"
dependencies: []
  # - "TASK-YYY"  # if depends on other tasks
files_to_create:
  - "[file path]"
files_to_modify:
  - "[file path]"
implementation_command: "/specs:task-implementation --lang=[lang] --task=\"docs/specs/[id]/tasks/TASK-XXX.md\""
---

# TASK-XXX: [Task Title]

**Description**: [Functional description]

**Complexity**: [Score]/100 - [Simple/Moderate/Complex]

## Acceptance Criteria

- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Definition of Ready (DoR)

- [ ] [Precondition 1]
- [ ] [Precondition 2]

## Definition of Done (DoD)

- [ ] [Completion condition 1]
- [ ] [Completion condition 2]

## Files

**To Create**:
- `[file path]`

**To Modify**:
- `[file path]`

**Implementation Command**:
/specs:task-implementation --lang=[lang] --task="docs/specs/[id]/tasks/TASK-XXX.md"

Template B: Full (For complex tasks requiring detailed tracking)

Use this template for complex tasks that need business context, data contracts, observability, and complexity tracking.

---
id: "TASK-XXX"
title: "[Task Title]"
status: "pending"  # pending | in-progress | completed | superseded | optional
description: "[What this task implements]"
acceptance_criteria:
  - "[Criterion 1]"
  - "[Criterion 2]"
definition_of_ready:
  - "[Precondition 1]"
  - "[Precondition 2]"
definition_of_done:
  - "[Completion condition 1]"
  - "[Completion condition 2]"
dependencies: []
  # - "TASK-YYY"  # if depends on other tasks
files_to_create:
  - "[file path]"
files_to_modify:
  - "[file path]"
implementation_command: "/specs:task-implementation --lang=[lang] --task=\"docs/specs/[id]/tasks/TASK-XXX.md\""
business_goals:
  - "[Business goal this task serves]"
data_contracts:
  input:
    - "[Input data contract]"
  output:
    - "[Output data contract]"
external_dependencies:
  - "[External system/dependency]"
observability:
  logging:
    - "[Log point 1]"
    - "[Log point 2]"
  metrics:
    - "[Metric 1]"
    - "[Metric 2]"
  security:
    - "[Security consideration 1]"
    - "[Security consideration 2]"
complexity:
  score: 0
  files: 0
  acceptance_criteria: 0
  independent_components: 0
  design_decisions: 0
  integration_points: 0
  external_dependencies: 0
parent_task: null
supersedes: []
notes:
  - "[Note]"
context_hash: "[SHA-256 hash for change detection]"
---

# TASK-XXX: [Task Title]

**Description**: [Functional description]

**Complexity**: [Score]/100 - [Simple/Moderate/Complex]

## Context Linkage

**Business Goal**: [Goal ID] - [Goal description]

**Data Contract**:
- Input: [Input contract reference]
- Output: [Output contract reference]

**External Dependencies**: [List or "None"]

## Implementation Notes

- [Technical constraint or guidance]
- [Integration point]

## Acceptance Criteria

- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Definition of Ready (DoR)

- [ ] [Precondition 1]
- [ ] [Precondition 2]

## Definition of Done (DoD)

- [ ] [Completion condition 1]
- [ ] [Completion condition 2]

## Files

**To Create**:
- `[file path]`

**To Modify**:
- `[file path]`

## Observability

**Logging**:
- [Log point]

**Metrics**:
- [Metric]

**Security**:
- [Security consideration]

**Implementation Command**:
/specs:task-implementation --lang=[lang] --task="docs/specs/[id]/tasks/TASK-XXX.md"

Context Hash Generation

The context_hash field is used for change detection. Generate SHA-256 hash of: task title + description + acceptance_criteria + definition_of_ready + definition_of_done + files_to_create + files_to_modify.

Regenerate whenever these fields change to detect task drift.

Action: Split

Splits a complex task into smaller, more manageable subtasks.

Process

Read the task file to be split
Analyze the task complexity:
- If complexity < 50, suggest keeping as single task
- If complexity >= 50, proceed with split
Propose a split strategy to the user:
- How many subtasks (typically 2-4)
- What each subtask covers
- Dependencies between subtasks
Get user confirmation on the split strategy
Create subtask files:
- Generate new task IDs (e.g., TASK-008, TASK-009)
- Each subtask inherits relevant context from parent
- Update dependencies to reflect split
- Calculate complexity for each subtask:
  - Count files, acceptance criteria, components, design decisions, integration points, external dependencies
  - Apply complexity formula
  - Ensure each subtask has complexity < parent task complexity
Mark original task as superseded:
- Edit the parent task file and add to frontmatter:
```
status: superseded
```
- The superseded status is automatically tracked by hooks
- Add supersedes reference to new subtasks in the frontmatter
Update task index with new structure
Update traceability matrix
- For each new subtask, add rows to traceability-matrix.md
- Update parent task rows to reflect new subtask structure
- Update coverage summary with new task count

Context Chain Inheritance

When splitting tasks, child tasks inherit context from parent:

# Parent task context (preserved)
business_goals:
  - "[Inherited from parent]"

data_contracts:
  # Inherited but can be refined
  input:
    - "[Subset relevant to child]"
  output:
    - "[Subset relevant to child]"

external_dependencies:
  # Assign only pertinent dependencies to each child
  - "[Relevant dependency]"

observability:
  # Inherited framework, refined specifics
  logging:
    - "[Relevant log points]"
  metrics:
    - "[Relevant metrics]"
  security:
    - "[Relevant security considerations]"

parent_task: "TASK-XXX"  # Reference to parent
supersedes: []  # Child tasks don't supersede

Action: Mark Optional/Required

Toggles the optional status of a task.

Process

Read the task file
Update the task frontmatter:
- For mark-optional: Set optional: true
- For mark-required: Set optional: false
Update the task index to reflect the change
Update the traceability matrix

Action: Update

Updates task details.

Process

Read the current task file
Present current values and ask what to update:
- Title
- Description
- Acceptance criteria
- Dependencies
- Files to create/modify
- Complexity assessment
- Context fields (business goals, data contracts, etc.)
Apply the requested changes
Recalculate complexity if relevant fields changed
Update context_hash if task structure changed
Update task index
Update traceability matrix if requirements mapping changed

Action: Regenerate Index

Recreates the task index file from existing task files.

Process

Scan docs/specs/[id]/tasks/ directory for all TASK-XXX.md files
Read each task file and extract:
- Task ID
- Title
- Status
- Complexity score
- Optional flag
- Dependencies
Sort tasks by ID
Generate new task index:
- Summary statistics
- Task table
- Complexity distribution
- Dependency graph
Write updated index file

Action: List

Displays all tasks with their status and complexity.

Process

Read the task index
Display formatted list:

Task List for [Feature Name]
============================

Simple Tasks (≤30):
  ✅ TASK-001: [Title] ([Status])
  ✅ TASK-002: [Title] ([Status])

Moderate Tasks (31-50):
  ⚠️  TASK-003: [Title] ([Status])

Complex Tasks (>50):
  ❌ TASK-004: [Title] ([Status]) - Consider splitting

Optional Tasks:
  ○ TASK-005: [Title] (optional)

Total: X tasks | Y simple | Z moderate | W complex

Show dependency warnings if any

Complexity Recalculation

When task details change, recalculate complexity:

COMPLEXITY SCORE =
  (Files × 10) +
  (Acceptance Criteria × 5) +
  (Independent Components × 25) +
  (Design Decisions × 10) +
  (Integration Points × 15) +
  (External Dependencies × 20)

Thresholds:
- 0-30: Simple
- 31-50: Moderate
- 51+: Complex (must split)

Update both the score and complexity level in the task frontmatter.

Index Update Template

When updating the task index, use this format:

# Task List: [Feature Name]

**Specification**: [Spec file path]
**Last Updated**: [Date]

## Summary

- **Total Tasks**: [N]
- **Simple (≤30)**: [N]
- **Moderate (31-50)**: [N]
- **Complex (>50)**: [N]
- **Optional Tasks**: [N]

## Tasks

| ID | Title | Status | Complexity | Optional | Dependencies |
|----|-------|--------|------------|----------|--------------|
| TASK-001 | [Title] | [Status] | [Score]/[Level] | [Yes/No] | [Deps] |

## Complexity Distribution

Simple: [████░░░░░░] X tasks Moderate: [██░░░░░░░░] Y tasks Complex: [█░░░░░░░░░] Z tasks (requires splitting)

## Implementation Commands

```bash
# Task 1
/specs:task-implementation --lang=[lang] --task="docs/specs/[id]/tasks/TASK-001.md"

# Task 2
/specs:task-implementation --lang=[lang] --task="docs/specs/[id]/tasks/TASK-002.md"

Next Actions

Address complex tasks (split recommended)
Complete simple tasks first
Resolve dependency chains

Examples

Example 1: Add a new task

# Add a new task to a specification
/specs:task-manage --action=add --spec=docs/specs/001-user-auth/ --lang=spring

Example 2: Split a complex task

# Split a complex task into subtasks
/specs:task-manage --action=split --task=docs/specs/001-user-auth/tasks/TASK-007.md

Example 3: Mark task as optional

# Mark a task as optional
/specs:task-manage --action=mark-optional --task=docs/specs/001-user-auth/tasks/TASK-003.md

Example 4: Regenerate task index

# Regenerate the task index file
/specs:task-manage --action=regenerate-index --spec=docs/specs/001-user-auth/

Example 5: List all tasks

# List all tasks with complexity
/specs:task-manage --action=list --spec=docs/specs/001-user-auth/

Todo Management

For each action, maintain a todo list:

[ ] Parse arguments and validate
[ ] Read existing context (task/spec)
[ ] Perform requested action
[ ] Update affected files
[ ] Regenerate index if needed
[ ] Update traceability matrix
[ ] Confirm changes to user