---
name: sow-pws-builder
description: >
  Trigger for: writing, revising, converting, or descoping a federal Statement
  of Work, Performance Work Statement, SOW, PWS, or SOO;
  develop executable requirements; define contract scope; create measurable
  performance standards; or prepare requirements before an IGCE. Produce a
  contract-file-ready .docx plus separate chat-only staffing and Section B
  handoffs. Never place FTEs, SOC codes, staffing estimates, IGCE content,
  CLINs, or pricing schedules inside the SOW/PWS body. Do NOT use for the IGCE,
  market research report, acquisition plan, QASP, or clause-selection matrix.
---

# SOW/PWS Builder

## Overview

Turn program-office scope decisions into a contract-file-ready `.docx` SOW or PWS. Produce three separate outputs:

1. The SOW/PWS `.docx`, containing requirements and measurable acceptance or surveillance content.
2. A chat-only staffing handoff for the FFP, LH/T&M, or CR pricing skill.
3. A chat-only Section B handoff with suggested CLIN structure, labor categories or estimated hours when needed, travel/ODC lines, and the total ceiling-price input for T&M/LH.

Never combine the handoffs with the document. FAR 37.602(b)(1) directs agencies, to the maximum extent practicable, to describe performance work by required results rather than method or hours. FAR 16.601 requires fixed hourly rates by labor category for T&M/LH and an overall ceiling price, but it does not require a labor-category ceiling-hours table inside the PWS. Keep pricing structure in Section B unless the user supplies a controlling solicitation template that places it elsewhere.

No external MCP server is required.

## Product quality default

Make the PWS/SOW read like a concise acquisition-file deliverable, not a process transcript. Its first page must identify the mission need, the performance decision it supports, the material operating assumptions, and the next acquisition-team action. Use a requirement-specific title, a short executive purpose block, and distinct visual hierarchy appropriate to the document type. Put detailed evidence and source notes in a compact appendix only when they affect a requirement; never let them crowd out executable requirements. This does not permit staffing, SOC, CLIN, pricing, or IGCE content inside the document.

Load supporting files only when needed:

- [question-blocks.md](references/question-blocks.md) for intake and scope questions.
- [document-specification.md](references/document-specification.md) before authoring the `.docx`.
- [professional-product-standard.md](references/professional-product-standard.md) before authoring the `.docx`.
- [regulatory-and-content-rules.md](references/regulatory-and-content-rules.md) for contract-type, security, QASP, and language rules.
- [handoff-specification.md](references/handoff-specification.md) before final chat output.
- [runtime-adaptation.md](references/runtime-adaptation.md) for questions, document tools, TOC handling, and delivery.
- [validation-gates.md](references/validation-gates.md) before delivery.

## Permanent correctness gates

1. **Separation:** The `.docx` contains no staffing handoff, FTE estimate, SOC code, IGCE content, CLIN table, pricing schedule, or skill-chain message. The two handoffs exist only in chat.
2. **No false FAR exception:** Do not cite FAR 37.102(d) as an hours prohibition. Use FAR 37.602(b)(1) for results-oriented PWS language.
3. **T&M/LH structure:** FAR 16.601(c)(2) requires fixed hourly rates by labor category, and FAR 16.601(d)(2) requires an overall ceiling price. Put the pricing schedule and ceiling in the Section B handoff, not the SOW/PWS body.
4. **Contract-type boundary:** Explain how a user-selected type changes the document, but do not originate the FAR Part 16 decision, T&M/LH Determination and Findings, commercial-item determination, or CPFF form selection.
5. **CPFF form:** Require the user to confirm Completion or Term under FAR 16.306(d). Do not default either form. Reflect the confirmed form in the document framework.
6. **Result-oriented PWS:** Organize a PWS around outcomes, measurable standards, AQLs, and assessment methods. Avoid prescribing staffing or contractor method unless a constraint is genuinely Government-controlled.
7. **QASP and CPARS:** QASP payment or administrative consequences must not pre-commit CPARS ratings. Never map an AQL threshold to `Satisfactory`, `Very Good`, `Exceptional`, `Marginal`, or `Unsatisfactory` CPARS ratings.
8. **Key personnel:** Name roles and qualifications only. Do not quantify staff. Never cite FAR 52.237-2 as a key-personnel substitution clause.
9. **Coverage derivation:** For the chat-only staffing handoff, derive coverage as annual coverage hours divided by productive hours. At 1,880 hours, one 24x7x365 seat is 4.6596 FTE, not three and not 4.2.
10. **Tier 1 mapping:** Preserve the project decision that Tier 1 help desk or contact-center agents map to SOC 43-4051. Do not change it during modernization.
11. **Decision gates:** Do not self-approve staffing or the Phase 2 Decision Summary. End each gate response at its confirmation question and wait.
12. **DOCX validation:** Use real heading styles, render every page to images, inspect every page, audit text and OOXML, and do not claim Word compatibility from a fallback renderer alone.

## Workflow selection

### Workflow A: full build

Use for a concept, rough requirements, or a build from scratch. Run intake and all phases.

