RCP-CWK-027 Cross-Project Knowledge Receiver

Receives, validates, and integrates knowledge from a peer project’s transfer packet (XFER-*.txt)

Receives, validates, and integrates knowledge from a peer project’s transfer packet (XFER-*.txt). The receiving project decides what is relevant — not the sender. Accepted items are promoted to the Lessons Learned file or optionally routed to the roadmap.

Cross-Project Knowledge Receiver

Cowork | Transfer (Cross-Project) | Difficulty: Intermediate | Time: 2–4 minutes
Tags: Introduced in Beta, Transfer, Knowledge, Cross-Project, Peer-to-Peer, Validation, Integration, XFER, Cowork

TL;DR

What It Does
Receives, validates, and integrates knowledge from a peer project’s transfer packet (XFER-*.txt). The receiving project decides what is relevant — not the sender. Accepted items are promoted to the Lessons Learned file or optionally routed to the roadmap.
How It Works
Five phases. Phase 1 (Structural Validation) reads the packet, verifies all 4 required sections exist, and confirms the target project ID matches. Phase 2 (Gate Validation) runs CWK-024 verification on 4 receiver-side claims: evidence grounding, LL consistency, applicability, and context sufficiency. Phase 3 (Independent Relevance Assessment) scores relevance from the receiver’s perspective using the same rubric as CWK-026 — divergences of more than 20 points from the sender’s score are noted. Phase 4 (Decision Routing) applies a decision matrix: ACCEPTED, REVIEW_REQUIRED, CONFLICT_DETECTED, or DEFERRED. Phase 5 (Integration) creates LL entries for accepted items, updates the packet’s TRANSFER_RESPONSE, moves the packet to processed/, and commits via CWK-005.
What To Expect
A decision on the transfer (ACCEPTED, DEFERRED, or REJECTED) with the packet moved from inbound/pending/ to inbound/processed/. Accepted items appear as new LL entries with full provenance. The original packet’s TRANSFER_RESPONSE section is filled in with the decision and routing details.
Best Results When You
Have the transfer packet in transfers/inbound/pending/ before invoking. Ensure your project’s Lessons Learned file is current — the LL consistency gate checks for contradictions. Use “review” mode (default) to maintain human oversight of what enters your knowledge base.
Typical Time
2–4 minutes. Structural validation and gate checks are fast. Most time is spent on user review (if in review mode) and conflict resolution (if conflicts detected).
Difficulty
Intermediate — requires understanding of transfer packet structure, how to evaluate relevance from the receiver’s perspective, and how to handle conflicts between transferred knowledge and existing project knowledge.

How To Start

This recipe is user-invoked when a transfer packet has arrived in your project’s transfers/inbound/pending/ directory. Companion to CWK-026 (Knowledge Packager) on the sender side.

STEP 1Provide the Transfer File

Point the recipe to the incoming XFER-*.txt packet and choose your integration mode.
Available parameters
  • transfer_file · string · required
    Path to the incoming transfer packet file (e.g., “XFER-CP-059a-TO-CP-060-20260302-001.txt”). The file should be in transfers/inbound/pending/.
  • integration_mode · string · optional · default: review · options: auto, review
    “auto” accepts transfers that pass all gates and score ≥70 relevance without user confirmation. “review” always asks the user before accepting. Conflicts always go through user review regardless of mode.
Invocations
Standard Review Mode
#H->AI::Directive: (Receive and validate cross-project transfer with transfer_file=“transfers/inbound/pending/XFER-CP-059a-TO-CP-060-20260302-001.txt”)
Auto Mode
#H->AI::Directive: (Receive and validate cross-project transfer with transfer_file=“transfers/inbound/pending/XFER-CP-061-TO-CP-067-20260415-001.txt”, integration_mode=“auto”)
Process All Pending
#H->AI::Directive: (Process all pending transfers in transfers/inbound/pending/)

Usage Examples

Three scenarios — a clean acceptance, a conflict that requires user resolution, and a deferral due to low confidence.
Example 1 · Accepted transfer promotes to LL
User: Process the incoming transfer from CP-059a.
Cat: Reading transfer packet. Structural validation: PASS (all 4 sections, target matches). Gate validation: 4/4 VERIFIED. Relevance: 85/100 (receiver) vs 90/100 (sender) — consistent. Decision: ACCEPTED. Promoting to Lessons Learned. Added as LL-PROJ-060-047. Packet moved to processed/. Git checkpoint committed.
Example 2 · Conflict detected — user resolves
User: Process the transfer from CP-061.
Cat: Structural validation: PASS. Gate validation: Claim 2 (LL Consistency) FLAGGED — transfer says “git pull works with fetch+show workaround” but existing LL-026 says “git pull is completely blocked.” Conflict detected. Accept transfer (supersedes existing), defer, or reject? User: Accept. Updated LL-026 with workaround details. Packet processed.
Example 3 · Deferred due to low confidence
User: Process the transfer from CP-068.
Cat: Structural validation: PASS. Gate validation: Claim 1 (Evidence Grounding) UNVERIFIED — no Tier 1 evidence. Claim 4 (Context Sufficiency) FLAGGED — implementation notes are vague. Average confidence: 48. Relevance: 45/100. Decision: DEFERRED. Storing for reference. Packet moved to processed/ with status DEFERRED.

How AI Reads This Recipe

