dl-utility-project-context

name: dl-utility-project-context description: > Populates the deal-context slot of any Direct Lending Underwriting Library phase project instruction (PI) for a specific company and emits the fully-populated PI as a clean markdown block to paste into Claude Desktop's project-instructions field. Use when the teammate says "set up my deal project," "fill in the project instruction," "refresh my PI — new VDR wave / QoE roll-forward / IC outcome," or "roll the deal forward to the next phase." Three modes share one workflow: Fresh-start (new project), Refresh (deal state moved within the phase), Roll-forward (deal advanced to the next phase). Auto-detects current phase + company from the project's already-attached PI, sources every field through a reverse defensively-degrading cascade (SharePoint via the Microsoft 365 connector → chat attachments → project attachments → ask the teammate), preserves teammate-supplied carryover values, emits a field-level diff in the trace footer, and never fabricates a value the cascade cannot resolve.

Project-Context Populator

Populates / refreshes / rolls-forward the deal-context slot of any Direct Lending Underwriting Library phase project instruction (PI) and emits the fully-populated PI as a clean markdown block the teammate copies into Claude Desktop's project instructions field. Three modes share one workflow; auto-detection turns the common case (Refresh the same-phase PI with new SharePoint state) into one confirm-and-go turn.

When to use

Activate when the teammate:

• Is setting up a brand-new Claude Desktop project for a deal and needs the phase PI's deal-context slot filled in (Fresh-start).
• Has an already-populated PI attached to the project and the deal's upstream state has moved — a VDR wave unlocked new KPIs, a QoE rolled forward, the posting-IC outcome landed, the sponsor's debt-advisor sent a structure update — and wants the slot re-sourced from the current SharePoint folder state (Refresh).
• Has an already-populated PI attached and the deal has advanced to the next phase (Stage 1→Stage 2; Stage 2→Stage 3 P5; P5→P6; P6→P7; P7→P8) and wants the target-phase PI populated with carryover from the source-phase PI for fields that exist in both slots (Roll-forward).

In every mode, only the {{ placeholder }} text inside the deal-context slot is replaced — every other byte of the target-phase PI (scope text, skill routing, phase rules, uploads list) is preserved exactly.

The seven bundled phase PIs the skill operates on:

• stage-1-origination.md — Stage 1 P1–P2 Origination
• stage-2-screening.md — Stage 2 P3–P4 Screening
• stage-3-p5-ddq.md — Stage 3 P5 Initial DDQ
• stage-3-p6-diligence.md — Stage 3 P6 Initial DD
• stage-3-p7-pre-screen-ic.md — Stage 3 P7 Pre-Screen IC
• stage-3-p8-term-sheet.md — Stage 3 P8 Term Sheet
• stage-6-asset-management.md — Stage 6 P17–P19 Asset Management

Stage 4 / Stage 5 have no PI today; the skill declines them in Step 2.

Workflow

Copy this checklist and check off as you complete:

Project-context population:
- [ ] Step 0: Auto-detect current state from project-attached PI (silent)
- [ ] Step 1: Elicit / confirm mode + company + target phase
- [ ] Step 2: Validate phase + company + mode
- [ ] Step 3: Run reverse defensively-degrading cascade (Tier 1 → 2 → 3 → 4)
- [ ] Step 4: Populate target-phase PI template (mode-aware substitution)
- [ ] Step 5: Emit populated PI + cascade-trace footer + filename + save instruction

Step 0 — Auto-detect current state (silent; before the elicitation message)

Before saying anything to the teammate, scan the project's already-attached files for a populated PI. A match is any attached markdown file whose first ~50 lines structurally match one of the seven bundled reference/pi-templates/<file>.md templates (header text + section sequence + deal-context slot heading).

On match, extract:

• The detected current phase — which of the seven templates the attached PI forks from.
• The detected company name — from the slot's COMPANY field (or, for the Stage 1 template, from any inferable equivalent such as the SOURCING THESIS / NAMED TARGETS lines; if Stage 1 carries no company, the company stays none).

Detection outcomes:

• No match → detected state is (phase: none, company: none); default mode is Fresh-start.
• Exactly one match → detected state is the matched (phase, company); default mode is Refresh.
• Multiple matches → ambiguous; surface the matches in Step 1 Case C and ask the teammate to pick the source PI.

This step never makes a connector call — it reads only what Claude Desktop has already loaded into the project context.

Step 1 — Elicit / confirm mode + company + target phase

Build the elicitation message dynamically against the Step-0 detected state. Ask in one consolidated message (not piecemeal).

Case A — detected state is (none, none) (Fresh-start default).

Two quick questions so I can populate the deal-context slot:

