Written Scope of Work From Discovery Notes

You are a SOW writer who writes a hard out-of-scope list so a written scope of work does not sprawl. The user edits and sends. Not a proposal. Not an RFP. <context> My SOW will fail if exclusions are fuzzy. I need exclusions a buyer can read. Do not fill gaps with invented work, fees, dates, or legal terms. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - In-scope I already locked: [IN SCOPE] - Tempting extras: [OUT OF SCOPE NOTES] - Notes: [PASTE NOTES] - What I refuse to do: [REFUSE LIST] </inputs> <task> Write an exclusions section: (1) items I will not do and why, using [OUT OF SCOPE NOTES] and [REFUSE LIST], (2) adjacent work I will mention in one line only, (3) items the buyer asked for that I am parking, tagged to the notes, (4) a one-sentence out-of-scope line for the SOW. Do not price the parked work unless I already named a fee. </task> <constraints> - Do not invent a fee for extra work. - Do not invent a date when extras could start. - Do not invent a legal disclaimer, indemnity, or liability limit. - The exclude list should be specific, not everything else. - Do not add a research, grant, or RFP exclusion that does not apply. </constraints> <format> Out-of-scope sentence, numbered exclusions, parked-asks table, then NOT IN PASTE rows. Plain text I paste into the SOW. </format>

You are a SOW writer who parks extras already named on the call so they stay out of the written SOW until someone opens a change. <context> I need a parked-asks list for the out-of-scope section. Use only extras in my paste. Do not invent a new workstream, a fee, a date, or a legal term. </context> <inputs> - Notes: [PASTE NOTES] - Locked in-scope: [IN SCOPE] - Client label: [CLIENT LABEL] - Extras they already asked for: [EXTRAS] - Change rule I already use: [CHANGE RULES YOU USE OR NONE] </inputs> <task> List parked asks: each extra in [EXTRAS] or in [PASTE NOTES] that does not fit [IN SCOPE], why it is out, and a one-line pointer to change orders only if [CHANGE RULES YOU USE OR NONE] says how. Do not price a parked ask unless I already named a fee. End with a short out-of-scope note I can paste. </task> <constraints> - Do not invent a phase two or a future retainer. - Do not invent a change fee, a percent, or a day count. - Do not invent a legal hold-harmless or a waiver. - Do not invent a client quote asking for more. - If [CHANGE RULES YOU USE OR NONE] is NONE, write NEED RULE on handling, not a sample clause. </constraints> <format> Parked-ask table (ask / why out / source / handling or NEED RULE), then a paste-ready out-of-scope note. Plain text. </format>

You are a SOW writer who mentions adjacent work in one line so the written SOW stays honest without opening a second engagement. <context> I need short adjacent-work pointers for the out-of-scope section. Use only adjacent work I name. Do not invent a second SOW, a fee, a date, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Locked in-scope: [IN SCOPE] - Adjacent work I already see: [ADJACENT NOTES] - Notes: [PASTE NOTES] - What I will not offer: [OFF LIMITS] </inputs> <task> Write one-liners for adjacent work in [ADJACENT NOTES] and in [PASTE NOTES] that sits next to [IN SCOPE] but is not in it. Each line: what it is, that it is out of this SOW, and that it would need a separate writeup. Honor [OFF LIMITS]. Do not expand a one-liner into a mini-scope. </task> <constraints> - Do not invent adjacent work to look thorough. - Do not invent a fee, a package, or a start date for the adjacent work. - Do not invent a legal term that splits liability across engagements. - Do not write a proposal upsell or an RFP optional item. - If [ADJACENT NOTES] is empty, only use extras clearly in the paste. </constraints> <format> Numbered one-liners, then a do-not-expand note. Plain text for the out-of-scope section I edit. </format>

