Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Engagement Scoping

ASecurity

Define the scope, success criteria, roles, and boundaries for a consulting engagement. Use when a consultant says "help me scope this engagement", "I need to define what's in and out", "the client keeps adding things", "scope is getting fuzzy", "we need a contracting conversation", "I'm not sure what we actually agreed to", "help me set boundaries with a client", or "what should be in a kickoff". Also trigger when describing an engagement that feels like it is expanding without agreement, or ...

20 stars
0 votes
0 copies
0 views
Added 10/4/2026
ai-agentsgo

Works with

cli

Security Analysis

A100/100

Scanned 10/4/2026

$npx -y skills add qa-aman/claude-skills --skill engagement-scoping --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Engagement Scoping?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Engagement Scoping
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/qa-aman-engagement-scoping/badge)](https://www.skillsdirectory.com/skills/qa-aman-engagement-scoping)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
Files
SKILL.md
---
name: engagement-scoping
description: >
  Define the scope, success criteria, roles, and boundaries for a consulting engagement.
  Use when a consultant says "help me scope this engagement", "I need to define what's in
  and out", "the client keeps adding things", "scope is getting fuzzy", "we need a
  contracting conversation", "I'm not sure what we actually agreed to", "help me set
  boundaries with a client", or "what should be in a kickoff". Also trigger when
  describing an engagement that feels like it is expanding without agreement, or when
  starting a new client relationship and preparing the initial contract or SOW.
---

## Overview

Based on **"Flawless Consulting"** by Peter Block. The contracting phase is the most important and most skipped phase of a consulting engagement. Vague contracting creates resentment, scope creep, and failed engagements - not bad execution. A well-contracted engagement defines what success looks like, who does what, what happens when things go wrong, and what is explicitly not in scope. Do it in writing, at the start.

## Workflow

### Step 1: Clarify the Business Problem

Before scoping anything, confirm you are solving the right problem. Block warns against solving the presenting problem when the real problem is different.

Ask:
- "What is the specific business problem this engagement is solving?" (Not the symptom - the root cause)
- "What would we see differently in 6 months if this engagement succeeds?"
- "Who is most affected by this problem and how?"
- "What has already been tried?"

Document: a 2-3 sentence problem statement in business language. Share it with the client and confirm alignment before proceeding. If they revise it significantly, you were not scoping the right problem.

### Step 2: Define Success Criteria

Success criteria must be specific and agreed-upon before the engagement starts, not after.

Template:
```
Success Criteria for [engagement name]

By [end date or milestone]:
- [Measurable outcome 1: e.g., "Leadership team agrees on 3-year strategic priorities"]
- [Measurable outcome 2: e.g., "Operating costs reduced by 15% in [department]"]
- [Measurable outcome 3: e.g., "New process documented and staff trained"]

Leading indicators (how we'll know we're on track mid-engagement):
- [Indicator 1]
- [Indicator 2]
```

Avoid success criteria that are activity-based ("workshops completed", "report delivered"). Activity-based criteria let a bad engagement end on time. Outcome-based criteria ensure you actually solved the problem.

### Step 3: Define Scope - In and Out

Write two explicit lists: what is in scope and what is out of scope. Out-of-scope items are as important as in-scope items.

Template:
```
In Scope:
- [Specific deliverable or work stream 1]
- [Specific deliverable or work stream 2]
- [Geographic/organizational boundaries, e.g., "North America operations only"]

Out of Scope:
- [Excluded area 1 and why, e.g., "IT systems implementation - requires separate vendor"]
- [Excluded area 2]
- [Adjacent topics that may come up but are not part of this engagement]

Assumptions:
- [Client will provide X by Y date]
- [Access to Z team/data/systems will be available]
- [Engagement assumes no major org restructuring during the engagement period]
```

Out-of-scope items should address the top 3 things most likely to expand during the engagement based on the discovery conversations.

### Step 4: Define Roles and Responsibilities

Consulting engagements fail when the client expects the consultant to do everything and the consultant expects the client to do everything.

Template:
```
Consultant responsibilities:
- [What you will produce, facilitate, or lead]
- [Decision-making authority you have]
- [Communication cadence you will drive]

Client responsibilities:
- [What they must provide: data, access, decisions, approvals]
- [Who the day-to-day point of contact is]
- [Executive sponsor: name, role, availability]
- [Time commitment expected from client team: e.g., "4 hours/week from project team"]

Shared responsibilities:
- [Joint activities, e.g., "Co-facilitate working sessions"]
```

Block's principle: the client must be a participant, not an audience. If the client will not commit to specific responsibilities, the engagement is at risk before it starts.

### Step 5: Governance and Decision Rights

Define how decisions will be made and who can make them.

Template:
```
Decision authority:
- [Scope changes]: [Who approves - e.g., Executive Sponsor only]
- [Timeline changes]: [Who approves]
- [Budget changes]: [Who approves]

Escalation path:
- Day-to-day issues: [Primary contact]
- Engagement-level issues: [Project lead]
- Escalation: [Executive sponsor]

Change management:
- Any work outside agreed scope requires a signed change order before proceeding.
- Change orders will document: description of change, impact on timeline, impact on fee.
```

Never do out-of-scope work without a written change order, even a brief email confirmation. Verbal agreements on scope changes are how engagements become unprofitable.

### Step 6: Boundaries and Ground Rules

Explicitly name the behaviors and boundaries that make the engagement work.

Template:
```
Communication:
- Status reports: [Weekly/biweekly, by whom, to whom]
- Escalation: [How and when issues get escalated]
- Client availability: [When the consultant can reach the client, response time expectations]

Confidentiality:
- [What data/information will be treated as confidential]
- [What can be referenced in anonymized form for other clients or publications]

Engagement health:
- If either party believes the engagement is off track, [mechanism - e.g., a brief
  "engagement health check" call will be scheduled within one week]
```

The engagement health check clause is one of the most valuable things in a scope document. It creates a safe mechanism to surface problems before they become crises.

### Step 7: Document and Confirm

Produce a 1-2 page Engagement Scope Summary. Send it to the client before the kickoff meeting, not after. Ask them to confirm or correct it in writing.

The confirming email framing: "Attached is my summary of what we've agreed to. Please review and let me know if anything looks different from your understanding. I want to make sure we start aligned."

## Anti-Patterns

**1. Scoping by activity instead of outcome**
Bad: "We will deliver 5 workshops and a final report."
Good: "We will deliver a documented process redesign that reduces [step X] from 3 days to 4 hours."
Activity scopes create arguments about whether workshops were "good enough." Outcome scopes create alignment on what was actually accomplished.

**2. Skipping the out-of-scope list**
Bad: Listing only what's in scope and leaving adjacent areas undefined.
Good: Name the top 3 things most likely to expand the engagement and explicitly put them out of scope.
Scope creep starts in the gaps. If it's not listed as in scope or out of scope, it's a negotiation waiting to happen.

**3. Verbal-only contracting**
Bad: "We talked about it in the kickoff and everyone was aligned."
Good: Written scope summary confirmed by the client in writing (even an email reply saying "looks right").
Memory is unreliable. Priorities change. Written agreements survive personnel changes.

**4. No client responsibilities section**
Bad: Listing only what the consultant will do.
Good: Explicitly naming what the client must provide, and when.
When a client fails to provide agreed inputs (data, access, decisions), the engagement stalls. Written responsibilities give you a professional basis for addressing the delay.

**5. No change order process**
Bad: Saying yes to client requests informally and absorbing scope creep.
Good: A brief written change order process that both parties agreed to at kickoff.
The change order process does not have to be bureaucratic. An email confirmation is enough. The goal is a written record.

## Quality Checklist

- [ ] Problem statement written in business language and confirmed by client
- [ ] Success criteria are outcome-based, not activity-based
- [ ] In-scope list is specific (not "strategy work")
- [ ] Out-of-scope list addresses the most likely expansion areas
- [ ] Client responsibilities are named, not implied
- [ ] Executive sponsor is identified by name and role
- [ ] Decision rights defined for scope, timeline, and budget changes
- [ ] Change order process agreed upon
- [ ] Engagement health check mechanism included
- [ ] Scope summary sent to client before kickoff and confirmed in writing

Attribution

qa-amanqa-aman
View sourceSee grades on GitHubMore from qa-aman →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Caveman

Terse caveman voice: answer first, fluff gone, every technical fact kept. Use for /caveman, "caveman mode", "talk like caveman", "be brief", "less tokens". Stays on until "stop caveman" or "normal mode".

1100021 votes

Hyperplan

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...

698461 votes

Writing Skills

Create and manage Claude Code skills in HASH repository following Anthropic best practices. Use when creating new skills, modifying skill-rules.json, understanding trigger patterns, working with hooks, debugging skill activation, or implementing progressive disclosure. Covers skill structure, YAML frontmatter, trigger types (keywords, intent patterns), UserPromptSubmit hook, and the 500-line rule. Includes validation and debugging with SKILL_DEBUG. Examples include rust-error-stack, cargo-dep...

3931 votes

Mcp Code Execution

Routes multi-tool workflows through MCP servers for large datasets and pipelines. Use when Bash tool overhead is limiting throughput on data-heavy tasks.

3421 votes

catchup

Recovers the conversation and failed tool calls of a previous Codex, Amp, Claude Code, Antigravity, Cline, Copilot CLI, Cursor, DeepSeek Harness, Grok Build, Kimi, OpenCode, Pi Agent, or ZCode session. Use when the user says "catch up", "what did the last session do", "get me up to speed", "I switched agents", asks to recover/summarize a previous session before continuing, or asks to diagnose or report a catchup failure. Do NOT use for the current conversation, git history, or any non-agent log.

741 votes
View all in ai-agents →