Chief of Staff — Experimental

What it does

Matt Pocock’s experimental chief-of-staff skill addresses the gap between completing an individual ticket and understanding the state of a project. The main session maintains orientation and delegates concrete work, while a durable wiki records decisions and historical facts with dated repository evidence. The important distinction is between persistent knowledge and a conversation’s temporary recollection. The source asks the user to agree where that knowledge belongs and permits environment improvements that make later work easier. It is a coordination pattern, not a packaged hosted service or a promise of autonomous project management.

When to use it

• Track several maintenance threads without losing which decisions were actually made.
• Prepare a repository handover using dated changes and open questions rather than remembered summaries.
• Identify repeated setup friction and propose a small, reviewable improvement to the working environment.

Step-by-step workflow

1. Agree the project goal, wiki location and boundaries of delegated work before starting a long session.
2. Read the actual repository and existing knowledge; distinguish current observations from historical claims.
3. Give each specialist a bounded task and pointers to the artifacts it needs, avoiding unnecessary duplicated context.
4. Reconcile returned evidence, update the project picture and attach commits or dates to durable historical statements.
5. Review unresolved work and environment friction; use scheduled follow-ups only if the host supports them and the user authorizes them.

Example request

Use chief-of-staff experimentally for our documentation migration. First agree a wiki folder. Keep an evidence-backed list of completed sections, unresolved terminology and blocked source files. Delegate only clearly scoped reviews. Link to the actual changes instead of claiming completion from an agent summary. Suggest one environment improvement if repeated friction appears; do not publish or schedule anything without authorization.

Worked example

Suppose a migration spans API docs, onboarding and release notes. A worker says onboarding is done, but the changed commit still leaves an old installation path. The coordinator records that discrepancy rather than marking the whole migration complete. A wiki entry can say which commit was checked, what remains and when it was observed. A later session follows those references and verifies the current tree instead of replaying the earlier conversation. Scheduling a follow-up remains a separate host-dependent action, not an automatic effect of reading the skill.

What you get

A maintained project knowledge base, scoped work briefs and an evidence-backed view of progress and unresolved decisions.

How to evaluate the result

• Every completion claim points to an artifact that can be inspected.
• Wiki entries distinguish dates and commits from current assumptions.
• Open questions and permissions remain explicit after a handover.

What you need

A project with real source artifacts, a writable agreed wiki and an agent host capable of delegation. Long-running sessions and scheduling depend on the chosen runtime.

Setup and activation

Experimental source: this folder is under skills/in-progress and is not a stable-release recommendation. Its frontmatter disables automatic model invocation, so explicitly select it in a host that supports that behavior. This directory reviewed source only; it did not install or execute the skill. Before adopting it, scan the exact version, inspect requested tools and permissions, and test on disposable non-sensitive inputs. A compatible instruction format does not establish identical host capabilities.

Limits and considerations

The source is in progress and can change. Coordination can consume more context and tool time than completing a small task directly. Delegation and schedule suggestions do not authorize external messages, releases or persistent monitoring.

Related workflows

• Use a task-specific implementation or review workflow for each bounded assignment.
• Use a handoff workflow when transferring the durable project context to a new session.

License and reuse

MIT at repository level. Preserve copyright and license notices; check companion files and external dependencies for their own terms.

Further reading

• Publisher setup and compatibility instructions
• Reviewed source at immutable commit