# Ot Project Description Builder

> >

- **Type:** Skill
- **Install:** `agentstack add skill-1102tools-federal-contracting-skills-ot-project-description-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/ot-project-description-builder
- **Website:** https://1102tools.com

## Install

```sh
agentstack add skill-1102tools-federal-contracting-skills-ot-project-description-builder
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# OT Project Description Builder

## Overview

This skill walks an agreements officer (AO) or program office through structured prototype scope decisions and assembles the answers into a milestone-based project description for an Other Transaction agreement. The core insight: OTs structure work around technology maturation phases and technical milestones, not task/subtask CLINs or performance objectives. The program office defines what must be demonstrated at each gate, and the performer proposes how to get there.

**Outputs (TWO SEPARATE ARTIFACTS -- never combined):**

1. **A .docx project description** with milestone-based structure -- the agreement attachment. This document contains NO cost estimates, NO should-cost figures, NO funding profiles, NO cost-sharing calculations, and NO government budget data. It defines what the prototype must achieve, by when, and what constitutes success at each milestone.

2. **A milestone 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 OT Cost Analysis skill. It is NEVER embedded in the project description document. It is NEVER saved as a companion file. It exists solely as a markdown table in the conversation so the user can review it and the downstream OT Cost Analysis skill can consume it.

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

**Statutory basis:** 10 USC 4021 (authority to carry out prototype projects), 10 USC 4022 (other transaction authority and follow-on production), 10 USC 4003 (definition of prototype project). NOT FAR-based. OTs operate outside the FAR; the project description replaces the SOW/PWS as the primary scope document attached to the agreement.

**Related policy:** DoD OT Guide (USD(R&E) / USD(A&S)), individual service OT policies (Army AFC, Navy NSWC, Air Force AFRL/AFWERX guidance). These are policy references, not binding regulations like the FAR.

## Workflow Selection

### Workflow A: Full Build (Default)
User needs a project description from a prototype concept or objective. Execute Acquisition Context Intake, then all three phases.
Triggers: "write an OT project description," "build a prototype agreement," "I need a project description for an OT," "scope a prototype."

### Workflow B: Convert from Existing Document
User has an existing SOW, SOO, BAA white paper, or proposal abstract and needs it developed into an OT project description. Start with Phase 0 (document intake), then Phases 1-3.
Triggers: "convert this SOW to an OT project description," "develop this white paper into a prototype scope," "we have a BAA response and need a project description."

### Workflow C: Scope Reduction
User has an existing OT project description or cost analysis output that exceeds budget or schedule. Walk through the milestone structure to identify what to cut or defer, then produce a revised document.
Triggers: "this prototype is too expensive," "we need to reduce scope," "can we drop a phase," "defer TRL 6 to a follow-on."

## Acquisition Context Intake

Before diving into the scope decision tree, collect four framing decisions that shape everything that follows. Ask these up front, in a single pass, before Block 1.

### Intake Question 1: OT Type

| Type | Statutory Authority | Use When |
|------|-------------------|----------|
| Prototype | 10 USC 4021 | R&D, technology maturation, proof of concept through system demo |
| Production Follow-On | 10 USC 4022(f) | Transitioning a successful prototype to limited or full-rate production |
| Research | 10 USC 4021 | Basic or applied research, typically pre-TRL 4 |

If the user is unsure, default to Prototype -- it covers the widest range of OT work and is the most common. Production follow-on requires a completed prototype OT as a predecessor. Research OTs are less common and typically issued by service labs (NRL, ARL, AFRL).

### Intake Question 2: Performer Type

| Type | Cost-Sharing Implication | 10 USC 4022(d) Path |
|------|------------------------|---------------------|
| Nontraditional Defense Contractor (NDC) | NDC participation satisfies 4022(d)(1)(A) | No cost share required if NDC has significant participation |
| Traditional + NDC Team | NDC sub or team member satisfies 4022(d)(1)(A) | Same as above |
| Small Business | Small business significant participation satisfies 4022(d)(1)(B) | No cost share required |
| Consortium Member | Depends on consortium structure and awardee | Varies by consortium agreement |
| Traditional (sole, no NDC/SB participation) | Must have cost-sharing arrangement per 4022(d)(1)(C) | Cost share required (typically 1/3 performer) |
| Traditional (with follow-on competition commitment) | Competitive follow-on satisfies 4022(d)(1)(D) | No cost share required but must compete production |

