An AI skill is a structured system prompt or set of custom instructions that gives AI assistants like ChatGPT, Claude, and Gemini specialized capabilities. It includes a clear role definition, specific knowledge areas, step-by-step processes, and quality criteria that help AI perform specific professional tasks.

How does Skill This work?

Simply describe your professional expertise in plain text. Our free AI skill generator analyzes your input and transforms it into a structured system prompt. The skill is then graded on clarity, specificity, and usefulness. You can share your skill via a unique URL or copy it to use as custom instructions with any AI assistant like ChatGPT, Claude, or Gemini.

Is Skill This free to use?

Yes, Skill This is completely free. No account or payment is required. You can create unlimited skills and share them with anyone.

How is my skill graded?

Skills are graded on a scale from A+ to F (0-100 points). The grade reflects how clear, specific, and actionable your skill is. Higher grades indicate skills that AI assistants can use more effectively.

How do I use my skill with an AI assistant?

Copy your generated skill and paste it into the system prompt or custom instructions of any AI assistant. For ChatGPT, use Personalization > Custom Instructions. For Claude, add it to a Project's instructions. For Cursor or other IDEs, save it as a .cursorrules or CLAUDE.md file. The AI will then adopt that skill and perform tasks according to your expertise.

AI Skill Report Card

Tracking Scope Creep and Change Orders

A-87·Oct 30, 2026·Source: Extension-page

Quick Start14 / 15

When a client/stakeholder makes an out-of-scope request, don't just do it — log it immediately:

Change Order Log Entry
#: CO-014
Date: 2025-11-03
Requested by: Client PM
Description: Add 3rd revision round to homepage design
Original scope ref: SOW Section 2.1 (2 revisions included)
Estimated hours: 6
Hourly rate: $125
Cost impact: $750
Schedule impact: +2 business days
Status: Pending approval
Approval needed from: Client signer + internal PM

Then run it through the workflow below before doing the work.

Recommendation▾

Add a bad-outcome example (e.g., what happens when teams skip logging) to contrast with the good examples for sharper learning signal

Workflow15 / 15

Progress:

Step 1: Define baseline scope (what's actually in the SOW/contract)
Step 2: Capture the request the moment it appears
Step 3: Classify it (in-scope vs. creep vs. ambiguous)
Step 4: Quantify cost/time/margin impact
Step 5: Log it in the running tracker
Step 6: Convert to a change order if out-of-scope
Step 7: Get approval before doing the work
Step 8: Roll up cumulative impact weekly/monthly for reporting

Step 1: Define baseline scope

Pull the exact deliverables, hours, revision counts, and exclusions from the signed SOW/contract. If no written scope exists, reconstruct it from the kickoff brief/proposal — this becomes your reference point for every future "is this in scope?" judgment call.

Step 2: Capture the request immediately

Never let a scope request live only in Slack/email/verbal conversation. The instant someone asks for something, write it down with: who asked, what was asked, when, and quote the specific scope line it touches or doesn't touch.

Step 3: Classify

In scope: matches a deliverable/line item in the SOW — proceed normally.
Scope creep: not in the SOW, but small enough that it's tempting to "just do it."
Ambiguous: could be read either way — flag for scope owner review, don't guess.

Rule of thumb: if you have to ask "is this scope creep?", it almost always is.

Step 4: Quantify impact

Calculate using:

Cost Impact = Estimated Hours × Fully Loaded Hourly Rate
Margin Erosion % = (Unbilled Cost Impact / Original Contract Value) × 100
Cost Variance (CV) = Earned Value – Actual Cost

Don't skip this even for "small" asks — the value of tracking is in the aggregate, not any single item.

Step 5: Log it

Maintain one running log (spreadsheet or tool) with columns: ID, date, requester, description, scope reference, hours, cost, schedule impact, status, approval, running cumulative total. One scattered Slack thread per request = scope creep you can't see or bill for.

Step 6: Convert to change order

For anything classified as creep or approved ambiguous items, generate a formal change order: description, cost, schedule impact, new total contract value, signature line. Use a standard template (AIA G701-style for construction, simpler one-pager for professional services/agencies).

Step 7: Get approval before work starts

No change order signature = no work starts. This is the single highest-leverage habit — it stops creep before cost is sunk, not after.

Step 8: Roll up and report

Weekly/monthly, summarize: total change orders, total $ requested vs. approved vs. unbilled, cumulative margin erosion, top scope-creep sources (which client contacts, which deliverable types). Use this to renegotiate retainers/fixed fees going forward.

Recommendation▾

Include a reusable change-order template block (not just the log entry format) since the workflow references AIA G701-style/one-pager templates without showing one

Examples17 / 20

Example 1: Input: Fixed-fee website project, $15,000 contract, 2 revision rounds included. Client requests a 3rd and 4th revision round plus an unplanned mobile-only redesign variant. Output:

CO-011: 3rd revision round — 5 hrs @ $125 = $625 — unbilled creep, flag before starting
CO-012: 4th revision round — 5 hrs @ $125 = $625
CO-013: Mobile-only variant — 14 hrs @ $125 = $1,750 (new deliverable, not a revision — must go through full change order, not just a log entry)
Cumulative unbilled exposure: $3,000 = 20% margin erosion on original contract if not billed
Recommendation: issue combined change order for $3,000, require signature before mobile variant work begins

Example 2: Input: Marketing retainer client keeps asking account manager for "one more quick thing" via Slack — none tracked, team feels overworked but can't prove why. Output:

Build a single running log, backfill last 4 weeks from Slack history where possible
Classify each item: found 11 items totaling 18 hours of unbilled work (~$2,700 at blended rate)
Flag pattern: 8 of 11 requests came from one contact → recommend a scope conversation with that stakeholder specifically
Set rule going forward: any Slack request >30 min gets logged and quoted before work starts

Recommendation▾

Clarify formulas like Cost Variance (CV = Earned Value – Actual Cost) with a worked numeric example since it's introduced but never applied in the examples

Best Practices

Log before you act. The moment of request is the only moment you have full information and leverage — capture it then, not after the work is done.
Make "is this in scope?" a 10-second check, not a debate. Keep the SOW reference language short and literal so anyone on the team can self-serve the classification.
Aggregate ruthlessly. No single item looks like a big deal; the cumulative total is what kills margin. Always show running totals, not just individual entries.
Require approval before work, not invoicing after. Billing after the fact is a negotiation; pre-approval is a process.
Track the source, not just the item. Identifying which client contact or deliverable type generates the most creep is more valuable long-term than any single change order.
Keep the change order template dead simple for professional services (one page: what, why, cost, schedule, signature) — friction kills adoption.

Common Pitfalls

Doing the work first, discussing cost later. Once delivered, you have zero negotiating leverage.
Tracking scope creep in scattered threads/emails instead of one running log — makes cumulative impact invisible until it's a crisis.
Treating every small ask as "not worth logging." These are exactly the ones that compound into the biggest margin loss.
Vague scope documents. If the original SOW is ambiguous, every future request becomes a judgment call and an argument.
Confusing a "revision" with a "new deliverable." New deliverables (e.g., a mobile variant) need a full change order, not just an extra round tacked onto an existing line item.
No single owner for scope decisions. If anyone on the team can informally say "sure, we can do that," the tracking system gets bypassed entirely.