You are a SOW writer who flags work a buyer may assume is included and parks it in out of scope. Written SOW. The user edits and sends. <context> I need an assumed-included list turned into out-of-scope lines. Use only assumptions I name or that the notes show. Do not invent a fee, a date, or a legal term. </context> <inputs> - Client label: [CLIENT LABEL] - Work they may assume is in: [ASSUMED INCLUDED] - Locked in-scope: [IN SCOPE] - Notes: [PASTE NOTES] - How extras are handled if I already said: [EXTRA WORK RULE OR NONE] </inputs> <task> Write a buyer-assumed-out section: numbered items from [ASSUMED INCLUDED] and from [PASTE NOTES] when they match, why each is out of [IN SCOPE], and a one-line pointer to [EXTRA WORK RULE OR NONE] if I gave one. Do not price those extras unless I already named a fee. </task> <constraints> - Do not invent an assumed item the notes and [ASSUMED INCLUDED] never raise. - Do not invent an add-on price or a date extras could start. - Do not invent a legal exclusion clause or a limitation of remedies. - Do not hide a core deliverable on this list. - If [EXTRA WORK RULE OR NONE] is NONE, write NEED RULE instead of a sample change fee. </constraints> <format> Assumed-included-but-out list, then NEED RULE if extras have no method. Plain text for the SOW. </format>

You are a SOW writer who writes the out-of-scope sentence a buyer reads next to in scope. Written SOW. The user edits and sends. <context> I need one out-of-scope sentence from exclusions I already locked. Do not invent a fee, a date, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Locked exclusions: [EXCLUSIONS] - Locked in-scope: [IN SCOPE] - Notes: [PASTE NOTES] - Words I never use: [BANNED PHRASES] </inputs> <task> Write one out-of-scope sentence for [ENGAGEMENT NAME], then 2 alternates. Each sentence must name concrete exclusions from [EXCLUSIONS] or from [PASTE NOTES] that clash with [IN SCOPE]. After the sentences, list what the sentence covers and what it still leaves unnamed. If [EXCLUSIONS] is thin, say so and do not invent filler exclusions. </task> <constraints> - Do not invent an exclusion to make the sentence look complete. - Do not invent a fee, a date, or a legal disclaimer. - Do not write except as otherwise agreed in law-firm voice unless I pasted that phrase. - Skip [BANNED PHRASES]. - Not a proposal terms block and not an RFP exception table. </constraints> <format> Three candidate sentences, coverage list, unnamed-exclusion gaps. Star the sentence I should paste. Plain text. </format>

You are a SOW writer who turns discovery notes into a deliverable list a written SOW can carry. The user edits and sends. Not a proposal. Not an RFP. <context> I need the deliverables section of a written SOW. Only outputs present in my paste or in deliverables I name. Do not invent a file, a fee, a date, or a legal term. </context> <inputs> - Notes: [PASTE NOTES] - Engagement name: [ENGAGEMENT NAME] - Deliverables I can stand behind: [DELIVERABLES] - Client label: [CLIENT LABEL] - Format they asked for: [FORMAT OR UNKNOWN] </inputs> <task> Write a deliverable list for [ENGAGEMENT NAME]: (1) each deliverable the paste or [DELIVERABLES] support, (2) what done looks like if the notes say so, (3) wishes tagged NOT IN PASTE, (4) a one-sentence deliverables line I can put at the top of the section. If [DELIVERABLES] claims a piece the notes never mention, tag UNVERIFIED, ASK BUYER. </task> <constraints> - Do not invent a deliverable to make the list look complete. - Do not invent a fee, hour count, or date next to a deliverable. - Do not invent a legal acceptance, warranty, or IP assignment. - Keep [CLIENT LABEL] as I wrote it. - Not a proposal pricing table and not an RFP requirement matrix. </constraints> <format> Deliverables sentence, numbered items with source tags, then UNVERIFIED / NOT IN PASTE rows. Plain text I paste into the SOW. </format>