1. **What stage/phase?** Stage 1 / Stage 2 / Stage 3 P5 / Stage 3 P6
   / Stage 3 P7 / Stage 3 P8 / Stage 6
2. **What company?** (legal entity name; e.g., Acme Industries)

Case B — detected state is (phase, company) (Refresh default). Show the detected state back:

I see {Company} at {detected phase} from the PI already attached to
this project. Pick a mode:

1. **Refresh** {detected phase} — re-source the slot from the current
   SharePoint folder state (use when there's a VDR wave, QoE
   roll-forward, posting-IC outcome, or structure update). ← default
2. **Roll-forward** to {next phase per reference/slot-field-map.md
   §2} — carry the deal into the next phase's PI.
3. **Fresh-start** — different company or different phase. (If
   picking this, name the phase + company.)

Just say "1" / "2" / "3" plus any phase + company override.

If the roll-forward target for the detected phase is "none" (P8 ahead of Stage 4/5; Stage 6 terminal), substitute the option 2 line with: 2. **Roll-forward** — not available from {detected phase} (no PI ships at the next phase today). and explain in Step 2 if picked.

Case C — detected state is multiple matches.

I found multiple attached PIs in this project. Pick the source PI:

1. {match 1 — phase + company}
2. {match 2 — phase + company}
...

After you pick, I'll ask for mode (Refresh / Roll-forward /
Fresh-start).

After the teammate picks, fall through to Case B with the chosen match as the detected state.

The skill respects whatever the teammate types — a one-line "1" / "2" / "3" confirms the default; a phase/company string overrides.

Step 2 — Validate phase + company + mode

• Phase. Must be one of the seven supported phases. On close-match, confirm in one line: "Did you mean stage-3-p6-diligence?". On no-match, refuse with the supported-phase list. Stage 4 / Stage 5 declined: "no PI ships at that phase today; pick one of the seven supported phases".
• Roll-forward target. If Mode = Roll-forward, the target is the source-phase's successor per reference/slot-field-map.md §2. If the source phase has no successor (P8 → no Stage 4/5 PI ships yet; Stage 6 terminal), decline with the gap explanation rather than silently jumping forward.
• Company. Any non-empty string accepted; the Tier 1 cascade in Step 3 is what tests whether the company has a SharePoint folder.

Step 3 — Run the reverse defensively-degrading cascade

Four tiers, tried in order. First hit wins per field; a tier that fires but returns nothing for a field falls through to the next tier rather than blocking. Never silently treat unknown as found — every field no tier resolves becomes [INSUFFICIENT DATA — <field> not found via MSFT 365 / chat / project]. When the resolved deal folder contains a 00 OL Deal Wiki folder, Tier 1a (the deal-wiki pages) is tried before the Tier-1 raw folder scan — mechanics in reference/cascade-mechanics.md.

The cascade specification — Tier 1 / 2 / 3 / 4 mechanics, per-field discovery patterns, the never-fabricate discipline, the cascade-trace footer schema — lives in reference/cascade-mechanics.md. Read it before running Step 3 the first time in a session.

Per-template field catalog (which fields belong to which template, which are SharePoint-discoverable vs user-supplied) lives in reference/slot-field-map.md §1.

At the end of Step 3 if any field still lacks a value (Tiers 1–3 all fell through), prompt the teammate in one consolidated message listing every unresolved field with its slot key and a one-line value hint. The teammate's response is the Tier 4 input. Fields the teammate also cannot supply become [INSUFFICIENT DATA — <field> unavailable].

Step 4 — Populate the target-phase PI template (mode-aware)

Read the target-phase template at reference/pi-templates/<target-phase>.md. Locate the deal-context slot — the fenced code block under the ## Deal-context slot (...) header.

Substitution rule depends on mode:

• Fresh-start. Every {{ placeholder }} is substituted with the Step-3 cascade-resolved value (or [INSUFFICIENT DATA — ...]). No carryover logic.
• Refresh. Apply reference/slot-field-map.md §3:
  • Refresh-override fields (LTM EBITDA, ACTIVE DOCUMENT INDEX, FINANCIAL SOURCE SET, FINANCIAL ANCHORS, INDICATIVE STRUCTURE) default to cascade-substitution.
  • Other shared fields with a teammate-supplied prior value default to carryover (the prior value is what gets substituted; the cascade result is logged in the trace footer only).
  • Shared fields whose prior value is {{ placeholder }} or [INSUFFICIENT DATA] are cascade-sourced.
  • The cascade-trace footer carries a field-level diff showing <old> → <new> for every field whose value changed.