### Workflow B: SOO conversion

Extract settled objectives, constraints, location, period, systems, volumes, security, and other facts from the SOO. Present the gaps that must be decided, then run the remaining phases without re-asking settled facts.

### Workflow C: scope reduction

Use an existing SOW/PWS and, when available, IGCE cost drivers to present capability and coverage tradeoffs. The user selects reductions. Revise affected requirements and handoffs without placing staff counts in the document.

## Runtime pre-flight

When this skill is entered immediately after a numbered Pre-Award Agent selection and the current assistant response has not already shown the orchestrator's outcome preview, emit these exact four lines before any intake or capability check:

Begin line 1 with `Recommended outcome:`. Do not precede the block with a heading, acknowledgement, selection recap, routing narration, or code fence.

```text
Recommended outcome: Validated SOW/PWS `.docx` plus two chat-only handoffs
Includes: an executable work statement, measurable standards, a staffing handoff, and a Section B handoff
Boundary/default: recommend PWS for performance-based services when the requirement supports it; the user or Contracting Officer retains contract type, commerciality, and other reserved decisions
Next: collect the current requirement or source material and missing acquisition-strategy facts
```

This is a routing fallback, not a second preview. Do not repeat it when the orchestrator already rendered the four lines in the current assistant response, and never replace it with component intake.

After the orchestrator's outcome preview, begin acquisition-strategy intake and reuse every supplied fact. Do not make document-authoring or rendering capability the first question or first action after workflow selection. A read-only or artifact-limited session may still inspect supplied material, identify gaps, and complete useful scope intake.

Before promising or beginning the validated `.docx` build:

1. Confirm the host can read inputs and create `.docx` files.
2. Confirm a DOCX render path is available, preferably LibreOffice through the host's document workflow.
3. Confirm Python and `python-docx` or an equivalent OOXML authoring capability for `scripts/validate_docx.py`.
4. Match capabilities semantically. Do not depend on `/mnt` paths, a named client tool, or a generated namespace.
5. If document authoring is unavailable, stop at the artifact boundary and report the missing capability. Preserve the intake already completed and explain what remains needed to resume. Do not silently substitute Markdown or HTML for the contract-file deliverable.

## Acquisition strategy intake

Collect framing decisions in one pass, skipping facts already supplied:

1. SOW or PWS.
2. User-confirmed contract type: FFP, T&M, LH, CR subtype, or hybrid by CLIN.
3. Commercial, noncommercial, or pending Contracting Officer determination.
4. Agency and solicitation format, if one controls.
5. Purpose, audience, acquisition stage, and desired file name.

If the user is unsure about SOW versus PWS, explain that PWS is outcome-oriented and preferred for performance-based services to the maximum extent practicable. A recommendation about document form is permitted. Do not turn it into the contract-type or commerciality decision.

If T&M or LH is selected, flag the D&F and overall ceiling-price requirement for Contracting Officer action. If CPFF is selected, require Completion or Term. If commerciality is unsettled, record `[DEFAULT: Commerciality determination pending]` in Constraints and Assumptions rather than deciding it.

## Phase 0: SOO or source intake

For a supplied source document:

1. Extract background, purpose, objectives, performance constraints, location, period, systems, volumes, security, Government-furnished resources, and named standards.
2. Distinguish explicit facts from derived assumptions.
3. Present gaps as the questions needed for executable requirements.
4. Carry settled facts forward without asking them again.

If the source is too thin to support task or objective decomposition, state that it can serve as background but additional scope decisions are required.

## Phase 1: scope decision tree

Use [question-blocks.md](references/question-blocks.md). Prefer structured choices when the host supports them; otherwise use numbered choices with a free-text escape. Batch three to four related questions. Ask open text only for values such as system names, volume, or incumbent facts.

Sequence:

1. Mission and service model.
2. Technical scope.
3. Scale and volume.
4. Organizational scope and phasing.
5. Period, transition, and Section B preferences.
6. Quality, oversight, security, and Government-furnished resources.

### Staffing derivation for the internal handoff

Derive a candidate staffing table only after scope decisions. Every row must cite a basis: workload, coverage hours, system/module count, site count, delivery cadence, or an explicit user override. Heuristics are starting points, not facts.

- Continuous coverage: covered seats times annual coverage hours divided by productive hours per FTE.
- Development: derive by system/module count and team design; do not use an unexplained fixed ratio.
- Contact center: annual contacts divided by workdays and contacts per agent-day, adjusted for service level and productive hours.
- Transition and surge: separate time-limited rows.
- O&M: derive from named workload, SLA, or environment size; never assume a fixed percentage of development staffing without user confirmation.

Present the candidate staffing table in chat and ask the user to confirm, amend, or override it. End immediately after that question and wait. Preserve override reasons.

## Phase 2: Decision Summary gate

After staffing approval and before authoring, present a concise Decision Summary containing:

