# Sow Pws Builder > > - **Type:** Skill - **Install:** `agentstack add skill-1102tools-federal-contracting-skills-sow-pws-builder` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [1102tools](https://agentstack.voostack.com/s/1102tools) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [1102tools](https://github.com/1102tools) - **Source:** https://github.com/1102tools/federal-contracting-skills/tree/main/skills/sow-pws-builder - **Website:** https://1102tools.com ## Install ```sh agentstack add skill-1102tools-federal-contracting-skills-sow-pws-builder ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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? | | SOW | PWS | |---|---|---| | Prescribes | Tasks and methods (how) | Outcomes and standards (what) | | Contractor flexibility | Low — government directs approach | High — contractor proposes approach | | Best for | Well-understood, repeatable work | Complex or innovative requirements | | QASP focus | Task completion | Performance metrics | | FAR preference | — | FAR 37.602 prefers PBA/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 choices, not open-ended questions. Collect in a single pass where possible. **Phase 1 execution:** On platforms that expose a structured multi-choice prompt tool (claude.ai web chat provides AskUserQuestion), use it for Acquisition Strategy Intake and Blocks 1-6. Batch 3-4 related questions per prompt block. Reserve prose for genuinely open-ended answers (ticket volume, system names, incumbent details). Every multi-choice question must include an "Other" / "Something else" free-text escape. **Anti-redundancy:** Before asking any framing or scope question, check whether the user's initial prompt already answers it. Do not re-ask explicit answers; confirm silently and proceed. ### Block 1: Mission and Service Model 1. **What is the core service?** (Provide options based on context, or ask open-ended if starting from scratch) 2. **Service delivery model:** Government FTEs with contractor augmentation | Fully contracted service | Hybrid (specify which functions are FTE vs. contractor) 3. **Coverage model:** Business hours (M-F 8-5) | Extended hours (specify) | 24/7/365 | Seasonal/surge 4. **Geographic scope:** Single site | Multi-site (how many?) | Virtual/remote | Hybrid ### Block 2: Technical Scope 5. **Build vs. Buy:** Custom development | COTS/SaaS configuration | Hybrid (custom integrations on COTS platform) 6. **Systems in scope:** List all systems the contractor will build, configure, integrate with, or maintain. For each: new build vs. existing system. 7. **Integration complexity:** Standalone | Integrates with 1-3 systems | Integrates with 4+ systems | Enterprise-wide integration 8. **Data migration:** No legacy data | Migrate from 1-2 sources | Migrate from 3+ sources | Complex multi-system consolidation 9. **AI/automation:** None | Basic automation (IVR, rules-based routing) | AI-assisted (NLP, ML classification) | Advanced AI (chatbots, predictive analytics) ### Block 3: Scale and Volume 10. **Transaction/contact volume:** Provide numbers if known, or characterize as low/medium/high 11. **User population:** Internal users (how many?) | External/public-facing | Both 12. **Concurrent user requirements:** If applicable 13. **Growth expectations:** Stable | Moderate growth (10-25%/yr) | High growth (>25%/yr) | Unknown ### Block 4: Organizational Scope 14. **How many organizational units?** (offices, centers, divisions served) 15. **Phasing:** All at once | Phased rollout (how many phases?) | Pilot then expand 16. **Stakeholder complexity:** Single program office | Multiple offices, single agency | Cross-agency ### Block 5: Contract Structure Contract type is already captured in the Acquisition Strategy Intake above; do not re-ask it here. 17. **Period of performance:** Base year + option years (how many?) 18. **Base year scope:** Full performance from day 1 | Ramp-up/transition-in period (how long?) | Design/development only, production in options 19. **CLIN structure preference (for Section B handoff, NOT the PWS body):** By period (CLINs = base year, OY1, OY2...) | By function (CLINs = development, operations, maintenance, training) | By deliverable | Unsure (skill will recommend). This preference is emitted as a chat-only CLIN Handoff Table in Phase 3 for the CO to paste into Section B of the solicitation. It does NOT go into the SOW/PWS document body. 20. **Transition requirements:** Transition-in from incumbent? | Transition-out plan required? | Both ### Block 6: Quality and Oversight 21. **Acceptable quality level (AQL):** For key performance metrics — e.g., 95% first-call resolution, 99.95% uptime, 50 FTEs, >$75M, or span >3 distinct technical domains, flag that this may need to be broken into multiple contracts. Suggest logical break points (e.g., development vs. operations, platform vs. contact center staffing). **User wants to skip Phase 1:** Don't let them. The decision tree is the value. If they say "just write the SOW from this SOO," explain: "The SOO describes objectives, but a SOW requires decisions the SOO intentionally leaves open — like staffing model, build vs. buy, phasing, and CLIN structure. These take about 10 minutes to walk through, and they're what make the SOW defensible." **Budget-constrained scope reduction (Workflow C):** When reducing scope to fit budget, work backwards: identify the highest-cost labor categories from the IGCE, map them to tasks/objectives, and present trade-offs: "Removing 24/7 coverage saves ~$X by eliminating night-shift agents, but means no live response outside business hours. Replacing custom AI with COTS chatbot saves ~$Y in developer FTEs but limits NLP accuracy." Let the user choose which scope reductions are acceptable, then regenerate affected SOW/PWS sections. ## What This Skill Does NOT Cover - **Pricing or cost estimates** — use IGCE Builder skills (FFP, LH/T&M, CR) - **Source selection criteria** — separate document, though CLIN structure informs it - **J&A or sole source justification** — separate document - **Full QASP** — this skill includes a QASP summary table; a detailed QASP with surveillance schedules is a separate deliverable - **Clause selection (Section I/L)** — requires contracting officer determination per FAR Parts 12, 15, 16, 52 - **Contract type determination** — this skill accepts the user's contract type decision; it does not advise on which type to select (that's a FAR 16 analysis) --- *MIT © James Jenrette / 1102tools. Source: github.com/1102tools/federal-contracting-skills* ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [1102tools](https://github.com/1102tools) - **Source:** [1102tools/federal-contracting-skills](https://github.com/1102tools/federal-contracting-skills) - **License:** MIT - **Homepage:** https://1102tools.com Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-1102tools-federal-contracting-skills-sow-pws-builder - Seller: https://agentstack.voostack.com/s/1102tools - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.