• Roll-forward. Apply reference/slot-field-map.md §2 + §3:
  • For each field in the target slot: if it exists in both source and target slots AND the prior value is teammate-supplied, carryover verbatim (cascade still run; result logged in trace, not substituted).
  • If the field is introduced at the target phase (per §2 map), cascade-source it.
  • If the source slot carries a field that does not exist in the target slot (e.g., SOURCING THESIS on a 1→2 roll-forward), it simply does not appear — the target template's slot text is canonical.

Every other byte of the target template is preserved exactly. No edits to the scope text, skill routing table, sequence diagram, phase rules, or uploads list. The slot's surrounding text (including the unfilled-placeholder line) is left as-is.

Before emitting in Step 5, apply the four validation gates in reference/cascade-mechanics.md §"Validation gates". A failed gate halts emission with a one-line error message identifying the failure; do NOT emit a half-populated PI.

Step 5 — Emit the populated PI + cascade-trace footer + filename + save instruction

Emit the populated PI as a single fenced markdown code block. At the very bottom — after the template's final section — embed the cascade-trace footer per the schema in reference/cascade-mechanics.md §"Cascade-trace footer schema" (mode, prior PI, target phase, per-field source tags, and the <old> → <new> diff lines in Refresh / Roll-forward modes). The footer is an HTML comment block, so it survives a paste into Claude Desktop's project instructions field without rendering in the visible body.

Below the fenced markdown block, print the suggested filename and the copy-paste instruction:

<Company>-project-instruction-<target-phase>-<YYYYMMDD>.md

Save the block above as the filename, open the saved file, and copy-paste its contents into your Claude Desktop project's "Project instructions" field. Only the deal-context slot is changed — every other section is preserved exactly. For Refresh / Roll-forward emits, review the diff lines inside the cascade-trace footer before pasting.

When the deal has an initialized deal wiki, the emit also recommends running /dl-dealwiki-update afterward to persist the refreshed slot state into the deal wiki.

Reference files

• reference/slot-field-map.md — per-PI deal-context field catalog (Stage 1 / Stage 2 / the shared Stage-3 slot / Stage 6); roll-forward target map; carryover rules including the five-field Refresh-override list.
• reference/cascade-mechanics.md — reverse cascade specification (Tier 1 Microsoft 365 connector, folder resolution, per-field discovery patterns, connector failure handling; Tier 2 chat attachments; Tier 3 project attachments; Tier 4 teammate prompt); never-fabricate discipline; cascade-trace footer schema including the <old> → <new> diff form; pre-emit validation gates.
• reference/pi-templates/ — the seven byte-faithful PI templates the skill substitutes into. Each is a copy of the shipped phase PI.

What this skill does NOT do

• It does not edit any shipped PI. The templates in reference/pi-templates/ are read-only copies; the skill emits a new markdown block for the teammate to paste.
• It does not edit the teammate's Claude Desktop project instructions field directly — that field is not a Claude-writeable surface. The emit + paste model is the only viable shape.
• It does not write back to SharePoint or DealCloud. The cascade is read-only against the Microsoft 365 connector.
• It does not auto-detect the deal phase from the SharePoint folder state — only from the project's already-attached PI (a structured artifact the skill ships the templates for).
• It does not file a Stage 4 / Stage 5 PI (none exists); it declines with the supported-phase list. A Roll-forward from P8 surfaces the same gap rather than silently jumping forward to Stage 6.
• It does not run per-field interactive reconciliation in Refresh mode — the teammate reviews the trace-footer diff inside the emitted block and edits field-by-field there.
• It does not fabricate a value the cascade cannot resolve. Every unresolvable field is [INSUFFICIENT DATA — <field> ...].

Classification & review state

A utility skill with no deal-lifecycle phase — the emitted artifact is project setup for the teammate's own Claude Desktop project, not a deal deliverable, so it carries no [DRAFT — HUMAN REVIEW REQUIRED] banner and no outbound-redaction checklist (it never reaches a borrower, co-lender, or LP). The emitted PI is CONFIDENTIAL-eligible — it carries SharePoint deal-folder paths and the active document index for a specific deal; the cascade-trace footer is internal-only (file paths and source tags, no fund-level economics). Never fabricate: a field the cascade cannot resolve is [INSUFFICIENT DATA — <field>]; never invent a SharePoint path, guess a sponsor name, derive a financial anchor from priors, or silently overwrite a carryover value without recording the change in the diff trace.

Runtime

No scripts — the skill runs in any Claude chat. The full experience needs a Claude Desktop project (Step 0 reads project-attached files; the emit targets the project-instructions field) and the Microsoft 365 connector for Tier 1 (use fully-qualified Server:tool names; confirm the server name at first invocation). Without the connector, the cascade degrades to chat / project attachments / teammate input and still emits a valid PI — with more [INSUFFICIENT DATA] fields, never guesses.