--- name: robot-assistant-assembler description: Assembler for the Robot Assistant Field Guide Starter Kit. Each video module asks personalized questions and customizes the corresponding Starter Kit template. By Video 10, the viewer has a complete, personalized system. status: active category: content triggers: - run the assembler - assembler for video - starter kit builder - build video - robot assistant assembler - field guide assembler dependencies: [] updated: 2026-02-23 --- The assembler for the Robot Assistant Field Guide Starter Kit. ## Purpose The Starter Kit provides template files (CLAUDE.md, starter skills, skill index, build log) that the viewer copies into their workspace folder. The assembler personalizes those templates as the viewer works through the 10-part Starter Video Series. Each video ends with an assembler step. The viewer triggers "Run the Assembler for Video [N]" and the assembler: 1. Asks targeted questions about the viewer's work, tools, and preferences 2. Customizes the corresponding Starter Kit template based on their answers 3. Connects it to everything customized in prior videos 4. Updates the skill index and CLAUDE.md as needed By the end of the series, every Starter Kit template has been personalized to the viewer's actual work. --- ## How to Trigger The viewer says one of: - "Run the Assembler for Video 3" - "Assembler for Video 4" - "Build Video 6" The number determines which module runs. Videos 1, 2, 8, and 10 have no assembler step (Video 8 covers file naming differently; Video 10 is a system tour with no build step). --- ## Assembler Behavior Rules 1. **Ask questions conversationally.** Don't dump all questions at once. Ask 2–3 at a time, respond to the answers warmly, then ask the next batch. The goal is guided conversation, not a form. 2. **Customize from answers.** The Starter Kit provides template files. The assembler's job is to replace generic placeholder content with specifics from the viewer's answers. After customization, no template boilerplate should remain — every section should reflect the viewer's actual work. 3. **Connect to prior work.** Each module should reference and integrate with what was customized in earlier modules. Video 5 updates the index to include the skill from Video 4. Video 7 customizes the briefing to use the MCP connections from Video 6. 4. **Explain what you built.** After creating files, briefly explain what was created, where it lives, and how it connects to the system. Keep it concise. 5. **Save a build log.** After each module, append a summary to `_build-log.md` in the viewer's skills directory. This tracks what's been built, what answers were given, and what's still pending. 6. **Preferences, not writing voice.** When asking about style preferences, focus on how the viewer wants the assistant to behave, format output, and communicate — NOT on teaching the assistant to write in the viewer's voice. Writing voice is a workshop topic. 7. **File locations.** All skills go in the viewer's skills directory. CLAUDE.md goes in the workspace root. The build log goes alongside the skills. --- ## Module Reference ### Video 3: Setting Up Claude Cowork **Starter Kit template:** `CLAUDE.md` **What it customizes:** The template CLAUDE.md with the viewer's identity, preferences, and rules **Questions to ask:** - What's your first name? - In one sentence, what do you do for work? (e.g., "I'm a freelance graphic designer," "I run a small marketing agency," "I teach high school English") - How do you prefer the assistant to communicate with you? (e.g., casual and brief, detailed and thorough, somewhere in between) - Are there any specific preferences you already know you want? (e.g., "always use bullet points for lists," "call me by my first name," "keep responses under 200 words unless I ask for more") - Do you have any hard rules — things the assistant should never do? (It's fine if the answer is "none yet") **What to customize:** - Update the Starter Kit's `CLAUDE.md` in the workspace root: - Replace the "About Me" placeholder with the viewer's name, role, and work description - Replace the "Preferences" placeholder with their communication style and format preferences - Replace the "Rules" placeholder with their hard constraints - Leave the "Skills" section pointing to the skill index (already set up in the template) - Leave the "Connected Tools" section for Video 6 **Build log entry:** Record the viewer's name, role, and key preferences. --- ### Video 4: Your First Skill **Starter Kit template:** `Skills/meeting-notes.md` **What it customizes:** Replaces or customizes the starter meeting-notes skill with a skill tailored to the viewer's most common repetitive task **Questions to ask:** - What's one type of task you do repeatedly at work? Something you do at least a few times a week. (Examples: summarize meetings, draft emails, write project updates, create invoices, prepare lesson plans) - When you do that task well, what does the result look like? Walk me through the ideal output — what sections does it have? How long is it? What format? - Are there any specific rules for this type of work? Things that should always be included, or never appear? - Can you give me a quick example of what a good result looks like? Even a rough sketch helps. (If the viewer can't, that's fine — work from the description.) **What to customize:** - If the viewer's most common task is meeting-related, customize the existing `Skills/meeting-notes.md` template with their specifics. - If their most common task is something else entirely, create a new skill file named after the task (kebab-case, e.g., `project-update.md` or `email-draft.md`) and keep the meeting-notes template as a bonus starter skill. - The customized or new skill should include: - Name and description - Trigger phrases (suggest 3–4 natural language phrases the viewer would actually say) - Clear step-by-step instructions based on the viewer's description of ideal output - Format specifications drawn from their answer - Constraints from their rules - An example if they provided one (or a note to add one after testing) **Build log entry:** Record the skill name, what it does, and the trigger phrases. --- ### Video 5: The Skill Index **Starter Kit template:** `Skills/_skill-index.md` **What it customizes:** Updates the template skill index with all skills built so far and the viewer's trigger phrases **Questions to ask:** - Are there other types of work you think you'll want skills for soon? (Just names — we won't build them now, but we'll reserve space in the index.) - Do you prefer your assistant to always check the index before starting any task, or only when it's not sure which skill to use? **What to customize:** - Update the Starter Kit's `Skills/_skill-index.md`: - Update the Quick Trigger Reference table with all skills built so far (the customized/new skill from Video 4 plus any remaining Starter Kit skills) with the viewer's trigger phrases - Place skills in the right category sections, add placeholder categories for planned skills - Add any future skills the viewer mentioned wanting to build - Verify CLAUDE.md references the skill index (should already be set from the template, but confirm). **Build log entry:** Record the index structure and any planned future skills. --- ### Video 6: Connecting to Your World (MCP) **Starter Kit template:** `Skills/drafts-inbox.md` **What it customizes:** Customizes the Drafts inbox skill for the viewer's workflow, documents MCP connections in CLAUDE.md **Questions to ask:** - Which apps do you use most for your work? (Calendar, email, notes, tasks, messaging, etc.) - Do you use Drafts app? (If yes, great — we'll set up the cowork inbox. If no, recommend it and explain why.) - Of the apps you mentioned, which one would be most useful for your assistant to access first? - Do you use Siri or voice input for quick capture during the day? **What to customize:** - Update CLAUDE.md "Connected Tools" section with: - List of the viewer's key tools and which MCP connectors to look for - The first priority connector to set up - If using Drafts: document the cowork inbox pattern — tag "cowork" for items meant for the assistant, check inbox at session start, archive when processed - Brief security note: what each connector can/can't do - Customize the Starter Kit's `Skills/drafts-inbox.md` based on the viewer's capture habits and workflow (if using Drafts). If not using Drafts, note the alternative and keep the template for reference. - Update the skill index with any changes to the drafts-inbox skill triggers. **Build log entry:** Record connected tools, first priority connector, and whether Drafts inbox was set up. --- ### Video 7: Building Workflows **Starter Kit templates:** `Skills/weekly-review.md` (or a custom workflow skill), `Skills/daily-briefing.md`, `Skills/shutdown-routine.md` **What it customizes:** Builds a personalized weekly review workflow (or an alternative multi-step workflow), then personalizes the daily briefing and shutdown routine skills This is the biggest assembler step. The video teaches workflows using the weekly review as the centerpiece, then the assembler also builds the viewer's daily system (briefing + shutdown) since those are the most immediately useful workflow-style skills. **Questions to ask:** *Part 1 — Weekly review workflow (the video's recommended first workflow):* - The video showed David's weekly review workflow. Let's build yours. First: do you currently do any kind of weekly check-in or planning session? Even an informal one? - What would you want to know at the start of a weekly review? (What happened this week? What's coming next week? How your projects are going? How you spent your time?) - Which of your connected tools should the review pull from? (Calendar, tasks, notes, email?) - When the review is done, what should the output look like? (A formatted summary? A simple list of priorities? A journal-style reflection?) - Should the assistant walk you through it conversationally (asking questions, you respond), or gather everything and present a summary for you to review? *If the viewer prefers a different workflow:* - If weekly review isn't the right first workflow for you, think about a multi-step task you do regularly — something that takes 3 or more steps. What is it? Walk me through the steps. - For each step: could your assistant handle this with the skills and connections it already has? Or would it need something new? *Part 2 — Daily briefing:* - Now let's build your daily system. What do you want to know at the start of each day? (Calendar? Weather? Tasks? Projects? Deadlines? News?) - Which of your connected tools should the briefing pull from? - How do you want it formatted? (Quick text summary? Formatted sections? PDF?) - Is there anything personal you'd want included? (A quote, a reminder, a health note?) *Part 3 — Shutdown routine:* - Do you want an end-of-day routine? (Some people do, some don't. Both are fine.) - If yes: what should it review? (What happened today? What's still open? What's tomorrow look like?) - Should it produce output (a summary document) or just walk you through verbally? **What to build:** *Workflow:* - **Weekly review (default path):** Create a `Skills/weekly-review.md` skill with: - Trigger phrases: "weekly review," "how'd my week go," "Sunday review," "plan my week" - Gather step: what data sources to pull from (based on their connected tools from Video 6) - Review step: what to scan — completed tasks, open items, calendar events - Reflect step: 3–5 questions tailored to what the viewer cares about (projects? habits? relationships? goals?) - Output step: format and destination for the weekly summary - Note whether the workflow is fully automated, semi-automated, or conversational - **Alternative workflow:** If the viewer chose a different workflow, build it as a skill file or document it as a workflow entry in the skill index, showing the chain (skill A → review → skill B → output). - If the workflow needs new lightweight skills: create simple skill files for the missing steps, add them to the index. *Daily system:* - Update the Starter Kit's `Skills/daily-briefing.md` with: - Trigger: "run my briefing" / "morning briefing" / "what's my day look like" - Instructions tailored to the viewer's requested sections - Data sources matching their connected tools - Format matching their preference - Any personal touches they requested - If the viewer wants a shutdown routine, update the Starter Kit's `Skills/shutdown-routine.md` with: - Trigger: "run my shutdown" / "end of day" / "close out the day" - Review steps based on their answers - Output format matching their preference *Shared updates:* - Update CLAUDE.md if any workflow requires new standing instructions. - Update the skill index with all new skills and their triggers. **Build log entry:** Record the workflow type (weekly review or custom), its steps, which skills and data sources it uses, and whether it's automated, semi-automated, or conversational. Also record briefing sections, data sources, format, and whether shutdown was set up. --- ### Video 9: Testing and Growing — System Diagnostic **Starter Kit template:** (no template — generates a new `system-health-report.md`) **What it builds:** A System Health Report auditing the current state of the viewer's customized system **This module is different — it's a diagnostic, not a questionnaire.** **What to do:** 1. Read the viewer's skill index. Check that: - Every skill listed in the index has a corresponding file - Every skill file in the skills directory has an index entry - Trigger phrases are unique (no collisions between skills) - Dependencies are noted and accurate 2. Read CLAUDE.md. Check that: - It references the skill index - Connected tools are documented - Naming conventions and folder structure are documented - Preferences are present and clear 3. Review the build log for completeness. 4. Produce a **System Health Report** that includes: - What's working well (skills, index entries, connections that are properly set up) - What's missing or incomplete (skills without index entries, undocumented tools, empty sections) - Suggestions for the next skill to build (based on the viewer's work, connected tools, and gaps in coverage) - A "maintenance checklist" — things to check weekly as the system grows 5. Save the report as `system-health-report.md` in the viewer's workspace. **Build log entry:** Record the diagnostic findings and recommendations. --- ## Build Log Format The build log (`_build-log.md`) tracks progress across all videos: ```markdown # Robot Assistant Field Guide Build Log ## Video 3 — CLAUDE.md **Date:** [date] **Name:** [viewer's name] **Role:** [what they do] **Key preferences:** [communication style, format preferences, rules] **Files created:** CLAUDE.md --- ## Video 4 — First Skill **Date:** [date] **Skill:** [name] **Purpose:** [what it does] **Triggers:** [trigger phrases] **Files created:** [skill filename] --- [continues for each video module] ``` --- ## Notes for Future Development - The assembler covers Videos 3–7 and 9. Videos 1, 2, 8, and 10 have no assembler step (Video 8 handles file naming differently; Video 10 is a system tour). - Video 7 is the biggest assembler step — it builds three skills (weekly review or custom workflow, daily briefing, shutdown routine). Consider breaking it into two conversation passes if it feels too long. - The "preferences" questions in Video 3 deliberately avoid writing voice. If a viewer asks about making the assistant write like them, acknowledge it's a great idea and point them toward the Voice and Style Workshop. - Each module should take 5–10 minutes of conversation. If it's taking longer, simplify. The goal is a functional first version, not a perfect one. - The system diagnostic in Video 9 should be genuinely useful, not performative. If there are real gaps, say so constructively. - Future workshops will extend the assembler pattern: "Run the Content Workshop Assembler" could build a full content pipeline skill set through guided questions.