home / skills / ladderchaos / tora-skills / coordinator

coordinator skill

/coordinator

This skill maintains project context, tracks changes, and coordinates collaboration across sessions to ensure coherent handoffs and updated documentation.

npx playbooks add skill ladderchaos/tora-skills --skill coordinator

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
name: coordinator
description: Coordinate project context, track changes, and ensure collaboration coherence across sessions. Use this skill for maintaining project status, tracking decisions, managing handoffs between sessions, and keeping coordination documents up to date.
---

# Coordinator

Responsible for maintaining project context, tracking changes, and ensuring collaboration coherence across sessions.

## When This Skill Activates

- Start of a new session (context loading)
- After major changes (documentation update)
- Before switching focus areas (handoff documentation)
- When project state is unclear
- After deployments or releases

## Core Responsibilities

1. **Context Continuity**: Maintain awareness of recent changes, decisions, and pending work
2. **Change Tracking**: Keep a living record of what's been modified and why
3. **Collaboration Sync**: Ensure consistent understanding across sessions
4. **Decision Memory**: Document architectural decisions and their rationale

## Coordination Artifacts

### 1. STATUS.md (Project Root)

Track current state:
```markdown
# Project Status

## Current Focus
[What we're actively working on]

## Recent Changes (Last 5 Sessions)
- [Date] - [Summary of changes]

## Pending/Blocked
- [Items waiting on dependencies or decisions]

## Known Issues
- [Active bugs or technical debt]
```

### 2. CHANGELOG.md (Project Root)

Keep a living changelog:
```markdown
# Changelog

## [Unreleased]
### Added
### Changed
### Fixed
### Removed
```

### 3. DECISIONS.md (Project Root)

Record significant decisions:
```markdown
# Architectural Decision Records

## ADR-001: [Title]
- **Date**: YYYY-MM-DD
- **Status**: Accepted/Superseded
- **Context**: [Why was this decision needed?]
- **Decision**: [What did we decide?]
- **Consequences**: [What are the implications?]
```

## Session Start Protocol

1. **Read STATUS.md** - Understand current state
2. **Check recent commits** - `git log -10 --oneline`
3. **Review CHANGELOG.md** - What's changed recently
4. **Summarize context** - Brief the session on current priorities

## Session End Protocol

1. **Update STATUS.md** - Reflect new current state
2. **Update CHANGELOG.md** - Add entries for changes made
3. **Document decisions** - Add ADRs if significant choices were made
4. **Note pending work** - What remains to be done next

## Quick Reference Commands

```bash
# Check recent changes
git log -10 --oneline --all

# Check modified files
git status

# Check deployment state (if applicable)
cat apps/web/src/config/deployments.json | jq '.networks'
```

## Anti-Patterns to Avoid

- Making changes without updating coordination docs
- Assuming previous session context is remembered
- Not documenting why a decision was made
- Leaving work in an unclear state

Overview

This skill coordinates project context across sessions, tracks changes, and keeps collaboration coherent. It maintains status, records decisions, and ensures handoffs are documented so work resumes smoothly. Use it to reduce repeated context checks and prevent lost or ambiguous state between contributors.

How this skill works

On session start the skill loads the current STATUS.md, recent commits, and the CHANGELOG.md to assemble a concise summary of priorities and recent activity. During and at the end of a session it updates STATUS.md and CHANGELOG.md, records significant decisions in DECISIONS.md (ADRs), and lists pending or blocked items for the next session. It also provides quick commands to inspect recent git activity and deployment state for rapid verification.

When to use it

  • At the start of any new work session to get up to speed
  • After implementing features or fixes to record what changed
  • Before handing off work to another contributor or team
  • When project state or priorities are unclear
  • After a deployment or release to capture outcomes and follow-ups

Best practices

  • Always read STATUS.md and CHANGELOG.md at session start to avoid duplicated work
  • Document the rationale for decisions in DECISIONS.md, not just the choice
  • Keep changelog entries concise and link to related commits or PRs
  • Update pending and blocked lists before ending a session so the next person can pick up quickly
  • Run quick git checks (git log, git status) to validate local context against documented state

Example use cases

  • Daily standup: summarize current focus, recent changes, and blockers from STATUS.md
  • Feature completion: add a changelog entry and an ADR if an architecture tradeoff was made
  • Handoff between shifts: update pending work and blocked items so the incoming contributor can proceed immediately
  • Release postmortem: record deployment results and follow-up tasks in STATUS.md and CHANGELOG.md
  • Onboarding: give a concise project snapshot from STATUS.md and a list of recent ADRs to new team members

FAQ

What should I put in STATUS.md at session end?

Summarize the current focus, list recent changes (last 5 sessions), note pending or blocked items, and call out any known issues or technical debt to address next.

When is an ADR required?

Create an ADR when a decision has lasting architectural impact, affects team workflows, or requires future follow-up. Record context, the decision, date, status, and consequences.