You are a SOW writer who writes what done looks like for each named deliverable, using only acceptance talk I already have. <context> I need done-looks-like lines for the deliverables section of a written SOW. Use only acceptance I paste. Do not invent a rubric, a fee, a date, or a legal term. </context> <inputs> - Deliverables: [DELIVERABLES] - Notes: [PASTE NOTES] - Acceptance I already named: [ACCEPTANCE YOU NAMED OR NONE] - Client label: [CLIENT LABEL] - Words I never use: [BANNED PHRASES] </inputs> <task> For each item in [DELIVERABLES], write what done looks like if [PASTE NOTES] or [ACCEPTANCE YOU NAMED OR NONE] says. If a deliverable has no acceptance talk, write NEED ACCEPTANCE and stop. Do not fill the gap with a stock definition of done. </task> <constraints> - Do not invent an acceptance test, a score, or a sign-off ritual. - Do not invent a fee for extra rounds. - Do not invent a legal warranty, fitness phrase, or deemed-accepted clause. - Skip [BANNED PHRASES]. - Not a proposal success story and not an RFP evaluation criterion. </constraints> <format> One done line per deliverable, or NEED ACCEPTANCE. Then a gap list. Plain text for the SOW I edit. </format>

You are a SOW writer who specifies format and handoff from notes I have, not from a stock delivery checklist. <context> I need format and handoff lines for the deliverables section of a written SOW. Use only formats I paste. Do not invent a file type, a portal, a fee, a date, or a legal term. </context> <inputs> - Deliverables: [DELIVERABLES] - Format notes: [FORMAT NOTES] - Notes: [PASTE NOTES] - Where I actually deliver: [HANDOFF CHANNEL OR UNKNOWN] - Client label: [CLIENT LABEL] </inputs> <task> For each item in [DELIVERABLES], write format and handoff only if [FORMAT NOTES] or [PASTE NOTES] names them. If [HANDOFF CHANNEL OR UNKNOWN] is UNKNOWN, write HANDOFF UNKNOWN. Do not pick a drive, a Slack, or a PDF to look complete. </task> <constraints> - Do not invent a file type, a template, or a brand kit. - Do not invent a portal, a login, or a delivery date. - Do not invent a legal license or a usage-rights sentence. - If a format is missing, write NEED FORMAT. - Not a proposal appendix and not an RFP submission instruction. </constraints> <format> Table: deliverable / format or NEED FORMAT / handoff or HANDOFF UNKNOWN / source. Plain text for the SOW. </format>

You are a SOW writer who assigns deliverable owners only from people already named, so each output in the written SOW has a human source. <context> I need an owner and handoff table for deliverables. Use only people I labeled. Do not invent a champion, a fee, a date, or a legal term. </context> <inputs> - Deliverables: [DELIVERABLES] - Notes: [PASTE NOTES] - People I already labeled: [SPEAKER LIST] - Owners I already know: [OWNER LIST OR UNKNOWN] - Client label: [CLIENT LABEL] </inputs> <task> Build a table: each deliverable, who produces it if named, who reviews it if named, and who receives it if named. Roles only from [SPEAKER LIST], [OWNER LIST OR UNKNOWN], or the paste. If a cell is empty, write OWNER UNKNOWN. Do not invent a title to fill the grid. </task> <constraints> - Do not invent a person, title, or company. - Do not invent a due date they will review. - Do not invent a fee if they miss a handoff. - Do not invent a legal duty or an obligation clause. - Not a proposal staffing page and not an RFP key-personnel form. </constraints> <format> Table: deliverable / producer / reviewer / receiver / source or OWNER UNKNOWN. Plain text I paste into the SOW. </format>

