Claude Fundamentals Before Cowork or Code

Full video transcript

Hello and welcome everybody to the Claude Mastery Sprint, part of the January 2026 workshop series focused on one tool, Claude and Claude Code, to master it for business, sales, marketing, and operations. This session checked in with members of the Gen AI University community on wins from the week, questions using Claude, and a few demonstrations.

A member mentioned appreciating an earlier video on connecting Firecrawl to Claude. That six-minute demonstration is available inside the community and on YouTube, showing how to set up MCP integrations, a process that can be applied to connecting different MCP servers for many other tools.

Before diving into demonstrations, the group checked in on breakthroughs, wins, and points of confusion from the first call of the sprint.

One member, Assad, shared that after following Firecrawl’s own step-by-step setup guide and applying a shared skill, Claude generated a complete blueprint. His question was how to then use that blueprint inside a project, since skills and projects were the two concepts covered the previous week.

The explanation: once skills are trained into Claude and MCP tools are set up, projects are the way to give Claude specific knowledge blocks so it has the right context as work progresses. For an agency working with multiple clients, keeping each client’s information in a single shared project risks too much irrelevant context bleeding together — a dental client’s data mixing with a med spa client’s data, for example. Separate projects are kept for separate ventures: Gen AI University, Side Hustle Live, and individual projects for each client or contact in a smaller group. Each project carries its own knowledge base — for instance, a buyer brief, community context, rules and instructions, and brand guidelines uploaded as files.

Assad asked specifically what to upload: should a generated blueprint go into the project’s files as a knowledge base to build on? The answer was yes — a blueprint generated from a skill can be uploaded into the project’s files so Claude references it as part of its memory going forward.

On where to actually run a skill: work happens in a specific conversation thread inside the project that holds the relevant knowledge. Starting a new thread inside that project and explicitly asking Claude to execute a specific skill (for example, “execute market sauce for this brand”) runs the skill with the project’s files in context. Being explicit about which skill to use matters, since Claude can sometimes reference other available skills unintentionally if not directed. It is not currently possible to permanently assign or restrict specific skills to a project, but skills can be toggled on or off for a given session.

A useful summary offered in the chat, confirmed as accurate: if a skill is used inside a project, the skill will use the project’s files and instructions for context. That is why it helps to have at least a starting knowledge base — such as a buyer’s brief or blueprint — in a project rather than starting from a completely blank one. Members who have not yet filled out their business blurb were invited to submit a short description so a market-sauce blueprint could be generated as a starting point. A cookbook of recipes and a walkthrough of the basic MCP setup for Claude are available in the community classroom under the Claude Mastery series.

Another member, Nikki, described building extensively in skills without touching projects at all, training Claude across three areas to research toxicity as a root cause of illness and generating a large output workbook. Her question was whether that work needed to be exported into a project. The answer: nothing needs to be exported. Once skills are set up and Claude has access to them, the next step is opening a project and, within a new conversation there, asking Claude to apply the trained skill to that project’s context (for example, building a blueprint for a specific client). For a chatbot-style intake tool intended to be shared outside her own Claude account, sharing a Claude project chat directly with others was flagged as a likely limitation — Claude itself suggested she would need something like Make.com or another external tool to sync with the skill.

This led to a broader discussion of tools like Pickaxe, described as a model-agnostic AI studio that lets a business owner build gated chatbots, give clients access without sharing the underlying Claude account, and review client responses. Pickaxe tools can be configured to run on Claude (including selecting a specific model such as Opus 4.5), ChatGPT, or other models. The tradeoff: building and maintaining a fully custom coded version of this kind of tool is possible with Claude Code but requires significantly more technical setup and ongoing maintenance than most non-technical users want to take on.

A brand-guide question came up: a member found Claude’s copy too weak and vague after applying a formal brand guide, and Claude cited “fear-mongering” language restrictions that did not match the brand’s own founder story. After pointing this out, Claude agreed the restriction did not make sense. The member had started creating a separate, more aggressive custom version of the guide and asked whether that was necessary, or whether the original brand guide could be shared as-is with custom instructions added to loosen tone restrictions. The recommendation was to test both, but to focus on setting clear custom instructions at the project level — preferred language, structure, words to avoid, words to favor — since those instructions influence every output in the project going forward, without needing to be repeated in each new chat. It was noted that even with instructions in place, Claude can inconsistently follow them over time and may need to be reminded.

A question about bringing existing custom GPTs into Claude: a custom GPT’s system instructions are, for the most part, equivalent to a Claude skill. The recommendation was to treat a custom GPT’s instructions as a skill and use it within a project so the project supplies the same background knowledge the custom GPT previously had attached, noting some differences in how knowledge files attach to skills versus custom GPTs.