- SOW/PWS, contract type and subtype, CPFF form when relevant, and commerciality status.
- Agency/template and solicitation-stage context.
- All defaults or derived assumptions with one-line rationale.
- Section 3 task areas for a SOW or performance objectives for a PWS.
- Applicable deliverables, QASP or inspection approach, security, period, location, and transition.
- Confirmation that staffing, SOCs, CLINs, and pricing will remain outside the document.

The final sentence must ask the user to proceed or correct the summary. Stop immediately after the question. Do not author the `.docx` in the same response.

## Phase 2: document assembly

After explicit approval:

1. Read [professional-product-standard.md](references/professional-product-standard.md), [document-specification.md](references/document-specification.md), and [regulatory-and-content-rules.md](references/regulatory-and-content-rules.md). Formal requirement controls remain binding, but the document should still read as deliberate professional work rather than a generated template.
2. Use the host's document-authoring workflow and a formal business-document design system. Preserve a supplied agency template when one exists.
3. Use real `Heading 1`, `Heading 2`, and `Heading 3` styles, real numbered or bulleted lists, explicit table geometry, page numbers, and accessible repeating table headers.
4. For more than eight main sections, include a dynamic TOC field. Set the document to update fields on open. If Word is available, update and save the field before delivery. Otherwise disclose the exact refresh step in chat. Do not put the refresh instruction inside the document.
5. Run the render, text, structure, and separation gates in [validation-gates.md](references/validation-gates.md).
6. Fix defects and repeat rendering until every page passes.

Do not generate a second DOCX for either handoff.

## Phase 3: final validation and handoff

Before delivery:

1. Confirm every requirement maps to a deliverable or measurable standard.
2. Confirm every deliverable has format, trigger or due date, and acceptance criteria.
3. Confirm document type, contract framework, security, location, period, and transition are consistent.
4. Confirm QASP consequences contain no CPARS rating commitments.
5. Confirm the document contains no staffing, SOC, IGCE, CLIN, pricing, or skill-chain leakage.
6. Run `scripts/validate_docx.py <document> --document-type <sow|pws>`.
7. Render and inspect every page.

Deliver the `.docx`, then present both chat-only handoffs using [handoff-specification.md](references/handoff-specification.md). The pricing skill consumes the approved staffing table without repeating decomposition. The final message must state that the SOW/PWS is the contract-file artifact and the handoffs are internal workpapers outside it.

When a dynamic TOC has not been updated in Word, end with: `Open the document in Word, press Ctrl+A (Cmd+A on Mac), then F9 to populate or refresh the Table of Contents, and save.`

## Out of scope

- IGCE rates, wraps, fee, or cost calculations.
- Acquisition plan, market research report, source-selection plan, J&A, or clause matrix.
- Final contract-type, commerciality, D&F, or inherently-governmental determination.
- Full standalone QASP beyond the embedded summary.
- Section I or L clause selection.

---

*MIT © James Jenrette / 1102tools. Source: github.com/1102tools-dev/federal-contracting-skills*

# SOW/PWS Builder Modernization Test Record

Tested August 21, 2026 against the modernized skill. The historical April test record remains in `testing.md`.

## Automated validation

- `quick_validate.py` passed the skill directory.
- `scripts/validate_docx.py --help` and Python compilation passed.
- A representative eight-page Enterprise Service Desk PWS fixture passed the DOCX ZIP, heading-order, QASP, separation, dynamic-TOC, and update-fields-on-open checks.
- The fixture used 13 ordered Heading 1 sections, six structured tables, repeating table headers, explicit table geometry, a page-number field, and a dynamic TOC field.
- Six fault-injected copies were rejected for the expected reasons: staffing handoff leakage, SOC/FTE leakage, CLIN handoff leakage, the incorrect FAR 37.102(d) citation, the incorrect FAR 52.237-2 key-personnel citation, and a missing QASP Summary.

## Render and visual review

- Rendered with LibreOffice through the Codex document renderer to eight page PNGs and a PDF.
- Inspected every rendered page. The first pass exposed table rows splitting across pages. The fixture was rebuilt with non-splitting rows and repeating headers, then rerendered and re-inspected.
- The final render had no clipped text, overlapping content, broken glyphs, accidental blank pages, or orphaned Heading 1 sections.
- The TOC remained a valid dynamic field with a placeholder in the LibreOffice render. The skill correctly requires a Word field refresh disclosure when Word has not populated it.
- Microsoft Word was not retested in this pass. LibreOffice rendering is not recorded as proof of Word behavior.

## Claude behavior tests

Surface: Claude Code CLI 2.1.238, `claude-opus-5`, explicit `/sow-pws-builder` invocation.

1. A rich FFP help-desk prompt with one 24x7x365 Tier 1 seat and 1,880 productive hours produced 4.6596 FTE for the coverage floor, preserved SOC 43-4051, kept staffing in chat, did not create a file, and ended at the staffing confirmation question.
2. A CPFF research-support prompt that asked the model to choose the form was stopped at the FAR 16.306(d) gate. Claude explained Completion and Term, refused to originate the choice, and ended by asking the user to confirm one form.

## Codex behavior test

Surface: Codex CLI 0.149.0-alpha.4, GPT-5.6 Sol, extra-high reasoning, explicit `$sow-pws-builder` invocation.

