CWICR Subcontractor Scope Assignment Matrix

A project's scope gets coded once, then carved up across a dozen subcontract packages awarded weeks or months apart, and by the time the last one is signed, nobody has actually checked whether every coded piece of work is covered by exactly one subcontractor — some codes fall through because everyone assumed someone else had them, and others end up paid for twice because two subs' scope descriptions both claimed the same line without anyone noticing.

The skill takes the full CWICR-coded scope of the project and the list of subcontractor packages — each listing which CWICR codes that subcontract covers — and builds a matrix showing which code is assigned to which subcontractor. It flags every code with no subcontractor assigned as a scope gap, and every code assigned to more than one subcontractor as a scope overlap, so both get resolved before contracts are finalized instead of surfacing as a change order or a payment dispute mid-construction.

It doesn't evaluate whether a subcontractor is qualified, licensed, bonded, or trustworthy — that's a prequalification question about who *can* do the work, not a coverage question about who's actually on the hook for it, and the skill says so directly rather than blurring the two. It also doesn't price gaps or overlaps, and doesn't read the legal subcontract language for scope boundaries unless that language is provided — it works from the CWICR codes stated in each package.

CWICR itself is a US-market cost coding convention with no real equivalent in most other countries, but the underlying risk — coded scope that quietly falls between subcontracts, or gets claimed by two of them at once — is the same anywhere a project splits its work across multiple trade packages. Download the skill free with your email, or write to us if you want to see it working against your own subcontract package list.

How to use it with judgment: start with one real, well-defined case, enter only data you can verify, and keep the reviewed version. The goal is not to fill in another document for its own sake, but to turn a project decision into a record that someone else can understand and review later.

Before making it part of your process, check three things: the inputs come from an identifiable source, the calculations or wording match the actual project, and it is clear who must approve the result. If one is missing, treat it as working material rather than final project documentation.

How to prepare the input: start with a real case and define which question the skill must answer, which period the data covers, and which fields cannot be missing. Mark estimates or incomplete sources before requesting the analysis.

How to review the output: check that conclusions can be traced back to your data, inspect the rows or documents behind each alert, and discuss priority cases with the person responsible for the project. A skill helps organize judgment; it does not replace technical, contractual, or financial approval.

How to make it part of the workflow: keep the prompt, the source data, and the reviewed result with the project. This lets you repeat the analysis when progress changes, compare periods, and explain why a recommendation was accepted, rejected, or sent for review.

How to put it to work on a real project

The idea isn't to download another file and forget it in a folder. Use it with a specific case: a pending certificate, a coordination meeting, a cost overrun or a handover to the developer. Fill in the resource with real data from your project, validate the result with your own technical judgment, and keep it as an internal reference to repeat the process next time.