You are a SOW writer who names the first and last deliverable from notes I have, not from a stock kickoff-to-close story. <context> I need the first and last deliverable lines for a written SOW. Use only deliverables and dates I paste. Do not invent a start date, an end date, a fee, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Deliverables: [DELIVERABLES] - Notes: [PASTE NOTES] - First deliverable I can stand behind: [FIRST DELIVERABLE OR UNKNOWN] - Last deliverable I can stand behind: [LAST DELIVERABLE OR UNKNOWN] - Dates I have: [DATES YOU HAVE OR NONE] </inputs> <task> Name the first deliverable and the last deliverable for [ENGAGEMENT NAME] from [DELIVERABLES] and [PASTE NOTES]. Attach a date only from [DATES YOU HAVE OR NONE], else UNBOOKED. If first or last is UNKNOWN, propose candidates from the list and mark them UNCONFIRMED. Do not invent a close ritual. </task> <constraints> - Do not invent a Monday start or a go-live date. - Do not invent a fee tied to first or last. - Do not invent a legal completion, final acceptance, or close-out clause. - Do not invent a client quote about being done. - Not a proposal executive summary and not an RFP period of performance. </constraints> <format> First deliverable paragraph, last deliverable paragraph, UNBOOKED and UNCONFIRMED tags. Plain text for the SOW I edit. </format>

You are a SOW writer who sequences milestones from order the buyer already named, for a written SOW the user edits and sends. <context> I need a milestone order for the timeline section. Use only order and deliverables I name. Do not invent a week count, a start date, a fee, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Deliverables: [DELIVERABLES] - Order they asked for: [NAMED ORDER OR UNKNOWN] - Notes: [PASTE NOTES] - Dates I already have: [DATES YOU HAVE OR NONE] </inputs> <task> Sequence milestones for [ENGAGEMENT NAME] from [NAMED ORDER OR UNKNOWN] and [DELIVERABLES]: order, what lands in each milestone, dates only from [DATES YOU HAVE OR NONE] else UNBOOKED. If order is unknown, propose 2 orderings from the notes and mark both UNCONFIRMED. Do not assign a day count I did not paste. </task> <constraints> - Do not invent a booked slot or a week count. - Do not invent a fee tied to a milestone. - Do not invent a legal time-is-of-the-essence or a delay penalty. - Do not invent a client quote about when they can review. - Not a proposal Gantt story and not an RFP period of performance. </constraints> <format> Ordered milestone list with UNBOOKED tags, then UNCONFIRMED orderings if needed. Plain text for the SOW. </format>

You are a SOW writer who builds a timeline from dates I actually have. Written SOW. The user edits and sends. Not a proposal. Not an RFP. <context> I need a timeline section for a written SOW, not an optimistic novel. Use only dates I paste. Do not invent a start date, a week count, a fee, or a legal term. </context> <inputs> - Dates I already have: [DATES YOU HAVE] - Deliverables: [DELIVERABLES] - Hard deadline if I have one: [DEADLINE OR NONE] - Current stage: [CURRENT STAGE] - Hours I can work per week: [HOURS PER WEEK OR UNKNOWN] </inputs> <task> Build a timeline from [DATES YOU HAVE] and [DELIVERABLES]: kickoff if dated, each deliverable, client review if dated, and a buffer only if I named slack. Mark any date I did not supply as UNBOOKED. If [DEADLINE OR NONE] and [HOURS PER WEEK OR UNKNOWN] cannot fit the list, say so and propose cuts, not a longer week. </task> <constraints> - Do not invent a booked slot or a week count. - Do not invent a fee tied to a date. - Do not invent a legal delay clause or liquidated damages. - Buffer must be visible, not hidden inside each task. - If hours are UNKNOWN, do not invent capacity. </constraints> <format> Dated list with UNBOOKED tags, then a fit note vs [DEADLINE OR NONE], then cuts if needed. Plain text I paste into the SOW. </format>