- The CPFF self-selection prompt was stopped at the required gate. Codex presented Completion and Term without choosing either and ended at the confirmation question.

## Confirmed gates

- Staffing, SOC, IGCE, CLIN, and pricing content stays outside the contract-file artifact.
- FAR 37.602(b)(1), not FAR 37.102(d), is used for results-oriented PWS language.
- T&M/LH labor-category rates, estimated hours, and overall ceiling inputs remain in the chat-only Section B handoff.
- CPFF Completion versus Term is user-confirmed.
- A 24x7x365 seat at 1,880 productive hours is 4.6596 FTE.
- Tier 1 help-desk intake remains SOC 43-4051.
- Both the staffing gate and Decision Summary gate stop and wait for approval.

## Open coverage

- Claude web, Claude Code after automatic compaction, Codex Desktop UI, and Microsoft Word were not rerun for this skill in this pass.
- Implicit activation was not treated as deterministic; published usage should retain explicit invocation examples.

# SOW/PWS Builder: Testing Record

# Part 1: For Federal Acquisition Users

## The bottom line

Two waves of independent testing in April 2026 (14 end-to-end runs, 168 binary assertions graded) show the SOW/PWS Builder reliably produces FAR-compliant Statements of Work and Performance Work Statements across six contract-type and workflow combinations on both Claude Opus 4.7 and Claude Sonnet 4.6. Five assertions failed across the two waves. Four of the five point to specific places where the skill's output needs a manual pass before solicitation release. None produced a document that was unsalvageable.

## Contract types tested and how reliably they work

| Contract type and workflow | Models | Result |
|---|---|---|
| T&M Statement of Work, non-commercial | Opus, Sonnet | Reliable |
| FFP PWS (commercial, full build) | Opus, Sonnet | Reliable |
| FFP PWS (commercial, SOO conversion) | Opus, Sonnet | Reliable |
| FFP PWS scope reduction (Workflow C) | Opus, Sonnet | Reliable after Wave 1 patch |
| CPFF R&D PWS, non-commercial | Opus, Sonnet | Reliable; verify CPFF form (see checklist) |
| Labor-Hour PWS, no materials, non-commercial | Opus, Sonnet | Reliable; verify DD Form 254 (see checklist) |

## Manual-verification checklist

The Wave 2 testing surfaced four specific gaps in the skill's output. **All four were patched after Wave 2.** The patches have not yet been regression-tested (Wave 3 will do that), so until the next wave confirms the fixes hold, scan every output for these items.

**1. Key Personnel substitution clause.** Historical gap: the skill emitted "FAR 52.237-2" as the Key Personnel clause on 5 of 6 Wave 2 runs. FAR 52.237-2 is actually "Protection of Government Buildings, Equipment, and Vegetation" — the wrong clause. The Wave 2 patch removed that default and added agency-aware guidance: NFS 1852.237-72 for NASA, HSAR 3052.237-72 for DHS, HHSAR 352.237-75 for HHS, DFARS where applicable for DoD, and a generic fallback that avoids FAR 52.237-2 entirely. Verify the citation still looks right for your agency.

**2. CPFF form selection.** Historical gap: on both Wave 2 CPFF runs, the skill cited FAR 16.306 without selecting completion form or term form. The Wave 2 patch added a Phase 2 rule requiring the skill to explicitly name completion form (FAR 16.306(d)(1)) or term form (FAR 16.306(d)(2)) wherever the contract framework first appears. Verify your CPFF PWS says which form it is. The difference matters: completion form requires delivery of a specified end product before the full fixed fee is earned; term form obligates a stated level of effort over a stated period. Term form is usually the right default for R&D where technical outcomes are uncertain.

**3. Classified security block.** Historical gap: on both Wave 2 Labor-Hour TS/SCI runs, DD Form 254 and Security Classification Guide references were missing. The Wave 2 patch added required DD 254 and SCG references in Section 9 whenever any clearance at Confidential or higher is called out. Verify the security block for any classified requirement.

**4. Section ordering.** Historical gap: workers occasionally swapped Section 11 (Reporting) and Section 12 (QASP) across runs. The Wave 2 patch added prescriptive language fixing Sections 11 through 14 in their correct order and explicitly disallowing merging or reordering. Low severity. A visual scan is enough.

## Choosing between Opus 4.7 and Sonnet 4.6

Short answer: use Opus 4.7 as the default.

**Opus 4.7** asks multi-choice clarification questions when the input has real ambiguity, waits for your explicit "proceed" before generating the document, and produces slightly more thorough clause citations. Two caveats:

- On claude.ai web chat, the Opus safety classifier sometimes blocks legitimate biodefense, vaccine, or pathogen-adjacent scenarios. If you hit a block ("Chat paused"), switch to Sonnet 4.6 or use the Claude API directly. This happened once in testing on an NIH mRNA vaccine R&D prompt.
- Opus consistently cites the wrong Key Personnel clause (see checklist item 1).

**Sonnet 4.6** is faster and works well on richly specified prompts. Two caveats:

