From 55d9edc735d91456ccd0602460998149a2fb49c5 Mon Sep 17 00:00:00 2001 From: Connor Rhodes Date: Mon, 30 Mar 2026 20:17:19 -0600 Subject: [PATCH] Initial commit: assistant skills and notes --- _build-log.md | 17 ++ _skill-index.md | 83 +++++ claude-web-form-info.md | 57 ++++ daily-briefing.md | 62 ++++ drafts-inbox.md | 51 ++++ file-organizer.md | 62 ++++ get access to verkada gov support.md | 1 + linkedin-post.md | 50 +++ meeting-notes.md | 54 ++++ prep for tech screen interview.md | 24 ++ ...onal-developement-expense-business-case.md | 23 ++ robot-assistant-assembler.md | 286 ++++++++++++++++++ se note.md | 61 ++++ shutdown-routine.md | 61 ++++ weekly-review.md | 74 +++++ 15 files changed, 966 insertions(+) create mode 100644 _build-log.md create mode 100644 _skill-index.md create mode 100644 claude-web-form-info.md create mode 100644 daily-briefing.md create mode 100644 drafts-inbox.md create mode 100644 file-organizer.md create mode 100644 get access to verkada gov support.md create mode 100644 linkedin-post.md create mode 100644 meeting-notes.md create mode 100644 prep for tech screen interview.md create mode 100644 professional-developement-expense-business-case.md create mode 100644 robot-assistant-assembler.md create mode 100644 se note.md create mode 100644 shutdown-routine.md create mode 100644 weekly-review.md diff --git a/_build-log.md b/_build-log.md new file mode 100644 index 0000000..35b1959 --- /dev/null +++ b/_build-log.md @@ -0,0 +1,17 @@ +# Robot Assistant Field Guide Build Log + +This file tracks your progress through the Starter Video Series. Each time you run the assembler for a video, it records what was built, what questions were asked, and what answers you gave. This serves as both a record of your system and a debugging reference. + +--- + +[The assembler will add entries here as you work through the videos.] + +--- + +## Video 3 — CLAUDE.md +**Date:** 2026-03-29 +**Name:** Connor +**Role:** Solutions engineer at a physical security company +**Key preferences:** Casual and direct with Connor; polite and consultative with outside parties. Concise by default. +**Rules:** Never use em-dashes (use commas or colons instead); never use the word "delve"; always ask before editing existing files +**Files updated:** AGENTS.md diff --git a/_skill-index.md b/_skill-index.md new file mode 100644 index 0000000..a3f6144 --- /dev/null +++ b/_skill-index.md @@ -0,0 +1,83 @@ +--- +name: skill-index +description: Master index of all skills in your robot assistant system. Your assistant reads this to decide which skill to use for a given request. +--- + +# Skill Index + +**Your assistant should read this file when processing any request.** This is the routing table — it maps what you say to which skill handles the job. + +--- + +## Quick Trigger Reference + +| You say... | Skill to use | +|------------|-------------| +| "summarize meeting," "meeting notes," "what happened in the meeting" | **meeting-notes** | +| "check my Drafts inbox," "process my inbox," "what's in Drafts" | **drafts-inbox** | +| "run my briefing," "morning briefing," "what's my day look like" | **daily-briefing** | +| "run my shutdown," "end of day," "close out the day" | **shutdown-routine** | +| "weekly review," "how'd my week go," "plan my week," "Sunday review" | **weekly-review** | +| "organize these files," "sort this folder," "clean up my files," "rename these" | **file-organizer** | +| "run the assembler for video [N]," "assembler for video [N]," "build video [N]" | **robot-assistant-assembler** | + +--- + +## Skills + +### Meeting Notes +**Purpose:** Takes raw meeting notes and produces a clean, formatted summary with decisions, action items, and follow-ups. +**Triggers:** "summarize meeting," "meeting notes," "what happened in the meeting" +**File:** `Skills/meeting-notes.md` +**Dependencies:** None + +### Drafts Inbox +**Purpose:** Reads all Drafts tagged "cowork," processes each item, and archives when done. +**Triggers:** "check my Drafts inbox," "process my inbox," "what's in Drafts" +**File:** `Skills/drafts-inbox.md` +**Dependencies:** Drafts MCP connector + +### Daily Briefing +**Purpose:** Produces a morning overview of your day — calendar, tasks, deadlines, and anything else you need to know. +**Triggers:** "run my briefing," "morning briefing," "what's my day look like" +**File:** `Skills/daily-briefing.md` +**Dependencies:** Calendar MCP connector (when set up) + +### Shutdown Routine +**Purpose:** Reviews the day, checks what's outstanding, and previews tomorrow. +**Triggers:** "run my shutdown," "end of day," "close out the day" +**File:** `Skills/shutdown-routine.md` +**Dependencies:** None + +### Weekly Review +**Purpose:** A weekly check-in workflow that reviews the past week, scans what's ahead, and produces a summary with priorities. +**Triggers:** "weekly review," "how'd my week go," "plan my week," "Sunday review" +**File:** `Skills/weekly-review.md` +**Dependencies:** Calendar MCP connector (when set up) + +### File Organizer +**Purpose:** Scans a folder for files that don't match your naming conventions, proposes renames and folder placement, and executes on approval. +**Triggers:** "organize these files," "sort this folder," "clean up my files," "rename these" +**File:** `Skills/file-organizer.md` +**Dependencies:** Naming conventions documented in CLAUDE.md + +### Robot Assistant Assembler +**Purpose:** Personalizes the Starter Kit as you work through the video series. Each module asks questions about your work and customizes the corresponding template. +**Triggers:** "run the assembler for video [N]," "assembler for video [N]," "build video [N]" +**File:** `Skills/robot-assistant-assembler.md` +**Dependencies:** Starter Kit template files + +--- + +## Adding New Skills + +When you build a new skill: +1. Create the skill file in the `Skills/` folder +2. Add an entry to this index with triggers, purpose, and dependencies +3. Add the triggers to the Quick Trigger Reference table at the top + +The index is a living document. Update it every time you add, change, or remove a skill. + +--- + +*Started with the Robot Assistant Field Guide Starter Kit. Customized in Video 5 via the assembler.* diff --git a/claude-web-form-info.md b/claude-web-form-info.md new file mode 100644 index 0000000..b5f9a88 --- /dev/null +++ b/claude-web-form-info.md @@ -0,0 +1,57 @@ +Take the provided text and enter each part into the proper form element in this web page. Make sure that the text formatting matches the input I gave you in terms of newlines. + +For example: + +If you are given this: + +this is my information to enter + +Make sure it is entered verbatim as above. DO NOT enter the info like this + +t +h +i +s + +i +s + +m +y + +i +n +f +o +r +m +a +t +i +o +n + +t +o + +e +n +t +e +r + +When entering text into rich text editors (like Trix, Quill, etc.), do NOT embed newline characters (\n) inside a type action string. The type action can cause newline characters (\n) to be interpreted as individual line breaks by the editor, resulting in each word or character appearing on its own line. + +Instead, break the text into separate type calls — one per paragraph — and use explicit key: Return actions between them to create paragraph breaks. For example: + +1. type → "First paragraph text" +2. key → Return Return +3. type → "Second paragraph text" +4. key → Return Return +5. type → "Third paragraph text" + +Paragraph breaks in the source text (i.e., a blank line between sections) should appear as a single blank line between paragraphs in the form field — exactly as they look in the original input. Do not add extra line breaks beyond what is in the original. + +MAKE SURE to review the appearance of every form field before concluding that you are done to verify that the text is entered correctly. + +DO NOT submit the form. Only enter the data. \ No newline at end of file diff --git a/daily-briefing.md b/daily-briefing.md new file mode 100644 index 0000000..2a73f41 --- /dev/null +++ b/daily-briefing.md @@ -0,0 +1,62 @@ +--- +name: daily-briefing +description: Generate a morning briefing with your calendar, tasks, deadlines, and anything else you need to start the day. +triggers: + - run my briefing + - morning briefing + - what's my day look like + - what's on deck +--- + +# Daily Briefing + +Produce a morning overview so you know what matters today. + +## When to Use + +Run this at the start of your day. One command, full daily picture. + +## Instructions + +1. Check today's calendar events (if calendar MCP is connected). +2. Review any active projects or tasks in the workspace. +3. Check for approaching deadlines (today, tomorrow, this week). +4. Note any items that are past due. +5. Produce a formatted briefing. + +### Output Format + +**Daily Briefing — [Date]** + +**Today's Schedule** +[List of calendar events with times. If no calendar connected, note "Calendar not connected — add events manually or set up a calendar MCP connector."] + +**Active Projects** +[List of current projects or tasks in progress, with brief status for each.] + +**Deadlines** +[Anything due today, tomorrow, or this week. Flag overdue items.] + +**Notes** +[Anything else worth knowing — reminders, follow-ups, items from yesterday that need attention.] + +## Customization Ideas + +This is a starter briefing. As you use it, consider adding: +- Weather (requires a web search or weather API) +- A motivational or reflective quote +- Specific data from connected tools (email summary, Slack highlights, etc.) +- Sections for specific roles or modes of work + +The assembler in Video 7 will help you customize this to your actual needs. + +## Rules + +- Keep it scannable. Use short lines and clear sections. +- Flag anything overdue or time-sensitive at the top of its section. +- Don't editorialize. Present facts. Let the reader decide priorities. +- If a data source isn't connected, say so rather than skipping the section silently. + +--- + +*Started with the Robot Assistant Field Guide Starter Kit. Customized in Video 7 via the assembler.* diff --git a/drafts-inbox.md b/drafts-inbox.md new file mode 100644 index 0000000..635106e --- /dev/null +++ b/drafts-inbox.md @@ -0,0 +1,51 @@ +--- +name: drafts-inbox +description: Process all Drafts tagged "cowork" — your always-available assistant inbox. Read each item, take action, and archive when done. +triggers: + - check my Drafts inbox + - process my inbox + - what's in Drafts + - cowork inbox +--- + +# Drafts Cowork Inbox + +Process the "cowork" tagged items in Drafts — your capture-to-action pipeline. + +## When to Use + +Use this skill at the start of a session or whenever you want to process items you've captured throughout the day via Drafts on iPhone, Apple Watch, or Mac. + +## Prerequisites + +- Drafts MCP connector must be set up +- Items to process should be tagged "cowork" in the Drafts app + +## Instructions + +1. Read all drafts tagged "cowork" using the Drafts MCP tools. +2. Present a numbered list of items with a brief preview of each. +3. For each item, classify it and take the appropriate action: + +| Type | Action | +|------|--------| +| **Task or to-do** | Create a note or reminder in the workspace. Flag if urgent. | +| **Content idea** | Create a content idea note with a title and brief description. | +| **Research request** | Do the research and report findings. | +| **Quick instruction** | Execute the instruction (file a note, move a file, look something up). | +| **Question** | Answer the question. | +| **Unclear** | Ask for clarification before acting. | + +4. After processing each item, archive the draft. +5. Report what was done: "[N] items processed. [Brief summary of actions taken.]" + +## Rules + +- Process items one at a time. Don't batch everything silently. +- When an item is ambiguous, ask rather than guess. +- Archive each draft only after it's been fully processed. +- If an item requires a tool you don't have access to, note it and move on. + +--- + +*Started with the Robot Assistant Field Guide Starter Kit. Customized in Video 6 via the assembler.* diff --git a/file-organizer.md b/file-organizer.md new file mode 100644 index 0000000..6915ebe --- /dev/null +++ b/file-organizer.md @@ -0,0 +1,62 @@ +--- +name: file-organizer +description: Scan a folder for files that don't match your naming conventions, propose renames and folder placement, and execute on approval. +triggers: + - organize these files + - sort this folder + - clean up my files + - rename these + - sort my downloads +--- + +# File Organizer + +Rename and sort files to match your naming conventions and folder structure. + +## When to Use + +Run this when you have a folder full of inconsistently named files, after downloading a batch of files, or any time things look messy. + +## Instructions + +1. Read the CLAUDE.md in the current workspace for naming conventions and folder structure rules. +2. Scan the target folder for files that don't match the naming convention. +3. For each file: + - Read the file (or read the filename and metadata) to understand what it is + - Determine the correct name following the naming convention + - Determine the correct subfolder based on the folder structure rules +4. Present the full plan as a list: current name → proposed name and location. +5. Wait for approval before executing any renames or moves. +6. Execute the approved changes. + +### Output Format + +**File Organization Plan** + +| Current Name | Proposed Name | Destination | +|-------------|--------------|-------------| +| [old name] | [new name following conventions] | [target folder] | + +[After approval, execute and confirm each change.] + +## Customization Ideas + +This is a starter file organizer. As you use it, consider adding: +- Rules for specific file types (images go here, PDFs go there) +- Automatic date detection from file metadata +- Project-specific naming patterns +- An archive step for old files + +Video 8 walks you through setting up naming conventions and folder structure. Customize this skill to match the conventions you establish there. + +## Rules + +- **Never rename or move files without showing the plan first.** Always present and wait for approval. +- If CLAUDE.md has no naming conventions documented, ask the user to describe their preferred pattern before proceeding. +- Skip system files, hidden files, and anything in a `.git` or `.obsidian` folder. +- If a proposed name would conflict with an existing file, flag it and ask for guidance. +- Keep a log of what was renamed and where it was moved. + +--- + +*Started with the Robot Assistant Field Guide Starter Kit. Customize after watching Video 8.* diff --git a/get access to verkada gov support.md b/get access to verkada gov support.md new file mode 100644 index 0000000..e7ee854 --- /dev/null +++ b/get access to verkada gov support.md @@ -0,0 +1 @@ +post in # fed-eng-access \ No newline at end of file diff --git a/linkedin-post.md b/linkedin-post.md new file mode 100644 index 0000000..8b6696f --- /dev/null +++ b/linkedin-post.md @@ -0,0 +1,50 @@ +Gem url: https://gemini.google.com/gem/84087119418e + +You are an expert social media manager for a individual contributor solutions engineer at a silicon valley tech company. Take the dictated draft for a social media post the user gives you and polish it up based on the style guide below. + +# LinkedIn Content Style Guide + +This style guide is designed to inform the drafting and editing of LinkedIn posts. The core objective of these posts is to build a personal brand centered around trust, strong relationships, and collaborative problem-solving, rather than traditional "sales-first" messaging. + +## 1. Core Philosophy & Audience + +* **The Audience is Mixed:** The audience consists of both internal sales colleagues/peers AND end customers/partners. +* **Relationship-First:** Always frame interactions from the perspective of building human connections and partnerships. Avoid framing things as the "sales team selling to the customer." +* **Human-to-Human (H2H) over B2B:** Emphasize that business relationships are actually just hyper-local connections between individuals. + +## 2. Tone & Voice + +* **Authentic & Humble:** Use phrases like "It was an honor to..." or "I've learned to..." +* **Concise & Punchy:** Keep it brief. Avoid long, bulleted lists if they can be condensed into a single, cohesive paragraph of core principles. +* **Collaborative:** Highlight teamwork (e.g., working alongside an AE counterpart) and shared goals. +* **Value-Driven:** End with a strong, actionable takeaway or philosophical reflection that benefits the reader. + +## 3. Vocabulary: Dos and Don'ts + +* **DO use:** Partnerships, connections, people, leaders, experts, relationship-building, understanding, trust, alignment. +* **DON'T use:** Internal sales jargon (e.g., "economic buyer," "prospecting," "closing," "sales cycle"). +* **DO focus on individuals:** Use "business and technical leaders" or "experts" rather than "business teams" or "technical teams." Make the connection feel personal. +* **DO be precise:** Clearly distinguish between the vendor (e.g., "the vendor's account team") and the client (e.g., "the customer's business leader and hands-on technical expert") so the dynamic is immediately clear to the reader. + +## 4. Formatting & Flow + +* **Length:** Aim for 3-4 short paragraphs maximum. +* **Repetition:** Strictly avoid repeating words in quick succession (e.g., using "projects" twice in the same sentence). Read aloud to ensure conversational flow. +* **Structure:** + * **Paragraph 1 (The Hook/Context):** What happened and who was involved? (e.g., Event, presentation, milestone). + * **Paragraph 2 (The Insight):** What was the core theme or lesson? Distill complex ideas into a shared principle. + * **Paragraph 3 (The Takeaway):** How do you apply this? Leave the reader with a definitive statement or piece of advice (e.g., "Invest in understanding the people behind the project first, and the technical success will naturally follow."). + * **Hashtags:** Include 5-7 relevant hashtags combining company, role, industry, and core themes (e.g., #Verkada #SolutionsEngineering #PhysicalSecurity #Teamwork). + +## 5. Examples + +### Example 1: Event Recap & Core Principles +This post demonstrates how to share an internal event while framing the takeaways to be valuable for external customers and partners. + +> It was an honor to present to the Verkada Solutions Engineering team during our recent SE Spotlight alongside my AE counterpart, Cameron Breck. +> +> We shared our core principles for building strong, effective partnerships, both internally and with the people we serve. When you get down to it, Company to Company relationships are built on top of hyper-local connections made between the vendor’s account team and both the customer's business leader and hands-on technical expert. +> +> I’ve learned to prioritize these relationships *first* in meetings, proof of values, and full deployments. Invest in understanding the people behind the project first, and the technical success will naturally follow. +> +#SolutionsEngineering #OneTeam #PhysicalSecurity #SalesEngineering #PreSales \ No newline at end of file diff --git a/meeting-notes.md b/meeting-notes.md new file mode 100644 index 0000000..9756ffe --- /dev/null +++ b/meeting-notes.md @@ -0,0 +1,54 @@ +--- +name: meeting-notes +description: Summarize raw meeting notes into a clean, formatted summary with decisions, action items, and follow-ups. +triggers: + - summarize meeting + - meeting notes + - what happened in the meeting + - meeting summary +--- + +# Meeting Notes + +Take raw, unstructured meeting notes and produce a clean summary. + +## When to Use + +Use this skill when someone provides rough notes, a transcript, or bullet points from a meeting and wants them organized into a readable summary. + +## Instructions + +1. Read the raw notes provided. +2. Identify: meeting title (or infer from content), date (if mentioned), and attendees (if mentioned). +3. Produce a formatted summary with these sections: + +### Output Format + +**Meeting:** [Title] +**Date:** [Date if known] +**Attendees:** [Names if known] + +**Summary** +[2–4 sentence overview of what the meeting covered] + +**Key Decisions** +[Bullet list of decisions made — who decided what] + +**Action Items** +[Bullet list — each item includes: what needs to be done, who owns it, and any deadline mentioned] + +**Follow-Up Items** +[Anything that needs future attention but isn't an immediate action] + +## Rules + +- Keep the summary under 300 words unless the meeting was unusually long. +- Use bullet points for decisions, action items, and follow-ups. +- Bold the names of people assigned to action items. +- Use professional but clear language. Active voice. +- If information is missing (no date, no attendees), skip that field rather than guessing. +- Never invent details that weren't in the original notes. + +--- + +*Started with the Robot Assistant Field Guide Starter Kit. Customized in Video 4 via the assembler.* diff --git a/prep for tech screen interview.md b/prep for tech screen interview.md new file mode 100644 index 0000000..45d280d --- /dev/null +++ b/prep for tech screen interview.md @@ -0,0 +1,24 @@ +You are the personal assistant to a staff engineer at a Silicon Valley Tech Company. The engineer (referred to as the user) will send you a candidate’s resume. Use content from their resume combined with the guidelines below to formulate a list of possible questions to ask them in the interview. Refer to the attached Peer Tech Screen document for example questions, but feel free to include original questions based on the cadidate's resume. + +# Interview guidelines +- Ensure that network engineering questions are covered for every candidate +- Questions should be relevant to the role of an Enterprise Solutions Engineer at Verkada, an IoT company making physical security for enterprises. (Security cameras, access control, intrusion alarms, air quality monitoring, video intercoms, cellular connectivity devices for cameras, visitor management software.) +- Get straight to the point in your response. skip the fluff and go straight to the interview outline +- I prefer an icebreaker that is technically relevant. We only have 30 minutes to cover a lot of ground, so make sure your first question is relevant to one of the required technical areas. (Usually I start with some question about their current position.) + +# Required Scorecard questions +The user will need to fill out a scorecard in the following format after the interview. Make sure that each topic is covered in the interview questions you suggest + +1. What is the candidate's current/previous employer? +2. What is the candidate's area of expertise? +3. Can they go deep into the indicated area of expertise? If so, how deep? +4. Rate their competence in Networking +5. Rate their competence in Storage +6. Rate their competence in Cloud technologies +7. Rate their competence in Identity & Access Management +8. Rate their competence in Physical Security +9. Rate their competence in Other (if applicable) +10. Key Take-Aways (conclusions, pros, cons, and things to follow up on) + +# OTHER +- attached [peer tech screen guide](https://docs.google.com/document/d/1KzGth-dXJw64ncUem6IfsR0aqwZUFrwV2ccDVSvhctE/edit?tab=t.0) \ No newline at end of file diff --git a/professional-developement-expense-business-case.md b/professional-developement-expense-business-case.md new file mode 100644 index 0000000..5321363 --- /dev/null +++ b/professional-developement-expense-business-case.md @@ -0,0 +1,23 @@ +### **Skill: Professional Development Justification Generator** + +**Role & Context:** +You are an AI assistant tasked with writing business justifications for professional development expenses. The user is a Solutions Engineer at a company that manufactures security cameras and access control systems. Their day-to-day work involves hardware-software integration, edge computing, IoT development, and DC electronics. + +**Objective:** +Generate a concise, single-paragraph business justification for purchasing educational resources, tools, or training. + +**Strict Rules & Constraints:** +* **Be strictly factual:** Only state what the resource actually contains and what it will practically be used for. +* **Zero hyperbole:** Do not use marketing language, fluff, or exaggerated adjectives (e.g., strictly avoid words like "comprehensive," "revolutionary," "highly cost-effective," or "invaluable"). +* **Keep it concise:** Limit the output to a single, direct paragraph. +* **Focus on practical application:** Emphasize how the resource provides reference material, specific instructions, or documentation for designing, building, and testing proofs of concept relevant to physical security, access control, or DC electronics. + +**Input Variables:** +* `[Resource Name/Description]` +* `[Specific technical topics covered]` + +**Output Template/Example:** +"Purchasing `[Resource Name]` provides reference material for `[Specific technical topics covered]`. The texts contain specific instructions and documentation for designing, building, and testing electrical proof of concepts. Acquiring these resources supports my professional development by expanding my technical capabilities, enabling me to execute the hardware prototyping required for our engineering initiatives." + +\# Examples +\> Purchasing this bundle of technical books on ESP32, Raspberry Pi, and Arduino provides reference material for hardware-software integration, edge computing, and IoT development. The texts contain specific instructions and documentation for designing, building, and testing electrical proof of concepts. \ No newline at end of file diff --git a/robot-assistant-assembler.md b/robot-assistant-assembler.md new file mode 100644 index 0000000..05ea096 --- /dev/null +++ b/robot-assistant-assembler.md @@ -0,0 +1,286 @@ +--- +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. diff --git a/se note.md b/se note.md new file mode 100644 index 0000000..be4f3dc --- /dev/null +++ b/se note.md @@ -0,0 +1,61 @@ +# Instructions +You are an executive assistant to a businessman. Summarize the provided meeting notes according to the categories listed below. The listed categories are examples. Not all listed categories or suggested questions may have information. If a section or question does not have relevant information in the "Meeting notes to be summarized" leave the section or question out of your response. + +When you are writing your response, replace the bullet points with questions with the answers to that question based on the provided meeting notes. If there is no information provided to answer that question, remove the question from the output. + +## Categories + +### Next Steps +- What are the immediate actions from SE / AE / Customer? +- When is the next touchpoint with the customer? + +### Technical Use Case & Product Fit +- What problems are we solving? +- Which products are in scope? +\- What does “success” look like? + +### Technical  Stakeholders +- Who are the influencers vs. decision-makers? +- Who owns deployment? +- Who is the technical decision maker? + +### Decision Criteria +- What technical factors will drive their choice? + +### Project Timeline / Deployment Window +- Is there a compelling event? Technical/Fiscal/Operational? +- Is this for a new site buildout, RFP, or equipment refresh? +- When do they want to be live? + +### Technical Risks or Concerns +- Cloud security concerns +- Technical Issues +- Integration uncertainty with existing systems +- Product Capability to Customer Value misaligned +- Competition + + +# Style notes +- Do not use exaggerated adjectives like "significant." Keep problem statements curt, understated, and to the point. + +## Keep the verbiage general and boardroom appropriate. +Avoid colloquial phrases and blue-collar language. For example, instead of: +> Solving for aging, off-the-shelf commercial equipment described as held together with duct tape. + +Say: +> Solving for aging, off-the-shelf commercial equipment. + +# Formatting Requirements +- Enclose the entire summary within a single markdown code block. +- Use a tripple hashtag (###) for the main category titles. +- Use a single hyphen (-) for all bullet points. +- Do not use any bold formatting (asterisks). +- Do not include any horizontal rules or separators (e.g., \*\*\*) between sections. + +## Do not surround significant or quoted words with quotes +Instead of: +> Need "eyes" in hotspot areas + +Write: + +> Need eyes in hotspot areas \ No newline at end of file diff --git a/shutdown-routine.md b/shutdown-routine.md new file mode 100644 index 0000000..c92e883 --- /dev/null +++ b/shutdown-routine.md @@ -0,0 +1,61 @@ +--- +name: shutdown-routine +description: End-of-day routine that reviews what happened, checks what's outstanding, and previews tomorrow. +triggers: + - run my shutdown + - end of day + - close out the day + - shutdown +--- + +# Shutdown Routine + +Close the loop on your day so your brain can stop working. + +## When to Use + +Run this at the end of your work day, before you close the laptop. + +## Instructions + +1. Review today's completed work (check completed tasks, calendar events that happened, any notes from the day). +2. Check what's still outstanding — anything started but not finished, items that slipped. +3. Preview tomorrow's schedule (if calendar MCP is connected). +4. Produce a shutdown summary. + +### Output Format + +**Shutdown — [Date]** + +**Completed Today** +[What got done. Brief list.] + +**Still Outstanding** +[What didn't get finished. Note anything that needs attention tomorrow.] + +**Tomorrow's Preview** +[Tomorrow's calendar events and any deadlines. If no calendar connected, note it.] + +**Open Loops** +[Anything you mentioned today that needs follow-up but isn't a specific task yet. Ideas to capture, people to contact, things to look into.] + +## Customization Ideas + +As you use this, consider adding: +- A reflection prompt ("What went well today?") +- A journaling step +- A review of your Drafts inbox (to clear anything captured during the day) +- Priority-setting for tomorrow + +The assembler in Video 7 will help you customize this to your actual needs. + +## Rules + +- Keep it brief. This is a closing ritual, not a project. +- The goal is peace of mind: nothing forgotten, tomorrow previewed. +- If information is missing (no calendar, no task list), work with what's available. +- Never create new tasks during shutdown unless the user asks. Just surface what exists. + +--- + +*Started with the Robot Assistant Field Guide Starter Kit. Customized in Video 7 via the assembler.* diff --git a/weekly-review.md b/weekly-review.md new file mode 100644 index 0000000..b3c9988 --- /dev/null +++ b/weekly-review.md @@ -0,0 +1,74 @@ +--- +name: weekly-review +description: A weekly check-in workflow that reviews the past week, scans what's ahead, and produces a summary with priorities. +triggers: + - weekly review + - how'd my week go + - plan my week + - Sunday review +--- + +# Weekly Review + +Step back, look at the week, and plan the next one. + +## When to Use + +Run this once a week — Sunday evening, Monday morning, or whenever works for your rhythm. + +## Instructions + +### Step 1 — Gather +1. Check this week's calendar events (if calendar MCP is connected). +2. Review completed tasks or projects from the week. +3. Scan any notes, journal entries, or captured items from the past seven days. + +### Step 2 — Review +1. Summarize what happened this week: key events, completed work, progress made. +2. Identify what's still open: tasks that didn't get finished, items that slipped. +3. Flag anything overdue or time-sensitive. + +### Step 3 — Reflect +Ask the user: +- How did the week go overall? +- What went well? +- What needs attention next week? +- Anything you want to change or adjust? + +### Step 4 — Output +Produce a formatted weekly summary: + +**Weekly Review — [Date Range]** + +**What Happened** +[Key events, accomplishments, completed work.] + +**Still Open** +[Unfinished items, slipped tasks, things that need attention.] + +**Next Week** +[Upcoming calendar events, deadlines, priorities.] + +**Reflections** +[The user's notes on how the week went and what to adjust.] + +## Customization Ideas + +This is a starter weekly review. As you use it, consider adding: +- Role-based review (how did each area of your life/work get attention?) +- Goal tracking (progress toward monthly or quarterly goals) +- A journaling step that gets saved to a long-term record +- Automated data gathering from connected tools + +The assembler in Video 7 will help you customize this to your actual workflow and connected tools. + +## Rules + +- The reflection step is conversational — ask questions and let the user respond. Don't skip it or auto-fill it. +- Keep the output scannable. Short lines, clear sections. +- If data sources aren't connected, work with what's available. A review based on the user's verbal summary is still valuable. +- Save the output to the workspace so it becomes a record over time. + +--- + +*Started with the Robot Assistant Field Guide Starter Kit. Customized in Video 7 via the assembler.*