project-tracking

name	project-tracking
description	Manage tasks and goals in Epismo projects. Run day-to-day tracking operations: create and update tracks, plan multi-step work, unblock stalled queues, and delegate tasks to AI agents. Trigger on: 'add a task', 'update status', 'plan this', 'what's blocked', 'rebalance workload', 'delegate to AI', or any intent to read or write project execution state.

Project Tracking

Operate on tasks and goals in Epismo projects — from a quick status update to full goal restructuring.

Core principle: read current state → apply the smallest useful change.

For connection setup, surface conventions, scope model, share URL resolution, and error handling, see Epismo Basics. For workflow pack discovery and release, see Workflow Pack.

Surface selection: CLI and MCP connect to the same Epismo service. Use CLI if available; fall back to MCP if not. Never use both in the same session.

Operations

Operation	CLI
search track	epismo track search --type task|goal --filter '{...}'
get track	epismo track get <track-reference>
create track	epismo track create --input '<json>'
update track	epismo track update <track-reference> --input '<json>'
delete track	epismo track delete <track-reference>
apply track	epismo track apply --input '<json>'
review track	epismo track review <track-reference...> [--instruction '<text>']
create log	epismo log create <track-reference> --content '<text>'
list logs	epismo log list [track-reference] [--author-id <userId>]
delete log	epismo log delete <log-id>

CLI forms are terminal commands (epismo ...). On MCP, derive the tool name mechanically from the full command name (epismo track get → epismo_track_get). See surface conventions.

For filter keys, status values, entity relationships, and search recipes, see Search & Filter. For when to append a log versus editing a track's own fields, see Runbook — Logs.

Intent Router

Intent	When to choose	Steps	Key reference
Update existing work	Field change on something that already exists (status, assignee, date, priority, content)	3 Coordinate — Partial Update	Runbook
Add one new item	Exactly one task or goal; existing structure is valid	3 Coordinate — New Item	Runbook
Plan multiple items or a new goal	New goal structure, multi-step plan, or batch creation	2 Plan → 3 Coordinate — Large-Scale	Runbook
Unblock or rebalance	Stalled queue, overloaded assignee, dependency bottleneck, noisy backlog	4 Risk → 3 Coordinate — Recovery	Runbook
Extract learning	Task is done, goal is completed/postponed, or user asks what should become reusable	3 Coordinate — Review	Runbook
Design an AI-owned task	Delegating work to an AI agent with clear acceptance criteria	3 Coordinate + AI Delegation	AI Delegation
Unclear intent	Cannot confidently match any row above	1 Intake — ask once	—

4-Step Flow

1 Intake

Confirm the user's desired outcome, constraints, timeline, active workspace, and target project scope. Ask one clarifying question if intent is ambiguous. If unanswered, default to read-only and report findings.

2 Plan

Run before structural changes (new goals, multi-item plans, dependency rewiring). Follow Runbook — Planning Checks: diagnose current state → select mode → design ownership contracts → confirm write destination → set next checkpoint. Always choose the smallest mode that satisfies the request.

3 Coordinate

Pick one execution mode from Runbook — Mode Selector:

• Partial Update — localized field edits on existing entities.
• New Item Creation — exactly one new task / goal.
• Large-Scale Planning — multiple coordinated items with ownership contracts.
• Recovery — address overload, stall, or noisy backlog.

When a task status changes to done, run a downstream dependents check: query dependsOn=["<task-id>"] and report what is now unblocked.

When a task reaches done or a goal reaches completed / postponed, check the update response for review. If the user asks for deeper learning or the lightweight review suggests reusable guidance, run review track for the relevant task or goal. If several completed/postponed items belong to the same outcome, pass them together so the review can compare cross-target patterns. Treat the result as read-only: create/update packs or create suggestions only through explicit follow-up operations.

Operational state lives in tracks. Use workflow packs only when the structure should be reused beyond the current execution context — see Workflow Pack.

Design AI-owned tasks with AI Delegation. Use Track Operations for structured write output after the Runbook checks are complete.

4 Risk

Evaluate bottlenecks and dependency risk per Runbook. Run backlog hygiene (stale, duplicate, low-signal) during recovery.

Write Safety

1. Scope first — confirm the target project before any write. If unclear, ask once.
2. No silent writes — if a clarification question is unanswered, continue read-only.
3. Approval for risk — require explicit approval for large-scale plans, multi-entity recovery, and destructive changes.

Source of Truth

Repository: https://github.com/epismoai/skills