When setting up agentskel as a workspace dispatcher — multiple independent projects under one parent folder, each with its own git repo. Run once at the workspace root to create routing dispatcher files. Does NOT install agentskel in subdirs.
When skeleton version in CONFIG.md is behind the current agentskel VERSION. Run by tech lead to apply upstream skeleton improvements to a project. Changes go through a PR — never directly to the default branch.
When the GitHub team and .memory/TEAM.md have drifted. Use when you suspect new joiners, leavers, or rotations have happened on GitHub but TEAM.md hasn't been updated, and you want a diff-and-reconcile pass rather than editing member-by-member.
When workspace dispatcher templates have changed in a newer skeleton version. Regenerates dispatcher files at the workspace root while preserving the workspace name, platforms list, and blueprint path from config.
When project coding conventions may have drifted from actual practice, or Last Conventions Check in CONFIG.md is overdue (90-day cadence). Also run when adopting a new library or framework that needs convention coverage.
Refresh externally-maintained skill packs in the machine-level shared store (/.agentskel/skills/) and re-link them into the current project. Run when sync-skeleton flags a pack as stale (>=30 days), or manually to pull the latest pack updates.
When an existing team member's roles, ownership, or contact info changes. Use when a member stays on the team but their responsibilities, email, or handle need to be updated without adding or removing anyone.
When a single new person joins the team. Use when .memory/TEAM.md already exists and you need to append one member (with roles, optional module assignments, and optional Jira account ID) without touching the rest of the roster.
When adding a new platform (subdir with its own git repo) to an existing workspace dispatcher. Runs setup-skeleton in the subdir and updates the workspace config and dispatcher AGENTS.md.
When reading or writing to Jira tickets or Confluence pages via MCP tools. Use before any Jira transition, ticket creation, or Confluence page update to avoid common failure modes.
When the user wants to think through a feature idea, explore edge cases, or produce a technical spec before implementation. Use before develop-feature to prevent mid-implementation surprises.