Get the FREE Ultimate OpenClaw Setup Guide →

manage-work

Scanned
npx machina-cli add skill hardness1020/VibeFlow/manage-work --openclaw
Files (1)
SKILL.md
9.9 KB

manage-work

Register work items, create feature branches, track and advance stages, close work items in the VibeFlow docs-first development workflow.

Purpose

This skill tracks multiple work items through the VibeFlow workflow by:

  • Registering work items with their workflow track and creating feat/<slug> branches
  • Tracking each work item's current stage independently
  • Advancing work items through stages and routing to the appropriate skill
  • Closing work items as DONE after Checkpoint #4 (release is optional)
  • Providing a dashboard view of all in-flight work items

Workflow

Register Work Item
    │
    ├── Assign ID, generate slug from description, and assign track
    ├── Create entry in docs/workflow-state.yaml (with branch field)
    ├── Create git branch: feat/<slug>
    └── Determine starting stage from track
    │
    ▼
Track Progress
    │
    ├── Show status dashboard (all work items)
    ├── Show detailed status (single work item)
    └── Cross-check manifest against artifacts
    │
    ▼
Advance & Route
    │
    ├── Mark work item as advancing to next stage
    ├── Recommend the appropriate skill command
    └── Update manifest with new stage
    │
    ▼
