Here’s a modified template with your update-subtask request included. I’ve adapted the structure so it fits well as a feature request or bug report for your task-master CLI tool.

Feature Request: Updated State in task-master show After Subtask Update

User Story:
As a user, I want the task-master show command to display the most recent state of a subtask after running task-master update-subtask, so that I can rely on it as an accurate log of the current status.

Motivation

Currently, when I run:

task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>"

The CLI correctly shows the updated subtasks immediately after the update.

However, when I later run:

task-master show --id=<parentId.subtaskId>

It only displays the previous state of the subtasks, not the most recent changes.

This inconsistency makes it difficult to track progress or use task-master show as a reliable log for the current task status.

Proposed Solution

Update the task-master show command to always fetch and display the latest subtask data, ensuring it reflects updates made through update-subtask.

High-Level Overview:

• When a subtask is updated, the changes should be persisted in storage (DB, file, or API).
• task-master show should read directly from this latest state.
• Ensure both commands (update-subtask and show) are fully synchronized.

Relevant Technologies:

• Current data storage mechanism (e.g., PostgreSQL, JSON file, Supabase, etc.)
• CLI architecture for read/write operations

High-Level Workflow

1. Update Subtask

   • User runs task-master update-subtask
   • CLI validates input and saves changes to the current storage layer.

2. Verify Updated State

   • User runs task-master show
   • CLI fetches the latest data and displays updated subtasks.

3. Confirm Sync

   • Ensure no caching or outdated reads interfere with real-time updates.

Key Elements

• Enhance update-subtask to ensure persistent updates.
• Update show command logic to pull the current state directly from storage.
• Add logging or timestamp metadata to track when updates occur.
• Ensure compatibility with existing task and subtask data models.

Example Workflow

# Update subtask
$ task-master update-subtask --id=123.456 --prompt="Update the UI design"
→ Subtask updated successfully:
  {
    "id": "4",
    "status": "in-progress",
    "description": "Update the UI design"
  }

# Show updated task
$ task-master show --id=1.4
→ Current task state as well as the appended/updated subtasks information:
  {
    "id": "4",
    "status": "in-progress",
    "description": "Update the UI design"
  }

Implementation Considerations

• Ensure data persistence is reliable (e.g., avoid in-memory-only updates).
• Validate that update-subtask triggers proper save operations.
• Optimize for performance when fetching large task trees.
• Maintain backward compatibility with older task data formats.

Out of Scope (Future Considerations)

• Bulk subtask updates (update-subtask on multiple IDs at once).
• Advanced history or audit trail for each subtask.
• Role-based access control for updating and viewing tasks.

Would you like me to convert this into a GitHub issue template so you can use it directly for tracking?