NotebookLM Skill Builder

# NotebookLM Skill Builder Use Google NotebookLM to generate high-quality skills for the skills platform (skills.skynet.ceo). Feed NotebookLM documentation + exemplar skills + format specs as sources, then prompt its chat to produce production-ready SKILL.md content grounded in real docs. ## Why NotebookLM NotebookLM grounds all output in the sources you provide — it won't hallucinate API endpoints, flags, or workflows. This makes it ideal for generating skills from complex documentation where accuracy matters more than creativity. The result is a skill with real commands, correct parameters, and proper error handling because NotebookLM won't make things up. ## Prerequisites - **claude-in-chrome MCP** connected - **Google account** signed into NotebookLM in Chrome (Ultra plan recommended) - **NotebookLM skill** — this skill depends on the `notebooklm` skill for browser automation. Fetch it first: `GET https://skills.skynet.ceo/api/skills/notebooklm/skill.md` - **skills.skynet.ceo** accessible for publishing ## Overview The workflow has 5 phases: 1. **Gather** — Collect documentation for the target tool/service 2. **Load** — Create a NotebookLM notebook and add sources (docs + skill format spec + exemplars) 3. **Generate** — Prompt NotebookLM's chat to produce the skill 4. **Extract** — Pull the generated content out of NotebookLM 5. **Publish** — Clean up and push to skills.skynet.ceo --- ## Phase 1: Gather Documentation Before touching NotebookLM, collect the source material. The quality of sources directly determines the quality of the generated skill. **What to gather:** - Official API reference / CLI help output - Getting started guide or quickstart - Configuration reference - Common patterns / cookbook / examples - Troubleshooting / FAQ pages **How to gather:** ```bash # For web docs — use fetch or curl to get raw content # For CLI tools — capture help output <tool> --help > /tmp/skill-source-help.txt <tool> <subcommand> --help >> /tmp/skill-source-help.txt # For API docs — save key endpoints curl -s https://docs.example.com/api-reference | html2text > /tmp/skill-source-api.txt ``` Alternatively, use NotebookLM's URL source feature to add documentation pages directly (works well for public docs sites). **Target size:** Aim for 10,000-40,000 characters of source material. Too little and the skill will be thin; too much and NotebookLM may lose focus. Prioritize the most actionable content — API endpoints, CLI commands, config options, error codes. --- ## Phase 2: Load Sources into NotebookLM Follow the notebooklm skill's Session Setup, then create a notebook and add three types of sources: ### Source 1: Target Documentation Add the gathered docs as the primary source. Use "Copied text" for prepared content or "Website" for URLs. If docs are large, split across 2-3 sources by topic area (e.g., "API Endpoints", "Configuration", "CLI Commands"). ### Source 2: Skill Format Specification Add this as a "Copied text" source — it teaches NotebookLM the output format: ``` # Skill Format Specification A skill is a markdown document with YAML frontmatter that teaches AI agents how to use a tool, service, or API. ## Structure The skill has two parts: 1. YAML frontmatter (name, description) 2. Markdown body (instructions) ## YAML Frontmatter (required) --- name: skill-name-in-kebab-case description: > One paragraph describing WHEN to use this skill and WHAT it does. Be specific about trigger conditions — mention tool names, commands, service names, and use cases. This is what determines if the skill gets loaded, so be thorough. --- ## Markdown Body Structure The body should follow this structure (adapt as needed): ### 1. Title and Overview One-line summary of what the skill automates. ### 2. Prerequisites What must be installed, configured, or authenticated before using this skill. Include specific tool versions, env vars, or access requirements. ### 3. Quick Reference Table (optional) For API/CLI skills, a table mapping common tasks to commands/endpoints. ### 4. Core Workflows The main section. Break into numbered workflows (3-7 typically): - Each workflow is a complete task (e.g., "Deploy a Service", "Create a Database") - Use numbered steps with actual commands, API calls, or code - Include expected output or verification steps - Show real values, not just placeholders where possible ### 5. Common Patterns / Recipes Copy-paste examples for frequent tasks. These are the most valuable part for agents — they can execute them directly. ### 6. Troubleshooting Common errors and how to fix them. Include: - Error message or symptom - Root cause - Fix command or workaround ### 7. References (optional) Links to official docs, related skills, or config files. ## Writing Principles - Use imperative form ("Run this command", not "You should run") - Include real commands with actual flags and parameters - Show verification steps after each major action - Keep it 50-300 lines — concise but complete - Explain WHY when the reason isn't obvious, not just WHAT - Don't over-document — focus on what an AI agent needs to execute tasks - Include error handling for things that commonly go wrong - Cross-reference other skills when relevant ``` ### Source 3: Exemplar Skill Add one strong example skill as a "Copied text" source. Pick one that's similar in type to what you're generating: **For API/service skills**, use this exemplar pattern: ``` # Example Skill: Deploy to Railway ## Prerequisites - Railway CLI installed and authenticated (`railway login`) - Project linked (`railway link`) ## Quick Reference | Task | Command | |------|---------| | Deploy | `railway up` | | View logs | `railway logs` | | Set env var | `railway variables set KEY=VALUE` | | Open dashboard | `railway open` | ## Workflow: Initial Setup 1. Install Railway CLI: `npm i -g @railway/cli` 2. Authenticate: `railway login` 3. Create project: `railway init` 4. Link to existing: `railway link` ## Workflow: Deploy a Service 1. From project root: `railway up` 2. Verify deployment: `railway status` 3. Check logs: `railway logs --tail` 4. If deployment fails, check build logs: `railway logs --build` ## Workflow: Add Postgres 1. Add plugin: `railway add -p postgresql` 2. Get connection URL: `railway variables get DATABASE_URL` 3. Run migrations: `railway run npx prisma migrate deploy` ## Troubleshooting **Build fails with "no start command":** - Add `start` script to package.json - Or set `RAILWAY_START_COMMAND` env var **Deployment stuck:** - Check `railway logs --build` for errors - Try `railway up --detach` then monitor with `railway logs` ``` **For browser automation skills**, use a similar pattern but with `find`/`computer`/`form_input` tool calls instead of CLI commands. Pick the exemplar closest to your target skill type. You can fetch real skills from the platform: ```bash curl -s "https://skills.skynet.ceo/api/skills?q=railway" | jq '.skills[0].instruction' -r ``` --- ## Phase 3: Generate the Skill via Chat Once all 3 sources are loaded, use NotebookLM's chat to generate the skill. The prompt is critical. ### The Generation Prompt Use this prompt template (customize the bracketed sections): ``` Based on the documentation provided, write a complete skill document for [TOOL/SERVICE NAME]. Follow the Skill Format Specification source exactly. Use the example skill as a structural guide. The skill should cover these workflows: 1. [Primary workflow — e.g., "Initial setup and authentication"] 2. [Second workflow — e.g., "Deploy a service"] 3. [Third workflow — e.g., "Manage databases"] 4. [Fourth workflow — e.g., "Monitor and debug"] Requirements: - Start with YAML frontmatter (name and description) - Include a prerequisites section with specific requirements - Include a quick reference table mapping common tasks to commands - Every workflow step must use REAL commands, flags, and parameters from the documentation — do not invent any - Include verification steps after major actions - End with a troubleshooting section covering common errors from the docs - Keep it between 50-300 lines - Write in imperative form for an AI agent audience ``` ### Submitting the Prompt Follow the notebooklm skill's "Chat with Notebook" workflow: ``` 1. find(query: "Start typing", tabId) or find(query: "Ask", tabId) 2. read_page(tabId, filter: "interactive") → get chat input ref 3. form_input(ref: <chat_input_ref>, value: "<generation prompt>", tabId) 4. computer(action: "key", text: "Return", tabId) 5. computer(action: "wait", duration: 15, tabId) → NotebookLM generates (can take 10-30s for long output) 6. computer(action: "screenshot", tabId) → verify response appeared ``` ### Iterating The first generation is rarely perfect. Follow up with refinement prompts: - "Add more detail to the troubleshooting section — include specific error messages from the docs" - "The prerequisites section is missing [X] — add it" - "Rewrite workflow 3 to use the newer API endpoint documented in source 1" - "Make the quick reference table more comprehensive — add all major commands" - "The description in the frontmatter is too vague — make it specific about when an agent should use this skill" Keep iterating until the skill looks complete. Usually 2-3 rounds. --- ## Phase 4: Extract the Generated Skill Pull the final skill content out of NotebookLM: ``` 1. get_page_text(tabId) → extract the full page text 2. Locate the most recent chat response containing the skill markdown 3. Clean up: remove any NotebookLM UI artifacts, chat prompt text, or citation markers 4. Save to a temporary file for review: ``` ```bash cat > /tmp/generated-skill.md << 'EOF' <paste extracted skill content> EOF ``` **Review checklist before publishing:** - [ ] YAML frontmatter has `name` and `description` - [ ] Description is specific enough to trigger correctly (mentions tool name, use cases, commands) - [ ] All commands and API calls are real (not hallucinated) — verify against the source docs - [ ] Workflows have numbered steps with real commands - [ ] Verification steps exist after major actions - [ ] Troubleshooting section covers likely failure modes - [ ] Length is 50-300 lines - [ ] No NotebookLM artifacts (citation numbers, UI text) remain --- ## Phase 5: Publish to Skills Platform Parse the frontmatter and publish via the API: ```bash # Extract name from frontmatter NAME="the-skill-name" SLUG="the-skill-slug" CATEGORY="dev" # or: infrastructure, content, ops, social # Publish via PUT (upsert) curl -s -X PUT "https://skills.skynet.ceo/api/skills/${SLUG}" \ -H "Content-Type: application/json" \ -d '{ "name": "'"$NAME"'", "description": "One-line description from frontmatter", "instruction": "<full markdown body>", "category": "'"$CATEGORY"'", "tags": ["tag1", "tag2"], "agents": ["claude-code"], "toolsRequired": ["shell"], "version": "1.0.0" }' ``` Or use JavaScript for proper JSON escaping of the instruction field: ```javascript const instruction = fs.readFileSync('/tmp/generated-skill.md', 'utf8'); // Strip YAML frontmatter from instruction body const body = instruction.replace(/^---[\s\S]*?---\n/, ''); const resp = await fetch('https://skills.skynet.ceo/api/skills/' + slug, { method: 'PUT', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ name, description, instruction: body, category, tags, agents, toolsRequired }) }); ``` After publishing, verify: ```bash # Check it's live curl -s "https://skills.skynet.ceo/api/skills/${SLUG}" | jq '.name, .description' # Fetch the rendered SKILL.md curl -s "https://skills.skynet.ceo/api/skills/${SLUG}/skill.md" ``` --- ## Tips for Better Skills **Source selection matters most.** A skill generated from a comprehensive API reference will always beat one from a sparse README. Prioritize: 1. API reference with all endpoints/flags documented 2. Quickstart guide (shows the happy path) 3. Troubleshooting/FAQ (shows what goes wrong) **One skill per tool, not per task.** A "Deploy to Railway" skill should cover setup through monitoring — not separate skills for each step. **Test the generated commands.** Before publishing, run key commands from the skill to verify they work. NotebookLM won't hallucinate if the source docs are good, but docs themselves can be outdated. **The description field is your trigger.** Spend extra time on it. A vague description means agents won't find the skill. Include the tool name, common aliases, key verbs (deploy, configure, manage), and specific use cases. **Iterate in NotebookLM, not after extraction.** It's easier to refine in NotebookLM's chat (where it has the sources for reference) than to manually edit after extraction. ## Notebook Naming Convention Name notebooks: `Skill Builder — {Tool Name}` Examples: - `Skill Builder — Railway` - `Skill Builder — Cloudflare Workers` - `Skill Builder — Google Analytics 4` This keeps the NotebookLM workspace organized for future skill updates.