Sidstack Aware

SidStack Task Progress & Completion

When This Activates

This skill provides workflow guidance during active implementation:

• New request arrives: classify intent → route to correct workflow
• After code changes: update progress milestones
• Work nearing completion: guide through quality gates
• Task status queries: "check task", "list tasks", "what's the status"

Note: Task lifecycle is guided by the /sidstack-dev skill. This skill tracks progress and completion flow.

Session Start Behavior

When activated at the beginning of a session or after context compaction:

1. task_list({ projectId: "FOLDER_NAME", preset: "actionable" }) — show active and pending tasks
2. If an in_progress task exists, display it and offer to resume
3. If no active task, show top pending tasks as options
4. training_context_get({ projectId: "FOLDER_NAME" }) — load applicable rules and lessons

Workflow Classification

When the user sends a natural-language request (not a /sidstack-* command), classify before acting.

Step 1: Classify Intent

Step 2: Context Check (for task-creating workflows only)

Before creating a new task:

1. task_list({ projectId: "FOLDER_NAME", preset: "actionable" }) — is there an existing task for this?
   • YES, matching topic → Resume it. Do not create duplicate.
   • NO → Continue to Step 3.
2. knowledge_search({ query: "[request summary]" }) — any past learnings?
3. training_context_get({ projectId: "FOLDER_NAME" }) — applicable rules?

Step 3: Disambiguate

If classification is uncertain:

• In-progress task on same topic? → Resume that task.
• Request mentions task-ID (task-xxx)? → Load and continue that task.
• Request mentions ticket-ID (JIRA-xxx, GH-xxx)? → Route to ticket workflow.
• Still ambiguous? → Ask user: "This could be a [bugfix] or [feature]. Which workflow fits better?"

Step 4: Route

Lightweight flow (when user says "proceed" instead of /sidstack-dev):

task_start_with_context({ taskId })
→ implement
→ task_update({ progress })
→ test
→ task_governance_check({ taskId })
→ test_result_create(...)
→ task_complete_with_context({ taskId })
→ memory_add(...)

Plan-First Gate (MANDATORY)

Before any implementation begins, verify the task has an approved plan:

mcp__sidstack__task_get({ taskId: "[id]" })
→ check: planStatus === "approved"

Exception: hotfix mode only (critical production issues can skip plan review).

Implementation Must Follow the Plan

When planStatus === "approved":

1. Read the solutionPlan field — this is the contract
2. Change only files listed in the plan
3. Follow the approach described in the plan
4. If you discover the plan is wrong or incomplete: STOP, update notes, move back to review
5. If you need to touch files NOT in the plan: ask user before proceeding

Progress Tracking

Update progress at milestones during implementation:

mcp__sidstack__task_update({ taskId: "[id]", progress: X, notes: "milestone" })

Task Queries

Completion Flow

Before calling mcp__sidstack__task_complete:

1. Code changes implemented
2. Tests pass (if applicable)
3. Build succeeds (if applicable)
4. Manually verified the change works
5. Submit implementSummary: what was done, key decisions, files changed

   mcp__sidstack__task_update({ taskId: "[id]", implementSummary: "[summary]" })
   

6. Lesson check: Any patterns, issues, or decisions worth noting?
   • If yes: use incident_create -> lesson_create flow
   • If no: proceed to completion

mcp__sidstack__task_complete({ taskId: "[id]" })

Integrated Workflow (applies to ALL implementation work)

These steps apply whether you're in /sidstack-dev mode or handling a regular prompt:

On Task Start (after create or resume)

1. entity_context({ entityType: "task", entityId: taskId }) — loads all linked knowledge, memory, references in one call
2. If entity_context returns no linked docs, fall back to knowledge_search
3. entity_link — link any newly discovered relevant docs to the task

During Implementation

4. entity_context — if you need full context for a task with linked entities
5. entity_link — link any new knowledge docs you create to the task

On Task Complete

6. memory_add — store key learnings: { content: "[summary + learnings]", projectId: "...", metadata: { sourceType: "task_completion", taskId: "..." } }
7. test_result_create — if tests were run, persist results with taskId

Rule: Always search before you build. Always store after you complete.

Task Creation Template

When a task needs to be created (e.g., no active task found):

mcp__sidstack__task_create({
  projectId: "FOLDER_NAME",
  title: "[TYPE] Clear description",
  description: "Problem: X. Solution: Y.",
  taskType: "feature|bugfix|refactor|test|docs",
  priority: "medium",
  acceptanceCriteria: [
    { description: "Specific verifiable outcome" }
  ]
})

Output Templates

Progress Update:

Progress: [X]% - [milestone description]

Task Complete:

Task [task-id] completed.
Summary: [what was done]
Quality gates: All passed

Error Handling

Task Systems: SidStack vs Built-in

Rule: Always create the SidStack MCP task first (governance requires it). Optionally use built-in tasks for sub-steps within the session.

Quick Reference

Converted and distributed by TomeVault — claim your Tome and manage your conversions.