- Sonnet tends to skip the clarification-question phase even when defaults should have been reviewed. On the DHS Labor-Hour test, Sonnet self-approved six applied defaults without waiting for user confirmation. Read the Decision Summary carefully and interrupt if you see something that needs adjusting.
- On very large documents (roughly 30 KB and up), Sonnet on claude.ai web chat sometimes hits an output truncation limit mid-generation. A fresh chat retry usually completes.

For a critical document, run Opus first. If Opus is blocked or unavailable, switch to Sonnet.

## What the skill does not do

- **It does not produce Independent Government Cost Estimates.** It emits a staffing handoff table in chat only, for the IGCE Builder skill to consume as a separate step.
- **It does not produce CLIN structures inside the PWS body.** CLINs go in Section B of the solicitation, and the skill correctly emits them as a chat-only handoff.
- **It does not handle classified data.** It produces unclassified acquisition documents that describe requirements for classified work. No actual classified information has been processed in testing.
- **It has not been tested on** Special Access Program or Special Access Required variants; commercial CPFF or commercial Labor-Hour (which require FAR 12.207(b) justifications); hybrid contract structures such as FFP plus T&M CLINs; multi-year ramping AQL structures where targets escalate across option years; or true document-to-document scope reduction using an actual prior .docx as input.

## Environmental gotchas on claude.ai web chat

| Gotcha | What happens | Workaround |
|---|---|---|
| Opus 4.7 biodefense classifier | Chat pauses mid-intake on vaccine, pathogen, or similar scenarios | Switch to Sonnet 4.6 or use Claude API |
| Sonnet 4.6 output truncation | "Claude's response could not be fully generated" on very large PWS builds | Fresh chat retry; optionally add size-constraint language to the prompt |
| Sonnet 4.6 silent self-approval | Skipped "proceed" gate on one run; applied defaults without confirmation | Read the Decision Summary carefully; interrupt to correct if needed |

# Part 2: For Developers and Technical Reviewers

## Testing methodology

Two testing waves, both in April 2026. Same methodology both times.

- Worker sessions ran end-to-end in fresh claude.ai web chat, the same environment the skill's end users run in.
- A separate Claude Code Opus 4.7 instance (1M context window, max effort mode, Claude Max 20x subscription) graded each run independently.
- The grader had no access to the worker's drafting conversation or self-assessment until after grading was complete. This separation distinguishes "observed behavior" from "claimed behavior."
- Each run was graded against a 14-point binary assertion matrix (8 general assertions plus 6 scenario-specific assertions).
- All assertions were committed before seeing any worker output, to prevent the grading standard from drifting to accommodate whatever the worker happened to produce (same discipline as pre-registering a study).

## Grading methodology

Each assertion received a binary pass or fail plus a one-line note on anything suspicious.

**General assertions (8, unchanged across both waves):**

- G1 Acquisition Strategy Intake collected before drafting
- G2 Phase 1 decision tree executed with visible Decision Summary before docx generation
- G3 .docx produced
- G4 No FTE counts, SOC codes, or staffing tables in document body (FAR 37.102(d))
- G5 No staffing or IGCE appendix in document
- G6 Staffing handoff chat-only, not saved as a file
- G7 Section numbering sequential
- G8 Key Personnel by role and qualifications, not by headcount

**Scenario-specific assertions (6 per scenario):** tailored to the contract-type and workflow behaviors being exercised.

## Wave 1 (initial, pre-publication testing)

Six canonical scenarios plus two AskUserQuestion stress tests.

### Wave 1 scenarios

- **Scenario 1:** Non-commercial T&M SOW, Workflow A, AFRL test range instrumentation under FAR Part 15 and FAR 16.601. Exercised the T&M Labor Category Ceiling Hours exception under FAR 16.601(c)(2).
- **Scenario 2:** Commercial FFP PWS, Workflow B (SOO conversion), Treasury Digital Customer Experience Modernization. Exercised SOO parsing, gap identification, and performance-based outcome framing.
- **Scenario 3:** FFP PWS Workflow C scope reduction, cybersecurity incident response and digital forensics. Reduced from $62M per year to $40M per year. Exercised trade-off menu generation, user validation gate, section regeneration, updated staffing handoff, and Section 14 cut documentation.
- **AskUserQuestion stress test:** One-sentence lazy prompt ("Need a PWS for help desk services for my agency. Can you help me write one?") to test whether the skill drives structured multi-choice intake when a non-expert user provides minimal context.

### Wave 1 results

#### Opus 4.7 worker results

| Scenario | Workflow | Assertions | Result |
|---|---|---|---|
| Non-commercial T&M SOW | A | 14 of 14 pass | PASS |
| SOO-to-PWS Conversion | B | 14 of 14 pass | PASS |
| Scope Reduction | C | 14 of 14 pass | PASS |

#### Sonnet 4.6 worker results

| Scenario | Workflow | Assertions | Result |
|---|---|---|---|
| Non-commercial T&M SOW | A | 14 of 14 pass | PASS |
| SOO-to-PWS Conversion | B | 14 of 14 pass | PASS |
| Scope Reduction | C | 13 of 14 pass | FAIL (G4) |