An NDC is defined at 10 USC 3014: an entity that is not currently performing, and has not performed for the prior one-year period, any DoD contract or subcontract subject to full Cost Accounting Standards (CAS) coverage under 41 USC 1502. The test is CAS full-coverage status, not a dollar threshold on contracts. Nonprofits performing DoD-relevant research and any other entity the contracting officer determines as nontraditional also qualify. The performer type determines whether cost-sharing is required and shapes the project description's cost-sharing section. Do NOT cite a dollar-value rule (e.g., "$500K+ in prior year"). That is not the statutory test and will cause mis-determinations.

### Intake Question 3: TRL Entry and Exit

| TRL | Description | Typical OT Phase |
|-----|-------------|-----------------|
| 1 | Basic principles observed | Research OT |
| 2 | Technology concept formulated | Research OT |
| 3 | Proof of concept | Early Prototype |
| 4 | Component validation in lab | Prototype (design/build) |
| 5 | Component validation in relevant environment | Prototype (build/test) |
| 6 | System demo in relevant environment | Prototype (test/demonstrate) |
| 7 | System prototype demo in operational environment | Late Prototype / Pre-production |
| 8 | System complete and qualified | Production Follow-On |
| 9 | System proven in operational environment | Production |

Collect: TRL at project start (entry) and TRL target at project end (exit). This determines the number of phases and the nature of milestones. Most prototype OTs span TRL 3-6 or TRL 4-7. Research OTs are typically TRL 1-3 or TRL 2-4.

If the user gives a range wider than 4 TRL levels (e.g., TRL 2 to 8), flag that this may exceed typical prototype OT scope and suggest breaking into two agreements or phasing with go/no-go gates.

### Intake Question 4: Consortium or Direct

| Approach | Description | Agreement Structure |
|----------|------------|---------------------|
| Direct OT | Government awards directly to a single performer | Bilateral agreement between government and performer |
| Consortium-brokered | Award through a consortium organization | Agreement may route through consortium (DIU, AFWERX, NavalX, NSTXL, SOSSEC, MTEC, etc.) |

If consortium: identify which consortium. Consortium OTs often follow consortium-specific templates and add a management fee (typically 3-5%). The project description content is the same; the agreement wrapper differs.

### Why these four questions come first

OT project descriptions must be shaped by the statutory authority, the cost-sharing path, the technology maturation scope, and the agreement structure. A TRL 3-6 prototype with an NDC performer reads differently from a TRL 6-7 production-readiness effort with a traditional prime requiring cost-sharing. Collecting these up front means Phase 1 can frame scope questions appropriately.

## Phase 0: Document Intake (Workflow B Only)

When the user provides an existing document (SOW, SOO, BAA white paper, proposal abstract):

1. **Read and extract.** Parse for: technical objective, current state of technology, systems involved, TRL indicators, proposed approach, deliverables, schedule, performer qualifications, prior work.

2. **Gap identification.** Flag what the document provides vs. what an OT project description needs:
   - Typically present: technical objective, background, proposed approach
   - Typically missing: TRL entry/exit mapping, milestone definitions, go/no-go criteria, data rights assertions, cost-sharing structure

3. **Decision bridge.** Present gaps as questions Phase 1 will answer. Frame it as: "This document tells us what the performer wants to build. Phase 1 asks the questions that turn a concept into executable prototype milestones with decision gates."

4. **Carry forward.** Pre-populate Phase 1 answers with anything the document already decided. Don't re-ask settled questions.

**SOW conversion note:** If converting from a traditional SOW, flag that OTs do not use task/subtask CLIN structure, FAR clause references, or performance-based language (those are FAR constructs). The conversion maps task areas to TRL phases and deliverables to milestone completion criteria.

**Cost data stripping (Workflow B).** If the source document contains cost figures (CLIN values, total contract value, labor rates, phase dollar amounts), do NOT preserve them in the project description body or any section of the .docx. Pass them to the Milestone Handoff Table as an informational reference line labeled "Source-doc cost references (informational only, do not anchor should-cost estimate)" so the OT Cost Analysis has calibration context without treating them as should-cost anchors.

**Cost-share arithmetic question (Workflow B + path (C) only).** If the source document states a total contract value and the performer type triggers 10 USC 4022(d)(1)(C) cost-sharing, ask the user whether the stated total represents (a) the government share with performer contributing additional funds on top, or (b) the total agreement value with performer share carved out of the stated figure. Do not default. The two interpretations produce materially different government obligations (roughly 50% delta at the standard 1/3 share).

## Phase 1: Scope Decision Tree

