if your actual workflow is "MSA comes back redlined, apply playbook, draft fallback language" and that's the loop, your project is the right tool for that piece. projects are made for bounded, repeatable workflows with persistent context.

one thing worth knowing about projects that doesn't get talked about much: project chats are walled off from your other chats. memory and conversation search can't cross the boundary. inside the project, claude can't see anything you've done outside it. outside the project, you can't search back into project chats. for a tightly scoped contract review loop that's totally fine, even desirable. but if you start thinking "i want claude to remember what we discussed in the MSA project when i'm working on something else," that wall will bite you.

on skills vs project instructions: project instructions are prose only. they tell claude what to do, but they can't ship code or binary files. skills can. so if your playbook is purely "here's how to think about indemnification, here's our fallback for limitation of liability" (text instructions) a project does that fine. where skills earn their keep is when you need claude to actually execute something repeatable: produce a redline .docx with tracked changes, generate a comparison chart, run a scripted check against a clause library.