Gates & Reviews

How gating levels control the pipeline and what each approval button does.

Gating Levels

Gates control when the pipeline pauses for human review. You set the gating level per project with a slash command:

Set Gating Level
/deevoted-set gating <level>

There are three levels:

off No checkpoints

The pipeline auto-chains from skill to skill with no review pauses. Deliverables are still saved to Drive and you still get notifications, but nothing waits for your approval before advancing. Useful for trusted repeat work or rapid prototyping.

skill Default

The pipeline pauses at every skill handoff — when the Strategist finishes and is about to hand off to Brand Designer, when Brand Designer finishes and is about to hand off to Copywriter, and so on. Inside a skill, individual deliverables auto-chain without waiting. This gives you control over the flow while keeping each skill's work moving efficiently.

deliverable Maximum control

The pipeline pauses after every single deliverable. When the Strategist finishes the Project Brief, you review it before the Audience Analysis begins. When the Audience Analysis is done, you review that before Competitive Analysis starts. Every deliverable gets its own gate.

The default is skill gating. Most projects work well with skill-level gates — you review the full body of work from each skill before the next one starts.

Gate Actions

When the pipeline hits a gate, Coordinator sends a notification in your project channel. Every gate notification includes four action buttons:

d
Deevoted Coordinator
App 10:15 AM
Brand Guidelines Ready for Review
Brand Designer has completed the Brand Guidelines Document. Review in Drive and choose an action below.
Approve
With Client
Request Revisions
Discuss in Claude
Approve

Accept the deliverable and advance the pipeline. The next skill (or next deliverable, depending on gating level) begins immediately.

With Client

Forward the deliverable to the client for their review. The pipeline pauses until the client responds. Use this when you need external sign-off before moving forward.

Request Revisions

Send the deliverable back with notes. You write what needs to change, the skill regenerates the deliverable incorporating your feedback, and it comes back for another review. This is the revision mechanism.

Discuss in Claude

Open a conversation about the deliverable without triggering a revision. Use this when you want to talk through an approach, ask questions about a creative choice, or explore alternatives before deciding. This is a separate path from Request Revisions — it's for discussion, not for sending work back.

Reviewing and Approving

When the pipeline hits a gate, the review follows a consistent process:

1

Notification

A deliverable is ready. You get a Slack notification with a link to the file in Drive.

2

Open the Google Doc version

Review there — it supports comments and tracked changes.

3

Review

Check for accuracy, completeness, and quality.

4

Decide

Approve

The pipeline advances. The deliverable is handed off to the next skill.

Request Revisions

Add revision notes describing the specific changes. The deliverable regenerates with your feedback applied.

How Revisions Work

When you click Request Revisions, the flow works like this:

1. Add Notes

You write revision notes describing what needs to change. Be specific — "the tone feels too formal for this audience" is more useful than "fix the tone."

2. Queued

Coordinator confirms your notes and queues the deliverable for regeneration. You see a confirmation in the channel.

3. Regenerate

The skill regenerates the deliverable, incorporating your revision notes alongside the original context. The updated version replaces the current file in Drive; the previous version moves to the previous-versions/ folder.

4. Re-review

You get a new gate notification with the same four buttons. Review again, approve, or request further revisions. There is no limit on revision cycles.

Discuss in Claude is not the revision mechanism. If you want a deliverable changed, use Request Revisions. Discuss in Claude is for conversation — exploring options, asking questions, or understanding a creative decision before you decide what to do.

Writing Effective Revision Requests

Good revision notes help the skill regenerate the deliverable correctly on the first pass.

Be specific

“The hero headline should lead with the outcome, not the feature” is actionable. “I don’t like the headline” is not.

Reference the deliverable

“In section 3 of the project brief, the audience description should include…” gives a clear location. The skill knows exactly where to look.

Distinguish must-fix from nice-to-have

If some issues are critical and others are suggestions, say so. The skill will prioritize accordingly.

Each deliverable gets up to three revision cycles by default. After three rounds, the Coordinator escalates to resolve any remaining issues.
Good revision feedback is specific and actionable. “The tone feels wrong” is vague. “The hero headline should be more authoritative — weight 900, not 300” is actionable.

Escalation

Sometimes a skill hits a problem it can't resolve on its own — a missing upstream deliverable, contradictory requirements, or a constraint that makes the work impossible as scoped. When this happens, the skill escalates upstream.

Escalation means the skill pauses its own work and flags the issue back to the skill (or to you) that can resolve it. Coordinator notifies you in the channel with a description of what went wrong and what the skill needs to continue. You resolve the issue — by updating the upstream deliverable, clarifying requirements, or adjusting the scope — and the skill resumes from where it stopped.

Escalation is rare in practice. Most projects flow through the pipeline without it. But when it happens, the pipeline handles it cleanly rather than producing work based on bad assumptions.