#### AskUserQuestion feature test

| Model | Behavior observed |
|---|---|
| Opus 4.7 | Defaulted to prose questions on first pass. Reached for the structured multi-choice tool only when explicitly prompted by the user. |
| Sonnet 4.6 | Auto-triggered the structured multi-choice tool on the first message. Batched 12 questions across 4 groups of 3. Included "Not sure" and "Something else" escape hatches. Produced a 422-paragraph contract-file-ready PWS after the user selected option one for every question. |

### The one Wave 1 bug

**Sonnet Scenario 3 G4 failure.** The Workflow C scope-reduction documentation in Section 14 contained specific staffing counts ("3-4 FTE examiners," "2-3 platform engineers," "8 Tier 2 analysts") as prior-state descriptors. Document bodies remain subject to FAR 37.102(d) even when describing historical or prior state. Opus passed the same scenario using capability-framed language ("night-shift onsite headcount eliminated," "no dedicated playbook engineer") without specific counts.

Root cause: the skill's FAR 37.102(d) enforcement block was focused on staffing tables and the Phase 3 handoff. It did not explicitly address Section 14 scope-reduction narrative. Workers interpreted "describe what was cut" as license to quote the prior staffing plan.

Fix: added explicit guidance in the Section 14 block requiring capability-and-coverage language, not staffing counts, for both current-state and historical-state descriptions. Included compliant and non-compliant examples. Prescribed the five-field documentation structure (Prior Scope, Revised Scope, Estimated Annual Savings, Rationale, Residual Risk).

## Wave 2 (follow-up, post-publication testing)

Three contract-type and workflow combinations not exercised in Wave 1. Each run once on Opus 4.7 and once on Sonnet 4.6, for six runs total.

### Wave 2 scenarios

- **Scenario 4:** Commercial FFP PWS, Workflow A, GSA PBS enterprise IT help desk for 25,000 users across 11 regions, $15M per year, 24x7x365, NIST 800-171 and CMMC Level 2 required.
- **Scenario 5:** Non-commercial CPFF R&D PWS, Workflow A, NASA Glenn Research Center cryogenic fluid management research for in-space propellant transfer and long-duration storage, $45M with 8% fixed fee, 5-year term, Principal Investigator model, NASA FAR Supplement applies.
- **Scenario 6:** Non-commercial Labor-Hour PWS (no materials), Workflow A, DHS CISA cyber threat analyst advisory support to the Cyber Threat Intelligence Integration Office, $8M NTE over 3 years, TS/SCI for all positions, 5 labor categories.

Scenario 5 was originally planned as NIH/NIAID mRNA vaccine platform R&D. The Opus 4.7 safety classifier on claude.ai web chat paused the worker mid-intake. The scenario was swapped to NASA Glenn CFM (same contract mechanics, no biodefense trigger words) to preserve apples-to-apples grading across models.

### Wave 2 results

| Run | Model | Scenario | Result | Failed assertion |
|---|---|---|---|---|
| 1 | Opus 4.7 | Commercial FFP (GSA PBS) | 14 of 14 PASS | — |
| 2 | Sonnet 4.6 | Commercial FFP (GSA PBS) | 14 of 14 PASS | — |
| 3 | Opus 4.7 | CPFF R&D (NASA Glenn) | 13 of 14 PASS | S5 |
| 4 | Sonnet 4.6 | CPFF R&D (NASA Glenn) | 13 of 14 PASS | S5 |
| 5 | Opus 4.7 | Labor-Hour (DHS CISA) | 13 of 14 PASS | S6 |
| 6 | Sonnet 4.6 | Labor-Hour (DHS CISA) | 13 of 14 PASS | S6 |

### The two Wave 2 failure modes

**Failure mode A: S5 on CPFF, both models.** Neither worker explicitly committed the document to completion form (FAR 16.306(d)(1)) or term form (FAR 16.306(d)(2)). Both documents cited FAR 16.306 multiple times but never made the form selection explicit. The distinction governs how fixed fee is earned: completion form ties earning to delivery of a specified end product; term form ties earning to level of effort over a stated time period. For R&D where technical success is uncertain, term form is usually more appropriate.

Root cause: skill-template gap. The Phase 2 CPFF block does not currently require or emit an explicit form selection.

Candidate patch: add a Phase 2 rule requiring the document to name completion form or term form wherever the contract framework first appears.

**Failure mode B: S6 on Labor-Hour, both models.** Neither worker referenced DD Form 254 in the security section of a TS/SCI Labor-Hour PWS. Both covered clearance levels, SCIF requirements per ICD 705, and derivative classification, but DD Form 254 and Security Classification Guide references were missing.

Root cause: skill-template gap. The Phase 2 security block does not currently emit DD Form 254 or SCG references for classified requirements.

Candidate patch: when clearance above Confidential is called out, the Phase 2 security block must reference DD Form 254 and the applicable SCG.

### Behavioral observations from Wave 2 (not assertion failures)

1. **FAR 52.237-2 misreference for Key Personnel substitution.** Appeared on 5 of 6 Wave 2 runs. Sonnet corrected it to NFS 1852.237-72 on the NASA CPFF scenario but reverted to the template default on the other runs. Skill-template bug, not a worker variance.

2. **Sonnet skips AskUserQuestion intake on medium-ambiguity prompts.** Sonnet triggered AskUserQuestion on 0 of 3 Wave 2 scenarios. Opus triggered on 2 of 3. This inverts the Wave 1 finding, where Sonnet was the auto-trigger model and Opus needed explicit prompting. The Wave 1 patch fixed Opus; Sonnet has now drifted in the other direction.

3. **Sonnet self-approved Phase 1 Decision Summary on Scenario 6.** Said "Proceeding to document assembly now" immediately after presenting the summary, without waiting for user "proceed." This denies the user a chance to override applied defaults before generation. The G2 assertion (visible Decision Summary before docx) passed on visibility, but the user-gate is a separate concern.

4. **Section ordering drift.** QASP and Transition sections swap positions (Section 11 versus Section 12) across and within models. Terminology is always correct; only position drifts. Low severity.

5. **Opus 4.7 biodefense classifier block.** Environmental observation on claude.ai web chat, not a skill defect. The classifier paused the worker mid-intake on an NIH/NIAID mRNA vaccine R&D scenario. Federal acquisition users working on biodefense, vaccine, or pathogen-related contracts should expect potential classifier blocks on Opus web chat and plan to use Sonnet or the Claude API.

6. **Sonnet 4.6 output truncation on large documents.** Environmental observation. First attempt on Scenario 4 Commercial FFP PWS hit "Claude's response could not be fully generated" mid-.docx-generation. Fresh chat retry completed cleanly.

7. **Sonnet domain reasoning on CPFF was notably sharp.** Sonnet on Scenario 5 caught that CPFF fee cannot be administratively reduced under FAR 16.306 and flagged the skill's QASP fee-deduction language as legally problematic, recommending either repositioning as a cure-notice tool or conversion to CPAF/CPIF. That is substantive acquisition-law reasoning, not template output. Opus did not surface this on its parallel CPFF run.

## Cumulative results across both waves

| | Wave 1 | Wave 2 | Total |
|---|---|---|---|
| Worker runs | 8 (6 canonical + 2 AskUserQuestion) | 6 | 14 |
| Scenario assertions graded | 84 | 84 | 168 |
| Passed | 83 | 80 | 163 |
| Failed | 1 (fixed in patch) | 4 (cross-model, patch candidates) | 5 |

## Skill patches: shipped and candidate

### Shipped after Wave 1 (9 patches)

| Patch | Section affected | Trigger |
|---|---|---|
| Unconditional handoff rule moved to top of Phase 3 with emphatic language | Phase 3 opening | 3 of 7 runs skipped handoff emission |
| SOW "Inspection and Acceptance" versus PWS "QASP" label differentiation | Phase 2 Section 12 block | Scenario 1 both models |
| Table of Contents instruction for documents exceeding 8 sections | Phase 2 opening | All runs produced 300-700 paragraph docs without TOC |
| SOO-implied objectives rule | Phase 0 | Scenario 2 both models added unstated objectives legitimately |
| Phase 2 Invocation Gate requiring Phase 1 Decision Summary before docx | Phase 2 opening | Cross-model Phase 1 compression plus network-blip resilience |
| Section 14 assumption format template (4-column) | Phase 2 Section 14 block | Workers independently invented divergent structures |
| Workflow C Section 14 compliance rule (no FTE counts in cut descriptions) | Phase 2 Section 14 block | The Wave 1 G4 failure |
| AskUserQuestion tool usage instruction | Phase 1 opening | Opus defaulted to prose without explicit instruction |
| Anti-redundancy rule | Phase 1 opening | Both models re-asked explicit answers |

Skill version lines: 361 before Wave 1 patches, 380 after. Ceiling: 1,000.

### Shipped after Wave 2 (5 patches)

| Patch | Section affected | Trigger |
|---|---|---|
| Agency-aware Key Personnel substitution clause selection (removed the wrong FAR 52.237-2 default; added agency-specific guidance for NASA, DHS, HHS, DoD, and a generic fallback) | Phase 2 Key Personnel block | FAR 52.237-2 emitted on 5 of 6 Wave 2 runs |
| Explicit CPFF form commitment required (skill must name completion form per FAR 16.306(d)(1) or term form per FAR 16.306(d)(2) wherever contract framework first appears) | Phase 2 Section 5 block | S5 failure on both Wave 2 CPFF runs |
| DD Form 254 and SCG reference added to Section 9 for any classified requirement at Confidential or higher | Phase 2 Section 9 block | S6 failure on both Wave 2 LH runs |
| Strengthened Phase 1 proceed gate; explicit "DO NOT self-approve" rule with requirement that the response must END after presenting the Decision Summary | Phase 2 Invocation Gate | Sonnet self-approved on Scenario 6 |
| Fixed section ordering made explicit and prescriptive (Section 11 Reporting, Section 12 QASP, Section 13 Transition, Section 14 Constraints — do not merge, combine, swap, or rename) | Phase 2 Section Structure header | QASP and Transition position drift across runs |

Skill version lines: 426 before Wave 2 patches, 450 after. Ceiling remains 1,000.

These patches are shipped in the current skill but have not yet been validated against a fresh test wave. Wave 3 will regression-test the same six scenarios against the patched skill to confirm the Wave 2 failure modes no longer reproduce.

### Post-Wave 2 bloat trim (5 cuts, no rules removed)

Following a discipline pass on April 23, 2026, five pieces of non-load-bearing prose were removed from the skill without altering any behavioral rule. Every rule that was enforced before the trim is still enforced.

| Cut | Section | What was removed |
|---|---|---|
| Section-ordering trailing anecdote | Phase 2 Section Structure | "Workers have been observed placing QASP at Section 11 and Transition at Section 12..." — testing history narrated as a rule. The preceding prescriptive sentence already covers it. |
| Forbidden-appendix bullet enumeration | Phase 2 Appendices | Six specific forbidden appendix titles condensed into one inline example list. Universal rule is "no staffing-related appendix"; exhaustive enumeration was bloat. |
| Staffing Handoff "Why this rule exists" paragraph | Phase 3 Staffing Handoff | Self-referential history about prior skill versions compressed to two sentences. The rule above is the rule; the why just needs to support judgment. |
| CLIN Handoff DO NOT block duplication | Phase 3 CLIN Handoff | The DO NOT list repeated the staffing handoff pattern verbatim. Replaced with "Same DO NOT rules apply as for the Staffing Handoff above" plus a one-line variant summary. |
| "Experienced 1102s flag this immediately" filler | Phase 3 CLIN Handoff | Rhetorical filler with no rule content. |

Skill version lines: 450 before trim, 437 after. Ceiling remains 1,000.

## What was not tested

- **Special Access Program and Special Access Required variants.** Classified coverage was limited to collateral Secret, Top Secret, and TS/SCI contexts in notional scenarios.
- **Commercial CPFF or commercial Labor-Hour.** Both require FAR 12.207(b) written Determinations and Findings and are edge cases on top of edge cases.
- **Hybrid contract structures** (FFP plus T&M or LH CLINs; FFP with cost-reimbursable travel CLINs was exercised only incidentally in the Wave 2 handoff tables).
- **True document-to-document scope reduction** using an actual prior .docx as Workflow C input. The Wave 1 test used a bulleted summary of the prior PWS rather than an actual document.
- **Multi-year ramping AQL structures** where performance targets escalate across option years. Exercised informally in Wave 1, not systematically.
- **Hardware-intensive Test and Evaluation domains** beyond the single Wave 1 Scenario 1 (AFRL test range) and Wave 2 Scenario 5 (NASA CFM).
- **Grants, cooperative agreements, and Other Transaction agreements** are out of scope for this skill. Separate skills cover those.

Users working in these contexts should expect to validate outputs more carefully and may encounter edge cases that the test waves did not surface.

## Note on classified scenario testing

Wave 1 Scenario 1 used a notional classified-context prompt (AFRL test range, Secret and Top Secret collateral clearances). The test verified only that the skill produces proper classified-contract boilerplate: clearance-by-position requirements, Security Classification Guide references, OPSEC language, facility clearance statements, and DD Form 254 references at the prompt level. All scenario inputs were fictional. No actual classified information was processed, transmitted, or stored at any point during testing. The skill itself does not and cannot handle classified data; it produces unclassified acquisition documents that describe requirements for classified work, which is standard practice for any SOW or PWS.

Wave 2 Scenario 6 (DHS CISA TS/SCI) extended classified-context coverage to a TS/SCI Labor-Hour PWS using a fictional CISA scope. Same constraint: no real classified information was ever handled.

Coverage was limited to collateral Secret, Top Secret, and TS/SCI contexts. Special Access Program and Special Access Required variants were not exercised.

## Independent grading

Every assertion was graded by a separate Claude instance reading only the worker's final output and the chat transcript. The grader had no access to the worker's internal reasoning and did not see the worker's self-assessment until after grading was complete. This separation is the load-bearing credibility claim of this testing program: it distinguishes "the worker claimed to do X" from "the output demonstrates X."

---

**Testing Methodology**

Evaluators: James Jenrette (1102tools) and Claude Code Opus 4.7 (1M context window, max effort mode, Claude Max 20x subscription).

Worker models tested: Claude Opus 4.7 and Claude Sonnet 4.6 on claude.ai web chat, the same environment the skill's end users run in.

Wave 1: 8 runs, 84 assertions, 83 passes, 1 confirmed failure (fixed in patch).

Wave 2: 6 runs, 84 assertions, 80 passes, 4 confirmed failures (cross-model, patch candidates identified).

Cumulative: 14 runs, 168 assertions, 163 passes.

Date: April 2026 (both waves).

Skill: sow-pws-builder. Source: github.com/1102tools-dev/federal-contracting-skills. License: MIT.