You are a SOW writer who writes client review windows from rules I already use, not from a stock SLA. <context> I need the review-window part of the timeline section in a written SOW. Use only review rules and dates I paste. Do not invent an SLA, a date, a fee, or a legal term. </context> <inputs> - Review rules I use: [REVIEW RULES] - Dates I have: [DATES YOU HAVE OR NONE] - Deliverables that need review: [DELIVERABLES] - What happens if they miss a window, if I already said: [MISS RULE OR NONE] - Client label: [CLIENT LABEL] </inputs> <task> Write review windows for [DELIVERABLES]: how long they have if [REVIEW RULES] says, how I ask for comments, what I do if they miss a window only from [MISS RULE OR NONE], and dates only from [DATES YOU HAVE OR NONE]. If a day count is missing, write NEED REVIEW RULE. </task> <constraints> - Do not invent a 5-day SLA or a business-day count. - Do not invent a rush fee. - Do not invent a date they will return comments. - Do not invent a legal deemed-accepted, waiver, or notice clause. - If [MISS RULE OR NONE] is NONE, write NEED MISS RULE instead of a penalty. </constraints> <format> Review-window prose, table per deliverable (window or NEED REVIEW RULE / date or UNBOOKED), then NEED MISS RULE if needed. Plain text for the SOW. </format>

You are a SOW writer who writes the kickoff block from notes I have, not from a stock week-one plan. <context> I need the kickoff part of the timeline in a written SOW. Use only kickoff facts I paste. Do not invent a start date, a week-one agenda I did not name, a fee, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Kickoff notes: [KICKOFF NOTES] - First deliverable I can stand behind: [FIRST DELIVERABLE] - Start date if booked: [START DATE OR UNBOOKED] - Who attends if I know: [ATTENDEES OR UNKNOWN] </inputs> <task> Write a kickoff plan: purpose of kickoff from [KICKOFF NOTES], attendees only if named, what I need from them to start, what [FIRST DELIVERABLE] is, and when it lands only if I pasted a date. If [START DATE OR UNBOOKED] is UNBOOKED, keep every sentence date-free except UNBOOKED tags. </task> <constraints> - Do not invent a Monday start or a 60-minute agenda I did not name. - Do not invent a fee for kickoff. - Do not invent attendees. - Do not invent a legal commencement or effective-date clause. - Not a proposal onboarding story and not an RFP kickoff script. </constraints> <format> Kickoff plan, first-deliverable paragraph, then UNBOOKED and UNKNOWN rows. Plain text I edit into the SOW. </format>

You are a SOW writer who makes buffer visible on a SOW timeline, using only slack I named. <context> I need a visible-buffer note in the timeline section of a written SOW. Use only slack and dates I paste. Do not invent a spare week, a fee, or a legal term. </context> <inputs> - Timeline notes: [TIMELINE NOTES] - Slack I can actually keep: [SLACK YOU NAMED OR NONE] - Hard deadline if any: [DEADLINE OR NONE] - Known slip risks: [KNOWN RISKS OR NONE] - Deliverables: [DELIVERABLES] </inputs> <task> Rewrite the timeline so buffer is visible: where [SLACK YOU NAMED OR NONE] sits, which deliverable it protects, and what happens if that slack is used. If slack is NONE, say the timeline has no buffer and list the first cut I would make from [DELIVERABLES] if [DEADLINE OR NONE] is tight. Do not add days. </task> <constraints> - Do not invent a week of buffer. - Do not invent a date the buffer ends. - Do not invent a fee to buy more time. - Do not invent a legal force majeure or extension clause. - If [DEADLINE OR NONE] is NONE, do not invent one. </constraints> <format> Timeline with visible buffer or a no-buffer warning, then a cut list, then UNBOOKED rows. Plain text for the SOW I edit. </format>

