Jonathon's AI Wiki

Claude Skills vs Projects — Eliot Prince's Verbs/Nouns Mental Model

8 min read

Source: Claude_SKILLS_vs_PROJECTS_Clearly_Explained_how_to_combine_them_properly Creator: Eliot Prince (eliotprince.com / AI Recipe Vault) URL: https://www.youtube.com/watch?v=Cw1iOBvcbsE Duration: ~14 minutes Platform: YouTube

Eliot Prince’s framing video on the most common Claude operator confusion: “should I build a skill or a project?” — provoked by his friend James texting “Eliot, what the hell do I do with Claude Projects now?” after building five Claude Skills over a weekend. Eliot’s mental model: skills are verbs (reusable processes that run anywhere in the Claude ecosystem), projects are nouns (scoped knowledge bases with overarching instructions and chat history). The two are complementary, not competitors — the magic is the kitchen analogy (project = stocked pantry; skill = recipe) plus the operator pattern of running a skill inside a project so it pairs general process with specific knowledge.

Key Takeaways

  • The core confusion this video corrects. Operators who just learned to build Claude Skills assume Projects are now obsolete. Eliot’s thesis: the opposite — skills and projects are complementary, you should build both, and the combination supercharges every workflow.
  • Skills are verbs. Projects are nouns. Operative one-liner: skills are doing words (the repeatable process); projects are things (the knowledge container with overarching rules and history). Use the linguistic test on any prompt — if you’re asking Claude to do something repeatable, it’s a skill; if you’re giving Claude a place to know about something, it’s a project.
  • Skills run anywhere in the Claude ecosystem; projects are scoped. A Claude Skill is available in any chat, in Cowork, in Claude Code — wherever you are. A Claude Project only runs inside that one workspace. This portability difference is the biggest functional consequence of the verb-vs-noun distinction.
  • The AI Kitchen analogy — Claude is the chef/operator. Project = stocked kitchen (pantry of ingredients/information + general kitchen rules + log of dishes you’ve cooked = chat history). Skill = recipe (the dish name + step-by-step cooking method + a side drawer with reference templates/spices). Skills can be pulled from the recipe binder into any kitchen.
  • Anatomy of a skill — three sections.
    1. Name at the top.
    2. Description — short paragraph + invocation phrases (“Turn this into a blog post”, “SEO content writer”, “YouTube to blog post”). Claude scans descriptions on every prompt to decide whether to invoke. Reads invocation-first — you can also force-invoke with /skill-name from a slash command.
    3. Custom instructions — the actual prompt body (description + custom instructions + step-by-step + style rules + auditing/QA pass).
    4. Reference files (third section) — SKILL.md plus a sibling reference/ folder for templates, checklists, short sharp reference docs. Discipline rule: keep reference files lightweight (templates, checklists), not in-depth company/client knowledge — knowledge belongs in projects so the skill stays transferable.
  • Anatomy of a project — three sections.
    1. Knowledge base — files always referenced in conversations (company info, client list, ICP details, transcripts of customer calls, financial breakdowns, the deep library).
    2. Custom instructions — general house rules (“You are the operating brain of Cerno Facilities Group. We always do X. We never do Y.”). Discipline rule: instructions here are overarching guidance only, NOT specific task workflows (those belong in skills).
    3. Chat history — every conversation in this project filed together for retrieval.
  • The Skill Creator is the bootstrap. Make sure skill creator is enabled in Customize → Skills (built-in skill on every account). To build a new skill conversationally: paste a repeatable prompt and say “I want to create a Claude skill that runs an SOP anytime I need” — invoke implicitly or explicitly via /skill-creator. Eliot’s worked example: turn his “Michael Gerber SOP Writer” prompt (act like the author of The E-Myth Revisited) into a skill that auto-triggers whenever he needs an SOP. The creator builds the skill, adds extra style rules + quality checks, and saves to the library.
  • Token-cost win. Claude Projects dramatically reduce token cost (Eliot estimates “perhaps 90% in some cases”) versus uploading and re-analyzing the same knowledge files in every fresh chat. Practical implication for users hitting Claude’s 4-hour weekly cap: move recurring context into a project.
  • The flywheel: skill INSIDE project. Worked example with a fictional Kerno Facilities Group project (commercial cleaning company in Cornwall) loaded with knowledge files (legal name, finance numbers, clients, team, differentiators). Inside Kerno project, Eliot voice-dumps the company credit-card SOP — the SOP Writer skill (built outside any project) is automatically invoked because the description matches; it pairs his brain-dumped credit-card process with Kerno’s project knowledge; output is a complete SOP that would live as a knowledge file in the project for staff to query.
  • Onboarding-via-AI loop. Eliot’s concluding architecture: voice-record N business processes → run SOP-Writer skill inside the project → save SOPs back as project knowledge → staff query Claude instead of asking the boss “how do I use the company credit card?” — the AI becomes the runbook layer over the business.