Ask questions in this sequence. Each decision narrows scope and implies milestones. 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 Context Intake and Blocks 1-6. Batch 3-4 related questions per prompt block. Reserve prose for genuinely open-ended answers (technical approach, system names, performer 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: Prototype Objective and Technical Baseline

1. **What is being prototyped?** Hardware system | Software application/platform | Process or workflow | Algorithm or model | Hybrid (hardware + software) | Integration of existing systems
2. **What is the current state?** Concept only (no existing implementation) | Lab prototype exists (needs maturation) | Commercial product exists (needs military adaptation) | Prior government prototype (needs iteration)
3. **What does success look like?** Define in terms of: "Demonstrate [capability X] at [performance level Y] in [environment Z]." This becomes the top-level prototype objective.
4. **Data rights posture:** Government Purpose Rights (GPR) | Limited Rights | Unlimited Rights | Negotiated split by deliverable category | Performer retains all background IP, government gets GPR on foreground

Data rights in OTs are negotiated per agreement, not prescribed by FAR Part 27. DFARS 252.227-7013 (technical data) and 252.227-7014 (software) provide a framework but can be tailored. The data rights posture should be decided early because it affects performer willingness and cost.

### Block 2: TRL Progression and Phase Structure

5. **Number of phases:** Typically 2-4 for a prototype OT. Each phase spans 1-2 TRL levels.
6. **For each phase, define:**
   - Entry TRL and exit TRL
   - Primary activity: Design | Build/Fabricate | Integrate | Test | Demonstrate
   - Duration estimate (months)
   - Key technical risk to retire in this phase
7. **Go/no-go criteria between phases:** What must be demonstrated to proceed? Examples:
   - "Component X achieves [metric] in lab environment" (TRL 4 gate)
   - "Integrated system passes [test] in simulated operational conditions" (TRL 5 gate)
   - "System demonstration meets [threshold] observed by government test team" (TRL 6 gate)
8. **Off-ramp conditions:** Under what circumstances would the government terminate before completing all phases? (Technical failure, budget reduction, requirement change, superior alternative identified)

### Block 3: Technical Scope

9. **Systems and technologies:** List all systems, subsystems, and enabling technologies the prototype will develop, integrate with, or demonstrate against.
10. **Integration requirements:** Standalone prototype | Must integrate with [existing government system] | Must demonstrate interoperability with [allied/partner system]
11. **Test environment:** Laboratory | Simulated operational (specify fidelity) | Operational (specify location/unit) | Multiple environments across phases
12. **Data and analytics:** Does the prototype produce data that requires analytics, ML model training, or algorithm validation? If yes, describe the data pipeline.

### Block 4: Scale and Deliverables

13. **Prototype units (if hardware):** Number of units to build. Single prototype | 2-5 units (for testing/evaluation) | Pre-production quantity (10+, likely production follow-on)
14. **Test events and demonstrations:** Number and type of formal test/demo events. Who observes? (Government test team, operational users, senior leadership, allied partners)
15. **Data deliverables:** Technical data packages | Design documents | Test reports | Source code | Training data sets | Algorithm documentation | User manuals
16. **Software deliverables (if applicable):** Source code | Compiled binaries | Container images | API documentation | Deployment scripts

### Block 5: Agreement Structure

17. **Period of performance by phase:** Duration per phase in months. Total PoP typically 12-36 months for prototype OTs.
18. **Milestones per phase:** Typically 2-4 milestones per phase. More milestones = more government oversight but also more payment events.
19. **Milestone payment type:** Fixed-price milestones (most common -- fixed payment upon completion) | Cost-type milestones (ceiling per milestone, reimburse actuals) | Mixed (some fixed, some cost-type)
20. **Cost-sharing arrangement (if applicable per Intake Q2):**
    - Performer cash contribution (what percentage?)
    - Performer in-kind contribution (lab time, equipment, personnel not charged to the agreement)
    - No cost share (NDC/SB participation path or competition commitment path)
21. **Production follow-on option (10 USC 4022(f)):** Yes -- include provisions for production transition | No -- prototype only | TBD -- evaluate after prototype results

### Block 6: Oversight and Reporting

22. **Technical review cadence:** Monthly | Quarterly | At milestone completion only | Per-phase technical interchange meetings (TIMs)
23. **Milestone acceptance process:** Government program office review | Independent test team evaluation | Joint government-performer review board | Combination
24. **Government test participation:** Government observers only | Government co-testers | Government provides test environment/range | Performer-led testing with government data access
25. **Key personnel:** Which performer roles require government approval? (Principal Investigator/Technical Lead always; others as needed)

…

## 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-ot-project-description-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%.