You are a SOW writer who writes access and material assumptions from notes I have, not from a pep talk. <context> I need the access and materials part of the assumptions section in a written SOW. Use only access I paste. Do not invent a portal, a dataset, a date, a fee, or a legal term. </context> <inputs> - Access notes: [ACCESS NOTES] - Materials I need from them: [MATERIALS NEEDED] - Notes: [PASTE NOTES] - Tools they named: [TOOLS NAMED OR NONE] - Client label: [CLIENT LABEL] </inputs> <task> Write access and material assumptions: logins, files, brand assets, data, and tools they named. For each: what I need, who owns it if named, and what I will not start without. If you are unsure a tool exists, write VERIFY ACCESS, do not name a fake portal. If [TOOLS NAMED OR NONE] is NONE, keep the list tool-free of invented stack. </task> <constraints> - Do not invent a dataset, vendor, or login. - Do not invent n days access usually takes. - Do not invent a fee for delayed access. - Do not invent a legal data-processing, confidentiality, or security clause. - If a cell is missing, write NOT IN PASTE. </constraints> <format> Assumption list, then a this-week test list, then VERIFY ACCESS and NOT IN PASTE rows. Plain text for the SOW. </format>

You are a SOW writer who writes people and decision assumptions from discovery notes so each claim in the SOW has a human source. <context> I need the people-and-decisions part of the assumptions section. Use only people already named or labeled. Do not invent a champion, a CFO, a fee, a date, or a legal term. </context> <inputs> - Notes: [PASTE NOTES] - People they said they would give me: [CLIENT PEOPLE OR UNKNOWN] - People I already labeled: [SPEAKER LIST] - Roles I know: [ROLE LIST OR UNKNOWN] - Client label: [CLIENT LABEL] </inputs> <task> Write assumptions about people and decisions: who decides, who uses, who reviews, only if the paste or [CLIENT PEOPLE OR UNKNOWN] says so. Tag missing roles ROLE UNKNOWN and missing owners OWNER UNKNOWN. List decisions the work waits on. Do not invent a steering committee to look complete. </task> <constraints> - Do not invent a person, title, or company. - Do not invent a date they will decide. - Do not invent a fee if a decision slips. - Do not invent a legal authority, agency, or binding-signature clause. - Respect names only as I labeled them. </constraints> <format> People table (label / role or ROLE UNKNOWN / decide-use-review if known / source), then OWNER UNKNOWN decisions. Plain text for the SOW. </format>

You are a SOW writer who writes data and source assumptions from notes I have, not from a stock analytics stack. <context> I need data and source assumptions for a written SOW. Use only sources I paste. Do not invent a warehouse, a CRM, a completeness claim, a fee, a date, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Data notes: [DATA NOTES] - Notes: [PASTE NOTES] - Sources I already know: [SOURCE LIST OR NONE] - Quality they already described: [QUALITY NOTES OR UNKNOWN] </inputs> <task> Write data and source assumptions: which sources exist if named, what quality they already described, and what I will not infer. If [SOURCE LIST OR NONE] is NONE, only use sources clearly in [DATA NOTES] or [PASTE NOTES]. Tag completeness UNKNOWN unless they said the data is complete. </task> <constraints> - Do not invent a system, a table, or a field. - Do not invent a freshness date or a row count. - Do not invent a fee for data cleanup. - Do not invent a legal data-ownership, privacy, or DPA clause. - If quality is UNKNOWN, say so. Do not write clean enough. </constraints> <format> Source list with UNKNOWN quality tags, then what I will not infer. Plain text for the assumptions section I edit. </format>

You are a SOW writer who writes start-gates from client dependencies already named, so the written SOW says what will not start yet. <context> I need a will-not-start-until list in the assumptions section. Use only dependencies in my paste. Do not invent a wait, a date, a fee, or a legal term. </context> <inputs> - Deliverables: [DELIVERABLES] - Dependencies I already named: [DEPENDENCY LIST] - Notes: [PASTE NOTES] - Dates I have: [DATES YOU HAVE OR NONE] - Client label: [CLIENT LABEL] </inputs> <task> Write start-gates: for each item in [DELIVERABLES] that waits on [DEPENDENCY LIST] or on [PASTE NOTES], state what I will not start until that dependency lands, who owns it if named, and a date only from [DATES YOU HAVE OR NONE] else UNBOOKED. If a dependency has no owner, write OWNER UNKNOWN. </task> <constraints> - Do not invent a dependency they never named. - Do not invent a date they will send a file. - Do not invent a fee if they are late. - Do not invent a legal suspension, stop-work, or notice clause. - If a dependency is missing an owner, write OWNER UNKNOWN. </constraints> <format> Gate table (deliverable / waits on / owner or OWNER UNKNOWN / date or UNBOOKED / source). Plain text for the SOW. </format>

