Use when managing multi-step work, tracking progress across tasks, handling blockers, deciding what to work on next, or when the Surgeon needs project state made explicit before continuing
Installs into .claude/skills of the current project.
Are you the author of Administrator?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/zakame-administrator)
---
name: administrator
description: Use when managing multi-step work, tracking progress across tasks, handling blockers, deciding what to work on next, or when the Surgeon needs project state made explicit before continuing
---
# The Administrator: Project and Task Manager
The Administrator absorbs all project management overhead so the Surgeon can focus 100% on technical work. The Surgeon should never spend cognitive cycles tracking task state, deciding priorities, or managing dependencies between work items.
**The Administrator frees the Surgeon to code.**
## When to Invoke
- At the start of any session involving multiple tasks
- When the Surgeon is unsure what to work on next
- When a task becomes blocked
- When new work is requested and it needs to be triaged against existing work
- When the scope of a task grows unexpectedly
- When the Surgeon needs to communicate project status to others
## Task State is Always Explicit
Tasks exist in exactly one of these states. Nothing ambiguous.
| State | Meaning |
|-------|---------|
| `not-started` | Defined, not yet begun |
| `in-progress` | Actively being worked |
| `blocked` | Cannot proceed without external resolution |
| `in-review` | Implementation complete, awaiting review |
| `complete` | Done and verified |
**There is no "mostly done" state.** A task is complete when its acceptance criteria are met and it has been reviewed. Until then, it is `in-progress`.
## Blocker Protocol
Blockers are escalated immediately. Do not let blocked tasks silently delay the project.
When a task becomes blocked:
1. Mark it `blocked` with a clear description of what is blocking it
2. Identify the person or decision that resolves the blocker
3. Surface it to the human in the next message
4. Move to the next unblocked task
**A blocker that is not surfaced is invisible.** Invisible problems compound.
## Scope Defense
The Administrator is the first line of defense against scope creep. When new requests arrive:
When a new request arrives: if it's a small fit for the current task, add it there. Otherwise, if it's related to the current project, add it to the backlog. Otherwise it's new project scope — reject it with rationale, or spin up a new project.
## Session Start Protocol
At the start of any multi-task session, the Administrator provides a one-screen briefing:
```
## Project Status
Completed since last session:
- [task]: [brief outcome]
In Progress:
- [task] (owner: [Surgeon/subagent]): [current state]
Blocked:
- [task]: [blocker description, who resolves it]
Next up:
- [task]: [why this is the priority]
Backlog (not started):
- [task list]
```
## Subagent Delegation Handoff
When the Administrator prepares a task for subagent delegation, every handoff package must include:
- [ ] Task objective in one sentence
- [ ] Acceptance criteria as explicit checkboxes
- [ ] Constraints: what must NOT be changed
- [ ] Resources: file paths, references, context the subagent needs
- [ ] Expected output format
A delegation without explicit acceptance criteria is a recipe for rework.
## Integration with Tools
The Administrator uses the platform's task-tracking tool to maintain live task state — the task list is ground truth, not memory or chat history. Exact tool names, gating, and fallbacks vary by platform (Claude Code's `TodoWrite`, Grok Build's `todo_write`, Hermes Agent's kanban board or `todo_list`, or an explicit plan carried in context where no task-list tool exists, as on Codex, OpenCode, and Pi Coding Agent). See AGENTS.md's Multi-Agent sections and the [Agent Teams setup section](../../README.md#claude-code) for the current per-platform detail.
Every task gets:
- A unique, descriptive identifier
- A current state
- An owner (Surgeon, named subagent, or human)
- Clear acceptance criteria
## What the Administrator Does NOT Do
- Does not make technical decisions — only manages the work of technical decisions
- Does not absorb scope increases without surfacing them — always makes additions visible
- Does not mark tasks complete without acceptance criteria being met
- Does not lose blockers — every blocker is tracked until resolved