The Verbs-vs-Nouns Decision Test

QuestionSkill (Verb)Project (Noun)
Where does it run?Anywhere in the Claude ecosystemInside that one project only
What does it contain?A repeatable processA library of specific knowledge
When do I reach for it?When I want a task done a certain way every timeWhen I want Claude to know about a specific business / client / workspace
Knowledge handlingTemplates + checklists only (transferable)Documents, transcripts, ICPs, deep context
InstructionsThe actual workflow (step 1, step 2, output format)House rules (“we always do X, we never do Y”)
ActivationConversational mention OR /skill-name slashOpen the project, start chatting

Implementation

  • Tool/Service: claude.ai (Pro / Max / Team plans for Projects + Skills).
  • Setup — Skills:
    1. Customize → Skills tab (left-hand panel).
    2. Verify “skill creator” is toggled ON (built-in).
    3. Start a chat: paste a frequently-used prompt + say “I want to create a Claude skill so it can run [task] anytime I need.”
    4. Skill Creator generates name + description + invocation phrases + custom instructions + (optionally) reference files.
    5. Review the draft → Save Skill → appears in skill library, available anywhere.
  • Setup — Projects:
    1. Projects (left-hand panel) → New Project.
    2. Add knowledge files: company info, client list, financials, transcripts, ICP cards, brand docs. (Eliot’s projects often have dozens of files.)
    3. Custom instructions: write overarching rules / personality / what we always and never do — not specific task workflows.
    4. Chat history accumulates per-project automatically.
  • Cost: Both skills and projects are included with Pro/Max/Team. Eliot’s claim: ~90% token-cost reduction by moving recurring knowledge into a project versus re-uploading on every chat. (Caveat: actual savings depend on knowledge size and prompt frequency.)
  • Integration notes: Skills work across Claude.ai chat, Claude Cowork, and Claude Code. Projects are claude.ai-scoped. Inside a project, conversationally-invoked skills auto-pair with project knowledge — no manual linkage.

Try It

  1. List your top 5 repeatable prompts from your prompt library or recent chat history. Pick the most-reached-for one → build it as your first skill via Skill Creator.
  2. Pick one client or department that you keep re-explaining to Claude → create a project + load its core knowledge files + write overarching instructions.
  3. Run a skill inside the project to feel the flywheel: pair the SOP-Writer-style skill with the project knowledge and watch a fully-contextualized deliverable come out.
  4. Audit your skill reference files: anything that looks like “deep company knowledge” should be moved out to a project. Keep skill references to templates / checklists / short sharp reference snippets.
  5. Save deliverables back to the project: every SOP / brand doc / strategy memo generated by a skill running inside the project should be saved as a knowledge file, building the project’s knowledge over time.

Open Questions

  • Skill description weight on auto-invocation. Eliot says “Claude always has access to descriptions and checks every prompt” — but the agent-skills-overview specifies ~100 tokens per skill metadata at Level 1. With many skills installed, how does description quality vs invocation phrase quality affect false-trigger rates?
  • Reference-files-vs-project-knowledge edge cases. Where does an SOP template that’s both a “skill reference” and “company knowledge” actually belong? Eliot’s discipline rule says keep skills transferable, but the example SOPs are deeply Kerno-specific.
  • Skill behavior inside a project’s custom instructions. When project instructions (“you are the operating brain of X”) conflict with a skill’s instructions (e.g., a generic SOP writer), which wins?

Graph View

Backlinks