To illustrate the project/skill relationship further, an example was given contrasting a media brand project and a comedy show project, each with distinct brand voice, tone, color schemes, and instructions stored as project knowledge. Running the same email-outreach skill from inside each project produces output tailored to that project’s specific context and value proposition, while still following the skill’s overall framework. It was recommended to keep projects for genuinely separate ventures strictly separate to avoid context muddling, and to start a new thread within a project for each new piece of work (such as a new YouTube video) rather than adding every new asset directly into the project’s permanent knowledge base, to avoid irrelevant content bleeding into later work.

On Claude’s account-level memory settings (separate from project files): under capabilities and memory preferences, memory and memory-search-in-chat settings can be toggled on or off. Because Claude’s general memory can influence conversations more broadly than intended, being deliberate about what gets saved to memory (versus supplied per-thread) was recommended — for example, keeping a brand tagline in memory if it needs to be referenced constantly, but explicitly telling Claude in a given thread to reference only the current transcript and not other prior conversations when that is the intent.

A brief note on artifacts: anything Claude generates as a document, calculator, or small interactive app is technically an artifact, and these can be saved to the account, published as a shareable link or embed code, or added into a project as a knowledge reference. A live example was built during the call — an ROI calculator artifact illustrating the value of being a vendor at an event — and published as a shareable link. A follow-up question about uploading existing Google Docs (a campaign structure template and a daily campaign structure doc) as “artifacts” was clarified: those reusable templates or frameworks are better treated as skills, not artifacts, since a skill is what lets Claude apply that framework repeatedly to new campaign inputs.

The core demonstration of the session was a walkthrough of turning an idea into a deployed prototype using Claude and Claude Code, prompted by an email from Ethan Mollick describing a similar workflow where he asked Claude to autonomously generate and build a web-based startup idea end to end. Rather than following that exact approach, the presenter asked Claude for a physical-world product idea instead of a web-based one, wanting something people could interact with in person, priced at a $1,000+ base level, with a prototype and crowdfunding campaign concept.

The key sequencing decision: when Claude started generating the concept output directly in chat, the response was paused mid-way to explicitly request a structured prompt/instruction set instead, specifically because generating everything directly in a standard Claude chat does not use Claude Code’s fuller agentic build capabilities. After providing more direction — treating the task with an “architect mindset,” needing full scaffolding and infrastructure before any code — Claude asked clarifying questions about the core experience, and after further back-and-forth produced a complete “seed prompt” ready to hand off.

Before starting in Claude Code, a new GitHub repository was created; Claude suggested naming the project “Kindred.” The seed prompt/instructions were then pasted into Claude Code, connected to that GitHub repository via the left-hand panel in Claude’s interface. From there, Claude Code built out the project files and pushed the code to a branch in the connected repository (not yet merged to main at the time of the demo). Gemini was used separately to generate prototype images, which were uploaded back into the flow for a few rounds of refinement — including removing one planned interactive element in favor of a static image. Total time invested was under two hours, with the Claude Code portion itself taking about 30 minutes.

Once Claude Code finished, the resulting project was downloaded as a zip file and deployed by manually dragging that zip into a free Netlify account (no paid plan required), producing a live, shareable web link. The presenter described this as a way to test whether an idea is worth pursuing further — for example, sharing the resulting landing page and asking whether people would pay $1,000 to be a founding member before committing to sourcing materials or building anything physical.

Questions from participants covered several follow-up points. Asked how it was clear Claude was not yet using Claude Code’s full agentic capabilities before the prompt was refined, the presenter noted this was based on understanding that the two are different dashboards/systems, though acknowledged not having tested that distinction rigorously. Asked whether giving Claude Code the full context directly (skipping the separate planning step in Claude chat) would work just as well, the presenter said this was worth testing but had not been tried directly, and that they personally prefer refining instructions in a Claude chat interface before handing off to Claude Code or another tool such as Lovable. On running multiple sub-agents or parallel work streams inside Claude Code, the presenter had heard this was possible (queuing multiple instructions that Claude Code would execute in sequence without waiting for confirmation between each) but had not tested a formal sub-agent setup themselves. A participant noted that Claude Code’s command-line interface has a plan mode that plans an entire project before switching to execute mode.

A closing question asked about the relationship between skills and building an actual chatbot or website: should a skill be deposited into code to create something, or does it stay housed as a skill? The response distinguished two paths: using Claude Code to build a fully custom coded platform (more control, more technical maintenance), versus using a platform like Pickaxe to wrap an existing skill/recipe in a simple, gated, shareable chatbot interface without managing custom code. A live example was shown inside an existing Pickaxe studio, where a buyer’s-brief-blueprint tool was demonstrated: users log in, the tool analyzes their website, and it applies a skill (an instruction set built largely using Claude) to generate a structured output, with the option to select which underlying AI model powers each tool. The general recommendation was to build and refine recipes and skills inside Claude first, get them working well, and only then decide whether a client-facing wrapper like Pickaxe is needed — since giving external users direct access to a personal Claude account is not a workable solution for client-facing tools.

The session closed with the presenter noting ongoing wins to share in the community between calls, and confirming the next session would take place the following Tuesday at 10:00 a.m., continuing the Claude Mastery series.