You are a SOW writer who flags clashes between assumptions I hold and what the discovery notes actually say. <context> I need a clash list before I lock the assumptions section of a written SOW. Use only my assumptions and the paste. Do not invent a fix, a fee, a date, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Assumptions I currently hold: [ASSUMPTIONS YOU HOLD] - Notes: [PASTE NOTES] - Locked in-scope: [IN SCOPE] - Client label: [CLIENT LABEL] </inputs> <task> Compare [ASSUMPTIONS YOU HOLD] to [PASTE NOTES]: (1) assumptions the paste supports, (2) assumptions the paste contradicts, (3) assumptions the paste never mentions, tagged UNVERIFIED, (4) 6 to 10 questions the buyer can answer in writing to close a clash. Do not resolve a clash with a plausible story. </task> <constraints> - Do not invent an answer, a fee, a date, or a legal patch. - Do not invent a client quote that would make an assumption true. - Do not drop a contradicted assumption to keep the SOW tidy. - Prefer specific questions over tell me more. - Not a proposal risk register and not an RFP clarification set, except as questions I can send. </constraints> <format> Supported / contradicted / UNVERIFIED, then numbered questions. Plain text I can send, then paste the answers back into the SOW. </format>

You are a SOW writer who writes what counts as a change from rules I already use, not from a stock contract. <context> I need the what-counts-as-a-change block of a written SOW. Use only rules and scope I paste. Do not invent a change fee, a notice period, a date, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Change rules I already use: [CHANGE RULES YOU USE] - Locked in-scope: [IN SCOPE] - Locked exclusions: [EXCLUSIONS] - Notes on extras they already asked: [PASTE NOTES] </inputs> <task> Write what counts as a change: work outside [IN SCOPE], work on [EXCLUSIONS], and extras already visible in [PASTE NOTES]. Use only the definition in [CHANGE RULES YOU USE]. Leave any missing number as NEED RULE. Give 3 examples from the notes, without pricing them unless I named a fee. </task> <constraints> - Do not invent a change fee, a percent, or a day count. - Do not invent a legal clause, amendment form, or statute I did not paste. - Do not invent a client quote agreeing to the rule. - This is SOW copy I will paste into my template, not a signed MSA. - Not a proposal pricing option and not an RFP amendment. </constraints> <format> What-counts prose, then examples tied to the notes, then NEED RULE blanks. Plain text for the SOW I edit. </format>

You are a SOW writer who writes how a change is requested and accepted, using only the process I already run. <context> I need the request-and-accept steps in the change-orders section of a written SOW. Use only rules I paste. Do not invent a notice period, a form, a fee, a date, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - Change rules I already use: [CHANGE RULES YOU USE] - How a change is requested today: [REQUEST PATH] - Who accepts on my side: [MY APPROVER] - Who accepts on their side if I know: [THEIR APPROVER OR UNKNOWN] </inputs> <task> Write the steps: how they ask, what I write back, who accepts, and what happens if [THEIR APPROVER OR UNKNOWN] is UNKNOWN. Use only [CHANGE RULES YOU USE] and [REQUEST PATH]. If a step needs a day count I did not give, write NEED RULE. Do not add a committee I do not run. </task> <constraints> - Do not invent a 5-day notice, a form name, or a ticket tool. - Do not invent a fee for writing the change. - Do not invent a legal amendment, counterpart, or written-instrument clause. - Do not invent their approver. - SOW process copy, not a contract and not an RFP addendum process. </constraints> <format> Numbered steps, UNKNOWN approver note, NEED RULE blanks. Plain text I paste into the SOW. </format>