Close Work Item (after Checkpoint #4)
    │
    ├── Mark stage as DONE (terminal state)
    ├── Branch ready for merge to main
    └── Alternative: advance to Stage I for release track

Usage

Register a New Work Item

/manage-work register "<description>" <ID> <track>

Registers a work item in docs/workflow-state.yaml, determines the starting stage, and creates a git branch feat/<slug>.

Steps:

  1. Generate kebab-case slug from description
  2. Add entry to manifest with branch: feat/<slug>
  3. Create and checkout git branch: git checkout -b feat/<slug>

Example:

/manage-work register "Add anti-hallucination guardrails" 030 medium
# Creates branch: feat/add-anti-hallucination-guardrails

/manage-work register "Export data to CSV" 031 small
# Creates branch: feat/export-data-to-csv

Status Dashboard

/manage-work status

Shows all registered work items with their current stage, track, and last checkpoint.

Example output:

Work Item                          Track    Stage  Checkpoint  Started
add-anti-hallucination-guardrails  Medium   G      3           2025-02-20
export-data-to-csv                 Small    E      2           2025-02-22

Detailed Work Item Status

/manage-work status <ID>

Shows detailed status for one work item including:

  • Current stage and description
  • Completed and remaining stages for its track
  • Last checkpoint passed
  • Artifact verification (cross-check with detect_track.py --workitem <ID>)

Advance a Work Item

/manage-work advance <ID>

Marks a work item as advancing to the next stage in its track:

  • Validates checkpoint if at a checkpoint boundary (blocks if failed)
  • Updates stage in docs/workflow-state.yaml
  • Updates checkpoint if a checkpoint boundary was crossed
  • Updates docs paths with any documents produced at the completed stage
  • Shows what the next stage requires
  • After Checkpoint #4 (Stage H): Offers two paths:
    • advance → proceed to Stage I (release track)
    • close → mark as DONE (see Close command below)

Close a Work Item

/manage-work close <ID>

Marks a work item as DONE after passing Checkpoint #4 (Implementation Complete):

  • Validates Checkpoint #4 if not yet passed (runs validate_checkpoint.py 4 --json --project-root <root>)
  • Requires work item to be at stage H or later with checkpoint >= 4
  • Sets stage: DONE in docs/workflow-state.yaml
  • Branch feat/<slug> is ready for merge to main
  • Blocked if Checkpoint #4 validation fails

Example:

/manage-work close 030
# Sets stage: DONE, branch feat/add-anti-hallucination-guardrails ready for merge

Next Steps for a Work Item

/manage-work next <ID>

Shows the recommended next action for a work item:

  • What the current stage requires
  • Which skill command to run
  • Whether a checkpoint validation is needed first

Workflow Tracks

TrackScopeStagesReleaseExample
MicroBug fix, typo, small refactorF → G → DONENoFix typo, update config
SmallSingle feature, no contractsE → F → G → H → DONEOptional (I-L)Add form field, UI polish
MediumMulti-component, no new servicesB → C → D → E → F → G → H → DONEOptional (I-L)New API endpoint
LargeSystem change, new contracts/servicesA → B → C → D → E → F → G → H → DONEOptional (I-L)New LLM integration

Stage Overview

Planning Stages (A-D)

  • A — Initiate: Create/update PRD
  • B — Discovery: Analyze codebase (Medium/Large)
  • C — Specify: Create/update Tech Specs
  • D — Decide: Create ADRs for decisions

Checkpoint #1: Planning Complete

Design Stage (E)

  • E — Plan: Create Feature Spec with API Design

Checkpoint #2: Design Complete

Implementation Stages (F-H)

  • F — RED: Write failing unit tests + stubs
  • G — GREEN: Implement to pass tests
  • H — REFACTOR: Integration tests + quality validation

Checkpoint #3: Tests Complete (after F) Checkpoint #4: Implementation Complete (after H)

Release Stages (I-L)

  • I — Reconcile: Update specs if implementation deviated
  • J — Prepare: Write OP-NOTE
  • K — Deploy: Follow OP-NOTE, verify
  • L — Close: Update indices, tag release

Checkpoint #5: Release Ready (after J) Checkpoint #6: Deployed (after L)

Manifest Format

The manifest file docs/workflow-state.yaml is the single source of truth for work item lifecycle state:

workitems:
  add-anti-hallucination-guardrails:
    id: 030
    description: "Add anti-hallucination guardrails"
    track: medium        # micro | small | medium | large
    stage: G             # current stage letter (A-L) or DONE
    branch: feat/add-anti-hallucination-guardrails  # git branch
    started: 2025-02-20  # date work item was registered
    checkpoint: 3        # last checkpoint passed (1-6)
    docs:
      prd: docs/prds/prd.md
      discovery: docs/discovery/disco-030.md
      specs:
        - docs/specs/spec-llm.md
      adrs:
        - docs/adrs/adr-030-prompt-strategy.md
      feature: docs/features/ft-030-anti-hallucination.md
      opnote: null
  export-data-to-csv:
    id: 031
    description: "Export data to CSV"
    track: small
    stage: E
    branch: feat/export-data-to-csv  # git branch
    started: 2025-02-22
    checkpoint: 2
    docs:
      prd: null
      discovery: null
      specs: []
      adrs: []
      feature: docs/features/ft-031-export-csv.md
      opnote: null

When registering a new work item:

  1. Create docs/workflow-state.yaml if it doesn't exist (use assets/workflow-state-template.yaml)
  2. Generate a kebab-case slug from the description (e.g., "Add anti-hallucination guardrails" → add-anti-hallucination-guardrails)
  3. Add the work item entry with id, description, track, stage (first stage for the track), branch (feat/<slug>), started (today), checkpoint: 0, and empty docs hierarchy
  4. Create and checkout git branch: git checkout -b feat/<slug>

When advancing a work item:

  1. Read docs/workflow-state.yaml
  2. Check if current stage is a checkpoint boundary (D→E=CP#1, E→F=CP#2, F→G=CP#3, H→I=CP#4, J→K=CP#5, L→done=CP#6)
  3. If checkpoint boundary: run python3 .claude/skills/validate-checkpoint/scripts/validate_checkpoint.py <N> --json --project-root <root>
    • If exit code 1 (failed): STOP. Report errors. Do NOT update manifest.
    • If exit code 0 or 2 (passed/warnings): proceed
  4. Update stage field to the next stage in the track
  5. Update checkpoint if a checkpoint boundary was crossed
  6. Update docs with any document paths produced at the completed stage

Skill Routing

Each stage maps to a specific skill. After determining the current stage for a work item, recommend the appropriate command:

StageSkillRecommended Command
Adefine-prd/define-prd
Banalyze-codebase/analyze-codebase <ID>
Cdefine-tech-spec/define-tech-spec <name>
Drecord-decision/record-decision <ID> <slug>
Ecreate-feature-spec/create-feature-spec <ID> <slug>
Frun-tdd/run-tdd red
Grun-tdd/run-tdd green
Hrun-tdd/run-tdd refactor
Iprepare-release/prepare-release reconcile <ID>
Jprepare-release/prepare-release opnote <slug>
Kprepare-release/prepare-release check
Lprepare-release/prepare-release check

Checkpoint boundaries — recommend /validate-checkpoint <N> before advancing past:

  • Stage D → E (Checkpoint #1)
  • Stage E → F (Checkpoint #2)
  • Stage F → G (Checkpoint #3)
  • Stage H → I (Checkpoint #4)
  • Stage J → K (Checkpoint #5)
  • Stage L → done (Checkpoint #6)

Artifact Verification

Use detect_track.py to cross-check the manifest against actual artifacts:

# Verify a specific work item's artifacts match its manifest stage
python scripts/detect_track.py --workitem <ID> --verify

# Detect artifacts for a specific work item
python scripts/detect_track.py --workitem <ID>

# Detect artifacts for all registered work items
python scripts/detect_track.py --all-workitems

This catches drift between the manifest and actual project state.

References

See references/workflow-summary.md for a condensed workflow overview.

Source

git clone https://github.com/hardness1020/VibeFlow/blob/main/.claude/skills/manage-work/SKILL.mdView on GitHub

Overview

manage-work registers work items with their track, creates a feat/<slug> branch, and tracks each item’s stage through a docs-first workflow. It provides a status dashboard, routes items to the appropriate skill, and closes items after Checkpoint #4 when needed.

How This Skill Works

When a new item is registered, the system assigns an ID, generates a kebab-case slug from the description, selects the starting stage based on the track, creates an entry in docs/workflow-state.yaml with a branch field, and checks out feat/<slug>. Progress is shown on a dashboard and cross-checked against artifacts. Advancing updates the stage, suggests the next skill to run, and updates the manifest; after Checkpoint #4 (Stage H), you can either move to Stage I for release or close the item as DONE.

When to Use It

  • Starting a new feature and registering it under a specific track
  • Reviewing the status dashboard to monitor multiple in-flight items
  • Advancing a work item to the next stage and validating checkpoint boundaries
  • Routing a completed item to Stage I for release or choosing to close it after Checkpoint #4
  • Cross-checking the manifest against produced artifacts during progress

Quick Start

  1. Step 1: /manage-work register "<description>" <ID> <track>
  2. Step 2: /manage-work status
  3. Step 3: /manage-work advance <ID> (or /manage-work close <ID> after Checkpoint #4)

Best Practices

  • Use a descriptive description to generate a meaningful slug for branch naming (feat/<slug>).
  • Keep docs/workflow-state.yaml in sync with branch and stage data for every item.
  • Regularly consult the status dashboard to maintain visibility across all work items.
  • Validate checkpoint boundaries and artifact verification when advancing items.
  • Choose the appropriate path after Checkpoint #4: release (Stage I) or DONE, and document decisions in the manifest.

Example Use Cases

  • Register 'Add anti-hallucination guardrails' → branch: feat/add-anti-hallucination-guardrails
  • Register 'Export data to CSV' → branch: feat/export-data-to-csv
  • Register 'Design analytics dashboard' → branch: feat/design-analytics-dashboard
  • Advance 'Export data to CSV' to the next stage and verify artifacts against detect_track.py
  • Close a completed item after Checkpoint #4 (Stage H) to mark DONE and prepare main merge

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers