SOW/PWS Builder

Overview

This skill walks a program office (or analyst acting on their behalf) through structured scope decisions and assembles the answers into a properly formatted SOW or PWS. The core insight: the program office doesn't need to know FTE counts or cost estimates up front — they need to make scope decisions, and staffing falls out as a derived output.

Outputs (TWO SEPARATE ARTIFACTS — never combined):

1. A .docx SOW or PWS with standard federal sections — the contract file deliverable. This document contains NO staffing table, NO FTE counts, NO labor category counts, NO SOC codes, NO hours-per-year estimates, and NO IGCE-related content. FAR 37.102(d) requires the requirement to be described in terms of results, not hours or number of people performing the work. The one narrow exception is T&M/LH contracts, which get a Labor Category Ceiling Hours table in Section 5 per FAR 16.601(c)(2) — see Phase 2 Section 5 for details.

2. A staffing handoff table — an internal government workpaper presented in chat output only at the end of the skill run. This is the data handoff to the IGCE Builder skills (FFP, LH/T&M, CR). It is NEVER embedded in the SOW/PWS document. It is NEVER saved as a companion .docx or any other file. It exists solely as a markdown/code-block table in the conversation so the user can review it and the downstream IGCE Builder can consume it.

No external APIs required. This is a decision tree + document generation skill.

Regulatory basis: FAR 37.102(d) (describe work in terms of results, not hours or number of people), FAR 37.602 (performance-based acquisition), FAR 46.401 (quality assurance), FAR 7.105 (written acquisition plans — requirement description), FAR 16.601(c)(2) (T&M/LH ceiling price mechanism).

Workflow Selection

Workflow A: Full Build (Default)

User needs a SOW/PWS from scratch or from a rough concept. Execute all three phases. Triggers: "write a SOW," "build a PWS," "I need a work statement for..."

Workflow B: SOO Conversion

User has an existing SOO and needs it developed into a SOW/PWS. Start with Phase 0 (SOO intake), then Phases 1–3. Triggers: "convert this SOO to a SOW," "develop this SOO into a PWS," "we have a SOO and need a work statement."

Workflow C: Scope Reduction

User has an existing SOW/PWS or IGCE output that exceeds budget. Walk through scope decision tree to identify what to cut, then produce a revised document. Triggers: "this is too expensive, what can we cut," "reduce scope to fit budget," "need to descope."

Acquisition Strategy Intake

Before diving into the scope decision tree, collect three framing decisions that shape everything that follows. Ask these up front, in a single pass, before Block 1. These are the acquisition strategy context — they determine document type, pricing structure, and FAR Part applicability.

Intake Question 1: SOW or PWS?

If the user is unsure, default to PWS — it's the FAR-preferred approach for services and gives the contractor room to propose efficient solutions. The decision tree is identical either way; only the output language changes.

Intake Question 2: Contract Type?

FFP | T&M | LH | CR | Hybrid (specify)

This is asked up front (not in Block 5) because contract type frames the rest of the scope decisions:

• FFP pairs naturally with PWS (outcomes + performance standards). Contractor owns labor mix risk. No labor info in the document body.
• T&M and LH require Labor Category Ceiling Hours in Section 5 per FAR 16.601(c)(2). The SOW/PWS must tell offerors what LCATs to propose rates against and the ceiling hours per period.
• CR (cost-reimbursement) pairs with either SOW or PWS. No labor info in the document body. Requires approved accounting system findings before award per FAR 16.301-3.
• Hybrid — identify which CLINs are which type; apply the rules per CLIN.

If the user says "unsure," recommend FFP for well-defined services, T&M for requirements where level of effort is unknown, and CR for R&D or high-uncertainty work. FAR Part 16 analysis is the contracting officer's call — this skill accepts the user's decision; it does not advise on contract type selection.

Intake Question 3: Commercial or Non-Commercial?

Commercial service (FAR Part 12) | Non-commercial (FAR Part 15) | Unsure — flag for Contracting Officer

• Commercial service = routinely sold to the general public in the course of normal business operations, per FAR 2.101 commercial product/service definition. Help desk services, facility maintenance, COTS software support, training, staff augmentation for standard skills are typically commercial.
• Non-commercial = government-unique work such as classified, research, weapon systems development, or work performed using specialized government processes not available in the commercial marketplace.
• When commercial, FAR Part 12 governs. FAR 52.212-4 terms apply in Section I of the solicitation; full Section I/L buildout is not required. Contract type is typically FFP per FAR 12.207. Performance-based description is preferred per FAR 12.102(g). CLIN structure (emitted in the Phase 3 chat-only handoff, not the PWS body) should accommodate commercial item pricing.
• When non-commercial, FAR Part 15 governs. Full Section I/L clause buildout applies. All contract types available.
• If the user is unsure, note "Commercial item determination pending — flag for Contracting Officer" in Section 14 Constraints and Assumptions and proceed with Phase 1.

Why these three questions come first

The issue a requirement writer faces: the same scope decisions produce different document language, different clause references, and different FAR Part applicability depending on these three framing choices. Collecting them up front means Phase 1 can frame its questions accordingly (e.g., for a commercial FFP PWS, skip Phase 1 questions about Government-unique processes; for a T&M SOW, ask more detail about labor categories and ceilings). It also means the generated document in Phase 2 can reference the correct FAR sections and clauses without a retrofit.

Phase 0: SOO Intake (Workflow B Only)

When the user provides an existing SOO:

1. Read and extract. Parse the SOO for: background, objectives, constraints, performance location, period of performance, known systems, volume data, key personnel, security requirements, and any appendix data.

2. Gap identification. Flag what the SOO provides vs. what a SOW/PWS needs:

   • ✅ Typically present in SOO: background, high-level objectives, constraints, PoP, location
   • ❌ Typically missing from SOO: task decomposition, staffing, deliverables with acceptance criteria, CLIN structure, QASP metrics, reporting cadence, transition details
   • ⚠️ If the SOO's scope implies a standard it doesn't explicitly state (availability for high-volume systems, security for PII/FISMA systems, continuity for mission-critical systems), add the implied objective and flag it in Section 14 as a derived objective.

3. Decision bridge. Present the gaps as the questions Phase 1 will answer. Frame it as: "The SOO tells us what the agency wants to achieve. Phase 1 asks the questions that turn objectives into executable requirements."

4. Carry forward. Pre-populate Phase 1 answers with anything the SOO already decided (location, PoP, known constraints). Don't re-ask settled questions.

Phase 1: Scope Decision Tree

Ask questions in this sequence. Each decision narrows scope and implies staffing. Present as structured ch