Claude Projects, Skills, and Your First Claude Code Build

Full video transcript

Hello and welcome everybody to the Claude Mastery Sprint, part of our January 2026 workshop series, where we’re going to be focusing on one tool, Claude and Claude Code, to master it for our business, sales, marketing, and operations. Tuning in today with members of the GenAI University community, checking in on our wins from the week and using Claude, our questions, and making some recipes. Got a few demonstrations up my sleeve that we can roll out today. Want to say hey to everyone that’s tuning in. How’s everybody doing today, this fine Thursday, January 8th, 2026? Good to see everybody. Kevin, Assad, Ian, good to see you. Tim, Marcel, Jim, Carlos, Dr. Nikki, Jonathan — what’s going on everybody? How’s everyone doing? Let me know, drop a comment. Feel free to come off mute briefly. You doing good out there? Staying warm this winter? It’s about to get real cold here in Texas — someone’s in the UK and it’s freezing and blowing a gale, called Storm Gerrit. Hopefully Claude can help keep you warm, at least on the inside.

Thank you for the video to attach Firecrawl — a question came up a few times after the kickoff last week about how to actually connect Firecrawl MCP inside of Claude, so there’s about six minutes inside the community now, and it’s on YouTube as well — just a quick demonstration of how to get that set up. The same process can be applied to setting up MCP integrations for different servers and tools, so hopefully that gives everyone an idea of how to get these tools in with Claude.

Before diving into demonstrations, Darby asks for wins or breakthroughs from the first call, and whether anyone is stuck getting started with Claude, since the group hasn’t gone deep into Claude Code yet. He mentions he wants to share something from using Claude the previous night that he thinks will give the group inspiration for how deep they can go over the next few weeks with Claude and Claude Code — but first, check-ins.

Assad shares that he skipped the YouTube walkthrough and instead used Firecrawl’s own step-by-step guide to connect it to Claude, then took Darby’s skill and used it in Claude, getting an impressive blueprint back. His sticking point: how does that translate into Projects? He has the skills installed but isn’t sure how to apply them inside a project.

Darby answers: once skills are trained in Claude and MCP tools are set up, Projects are a way to give Claude specific knowledge blocks so it has the right context as you build things out. If you’re running an agency with several clients and put everything into one project, there’s too much irrelevant context muddying things up — you don’t want a dental client’s information mixed with a med spa client’s in the same project. Darby shows his own setup: separate projects for GenAI University, Side Hustle Live, individual client projects for a smaller mastermind group, and separate projects for different publishing efforts and apps — each with its own knowledge base. Inside an individual project you can add context (for example, “this show”) that Claude will reference directly as it builds things out for that project.

Assad clarifies his question: what do you actually put into the project to make use of the skills together with it? Darby responds that any skill in your account is applicable directly inside a project, and that if you build a blueprint — like the one Darby generated for Assad — you should upload it into the project’s files as a knowledge base so Claude understands that blueprint going forward. Each project has its own files; Darby gives an example of a project he set up with a client the day before, uploading a buyer brief, community context, rules and instructions, and brand guidelines as the file set.

Assad asks where exactly you run the skills relative to the project — inside a specific conversation thread within that project. Darby confirms: you’d start any new thread inside the project, and if you wanted to run a specific recipe for that brand, you’d say “execute [recipe] inside this project for this thing” and click it. Assad confirms he now understands: go into the project, open a thread within the project, and tell Claude to use a specific skill.

Darby adds a nuance: be very particular about which skill you want Claude to use for a given task, because members have reported Claude sometimes reaching for other skills it has access to if you aren’t explicit. Asked whether skills can be permanently assigned to a project, Darby says he doesn’t think so — skills can be toggled on or off, but you still have to specify which one to use for a given task in the moment, ideally while working inside the project that holds the relevant client or brand knowledge. He notes recipes can use variables (e.g., “execute for variable brand”) so Claude fills in the blanks with whatever brand information you provide, rather than needing a separate recipe per brand.

Darby summarizes the mental model, echoing a comment from the chat: if you use a skill in a project, the skill will use the project’s files and instructions for context — so you want the project to have that context set up first, typically starting from a buyer’s brief or blueprint. He mentions this is available in the community cookbook, and offers to run a first blueprint for anyone who submits a short blurb about their business and website, and points newcomers to the kickoff call and Claude Mastery cookbook for the basics of skills and MCP setup.

Dr. Nikki shares she spent all day (until 9pm) working in the Skills section, training Claude across three different areas to search for toxicity as a root cause of illness, generating a roughly 120-page output workbook — she’s thrilled with the capability but hasn’t touched Projects, and asks whether she should export everything into a project. Darby says she doesn’t need to export anything: once skills are set up and Claude knows the skills, the next step is opening a project and telling Claude, in a new conversation inside that project, to create something (e.g., a blueprint) using the client’s information. Nikki describes a chatbot she’s building for a health-intake use case and asks about sharing it. Darby cautions that sharing a Claude chat or project directly with outside people isn’t straightforward — you may need something like Make.com or a separate tool to sync with the skill, since giving someone access to your Claude project effectively gives them access to your account.

Darby introduces Pickaxe as an alternative: a model-agnostic AI studio tool where you build a “pickaxe” (a gated chatbot interface) that people can use without ever seeing your account, letting you review their responses and use that information downstream. He notes Pickaxe uses Claude (including Claude Opus 4.5) as one of its selectable models, but also supports ChatGPT and Gemini, so it’s model-agnostic. He clarifies this isn’t the only path — technically capable users could build their own custom interface — but for most people, a tool like Pickaxe (or a fully custom build) solves the problem of not wanting to hand out access to your own Claude account.

A member asks about brand-guide adherence: their brand guide made Claude’s copy too soft and non-aggressive, flagging language as violating “fear-based/fear-mongering” restrictions even when the founder story itself involved visceral, fear-based content. The member created their own more aggressive custom instructions rather than following the stated brand guide literally, and asks whether that’s the right approach versus keeping the official guide and telling Claude via custom instructions to be less strict. Darby recommends testing it directly: custom instructions are the place to define tone, structure, words to avoid, and words to favor — clearly defined custom instructions influence everything in a project, so testing how they shift output is the way to find the right balance rather than guessing. He acknowledges models can behave inconsistently month to month (“some months Claude is being super woke,” other months looser), so consistent reinforcement in prompts (reminding Claude to follow its instructions) may be necessary regardless of how the instructions are written.

Bob asks whether his custom GPTs, if brought into Claude, would count as skills. Darby says largely yes — a custom GPT’s instructions are essentially a skill/recipe, but a skill should ideally be used within a project so it has access to the same kind of contextual knowledge the custom GPT was built around. Bob describes a podcast-support custom GPT with reference documents and formatting rules (show notes, intros, social posts) and asks how that maps onto Claude’s terminology — specifically, when to use a project versus a skill. Darby reiterates the GenAI University vs. Side Hustle example: each is its own project with its own brand voice, tone, color schemes, dos and don’ts, and negative keywords, plus its own set of conversation threads (e.g., a new thread per new video). Skills executed inside that project’s thread automatically reference the project’s knowledge — for example, an outreach-sequence skill for Side Hustle sponsorships can pull Firecrawl to research prospects and then write emails referencing the project’s brand knowledge, without Darby re-pasting brand details each time. Running the same skill inside the GenAI University project instead would produce structurally similar output but with a different value proposition, because the underlying project knowledge differs even though the skill framework is the same.

Bob restates his understanding: the podcast becomes a project, and intros, social posts, and show notes could each be separate skills operating under that project’s context — plus a separate project for advisory work, and another for other ventures. Darby confirms, and adds that keeping projects distinctly separate avoids context muddling. He also addresses managing chat continuity: in his own workflow, he’ll upload a new transcript into a new thread inside a project and tell Claude explicitly to work only with that transcript, rather than referencing prior videos — noting Claude hasn’t caused him much cross-context confusion unless he explicitly asks it to recall something from another video. He flags that account-level memory (as opposed to project files) can influence every chat more broadly, and that Claude’s Capabilities/Memory Preferences settings let users review, search, and toggle what’s remembered if that becomes a problem — similar to issues some users reported with ChatGPT’s cross-chat memory.

A question comes in about parallel/multi-agent work: whether Claude Code can be told to spin up two or three agents to work in parallel from one prompt. Darby says he’s heard this is possible but hasn’t tested it directly himself in this thread; he noticed Claude Code letting him queue up multiple follow-on instructions without waiting for each to finish sequentially (unlike normal chat), but he hasn’t specifically tested defining sub-agents up front. He says this is something the group will explore together over the coming weeks.

Darby then walks through the Claude Code build he promised. It started with an email from Ethan Mollick (a researcher/writer he follows for AI commentary) describing a prompt that, when given to Claude Code, spent about an hour and a half developing a web-based software idea meant to earn $1,000/month with no coding knowledge required — Mollick’s Claude arrived at an idea around selling prop packs. That got Darby thinking about a physical-world version of the same exercise, partly inspired by a conversation with his wife about wanting to build more in-person, screen-free experiences amid a broader “back to analog” trend (VHS tapes, etc.).

Darby’s process: he opened a Claude tab inside his GenAI University project and gave it Mollick’s original prompt, but redirected it toward a physical-world product idea — something people could touch and interact with, priced at a $1,000+ base level, with a mockup design, built around stimulating creative/sensory engagement, and structured as a crowdfunding campaign. Claude began processing the idea and drafting output, but Darby stopped it before it went further, clarifying that his actual goal was to get a complete prompt written in Claude first, then hand that prompt to Claude Code — noting that even when moving to tools like Lovable to build a landing page, getting the instructions fully fleshed out in Claude first makes downstream execution more efficient.

Before starting in Claude Code, Darby created a new GitHub repository; Claude named the resulting concept “Kindred.” He describes stopping Claude mid-response because it seemed like it was going to generate the full output directly in that chat rather than producing an actual seed prompt meant for Claude Code’s agentic build process — he clarified he needed the full scaffolding and infrastructure defined first, “architect mindset,” before any code got written. Claude then asked clarifying questions about the core experience (a gathering kit, a one-time event, a visitable object), and Darby fed it more detail about the product concept and the $1,000 price target. Claude then produced a “seed prompt” — at that point options included publishing it as an artifact, downloading as a PDF, or adding it to the project; Darby copied the seed prompt directly into Claude Code.

In Claude Code, he connected the GitHub repository he’d created, pasted in the full instruction set, and let Claude Code run agentically, pushing code to a branch (not yet merged to main). He estimates the whole session — from idea to output — took under two hours, with the core Claude Code build itself taking roughly 30 minutes. He used Gemini to generate a prototype image based on the instructions Claude had produced, uploaded a few image iterations into the mix, and gave feedback back and forth. Once satisfied, he downloaded the resulting project as a zip file from GitHub and deployed it by dragging the zip folder into Netlify (a free-tier account, manual deploy) to get a live, shareable link — noting the link may change later since he isn’t maintaining it as a permanent project.

He emphasizes that being able to take an idea from zero to a shareable, deployed prototype in roughly 30–90 minutes is valuable for deciding whether an idea is worth further investment of time and resources, before bringing in developers for full production work (which he does for larger client projects).

A member (Picos) asks what prompt was used to generate the seed prompt. Darby scrolls back and shows that he started by giving Claude the Mollick-style prompt, then explicitly redirected it toward the physical-product concept and clarified what he did not want (a purely digital/web product) — being clear about both what he wanted and what he was ruling out.

Picos also asks how Darby knew Claude wasn’t yet using Claude Code’s full agentic capabilities, prompting him to pause and redirect it. Darby explains that at that point, the work was still happening in the regular Claude (Opus 4.5) interface, not Claude Code — a different dashboard/environment — so even though Opus 4.5 is itself agentic, it isn’t Claude Code, and he wanted the scaffolding-first architecture before any code got written. He reads back the prompt he actually typed in the moment (while multitasking watching TV), instructing Claude to initiate agentic decision-making to produce a full production-ready prototype sales page and campaign with interactive elements — noting he later removed one interactive element (letting users move a 3D box around) and replaced it with a static image because it didn’t work as intended.

Asked whether the earlier Claude chat was used only for architecture/planning and the Claude Code prompt, Darby confirms yes — that chat’s job was solely to arrive at the seed prompt, which he then took to Claude Code, set up a repository for, and pasted in.

Another question: would Claude Code have handled all of this on its own if given enough context up front, without the separate planning step in Claude chat first? Darby calls it a great question worth testing, but says he hasn’t tried giving Claude Code a rough prompt directly without the intermediate planning stage — his preference is to refine the full instruction set in a chat interface first (similar to his workflow before Claude Code existed, using Claude to write website copy and creative direction before handing it to Lovable), because that produces a more complete one-shot instruction for Claude Code to execute in 15–20 minutes, rather than working out the plan interactively inside Claude Code itself.

Darby adds that as he gets more comfortable with GitHub — including handling things like API keys securely — he expects to rely on Claude Code more heavily, translating quick 0-to-1 prototypes into fuller production builds with his team. Someone asks whether it’s possible to tell Claude Code to spin up two or three agents to work a prompt in parallel; Darby repeats that he’s heard this is possible but hasn’t tested it specifically, though he did notice Claude Code letting him queue multiple instructions (“also do this, also do this”) without waiting for each to complete sequentially, unlike a normal Claude chat. A member (Bruce) notes in the chat that using Claude Code via the command line offers a “plan mode” that plans the whole project before switching to execute mode.

A member describes having built out a large set of skills and asks: do you then take a skill and put it into code to build something, or does it just live in Skills — and when do you use Claude Code to build a website? Darby says this is an open question from the first call he doesn’t have a full answer to yet — how to connect skills to a chatbot or app you’re building. He distinguishes two paths: (1) use Claude Code to build your own custom platform, which he generally wouldn’t recommend unless you want to manage and maintain real technical infrastructure, versus (2) for most business/marketing/content work, there often isn’t a need to build and deploy a full custom app — an Artifact can hold a lot of the code for a mini app, but a full custom app makes sense only if you have a genuine larger vision for it.

He then demonstrates Pickaxe again in more detail as the answer for people who want an easy way for clients to interact with a tool (fill out a chatbot, get a report) without managing the technical build themselves. He shows his own Pickaxe studio, where different GPTs are configured to use either Claude or OpenAI models, gated behind a free-credit system, with one example being a buyer-brief blueprint generator skill wired into the studio. Behind each pickaxe is a recipe/skill Darby trained (in Claude), including a full prompt framework drawn from his own written material; users never see the underlying prompt or need direct access to his Claude account. Pickaxe also supports additional actions (PDF generation, Google search, and other integrations), similar in spirit to giving Claude MCP integrations. Darby is candid that his demo buyer-brief tool wasn’t correctly reading the test website in that moment (a live glitch), but reiterates the broader point: this class of problem — wanting to gate access, not give away your prompt/IP, and track client responses — is what a tool like Pickaxe solves, and that it’s reasonable to start by building and tightening recipes/skills in Claude first, then decide later how to gate access to them for other users (a topic the group will cover further).

A member (Bruce) notes in the chat that Pickaxe supports setting up one studio per client, storing each client’s brief so it’s referenced automatically; Darby confirms that’s possible depending on the account tier — cloning studios per client while reusing the same underlying pickaxe tools and recipes.

Closing out, a member jokes about a “Darby AI video clone,” which Darby denies exists (he confirms he’s speaking live, using voice-to-text rather than typing). He wraps the session thanking everyone for their questions and wins, encourages people to share progress, questions, and roadblocks in the community between sessions, and confirms the next Claude Mastery session is Tuesday at 10:00 a.m., same time and place.