Convert source cards into project decisions. This skill answers: What does this source mean for our project?
Use after reference-reading-summarizer has produced a source card. Do not repeatedly re-read raw sources unless the card is insufficient or low confidence.
Skill Directory Layout
<installed-skill-dir>/
├── SKILL.md
├── references/
│ └── project-link-routing.md
└── templates/
└── project-use-note.md
Core Contract
- Read project memory before linking a source to claims, experiments, risks, implementation, collaborator actions, or writing.
- Use source cards as compressed inputs. Raw source files and raw reading trajectories stay out of project memory.
- Stronger reasoning is required when the source changes a claim, baseline, benchmark, novelty boundary, implementation plan, collaborator commitment, or project seed.
- Every project implication should link to a source card, confidence level, and target memory object.
- Do not promote a cheap skim into a project decision without marking uncertainty or requesting deeper reading.
Inputs
Prefer:
reference/cards/<source-id>.mdreference/.agent/source-index.mdreference/.agent/processing-status.md- backward-compatible
reference/.agent/reference-index.mdandreading-status.md memory/current-status.mdmemory/claim-board.mdmemory/evidence-board.mdmemory/risk-board.mdmemory/action-board.mdpaper/.agent/writing-contract.mdcode/.agent/benchmark-plan.mdor equivalent, when present
Model Routing
Read references/project-link-routing.md.
- Tier 2 normal main model: routine project-use notes, citation placement, writing-pattern routing, structured feedback actions.
- Tier 3 strong/deep model: closest-work risk, must-have baseline, benchmark protocol, core algorithm/theory impact, project seed, conflicted collaborator feedback, final positioning.
- Do not use cheap sidecar output as the final authority for project decisions.
Workflow
- Locate the project root and existing memory.
- Read the relevant source card and its confidence/provenance.
- Identify requested synthesis mode:
- claim support or challenge
- baseline implication
- benchmark/task/protocol implication
- method/theory implication
- implementation implication
- writing pattern
- citation placement
- collaborator feedback/action
- project spec/constraint
- project seed
- reviewer-risk or novelty boundary
- Create or update
reference/project-use/<source-id>.mdfromtemplates/project-use-note.md. - Write only durable conclusions into project memory — link-mode determines target:
- claim support/challenge →
memory/claim-board.md+memory/evidence-board.md - identified risk or blocker →
memory/risk-board.md+memory/action-board.md - baseline or benchmark → code-side
docs/experiments/ormemory/evidence-board.md - implementation hint → code-side design doc or
memory/decision-log.md - writing exemplar or style pattern →
paper/.agent/writing-memory/viapaper-writing-memory-manager - reviewer-risk or novelty framing →
memory/risk-board.mdorpaper/.agent/paper-evidence-board.md - provenance link →
memory/provenance-board.md
- claim support/challenge →
- If the card is too weak, route back to
reference-reading-summarizerwith the required reading mode.
Output Rules
Each project-use note should include:
- one-line project relevance
- supported or challenged claims
- baseline, benchmark, implementation, or spec implications
- algorithm/theory implications
- writing/citation implications
- collaborator actions if relevant
- risks and actions
- confidence and required follow-up
End with the closure audit:
Goal: What project question did this source help answer?
Answer: What did we learn?
Path: Which card, sections/files, and memory objects support this?
Correctness: Why should we trust it, and what needs deeper reading?
Next: What changes in the project?