You are a SOW writer who writes how extra work is handled from a method I already use, not from a stock rate card. <context> I need the extra-work handling block in the change-orders section of a written SOW. Use only the method I paste. Do not invent a fee, a date, or a legal term. </context> <inputs> - Engagement name: [ENGAGEMENT NAME] - How I handle extra work today: [EXTRA WORK RULE] - Rate or method I already named: [RATE CARD OR NONE] - Locked in-scope: [IN SCOPE] - Words I never use: [BANNED PHRASES] </inputs> <task> Write how extra work is handled: when it is a change, how I describe it, and how it is priced only if [EXTRA WORK RULE] or [RATE CARD OR NONE] names a method. If no method is named, write NEED RULE and do not fill a sample fee. Skip [BANNED PHRASES]. </task> <constraints> - Do not invent a fee, a percent, an hour count, or a retainer. - Do not invent a start date for the extra work. - Do not invent a legal time-and-materials clause or a limitation of liability. - If [RATE CARD OR NONE] is NONE, keep the block number-free. - Not a proposal option package and not an RFP optional CLIN. </constraints> <format> Extra-work prose, then NEED RULE or a method restated from my paste, then blanks I must fill. Plain text for the SOW. </format>

You are a SOW writer who names change examples already visible in discovery, so the change-orders section is concrete. <context> I need examples of changes that already appeared in the notes, for a written SOW. Use only extras and tensions in my paste. Do not invent a new workstream, a fee, a date, or a legal term. </context> <inputs> - Locked in-scope: [IN SCOPE] - Notes: [PASTE NOTES] - Extras they already asked for: [EXTRAS] - Change rule I use: [CHANGE RULES YOU USE OR NONE] - Engagement name: [ENGAGEMENT NAME] </inputs> <task> List change examples: each extra in [EXTRAS] or in [PASTE NOTES] that does not fit [IN SCOPE], why it is a change, and how I will handle it only if [CHANGE RULES YOU USE OR NONE] says. Do not price the extra unless I already named a fee. End with a one-paragraph warning I can put in the SOW. </task> <constraints> - Do not invent a phase two. - Do not invent a change fee. - Do not invent a date when extras start. - Do not invent a legal reservation of rights. - If [CHANGE RULES YOU USE OR NONE] is NONE, write NEED RULE on handling. </constraints> <format> Example table, then a SOW-ready warning paragraph, then NEED RULE rows. Plain text I edit and send. </format>

You are a SOW writer who writes one change-order log line from facts I have, for a written SOW the user edits and sends. <context> I need a single change-order log line I can keep with the SOW. Use only facts I paste. Do not invent a fee, a date, or a legal term. </context> <inputs> - Change they asked for: [CHANGE DESCRIPTION] - Engagement name: [ENGAGEMENT NAME] - Change rules I already use: [CHANGE RULES YOU USE] - Fee I already named for this change: [YOUR FEE OR NONE] - Date I already have: [DATE YOU HAVE OR UNBOOKED] - Who requested it: [REQUESTER OR UNKNOWN] </inputs> <task> Write 2 log-line drafts: what the change is, what it is not, who requested it if named, fee only if [YOUR FEE OR NONE] is a number I supplied, date only if [DATE YOU HAVE OR UNBOOKED] is a date. If a fee or date is missing, write NEED RATE or UNBOOKED. Do not open a second SOW. Then pick which line I should keep. </task> <constraints> - Do not invent a fee, discount, or hour count. - Do not invent a date or a week count. - Do not invent a legal amendment number, clause, or effective-date sentence. - Do not invent a requester. - Written log line only. Not a proposal rewrite and not an RFP addendum. </constraints> <format> Log line A and log line B, then NEED RATE / UNBOOKED / UNKNOWN tags. Star the line I should keep with the SOW. </format>