When this recipe is triggered, the AI processes an incoming transfer through 5 phases. The AI should:
  1. VALIDATE STRUCTURE. Read the transfer packet. Verify 4 required sections: TRANSFER_METADATA, TRANSFER_ITEM, EVIDENCE, TRANSFER_RESPONSE. Confirm target_project_id matches this project. If mismatched, warn user and ask whether to proceed. Extract metadata: source project, item type, title, sender relevance score.
  2. RUN CWK-024 VERIFICATION GATES. Submit 4 receiver-side claims: evidence grounding (Tier 1 present? 85 or 40 initial confidence), LL consistency (contradictions with existing LL? 90 or 30), applicability (relevance explanation connects to this project? 80 or 50), context sufficiency (implementation notes actionable? 80 or 45). Gate passed = all claims VERIFIED or FLAGGED ≥60.
  3. ASSESS RELEVANCE INDEPENDENTLY. Score from receiver’s perspective: Cowork constraints (+25), framework version (+20), goal applicability (+30), error prevention (+25). If sender and receiver scores diverge by >20 points, note the divergence. Receiver score takes precedence for routing.
  4. ROUTE DECISION. Apply matrix: gates passed + relevance ≥70 = ACCEPTED; gates passed + relevance ≥50 = REVIEW_REQUIRED; low average confidence = DEFERRED; conflicts detected = CONFLICT_DETECTED. In review mode, always ask user. In auto mode, auto-accept if ACCEPTED. Never auto-accept conflicts.
  5. INTEGRATE. For ACCEPTED: create LL entry with full provenance (source, transfer ID, evidence, caveats), optionally route to roadmap, update TRANSFER_RESPONSE in packet, move to processed/, commit via CWK-005. For DEFERRED/REJECTED: update TRANSFER_RESPONSE, move to processed/. Update transfer registry via CWK-028 if available.
Error handling: if packet is unreadable or corrupted, suggest re-export from source project using CWK-026. If directories cannot be created, process in project root. Never auto-accept a transfer that conflicts with existing LL — always route conflicts to user review. R-12 audit trail is recorded.

When to Use This Recipe

Use this recipe when you:
  • Have received a transfer packet (XFER-*.txt) from a peer project in your transfers/inbound/pending/ directory.
  • Want to validate, assess, and integrate external knowledge into your project’s Lessons Learned or roadmap.
  • Need to independently verify the relevance and accuracy of transferred knowledge from the receiver’s perspective.
  • Want an audit trail of received transfers with decision rationale and provenance tracking.
Do not use this recipe when:
You are the sender — use CWK-026 (Knowledge Packager) instead. Also not appropriate for processing raw files or code deliverables between projects. CWK-027 handles structured knowledge items (lessons, patterns, discoveries), not arbitrary file transfers.

Recipe FAQ

Q.What are the four receiver-side verification gates?

Evidence Grounding (is Tier 1 evidence present and real?), LL Consistency (does the transfer conflict with existing knowledge?), Applicability (does the relevance explanation connect to this project?), Context Sufficiency (can this project act on the implementation notes without asking the source?).

Q.What are the four possible decisions?

ACCEPTED (promote to LL, optionally roadmap), REVIEW_REQUIRED (moderate relevance, ask user), CONFLICT_DETECTED (contradicts existing LL, ask user to resolve), DEFERRED (low confidence or relevance, store for reference).

Q.What happens when sender and receiver relevance scores diverge?

If they diverge by more than 20 points, the divergence is noted. The receiver’s score always takes precedence for the routing decision. This is by design — the receiving project decides what is relevant, not the sender.

Q.How are conflicts handled?

Conflicts are never auto-accepted. The recipe presents both the transfer content and the conflicting LL entry, then asks the user to accept (supersede existing), defer, or reject. The user makes the final call.

Q.What does integration_mode “auto” do?

Transfers that pass all gates and score ≥70 relevance are automatically accepted and promoted to LL without user confirmation. Transfers with moderate relevance, failed gates, or conflicts still go through user review. Useful for batch processing trusted sources.

Q.Where does the processed packet go?

From transfers/inbound/pending/ to transfers/inbound/processed/. The TRANSFER_RESPONSE section is filled in with the decision, timestamp, receiver info, and routing details before moving. This provides a complete audit trail.

Version History

Changes to this recipe over time. Most recent first.
v1.01a 2026-03-15
Added CWK-024 verification gate integration (Phase 2) with 4 receiver-side claims. Independent relevance scoring with sender divergence detection. CWK-028 transfer registry update. CWK-005 git checkpoint on acceptance. Decision matrix expanded to 4 outcomes. Error handling for unreadable packets and missing directories.
v1.00a 2026-02-28
Initial release. 5-phase transfer reception pipeline with structural validation, relevance assessment, decision routing (ACCEPT/DEFER/REJECT), LL integration with provenance tracking, roadmap routing option. Peer-to-peer model — receiver decides independently.

Get this recipe with CRAFT for Claude Cowork

Cowork recipes ship bundled with CRAFT for Claude Cowork — there’s no separate download. Clone the framework once, and your AI runs every recipe automatically when invoked.

Pull anytime to stay on the latest version — free to clone, no login or email required.

Then start your session

Once CRAFT is in your project folder, open a new Cowork session and ask Claude to initialize. For example:

You

Please initialize my CRAFT session.

Claude

CRAFT session ready. Your project is loaded, your persona is active, and your recipes are available. What would you like to work on?

What is CRAFT for Claude Cowork?

Not familiar with Git? Download as a ZIP

No command line needed. Just download, move, and unzip:

  1. Open the CRAFT framework repo on GitHub.
  2. Click the green Code button, then choose Download ZIP.
  3. Move the downloaded ZIP into your Claude Cowork project folder.
  4. Unzip it: double-click on Mac, or right-click → Extract All on Windows.

Similar Posts