TL;DR
What It Does
Packages a lesson learned, discovery, error pattern, technique, or best practice from the current project into a structured transfer packet file for delivery to a peer project. Produces a portable XFER-*.txt file that the user carries between Cowork sessions.
How It Works
Six steps. Step 1 locates and extracts the source item — grepping the LL file for Lesson Learned types or prompting for a description for others. Step 2 gathers evidence across 4 tiers: direct observation (Tier 1), artifact citation (Tier 2), cross-references (Tier 3), and causal reasoning (Tier 4). Step 3 computes a relevance score (0–100) based on shared Cowork constraints (+25), shared framework version (+20), goal applicability (+30), and error prevention value (+25). Step 4 runs CWK-024 verification gates on 3 transfer claims. Step 5 generates the XFER-*.txt packet with metadata, content, evidence, and a blank response section. Step 6 saves to transfers/outbound/ and optionally updates the transfer registry via CWK-028.
What To Expect
A structured XFER-*.txt file in transfers/outbound/ containing full metadata (source, target, relevance score, CWK-024 gate result), the knowledge item with implementation notes, 4-tier evidence, and a blank TRANSFER_RESPONSE section for the receiver. Delivery is manual — copy the file to the target project’s transfers/inbound/pending/ folder.
Best Results When You
Have a specific, well-defined knowledge item rather than a vague observation. Include a clear relevance explanation connecting the item to the target project’s goals. The stronger your evidence tiers, the higher the CWK-024 verification gate scores and the more credible the packet.
Typical Time
3–5 minutes. Most time is spent in Step 2 (evidence extraction) and Step 4 (verification gates). Simple LL transfers with strong evidence complete faster.
Difficulty
Intermediate — requires understanding of what makes knowledge transferable across projects, how to articulate relevance, and how to interpret verification gate results. The recipe handles formatting and packaging automatically.
How To Start
This recipe is user-invoked when you want to send a knowledge item from the current project to another project. Peer-to-peer — no hierarchy assumed.
STEP 1Specify the Knowledge Item and Target
Identify what you want to transfer, what type it is, and which project should receive it.
Available parameters
-
item_type
· string · required · options: LESSON_LEARNED, DISCOVERY, ERROR_PATTERN, TECHNIQUE, BEST_PRACTICE
Category of knowledge being transferred. Each type has slightly different extraction logic in Step 1.
-
item_reference
· string · required
Reference to the source item. For LESSON_LEARNED, this is the LL ID (e.g., “LL-039”). For other types, a descriptive label or observation name.
-
target_project_id
· string · required
Target project receiving this knowledge (e.g., “CP-060”). Used in the transfer packet filename and metadata.
-
target_project_name
· string · optional · default: “”
Human-readable name of the target project. Included in the packet for context.
-
relevance_explanation
· string · required
Why this item matters to the target project (2–3 sentences). Directly feeds the relevance scoring rubric in Step 3.
Invocations
Transfer a Lesson Learned
#H->AI::Directive: (Package knowledge for cross-project transfer with item_type=“LESSON_LEARNED”, item_reference=“LL-039”, target_project_id=“CP-060”, target_project_name=“CRAFT Master”, relevance_explanation=“Git pull workaround applies to all Cowork projects using the same sandbox constraints.”)
Transfer a Discovery
#H->AI::Directive: (Package knowledge for cross-project transfer with item_type=“DISCOVERY”, item_reference=“context-compaction-recovery”, target_project_id=“CP-068”, relevance_explanation=“Context compaction recovery pattern applies to any long-running Cowork session.”)
Transfer an Error Pattern
#H->AI::Directive: (Package knowledge for cross-project transfer with item_type=“ERROR_PATTERN”, item_reference=“git-index-lock-cascade”, target_project_id=“CP-059”, target_project_name=“Legacy Migration”, relevance_explanation=“Git lock cascade affects any project using git operations in Cowork sandbox.”)
Usage Examples
Three scenarios — a clean LL transfer, a low-relevance warning, and a verification gate flag.
Example 1 · Transferring a Lesson Learned
User:
Package LL-039 (git pull workaround) for CP-060. Both projects use the same Cowork sandbox.
Cat:
Locating LL-039 in Lessons Learned file. Extracted: “Git pull blocked in Cowork sandbox — use fetch+show pattern.” Gathering evidence: Tier 1 — LL-039 in project LL file. Tier 2 — git operations confirmed in H003 session log. Tier 3 — ULL-001 corroborates. Tier 4 — Cowork sandbox mount restrictions explain root cause. Relevance score: 95/100 (HIGH). CWK-024 verification: 3/3 VERIFIED. Transfer packet saved: transfers/outbound/XFER-CP-061-TO-CP-060-20260415-001.txt
Example 2 · Low relevance score triggers warning
User:
Package a discovery about recipe naming conventions for CP-068, a website project.
Cat:
Relevance score: 35/100 (LOW). Warning: This item may not be useful to CP-068. The naming convention discovery is specific to cookbook authoring, and CP-068 focuses on website content. Proceed anyway? User confirms. Generating packet with LOW confidence flag.
Example 3 · Verification gate flags an issue
User:
Package an error pattern about npm timeouts for CP-065.
Cat:
CWK-024 verification: Claim 1 (evidence grounded): FLAGGED — no file evidence for this error pattern, only session memory. Claim 2 (target relevance): VERIFIED. Claim 3 (actionable): VERIFIED. Recommend addressing Claim 1 before export — can you point me to a session log or commit where this error occurred? User provides context. Re-running gates. All VERIFIED. Packet generated.
How AI Reads This Recipe
When this recipe is triggered, the AI processes knowledge packaging through a 6-step pipeline. The AI should:
- SELECT AND EXTRACT THE SOURCE ITEM. If item_type is LESSON_LEARNED, grep the LL file for the reference and extract the full entry. For other types, prompt the user for a description and generate a 5–10 word summary title. Validate that content is non-empty and at least 20 words.
- GATHER EVIDENCE ACROSS 4 TIERS. Tier 1: direct observation or file reference. Tier 2: artifact citation with specific file, line, or commit. Tier 3: cross-references from other CRAFT materials. Tier 4: causal reasoning explaining transferability. Never fabricate evidence — leave tiers empty with a note if no evidence exists.
- COMPUTE RELEVANCE SCORE. Apply 4-dimension rubric: shared Cowork constraints (+25), shared framework version (+20), direct applicability to target goals (+30), error prevention value (+25). Scores below 40 trigger a warning requiring user confirmation before proceeding.
- RUN CWK-024 VERIFICATION GATES. Submit 3 claims: evidence grounding (initial confidence 80 if Tier 1 present, 50 otherwise), target relevance (initial confidence = relevance score), implementation actionability (initial confidence 75). If any claim is FLAGGED or UNVERIFIED, warn the user and offer to revise before export.
- GENERATE TRANSFER PACKET. Build XFER-*.txt with: TRANSFER_METADATA (IDs, scores, gate result), TRANSFER_ITEM (title, description, relevance explanation, implementation notes, related recipes/files, caveats), EVIDENCE (4 tiers), blank TRANSFER_RESPONSE (for receiver), and AUDIT_TRAIL.
- SAVE AND LOG. Write to transfers/outbound/. Determine sequence number from existing files. Update transfer registry via CWK-028 if available. Report filename, location, and delivery instructions to user.
Error handling: if the transfers directory cannot be created due to sandbox permissions, write the packet to the project root instead. Never fabricate evidence tiers. The peer project uses CWK-027 (Knowledge Receiver) to process incoming packets. R-12 audit trail is recorded.
When to Use This Recipe
Use this recipe when you:
- Have a lesson learned, discovery, error pattern, technique, or best practice that would benefit another CRAFT project.
- Need to formally document and evidence-ground knowledge before sending it to a peer project.
- Want a structured, portable transfer format that the receiving project can validate and integrate using CWK-027.
- Need an audit trail of what knowledge was sent, when, and with what confidence level.
Do not use this recipe when:
You want to transfer raw files or code between projects — CWK-026 is for transferring knowledge items (insights, patterns, lessons), not bulk file transfers. Also not needed for knowledge already promoted to Universal Lessons (CRAFT-UNIVERSAL-LESSONS.txt), which is automatically seeded into new projects.
Recipe FAQ
Q.What are the five item types?
LESSON_LEARNED (captured LL entry), DISCOVERY (novel finding), ERROR_PATTERN (reproducible error with workaround), TECHNIQUE (effective method or approach), BEST_PRACTICE (proven pattern worth adopting). Each type has slightly different extraction logic in Step 1.
Q.How does relevance scoring work?
Four rubric dimensions: shared Cowork constraints (+25), shared framework version (+20), direct applicability to target goals (+30), and error prevention value (+25). Maximum possible score is 100. Scores below 40 trigger a low-relevance warning requiring user confirmation.
Q.What are the four evidence tiers?
Tier 1: direct observation or file reference (strongest). Tier 2: artifact citation with specific file, line, or commit. Tier 3: cross-references from other CRAFT materials. Tier 4: causal reasoning or explanation (weakest but still valuable). Empty tiers are noted, not fabricated.
Q.How does the receiving project use the packet?
The receiving project uses CWK-027 (Knowledge Receiver) to validate, classify, and integrate the transfer. The packet includes a blank TRANSFER_RESPONSE section that the receiver fills in with their decision and routing.
Q.What if CWK-024 verification fails?
The recipe warns the user and lists which claims failed. You can revise the content (loop back to Step 1) or proceed with the flags noted in the packet. Flagged packets are still valid — the confidence level is adjusted accordingly.
Q.Is delivery automatic?
No. Delivery is manual. Copy the XFER-*.txt file from transfers/outbound/ to the target project’s transfers/inbound/pending/ folder, or upload it as an attachment when starting the receiving session. This is by design — Cowork sessions cannot communicate directly.
Version History
Changes to this recipe over time. Most recent first.
v1.01a
2026-03-15
Added CWK-024 verification gate integration (Step 4). Transfer claims are now evidence-grounded before export. Added CWK-028 transfer registry update call in Step 6. Sequence numbering for multiple transfers to the same target. Error handling for sandbox permission issues.
v1.00a
2026-02-28
Initial release. 6-step knowledge packaging pipeline with 5 item types, 4-tier evidence extraction, relevance scoring (0–100), structured XFER-*.txt output format. Peer-to-peer transfer model. Audit trail via R-12.