{"owner":"bytedance","repo":"deer-flow","hasSkills":true,"totalSkillsCount":72,"totalTokensCount":50138,"categories":["anthropic-skill","copilot-instructions","root-instruction","claude-rule","subagent-persona"],"hasMcp":false,"mcpConfig":null,"found":["skills/public/video-generation/SKILL.md","skills/public/web-design-guidelines/SKILL.md","skills/public/surprise-me/SKILL.md",".agent/skills/smoke-test/SKILL.md","skills/public/systematic-literature-review/SKILL.md","skills/public/podcast-generation/SKILL.md","skills/public/image-generation/SKILL.md","skills/public/newsletter-generation/SKILL.md","skills/public/ppt-generation/SKILL.md","skills/public/github-deep-research/SKILL.md","skills/public/skill-creator/SKILL.md","skills/public/frontend-design/SKILL.md","skills/public/find-skills/SKILL.md","skills/public/deep-research/SKILL.md","skills/public/data-analysis/SKILL.md","skills/public/consulting-analysis/SKILL.md","skills/public/code-documentation/SKILL.md","skills/public/claude-to-deerflow/SKILL.md","skills/public/chart-visualization/SKILL.md","skills/public/bootstrap/SKILL.md","skills/public/academic-paper-review/SKILL.md",".github/copilot-instructions.md","backend/AGENTS.md","backend/CLAUDE.md","frontend/AGENTS.md","frontend/CLAUDE.md",".agent/skills/smoke-test/references/SOP.md",".agent/skills/smoke-test/references/troubleshooting.md",".agent/skills/smoke-test/templates/report.docker.template.md",".agent/skills/smoke-test/templates/report.local.template.md","skills/public/systematic-literature-review/evals/evals.json","skills/public/systematic-literature-review/evals/trigger_eval_set.json","skills/public/systematic-literature-review/templates/apa.md","skills/public/systematic-literature-review/templates/bibtex.md","skills/public/systematic-literature-review/templates/ieee.md","skills/public/skill-creator/agents/analyzer.md","skills/public/skill-creator/agents/comparator.md","skills/public/skill-creator/agents/grader.md","skills/public/skill-creator/references/output-patterns.md","skills/public/skill-creator/references/schemas.md","skills/public/skill-creator/references/workflows.md","skills/public/podcast-generation/templates/tech-explainer.md","skills/public/image-generation/templates/doraemon.md","skills/public/github-deep-research/assets/report_template.md","skills/public/chart-visualization/references/generate_area_chart.md","skills/public/chart-visualization/references/generate_bar_chart.md","skills/public/chart-visualization/references/generate_boxplot_chart.md","skills/public/chart-visualization/references/generate_column_chart.md","skills/public/chart-visualization/references/generate_district_map.md","skills/public/chart-visualization/references/generate_dual_axes_chart.md","skills/public/chart-visualization/references/generate_fishbone_diagram.md","skills/public/chart-visualization/references/generate_flow_diagram.md","skills/public/chart-visualization/references/generate_funnel_chart.md","skills/public/chart-visualization/references/generate_histogram_chart.md","skills/public/chart-visualization/references/generate_line_chart.md","skills/public/chart-visualization/references/generate_liquid_chart.md","skills/public/chart-visualization/references/generate_mind_map.md","skills/public/chart-visualization/references/generate_network_graph.md","skills/public/chart-visualization/references/generate_organization_chart.md","skills/public/chart-visualization/references/generate_path_map.md","skills/public/chart-visualization/references/generate_pie_chart.md","skills/public/chart-visualization/references/generate_pin_map.md","skills/public/chart-visualization/references/generate_radar_chart.md","skills/public/chart-visualization/references/generate_sankey_chart.md","skills/public/chart-visualization/references/generate_scatter_chart.md","skills/public/chart-visualization/references/generate_spreadsheet.md","skills/public/chart-visualization/references/generate_treemap_chart.md","skills/public/chart-visualization/references/generate_venn_chart.md","skills/public/chart-visualization/references/generate_violin_chart.md","skills/public/chart-visualization/references/generate_word_cloud_chart.md","skills/public/bootstrap/references/conversation-guide.md","skills/public/bootstrap/templates/SOUL.template.md"],"skills":{"skills/public/video-generation/SKILL.md":"---\nname: video-generation\ndescription: Use this skill when the user requests to generate, create, or imagine videos. Supports structured prompts and reference image for guided generation.\n---\n\n# Video Generation Skill\n\n## Overview\n\nThis skill generates high-quality videos using structured prompts and a Python script. The workflow includes creating JSON-formatted prompts and executing video generation with optional reference image.\n\n## Core Capabilities\n\n- Create structured JSON prompts for AIGC video generation\n- Support reference image as guidance or the first/last frame of the video\n- Generate videos through automated Python script execution\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests video generation, identify:\n\n- Subject/content: What should be in the image\n- Style preferences: Art style, mood, color palette\n- Technical specs: Aspect ratio, composition, lighting\n- Reference image: Any image to guide generation\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Prompt\n\nGenerate a structured JSON file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}.json`\n\n### Step 3: Create Reference Image (Optional when image-generation skill is available)\n\nGenerate reference image for the video generation.\n\n- If only 1 image is provided, use it as the guided frame of the video\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/video-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/prompt-file.json \\\n --reference-images /path/to/ref1.jpg \\\n --output-file /mnt/user-data/outputs/generated-video.mp4 \\\n --aspect-ratio 16:9\n```\n\nParameters:\n\n- `--prompt-file`: Absolute path to JSON prompt file (required)\n- `--reference-images`: Absolute paths to reference image (optional)\n- `--output-file`: Absolute path to output image file (required)\n- `--aspect-ratio`: Aspect ratio of the generated image (optional, default: 16:9)\n\n[!NOTE]\nDo NOT read the python file, instead just call it with the parameters.\n\n## Video Generation Example\n\nUser request: \"Generate a short video clip depicting the opening scene from \"The Chronicles of Narnia: The Lion, the Witch and the Wardrobe\"\n\nStep 1: Search for the opening scene of \"The Chronicles of Narnia: The Lion, the Witch and the Wardrobe\" online\n\nStep 2: Create a JSON prompt file with the following content:\n\n```json\n{\n \"title\": \"The Chronicles of Narnia - Train Station Farewell\",\n \"background\": {\n \"description\": \"World War II evacuation scene at a crowded London train station. Steam and smoke fill the air as children are being sent to the countryside to escape the Blitz.\",\n \"era\": \"1940s wartime Britain\",\n \"location\": \"London railway station platform\"\n },\n \"characters\": [\"Mrs. Pevensie\", \"Lucy Pevensie\"],\n \"camera\": {\n \"type\": \"Close-up two-shot\",\n \"movement\": \"Static with subtle handheld movement\",\n \"angle\": \"Profile view, intimate framing\",\n \"focus\": \"Both faces in focus, background soft bokeh\"\n },\n \"dialogue\": [\n {\n \"character\": \"Mrs. Pevensie\",\n \"text\": \"You must be brave for me, darling. I'll come for you... I promise.\"\n },\n {\n \"character\": \"Lucy Pevensie\",\n \"text\": \"I will be, mother. I promise.\"\n }\n ],\n \"audio\": [\n {\n \"type\": \"Train whistle blows (signaling departure)\",\n \"volume\": 1\n },\n {\n \"type\": \"Strings swell emotionally, then fade\",\n \"volume\": 0.5\n },\n {\n \"type\": \"Ambient sound of the train station\",\n \"volume\": 0.5\n }\n ]\n}\n```\n\nStep 3: Use the image-generation skill to generate the reference image\n\nLoad the image-generation skill and generate a single reference image `narnia-farewell-scene-01.jpg` according to the skill.\n\nStep 4: Use the generate.py script to generate the video\n```bash\npython /mnt/skills/public/video-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/narnia-farewell-scene.json \\\n --reference-images /mnt/user-data/outputs/narnia-farewell-scene-01.jpg \\\n --output-file /mnt/user-data/outputs/narnia-farewell-scene-01.mp4 \\\n --aspect-ratio 16:9\n```\n> Do NOT read the python file, just call it with the parameters.\n\n## Output Handling\n\nAfter generation:\n\n- Videos are typically saved in `/mnt/user-data/outputs/`\n- Share generated videos (come first) with user as well as generated image if applicable, using `present_files` tool\n- Provide brief description of the generation result\n- Offer to iterate if adjustments needed\n\n## Notes\n\n- Always use English for prompts regardless of user's language\n- JSON format ensures structured, parsable prompts\n- Reference image enhance generation quality significantly\n- Iterative refinement is normal for optimal results\n\n## Providers (Gemini / MiniMax)\n\nProvider credentials are read from the runtime environment, not embedded in the\nscript. Do not put their values in prompt files or command-line arguments.\n\nAuto-selected by environment variables (CLI unchanged):\n\n- `GEMINI_API_KEY` set → Gemini Veo (default, unchanged).\n- Only `MINIMAX_API_KEY` set → MiniMax video (`/v1/video_generation`, async 3-step poll/download).\n- Force with `VIDEO_GENERATION_PROVIDER=gemini|minimax`.\n\nMiniMax overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_VIDEO_MODEL` (default `MiniMax-Hailuo-2.3`). The first reference image is used\nas MiniMax `first_frame_image`. MiniMax ignores `--aspect-ratio` (it uses resolution/duration).\n","skills/public/web-design-guidelines/SKILL.md":"---\nname: web-design-guidelines\ndescription: Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".\nmetadata:\n author: vercel\n version: \"1.0.0\"\n argument-hint: \n---\n\n# Web Interface Guidelines\n\nReview files for compliance with Web Interface Guidelines.\n\n## How It Works\n\n1. Fetch the latest guidelines from the source URL below\n2. Read the specified files (or prompt user for files/pattern)\n3. Check against all rules in the fetched guidelines\n4. Output findings in the terse `file:line` format\n\n## Guidelines Source\n\nFetch fresh guidelines before each review:\n\n```\nhttps://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md\n```\n\nUse WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.\n\n## Usage\n\nWhen a user provides a file or pattern argument:\n1. Fetch guidelines from the source URL above\n2. Read the specified files\n3. Apply all rules from the fetched guidelines\n4. Output findings using the format specified in the guidelines\n\nIf no files specified, ask the user which files to review.\n","skills/public/surprise-me/SKILL.md":"---\nname: surprise-me\ndescription: Create a delightful, unexpected \"wow\" experience for the user by dynamically discovering and creatively combining other enabled skills. Triggers when the user says \"surprise me\" or any request expressing a desire for an unexpected creative showcase. Also triggers when the user is bored, wants inspiration, or asks for \"something interesting\".\n---\n\n# Surprise Me\n\nDeliver an unexpected, delightful experience by dynamically discovering available skills and combining them creatively.\n\n## Workflow\n\n### Step 1: Discover Available Skills\n\nRead all the skills listed in the .\n\n### Step 2: Plan the Surprise\n\nSelect **1 to 3** skills and design a creative mashup. The goal is a single cohesive deliverable, not separate demos.\n\n**Creative combination principles:**\n- Juxtapose skills in unexpected ways (e.g., a presentation about algorithmic art, a research report turned into a slide deck, a styled doc with canvas-designed illustrations)\n- Incorporate the user's known interests/context from memory if available\n- Prioritize visual impact and emotional delight over information density\n- The output should feel like a gift — polished, surprising, and fun\n\n**Theme ideas (pick or remix):**\n- Something tied to today's date, season, or trending news\n- A mini creative project the user never asked for but would love\n- A playful \"what if\" concept\n- An aesthetic artifact combining data + design\n- A fun interactive HTML/React experience\n\n### Step 3: Fallback — No Other Skills Available\n\nIf no other skills are discovered (only surprise-me exists), use one of these fallbacks:\n\n1. **News-based surprise**: Search today's news for a fascinating story, then create a beautifully designed HTML artifact presenting it in a visually striking way\n2. **Interactive HTML experience**: Build a creative single-page web experience — generative art, a mini-game, a visual poem, an animated infographic, or an interactive story\n3. **Personalized artifact**: Use known user context to create something personal and delightful\n\n### Step 4: Execute\n\n1. Read the full SKILL.md body of each selected skill\n2. Follow each skill's instructions for technical execution\n3. Combine outputs into one cohesive deliverable\n4. Present the result with minimal preamble — let the work speak for itself\n\n### Step 5: Reveal\n\nPresent the surprise with minimal spoilers. A short teaser line, then the artifact.\n\n- **Good reveal:** \"I made you something ✨\" + [the artifact]\n- **Bad reveal:** \"I decided to combine the pptx skill with the canvas-design skill to create a presentation about...\" (kills the surprise)\n",".agent/skills/smoke-test/SKILL.md":"---\nname: smoke-test\ndescription: End-to-end smoke test skill for DeerFlow. Guides through: 1) Pulling latest code, 2) Docker OR Local installation and deployment (user preference, default to Local if Docker network issues), 3) Service availability verification, 4) Health check, 5) Final test report. Use when the user says \"run smoke test\", \"smoke test deployment\", \"verify installation\", \"test service availability\", \"end-to-end test\", or similar.\n---\n\n# DeerFlow Smoke Test Skill\n\nThis skill guides the Agent through DeerFlow's full end-to-end smoke test workflow, including code updates, deployment (supporting both Docker and local installation modes), service availability verification, and health checks.\n\n## Deployment Mode Selection\n\nThis skill supports two deployment modes:\n- **Local installation mode** (recommended, especially when network issues occur) - Run all services directly on the local machine\n- **Docker mode** - Run all services inside Docker containers\n\n**Selection strategy**:\n- If the user explicitly asks for Docker mode, use Docker\n- If network issues occur (such as slow image pulls), automatically switch to local mode\n- Default to local mode whenever possible\n\n## Structure\n\n```\nsmoke-test/\n├── SKILL.md ← You are here - core workflow and logic\n├── scripts/\n│ ├── check_docker.sh ← Check the Docker environment\n│ ├── check_local_env.sh ← Check local environment dependencies\n│ ├── frontend_check.sh ← Frontend page smoke check\n│ ├── pull_code.sh ← Pull the latest code\n│ ├── deploy_docker.sh ← Docker deployment\n│ ├── deploy_local.sh ← Local deployment\n│ └── health_check.sh ← Service health check\n├── references/\n│ ├── SOP.md ← Standard operating procedure\n│ └── troubleshooting.md ← Troubleshooting guide\n└── templates/\n ├── report.local.template.md ← Local mode smoke test report template\n └── report.docker.template.md ← Docker mode smoke test report template\n```\n\n## Standard Operating Procedure (SOP)\n\n### Phase 1: Code Update Check\n\n1. **Confirm current directory** - Verify that the current working directory is the DeerFlow project root\n2. **Check Git status** - See whether there are uncommitted changes\n3. **Pull the latest code** - Use `git pull origin main` to get the latest updates\n4. **Confirm code update** - Verify that the latest code was pulled successfully\n\n### Phase 2: Deployment Mode Selection and Environment Check\n\n**Choose deployment mode**:\n- Ask for user preference, or choose automatically based on network conditions\n- Default to local installation mode\n\n**Local mode environment check**:\n1. **Check Node.js version** - Requires 22+\n2. **Check pnpm** - Package manager\n3. **Check uv** - Python package manager\n4. **Check nginx** - Reverse proxy\n5. **Check required ports** - Confirm that ports 2026, 3000, and 8001 are not occupied\n\n**Docker mode environment check** (if Docker is selected):\n1. **Check whether Docker is installed** - Run `docker --version`\n2. **Check Docker daemon status** - Run `docker info`\n3. **Check Docker Compose availability** - Run `docker compose version`\n4. **Check required ports** - Confirm that port 2026 is not occupied\n\n### Phase 3: Configuration Preparation\n\n1. **Check whether config.yaml exists**\n - If it does not exist, run `make config` to generate it\n - If it already exists, check whether it needs an upgrade with `make config-upgrade`\n2. **Check the .env file**\n - Verify that required environment variables are configured\n - Especially model API keys such as `OPENAI_API_KEY`\n\n### Phase 4: Deployment Execution\n\n**Local mode deployment**:\n1. **Check dependencies** - Run `make check`\n2. **Install dependencies** - Run `make install`\n3. **(Optional) Pre-pull the sandbox image** - If needed, run `make setup-sandbox`\n4. **Start services** - Run `make start` (production mode)\n5. **Wait for startup** - Give all services enough time to start completely (90-120 seconds recommended)\n\n**Docker mode deployment** (if Docker is selected):\n1. **Initialize Docker environment** - Run `make docker-init`\n2. **Start Docker services** - Run `make up` (production mode)\n3. **Wait for startup** - Give all containers enough time to start completely (60 seconds recommended)\n\n### Phase 5: Service Health Check\n\n**Local mode health check**:\n1. **Check process status** - Confirm that Gateway, Frontend, and Nginx processes are all running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n**Docker mode health check** (when using Docker):\n1. **Check container status** - Run `docker ps` and confirm that all containers are running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n### Optional Functional Verification\n\n1. **List available models** - Verify that model configuration loads correctly\n2. **List available skills** - Verify that the skill directory is mounted correctly\n3. **Simple chat test** - Send a simple message to verify the end-to-end flow\n\n### Phase 6: Generate Test Report\n\n1. **Collect all test results** - Summarize execution status for each phase\n2. **Record encountered issues** - If anything fails, record the error details\n3. **Generate the final report** - Use the template that matches the selected deployment mode to create the complete test report, including overall conclusion, detailed key test cases, and explicit frontend page / route results\n4. **Provide follow-up recommendations** - Offer suggestions based on the test results\n\n## Execution Rules\n\n- **Follow the sequence** - Execute strictly in the order described above\n- **Idempotency** - Every step should be safe to repeat\n- **Error handling** - If a step fails, stop and report the issue, then provide troubleshooting suggestions\n- **Detailed logging** - Record the execution result and status of each step\n- **User confirmation** - Ask for confirmation before potentially risky operations such as overwriting config\n- **Mode preference** - Prefer local mode to avoid network-related issues\n- **Template requirement** - The final report must use the matching template under `templates/`; do not output a free-form summary instead of the template-based report\n- **Report clarity** - The execution summary must include the overall pass/fail conclusion plus per-case result explanations, and frontend smoke check results must be listed explicitly in the report\n- **Optional phase handling** - If functional verification is not executed, do not present it as a separate skipped phase in the final report\n\n## Known Acceptable Warnings\n\nThe following warnings can appear during smoke testing and do not block a successful result:\n- Feishu/Lark SSL errors in Gateway logs (certificate verification failure) can be ignored if that channel is not enabled\n- Warnings in Gateway logs about missing methods in the custom checkpointer, such as `adelete_for_runs` or `aprune`, do not affect the core functionality\n- The `frontend_check.sh` script automatically handles authentication. When auth is enabled it registers / logs in a smoke-test user (`smoke-test@deerflow.dev` by default) to verify the real `/workspace/*` pages. The registration may produce a log entry from the auth provider, which is expected and harmless.\n\n## Key Tools\n\nUse the following tools during execution:\n\n1. **bash** - Run shell commands\n2. **present_file** - Show generated reports and important files\n3. **task_tool** - Organize complex steps with subtasks when needed\n\n## Success Criteria\n\nSmoke test pass criteria (local mode):\n- [x] Latest code is pulled successfully\n- [x] Local environment check passes (Node.js 22+, pnpm, uv, nginx)\n- [x] Configuration files are set up correctly\n- [x] `make check` passes\n- [x] `make install` completes successfully\n- [x] `make dev` starts successfully\n- [x] All service processes run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\nSmoke test pass criteria (Docker mode):\n- [x] Latest code is pulled successfully\n- [x] Docker environment check passes\n- [x] Configuration files are set up correctly\n- [x] `make docker-init` completes successfully\n- [x] `make up` completes successfully\n- [x] All Docker containers run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\n## Read Reference Files\n\nBefore starting execution, read the following reference files:\n1. `references/SOP.md` - Detailed step-by-step operating instructions\n2. `references/troubleshooting.md` - Common issues and solutions\n3. `templates/report.local.template.md` - Local mode test report template\n4. `templates/report.docker.template.md` - Docker mode test report template\n","skills/public/systematic-literature-review/SKILL.md":"---\nname: systematic-literature-review\ndescription: Use this skill when the user wants a systematic literature review, survey, or synthesis across multiple academic papers on a topic. Also covers annotated bibliographies and cross-paper comparisons. Searches arXiv and outputs reports in APA, IEEE, or BibTeX format. Not for single-paper tasks — use academic-paper-review for reviewing one paper.\n---\n\n# Systematic Literature Review Skill\n\n## Overview\n\nThis skill produces a structured **systematic literature review (SLR)** across multiple academic papers on a research topic. Given a topic query, it searches arXiv, extracts structured metadata (research question, methodology, key findings, limitations) from each paper in parallel, synthesizes themes across the full set, and emits a final report with consistent citations.\n\n**Distinct from `academic-paper-review`:** that skill does deep peer review of a single paper. This skill does breadth-first synthesis across many papers. If the user hands you one paper URL and asks \"review this paper\", route to `academic-paper-review` instead.\n\n## When to Use This Skill\n\nUse this skill when the user wants any of the following:\n\n- A literature survey on a topic (\"survey transformer attention variants\", \"review the literature on diffusion models\")\n- A synthesis across multiple papers (\"what do recent papers say about X\", \"compare methodologies across papers on Y\")\n- A systematic review with consistent citation format (\"do an SLR on Z in APA format\")\n- An annotated bibliography on a topic\n- An overview of research trends in a field over a time window\n\nDo **not** use this skill when:\n\n- The user provides exactly one paper and asks to review it (use `academic-paper-review`)\n- The user asks a factual question that does not require synthesizing multiple sources (answer directly)\n- The user wants general web research without academic rigor (use standard web search)\n\n## Workflow\n\nThe workflow has five phases. Follow them in order.\n\n### Phase 1: Plan\n\nBefore doing any retrieval, confirm the following with the user. If any of these are unclear, ask **one** clarifying question that covers the missing pieces. Do not ask one question at a time.\n\n- **Topic**: the research area in plain English (e.g. \"transformer attention variants\").\n- **Scope**: how many papers (default 20, hard upper bound 50), optional time window (e.g. \"last 2 years\"), optional arXiv category (e.g. `cs.CL`, `cs.CV`).\n- **Citation format**: APA, IEEE, or BibTeX (default APA if the user does not specify and does not seem to be writing for a specific venue).\n- **Output location**: where to save the final report (default `/mnt/user-data/outputs/`).\n\nIf the user says \"50+ papers\", politely cap it at 50 and explain that synthesis quality degrades quickly past that — for larger surveys they should split by sub-topic.\n\n### Phase 2: Search arXiv\n\nCall the bundled search script. Do **not** try to scrape arXiv by other means and do **not** write your own HTTP client — this script handles URL encoding, Atom XML parsing, and id normalization correctly.\n\n```bash\npython /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \\\n \"\" \\\n --max-results \\\n [--category ] \\\n [--sort-by relevance] \\\n [--start-date YYYY-MM-DD] \\\n [--end-date YYYY-MM-DD]\n```\n\n**IMPORTANT — extract 2-3 core keywords before searching.** Do not pass the user's full topic description as the query. Before calling the script, mentally reduce the topic to its 2-3 most essential terms. Drop qualifiers like \"in computer vision\", \"for NLP\", \"variants\", \"recent\" — those belong in `--category` or `--start-date`, not in the query string.\n\n**Query phrasing — keep it short.** The script wraps multi-word queries in double quotes for phrase matching on arXiv. This means:\n\n- `\"diffusion models\"` → searches for the exact phrase → good, returns relevant papers.\n- `\"diffusion models in computer vision\"` → searches for that exact 5-word phrase → **too specific, likely returns 0 results** because few papers contain that exact string.\n\nUse **2-3 core keywords** as the query, and use `--category` to narrow the field instead of stuffing field names into the query. Examples:\n\n| User says | Good query | Bad query |\n|---|---|---|\n| \"diffusion models in computer vision\" | `\"diffusion models\" --category cs.CV` | `\"diffusion models in computer vision\"` |\n| \"transformer attention variants\" | `\"transformer attention\"` | `\"transformer attention variants in NLP\"` |\n| \"graph neural networks for molecules\" | `\"graph neural networks\" --category cs.LG` | `\"graph neural networks for molecular property prediction\"` |\n\nThe script prints a JSON array to stdout. Each paper has: `id`, `title`, `authors`, `abstract`, `published`, `updated`, `categories`, `pdf_url`, `abs_url`.\n\n**Sort strategy**:\n\n- **Always use `relevance` sorting** — arXiv's BM25-style scoring ensures results are actually about the user's topic. `submittedDate` sorting returns the most recently submitted papers in the category regardless of topic relevance, which produces mostly off-topic results.\n- When the user asks for \"recent\" papers or gives a time window, use `--sort-by relevance` **combined with `--start-date`** to constrain the time range while keeping results on-topic. For example, \"recent diffusion model papers\" → `--sort-by relevance --start-date 2024-01-01`, not `--sort-by submittedDate`.\n- `submittedDate` sorting is only appropriate when the user explicitly asks for chronological order (e.g. \"show me papers in the order they were published\"). This is rare.\n- `lastUpdatedDate` is rarely useful; ignore it unless the user asks.\n\n**Run the search exactly once.** Do not retry with modified queries if the results seem imperfect — arXiv's relevance ranking is what it is. Retrying with different query phrasings wastes tool calls and risks hitting the recursion limit. If the results are genuinely empty (0 papers), tell the user and suggest they broaden their topic or remove the category filter.\n\n**If the script returns fewer papers than requested**, that is the real size of the arXiv result set for the query. Do not pad the list — report the actual count to the user and proceed.\n\n**If the script fails** (network error, non-200 from arXiv), tell the user which error and stop. Do not try to fabricate paper metadata.\n\n**Do not save the search results to a file** — the JSON stays in your context for Phase 3. The only file saved during the entire workflow is the final report in Phase 5.\n\n### Phase 3: Extract metadata in parallel\n\n**You MUST delegate extraction to subagents via the `task` tool — do not extract metadata yourself.** This is non-negotiable. Specifically, do NOT do any of the following:\n\n- ❌ Write `python -c \"papers = [...]\"` or any Python/bash script to process papers\n- ❌ Extract metadata inline in your own context by reading abstracts one by one\n- ❌ Use any tool other than `task` for this phase\n\nInstead, you MUST call the `task` tool to spawn subagents. The reason: extracting 10-50 papers in your own context consumes too many tokens and degrades synthesis quality in Phase 4. Each subagent runs in an isolated context with only its batch of papers, producing cleaner extractions.\n\nSplit papers into batches of ~5, then for each batch, call the `task` tool with `subagent_type: \"general-purpose\"`. Each subagent receives the paper abstracts as text and returns structured JSON.\n\n**Concurrency limit: at most 3 subagents per turn.** The DeerFlow runtime enforces `MAX_CONCURRENT_SUBAGENTS = 3` and will silently drop any extra dispatches in the same turn — the LLM will not be told this happened, so strictly follow the round strategy below.\n\n**Round strategy — use this decision table, do not compute the split yourself**:\n\n| Paper count | Batches of ~5 papers | Rounds | Per-round subagent count |\n|---|---|---|---|\n| 1–5 | 1 batch | 1 round | 1 subagent |\n| 6–10 | 2 batches | 1 round | 2 subagents |\n| 11–15 | 3 batches | 1 round | 3 subagents |\n| 16–20 | 4 batches | 2 rounds | 3 + 1 |\n| 21–25 | 5 batches | 2 rounds | 3 + 2 |\n| 26–30 | 6 batches | 2 rounds | 3 + 3 |\n| 31–35 | 7 batches | 3 rounds | 3 + 3 + 1 |\n| 36–40 | 8 batches | 3 rounds | 3 + 3 + 2 |\n| 41–45 | 9 batches | 3 rounds | 3 + 3 + 3 |\n| 46–50 | 10 batches | 4 rounds | 3 + 3 + 3 + 1 |\n\n**Never dispatch more than 3 subagents in the same turn.** When a row says \"2 rounds (3 + 1)\", that means: first turn dispatches 3 subagents in parallel, wait for all 3 to complete, then second turn dispatches 1 subagent. Rounds are strictly sequential at the main-agent level.\n\nIf the paper count lands between rows (e.g. 23 papers), round up to the next row's layout but only dispatch as many batches as you actually need — the decision table gives you the shape, not a rigid prescription.\n\n**Do the batching at the main-agent level**: you already have every paper's abstract from Phase 2, so each subagent receives pure text input. Subagents should not need to access the network or the sandbox — their only job is to read text and return JSON. Do not ask subagents to re-run `arxiv_search.py`; that would waste tokens and risk rate-limiting.\n\n**What each subagent receives**, as a structured prompt:\n\n```\nExecute this task: extract structured metadata and key findings from the\nfollowing arXiv papers.\n\nPapers:\n[Paper 1]\narxiv_id: 1706.03762\ntitle: Attention Is All You Need\nauthors: Ashish Vaswani, Noam Shazeer, ...\npublished: 2017-06-12\nabstract: \n\n[Paper 2]\narxiv_id: ...\n...\n\nFor each paper, return a JSON object with these fields:\n- arxiv_id (string)\n- title (string)\n- authors (list of strings)\n- published_date (string, YYYY-MM-DD)\n- research_question (1 sentence, what problem the paper tackles)\n- methodology (1-2 sentences, how they tackle it)\n- key_findings (3-5 bullet points, what they actually found)\n- limitations (1-2 sentences, what they acknowledge or what is obviously missing)\n\nReturn the result as a JSON array, one object per paper, in the same\norder as the input. Do not include any text outside the JSON — no\npreamble, no markdown fences, just the array.\n```\n\n**Parsing subagent results**: the task tool returns strings with a fixed prefix like `Task Succeeded. Result: [...JSON...]`. Strip the `Task Succeeded. Result: ` prefix (or `Task failed.` / `Task timed out.` prefixes) before trying to parse JSON. If a batch fails or returns unparseable JSON, log it, note which papers were affected, and continue with the remaining batches — do not fail the whole synthesis on one bad batch.\n\nAfter all rounds complete, flatten the per-batch arrays into a single list of paper metadata objects, preserving order.\n\n### Phase 4: Synthesize and format\n\nNow produce the final SLR report. Two things happen here: cross-paper synthesis (thematic analysis) and citation formatting.\n\n**Cross-paper synthesis**: the report must do more than list papers. At minimum, identify:\n\n- **Themes**: 3-6 recurring research directions, approaches, or problem framings across the set.\n- **Convergences**: findings that multiple papers agree on.\n- **Disagreements**: where papers reach different conclusions or use incompatible methodologies.\n- **Gaps**: what the collective literature does not yet address (often stated explicitly in the \"limitations\" fields).\n\nIf the paper set is too small or too heterogeneous to support thematic synthesis (e.g. 5 papers on wildly different sub-topics), say so explicitly in the report — do not force themes that are not there.\n\n**Citation formatting**: the exact format depends on user preference. Read **only** the template file that matches the user's requested format, not all three:\n\n- [templates/apa.md](templates/apa.md) — APA 7th edition. Default for social sciences and most CS journals. Use when the user requests APA or does not specify a format.\n- [templates/ieee.md](templates/ieee.md) — IEEE numeric citations. Use when the user targets an IEEE conference or journal, or explicitly asks for IEEE.\n- [templates/bibtex.md](templates/bibtex.md) — BibTeX entries. Use when the user mentions BibTeX, LaTeX, or wants machine-readable references. **Important**: arXiv papers are cited as `@misc`, not `@article` — the BibTeX template covers this explicitly.\n\nEach template contains both the citation rules and a full report structure (executive summary, themes, per-paper annotations, references, methodology section). Follow the template's structure verbatim for the report body, then fill in content from your Phase 3 metadata.\n\n### Phase 5: Save and present\n\nSave the full report to `/mnt/user-data/outputs/slr--.md` where `` is a lowercased hyphenated version of the topic (e.g. `transformer-attention`). Then call the `present_files` tool with that path so the user can download it.\n\n**In the chat message**, show a short preview so the user immediately sees value without opening the file:\n\n1. **Executive summary** — the 3–5 sentence paragraph from the top of the report, verbatim.\n2. **Themes list** — bullet list of the themes you identified in Phase 4 synthesis (just the theme names + one-line gloss, not the full theme sections).\n3. **Paper count + a pointer to the file** — e.g. \"Full report with 20 papers, per-paper annotations, and formatted references saved to `slr-transformer-attention-20260409.md`.\"\n\nDo **not** dump the full 2000+ word report inline — per-paper annotations, references, and methodology belong in the file. The preview is there to let the user judge the report at a glance and decide whether to open it.\n\n## Examples\n\n**Example 1: Typical SLR request**\n\nUser: \"Do a systematic literature review of recent transformer attention variants, 20 papers, APA format.\"\n\nYour flow:\n1. Phase 1: confirm topic (transformer attention variants), scope (20 papers, default time window), format (APA). Ask **one** clarification only if something is missing (e.g. \"Any particular time window, or should I default to the last 3 years?\").\n2. Phase 2: `arxiv_search.py \"transformer attention\" --max-results 20 --sort-by relevance --start-date 2023-01-01`.\n3. Phase 3: 20 papers → round 1 = 3 subagents × 5 papers = 15 covered, round 2 = 1 subagent × 5 papers = 5 covered. Aggregate.\n4. Phase 4: read `templates/apa.md`, write the report using its structure, fill in themes + per-paper annotations from Phase 3 metadata.\n5. Phase 5: save to `slr-transformer-attention-20260409.md`, call `present_files`.\n\n**Example 2: Small-set request with ambiguity**\n\nUser: \"Survey a few papers on diffusion models for me.\"\n\nYour flow:\n1. Phase 1: \"a few\" is ambiguous. Ask one question: \"How many papers would you like — 10, 20, or 30? And any citation format preference (APA is the default)?\"\n2. User responds \"10, BibTeX\".\n3. Phase 2: `arxiv_search.py \"diffusion models\" --max-results 10 --category cs.CV`.\n4. Phase 3: 10 papers → single round, 2 subagents × 5 papers.\n5. Phase 4: read `templates/bibtex.md`, format with `@misc` entries (not `@article`).\n6. Phase 5: save and present.\n\n**Example 3: Out-of-scope request**\n\nUser: \"Here's one paper (https://arxiv.org/abs/1706.03762). Can you review it?\"\n\nThis is a single-paper peer review, not a literature survey. Do not use this skill. Route to `academic-paper-review` instead.\n\n## Notes\n\n- **Prerequisite: `subagent_enabled` must be `true`**. Phase 3 requires the `task` tool for parallel metadata extraction. This tool is only loaded when `subagent_enabled` is set to `true` in the runtime config (`config.configurable.subagent_enabled`). Without it, the `task` tool will not appear in the available tools and Phase 3 cannot execute as designed.\n- **arXiv only, by design**. This skill does not query Semantic Scholar, PubMed, or Google Scholar. arXiv covers the bulk of CS/ML/physics/math preprints, which is what DeerFlow users most often want to survey. Multi-source academic search belongs in a dedicated MCP server, not inside this skill.\n- **Hard upper bound of 50 papers**. This is tied to the Phase 3 concurrency strategy (max 3 subagents per round, ~5 papers each, at most ~3 rounds). Surveys larger than 50 papers degrade in synthesis quality and are better done by splitting into sub-topics.\n- **Phase 3 requires subagents to be enabled**. This skill's parallel extraction step hard-requires the `task` tool, which is only available when `subagent_enabled=true` at runtime. If subagents are unavailable, do not claim to execute the Phase 3 parallel plan; instead, tell the user that subagents must be enabled for the full workflow, or offer to narrow/split the request into a smaller manual review.\n- **Subagent results are strings, not objects**. Always strip the `Task Succeeded. Result: ` / `Task failed.` / `Task timed out.` prefixes before parsing the JSON payload.\n- **The `id` field is a bare arXiv id** (e.g. `1706.03762`), not a URL and not with a version suffix. `abs_url` / `pdf_url` hold the full URLs if you need them.\n- **Synthesis, not listing**. The final report must identify themes and compare findings across papers. A report that only lists papers one after another is a failure mode — if you cannot find themes, say so explicitly instead of faking them.\n","skills/public/podcast-generation/SKILL.md":"---\nname: podcast-generation\ndescription: Use this skill when the user requests to generate, create, or produce podcasts from text content. Converts written content into a two-host conversational podcast audio format with natural dialogue.\n---\n\n# Podcast Generation Skill\n\n## Overview\n\nThis skill generates high-quality podcast audio from text content. The workflow includes creating a structured JSON script (conversational dialogue) and executing audio generation through text-to-speech synthesis.\n\n## Core Capabilities\n\n- Convert any text content (articles, reports, documentation) into podcast scripts\n- Generate natural two-host conversational dialogue (male and female hosts)\n- Synthesize speech audio using text-to-speech\n- Mix audio chunks into a final podcast MP3 file\n- Support both English and Chinese content\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests podcast generation, identify:\n\n- Source content: The text/article/report to convert into a podcast\n- Language: English or Chinese (based on content)\n- Output location: Where to save the generated podcast\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Script JSON\n\nGenerate a structured JSON script file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}-script.json`\n\nThe JSON structure:\n```json\n{\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"dialogue text\"},\n {\"speaker\": \"female\", \"paragraph\": \"dialogue text\"}\n ]\n}\n```\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/podcast-generation/scripts/generate.py \\\n --script-file /mnt/user-data/workspace/script-file.json \\\n --output-file /mnt/user-data/outputs/generated-podcast.mp3 \\\n --transcript-file /mnt/user-data/outputs/generated-podcast-transcript.md\n```\n\nParameters:\n\n- `--script-file`: Absolute path to JSON script file (required)\n- `--output-file`: Absolute path to output MP3 file (required)\n- `--transcript-file`: Absolute path to output transcript markdown file (optional, but recommended)\n\n> [!IMPORTANT]\n> - Execute the script in one complete call. Do NOT split the workflow into separate steps.\n> - The script handles all TTS API calls and audio generation internally.\n> - Do NOT read the Python file, just call it with the parameters.\n> - Always include `--transcript-file` to generate a readable transcript for the user.\n> - The TTS provider and its concurrency are selected automatically from environment variables — you do not choose or tune them.\n\n## Script JSON Format\n\nThe script JSON file must follow this structure:\n\n```json\n{\n \"title\": \"The History of Artificial Intelligence\",\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"Hello Deer! Welcome back to another episode.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Hey everyone! Today we have an exciting topic to discuss.\"},\n {\"speaker\": \"male\", \"paragraph\": \"That's right! We're going to talk about...\"}\n ]\n}\n```\n\nFields:\n- `title`: Title of the podcast episode (optional, used as heading in transcript)\n- `locale`: Language code - \"en\" for English or \"zh\" for Chinese\n- `lines`: Array of dialogue lines\n - `speaker`: Either \"male\" or \"female\"\n - `paragraph`: The dialogue text for this speaker\n\n## Script Writing Guidelines\n\nWhen creating the script JSON, follow these guidelines:\n\n### Format Requirements\n- Only two hosts: male and female, alternating naturally\n- Target runtime: approximately 10 minutes of dialogue (around 40-60 lines)\n- Start with the male host saying a greeting that includes \"Hello Deer\"\n\n### Tone & Style\n- Natural, conversational dialogue - like two friends chatting\n- Use casual expressions and conversational transitions\n- Avoid overly formal language or academic tone\n- Include reactions, follow-up questions, and natural interjections\n\n### Content Guidelines\n- Frequent back-and-forth between hosts\n- Keep sentences short and easy to follow when spoken\n- Plain text only - no markdown formatting in the output\n- Translate technical concepts into accessible language\n- No mathematical formulas, code, or complex notation\n- Make content engaging and accessible for audio-only listeners\n- Exclude meta information like dates, author names, or document structure\n\n## Podcast Generation Example\n\nUser request: \"Generate a podcast about the history of artificial intelligence\"\n\nStep 1: Create script file `/mnt/user-data/workspace/ai-history-script.json`:\n```json\n{\n \"title\": \"The History of Artificial Intelligence\",\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"Hello Deer! Welcome back to another fascinating episode. Today we're diving into something that's literally shaping our future - the history of artificial intelligence.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Oh, I love this topic! You know, AI feels so modern, but it actually has roots going back over seventy years.\"},\n {\"speaker\": \"male\", \"paragraph\": \"Exactly! It all started back in the 1950s. The term artificial intelligence was actually coined by John McCarthy in 1956 at a famous conference at Dartmouth.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Wait, so they were already thinking about machines that could think back then? That's incredible!\"},\n {\"speaker\": \"male\", \"paragraph\": \"Right? The early pioneers were so optimistic. They thought we'd have human-level AI within a generation.\"},\n {\"speaker\": \"female\", \"paragraph\": \"But things didn't quite work out that way, did they?\"},\n {\"speaker\": \"male\", \"paragraph\": \"No, not at all. The 1970s brought what's called the first AI winter...\"}\n ]\n}\n```\n\nStep 2: Execute generation:\n```bash\npython /mnt/skills/public/podcast-generation/scripts/generate.py \\\n --script-file /mnt/user-data/workspace/ai-history-script.json \\\n --output-file /mnt/user-data/outputs/ai-history-podcast.mp3 \\\n --transcript-file /mnt/user-data/outputs/ai-history-transcript.md\n```\n\nThis will generate:\n- `ai-history-podcast.mp3`: The audio podcast file\n- `ai-history-transcript.md`: A readable markdown transcript of the podcast\n\n## Specific Templates\n\nRead the following template file only when matching the user request.\n\n- [Tech Explainer](templates/tech-explainer.md) - For converting technical documentation and tutorials\n\n## Output Format\n\nThe generated podcast follows the \"Hello Deer\" format:\n- Two hosts: one male, one female\n- Natural conversational dialogue\n- Starts with \"Hello Deer\" greeting\n- Target duration: approximately 10 minutes\n- Alternating speakers for engaging flow\n\n## Output Handling\n\nAfter generation:\n\n- Podcasts and transcripts are saved in `/mnt/user-data/outputs/`\n- Share both the podcast MP3 and transcript MD with user using `present_files` tool\n- Provide brief description of the generation result (topic, duration, hosts)\n- Offer to regenerate if adjustments needed\n\n## Requirements\n\nThe following environment variables must be set:\n- For Volcengine: `VOLCENGINE_TTS_APPID` and `VOLCENGINE_TTS_ACCESS_TOKEN`\n- For MiniMax: `MINIMAX_API_KEY`\n- `VOLCENGINE_TTS_CLUSTER`: Volcengine TTS cluster (optional, defaults to \"volcano_tts\")\n- `VOLCENGINE_TTS_VOICE_TYPE_MALE`: Volcengine male voice type (optional, defaults to `zh_male_yangguangqingnian_moon_bigtts`)\n- `VOLCENGINE_TTS_VOICE_TYPE_FEMALE`: Volcengine female voice type (optional, defaults to `zh_female_sajiaonvyou_moon_bigtts`)\n\nVoice type overrides are trimmed; unset or blank values use the listed defaults.\n\n## Notes\n\n- **Always execute the full pipeline in one call** - no need to test individual steps or worry about timeouts\n- The script JSON should match the content language (en or zh)\n- Technical content should be simplified for audio accessibility in the script\n- Complex notations (formulas, code) should be translated to plain language in the script\n- Long content may result in longer podcasts\n\n## Providers (Volcengine / MiniMax)\n\nAuto-selected by environment variables:\n\n- `VOLCENGINE_TTS_APPID` + `VOLCENGINE_TTS_ACCESS_TOKEN` set → Volcengine TTS (default).\n- Only `MINIMAX_API_KEY` set → MiniMax TTS (`/v1/t2a_v2`).\n- Force with `PODCAST_GENERATION_PROVIDER=volcengine|minimax`.\n\nMiniMax overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_TTS_MODEL` (default `speech-2.6-hd`), `MINIMAX_TTS_VOICE_MALE`\n(default `male-qn-qingse`), `MINIMAX_TTS_VOICE_FEMALE` (default `female-tianmei`).\n\nConcurrency is owned by each provider internally — MiniMax runs single-threaded\nto reduce rate-limit failures, Volcengine uses 4 workers. There is no\ncaller-facing concurrency knob; transient rate limits are handled by automatic\nretry with backoff.\n","skills/public/image-generation/SKILL.md":"---\nname: image-generation\ndescription: Use this skill when the user requests to generate, create, imagine, or visualize images including characters, scenes, products, or any visual content. Supports structured prompts and reference images for guided generation.\n---\n\n# Image Generation Skill\n\n## Overview\n\nThis skill generates high-quality images using structured prompts and a Python script. The workflow includes creating JSON-formatted prompts and executing image generation with optional reference images.\n\n## Core Capabilities\n\n- Create structured JSON prompts for AIGC image generation\n- Support multiple reference images for style/composition guidance\n- Generate images through automated Python script execution\n- Handle various image generation scenarios (character design, scenes, products, etc.)\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests image generation, identify:\n\n- Subject/content: What should be in the image\n- Style preferences: Art style, mood, color palette\n- Technical specs: Aspect ratio, composition, lighting\n- Reference images: Any images to guide generation\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Prompt\n\nGenerate a structured JSON file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}.json`\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/prompt-file.json \\\n --reference-images /path/to/ref1.jpg /path/to/ref2.png \\\n --output-file /mnt/user-data/outputs/generated-image.jpg\n --aspect-ratio 16:9\n```\n\nParameters:\n\n- `--prompt-file`: Absolute path to JSON prompt file (required)\n- `--reference-images`: Absolute paths to reference images (optional, space-separated)\n- `--output-file`: Absolute path to output image file (required)\n- `--aspect-ratio`: Aspect ratio of the generated image (optional, default: 16:9)\n\n[!NOTE]\nDo NOT read the python file, just call it with the parameters.\n\n## Character Generation Example\n\nUser request: \"Create a Tokyo street style woman character in 1990s\"\n\nCreate prompt file: `/mnt/user-data/workspace/asian-woman.json`\n```json\n{\n \"characters\": [{\n \"gender\": \"female\",\n \"age\": \"mid-20s\",\n \"ethnicity\": \"Japanese\",\n \"body_type\": \"slender, elegant\",\n \"facial_features\": \"delicate features, expressive eyes, subtle makeup with emphasis on lips, long dark hair partially wet from rain\",\n \"clothing\": \"stylish trench coat, designer handbag, high heels, contemporary Tokyo street fashion\",\n \"accessories\": \"minimal jewelry, statement earrings, leather handbag\",\n \"era\": \"1990s\"\n }],\n \"negative_prompt\": \"blurry face, deformed, low quality, overly sharp digital look, oversaturated colors, artificial lighting, studio setting, posed, selfie angle\",\n \"style\": \"Leica M11 street photography aesthetic, film-like rendering, natural color palette with slight warmth, bokeh background blur, analog photography feel\",\n \"composition\": \"medium shot, rule of thirds, subject slightly off-center, environmental context of Tokyo street visible, shallow depth of field isolating subject\",\n \"lighting\": \"neon lights from signs and storefronts, wet pavement reflections, soft ambient city glow, natural street lighting, rim lighting from background neons\",\n \"color_palette\": \"muted naturalistic tones, warm skin tones, cool blue and magenta neon accents, desaturated compared to digital photography, film grain texture\"\n}\n```\n\nExecute generation:\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/cyberpunk-hacker.json \\\n --output-file /mnt/user-data/outputs/cyberpunk-hacker-01.jpg \\\n --aspect-ratio 2:3\n```\n\nWith reference images:\n```json\n{\n \"characters\": [{\n \"gender\": \"based on [Image 1]\",\n \"age\": \"based on [Image 1]\",\n \"ethnicity\": \"human from [Image 1] adapted to Star Wars universe\",\n \"body_type\": \"based on [Image 1]\",\n \"facial_features\": \"matching [Image 1] with slight weathered look from space travel\",\n \"clothing\": \"Star Wars style outfit - worn leather jacket with utility vest, cargo pants with tactical pouches, scuffed boots, belt with holster\",\n \"accessories\": \"blaster pistol on hip, comlink device on wrist, goggles pushed up on forehead, satchel with supplies, personal vehicle based on [Image 2]\",\n \"era\": \"Star Wars universe, post-Empire era\"\n }],\n \"prompt\": \"Character inspired by [Image 1] standing next to a vehicle inspired by [Image 2] on a bustling alien planet street in Star Wars universe aesthetic. Character wearing worn leather jacket with utility vest, cargo pants with tactical pouches, scuffed boots, belt with blaster holster. The vehicle adapted to Star Wars aesthetic with weathered metal panels, repulsor engines, desert dust covering, parked on the street. Exotic alien marketplace street with multi-level architecture, weathered metal structures, hanging market stalls with colorful awnings, alien species walking by as background characters. Twin suns casting warm golden light, atmospheric dust particles in air, moisture vaporators visible in distance. Gritty lived-in Star Wars aesthetic, practical effects look, film grain texture, cinematic composition.\",\n \"negative_prompt\": \"clean futuristic look, sterile environment, overly CGI appearance, fantasy medieval elements, Earth architecture, modern city\",\n \"style\": \"Star Wars original trilogy aesthetic, lived-in universe, practical effects inspired, cinematic film look, slightly desaturated with warm tones\",\n \"composition\": \"medium wide shot, character in foreground with alien street extending into background, environmental storytelling, rule of thirds\",\n \"lighting\": \"warm golden hour lighting from twin suns, rim lighting on character, atmospheric haze, practical light sources from market stalls\",\n \"color_palette\": \"warm sandy tones, ochre and sienna, dusty blues, weathered metals, muted earth colors with pops of alien market colors\",\n \"technical\": {\n \"aspect_ratio\": \"9:16\",\n \"quality\": \"high\",\n \"detail_level\": \"highly detailed with film-like texture\"\n }\n}\n```\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/star-wars-scene.json \\\n --reference-images /mnt/user-data/uploads/character-ref.jpg /mnt/user-data/uploads/vehicle-ref.jpg \\\n --output-file /mnt/user-data/outputs/star-wars-scene-01.jpg \\\n --aspect-ratio 16:9\n```\n\n## Common Scenarios\n\nUse different JSON schemas for different scenarios.\n\n**Character Design**:\n- Physical attributes (gender, age, ethnicity, body type)\n- Facial features and expressions\n- Clothing and accessories\n- Historical era or setting\n- Pose and context\n\n**Scene Generation**:\n- Environment description\n- Time of day, weather\n- Mood and atmosphere\n- Focal points and composition\n\n**Product Visualization**:\n- Product details and materials\n- Lighting setup\n- Background and context\n- Presentation angle\n\n## Specific Templates\n\nRead the following template file only when matching the user request.\n\n- [Doraemon Comic](templates/doraemon.md)\n\n## Output Handling\n\nAfter generation:\n\n- Images are typically saved in `/mnt/user-data/outputs/`\n- Share generated images with user using present_files tool\n- Provide brief description of the generation result\n- Offer to iterate if adjustments needed\n\n## Tips: Enhancing Generation with Reference Images\n\nFor scenarios where visual accuracy is critical, **use the `image_search` tool first** to find reference images before generation.\n\n**Recommended scenarios for using image_search tool:**\n- **Character/Portrait Generation**: Search for similar poses, expressions, or styles to guide facial features and body proportions\n- **Specific Objects or Products**: Find reference images of real objects to ensure accurate representation\n- **Architectural or Environmental Scenes**: Search for location references to capture authentic details\n- **Fashion and Clothing**: Find style references to ensure accurate garment details and styling\n\n**Example workflow:**\n1. Call the `image_search` tool to find suitable reference images:\n ```\n image_search(query=\"Japanese woman street photography 1990s\", size=\"Large\")\n ```\n2. Download the returned image URLs to local files\n3. Use the downloaded images as `--reference-images` parameter in the generation script\n\nThis approach significantly improves generation quality by providing the model with concrete visual guidance rather than relying solely on text descriptions.\n\n## Providers (Gemini / MiniMax / OpenAI-compatible)\n\nThis skill auto-selects the provider by environment variables (no CLI change):\n\n- `GEMINI_API_KEY` set → use Gemini (default, unchanged).\n- Otherwise, `MINIMAX_API_KEY` set → use MiniMax (`/v1/image_generation`, model `image-01`).\n- Otherwise, `IMAGE_GENERATION_API_KEY` set → use an OpenAI-compatible Images API.\n- Force one explicitly with `IMAGE_GENERATION_PROVIDER=gemini|minimax|openai`.\n `openai-compatible` is also accepted as an alias for `openai`.\n\nOpenAI-compatible settings:\n\n- `IMAGE_GENERATION_API_KEY` (required)\n- `IMAGE_GENERATION_BASE_URL` (default `https://api.openai.com/v1`)\n- `IMAGE_GENERATION_MODEL` (default `gpt-image-2.5-flare`)\n- `IMAGE_GENERATION_SIZE` (optional fixed size override)\n\nText-to-image calls use `POST {base_url}/images/generations`. Reference-image calls\nuse multipart `POST {base_url}/images/edits`; a relay may support generation without\nsupporting edits. Responses may contain base64 image data, a data URL, or a downloadable\nURL. Aspect ratios map to `1024x1024`, `1536x1024`, or `1024x1536` unless\n`IMAGE_GENERATION_SIZE` is set. The output extension selects the API `output_format`:\n`.jpg`/`.jpeg` uses `jpeg`, `.webp` uses `webp`, and all other extensions use `png`.\nWhen `dall-e-2` or `dall-e-3` is configured instead, the request uses the model's\nsupported dimensions and `response_format=b64_json`; DALL-E output files must use a\n`.png` extension. Reference-image editing with DALL-E models is not supported by this\nskill; use the default GPT Image model for edits.\n\nMiniMax optional overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_IMAGE_MODEL` (default `image-01`). Reference images are sent as the MiniMax\n`subject_reference` character image. The CLI and `--prompt-file` / `--reference-images`\n/ `--output-file` / `--aspect-ratio` arguments are identical for both providers.\n\n**MiniMax prompt handling (provider-internal).** Authoring is provider-agnostic — write\nthe same structured JSON regardless of which provider is active. MiniMax `image-01`\nconsumes a single text string, so the MiniMax path itself sends only the JSON `prompt`\nfield (the other fields such as `style` / `composition` / `negative_prompt` apply to the\nGemini path) and enables `prompt_optimizer` so MiniMax expands it server-side. MiniMax\ncaps that prompt at 1500 characters; if the `prompt` field is longer, the script returns\nan error instead of calling the API. The Gemini path receives the full structured JSON.\n\n## Notes\n\n- Always use English for prompts regardless of user's language\n- JSON format ensures structured, parsable prompts\n- Reference images enhance generation quality significantly\n- Iterative refinement is normal for optimal results\n- For character generation, include the detailed character object plus a consolidated prompt field\n","skills/public/newsletter-generation/SKILL.md":"---\nname: newsletter-generation\ndescription: Use this skill when the user requests to generate, create, write, or draft a newsletter, email digest, weekly roundup, industry briefing, or curated content summary. Supports topic-based research, content curation from multiple sources, and professional formatting for email or web distribution. Trigger on requests like \"create a newsletter about X\", \"write a weekly digest\", \"generate a tech roundup\", or \"curate news about Y\".\n---\n\n# Newsletter Generation Skill\n\n## Overview\n\nThis skill generates professional, well-researched newsletters that combine curated content from multiple sources with original analysis and commentary. It follows modern newsletter best practices from publications like Morning Brew, The Hustle, TLDR, and Benedict Evans to produce content that is informative, engaging, and actionable.\n\nThe output is a complete, ready-to-publish newsletter in Markdown format, suitable for email distribution platforms, web publishing, or conversion to HTML.\n\n## Core Capabilities\n\n- Research and curate content from multiple web sources on specified topics\n- Generate topic-focused or multi-topic newsletters with consistent voice\n- Write engaging headlines, summaries, and original commentary\n- Structure content for optimal readability and scanning\n- Support multiple newsletter formats (daily digest, weekly roundup, deep-dive, industry briefing)\n- Include relevant links, sources, and attributions\n- Adapt tone and style to target audience (technical, executive, general)\n- Generate recurring newsletter series with consistent branding and structure\n\n## When to Use This Skill\n\n**Always load this skill when:**\n\n- User asks to generate a newsletter, email digest, or content roundup\n- User requests a curated summary of news or developments on a topic\n- User wants to create a recurring newsletter format\n- User asks to compile recent developments in a field into a briefing\n- User needs a formatted email-ready content piece with multiple curated items\n- User asks for a \"weekly roundup\", \"monthly digest\", or \"morning briefing\"\n\n## Newsletter Workflow\n\n### Phase 1: Planning\n\n#### Step 1.1: Understand Newsletter Requirements\n\nIdentify the key parameters:\n\n| Parameter | Description | Default |\n|-----------|-------------|---------|\n| **Topic(s)** | Primary subject area(s) to cover | Required |\n| **Format** | Daily digest, weekly roundup, deep-dive, or industry briefing | Weekly roundup |\n| **Target Audience** | Technical, executive, general, or niche community | General |\n| **Tone** | Professional, conversational, witty, or analytical | Conversational-professional |\n| **Length** | Short (5-min read), medium (10-min), long (15-min+) | Medium |\n| **Sections** | Number and type of content sections | 4-6 sections |\n| **Frequency Context** | One-time or part of a recurring series | One-time |\n\n#### Step 1.2: Define Newsletter Structure\n\nBased on the format, select the appropriate structure:\n\n**Daily Digest Structure**:\n```\n1. Top Story (1 item, detailed)\n2. Quick Hits (3-5 items, brief)\n3. One Stat / Quote of the Day\n4. What to Watch\n```\n\n**Weekly Roundup Structure**:\n```\n1. Editor's Note / Intro\n2. Top Stories (2-3 items, detailed)\n3. Trends & Analysis (1-2 items, original commentary)\n4. Quick Bites (4-6 items, brief summaries)\n5. Tools & Resources (2-3 items)\n6. One More Thing / Closing\n```\n\n**Deep-Dive Structure**:\n```\n1. Introduction & Context\n2. Background / Why It Matters\n3. Key Developments (detailed analysis)\n4. Expert Perspectives\n5. What's Next / Implications\n6. Further Reading\n```\n\n**Industry Briefing Structure**:\n```\n1. Executive Summary\n2. Market Developments\n3. Company News & Moves\n4. Product & Technology Updates\n5. Regulatory & Policy Changes\n6. Data & Metrics\n7. Outlook\n```\n\n### Phase 2: Research & Curation\n\n#### Step 2.1: Multi-Source Research\n\nConduct thorough research using web search. **The quality of the newsletter depends directly on the quality and recency of research.**\n\n**Search Strategy**:\n\n```\n# Current news and developments\n\"[topic] news [current month] [current year]\"\n\"[topic] latest developments\"\n\"[topic] announcement this week\"\n\n# Trends and analysis\n\"[topic] trends [current year]\"\n\"[topic] analysis expert opinion\"\n\"[topic] industry report\"\n\n# Data and statistics\n\"[topic] statistics [current year]\"\n\"[topic] market data latest\"\n\"[topic] growth metrics\"\n\n# Tools and resources\n\"[topic] new tools [current year]\"\n\"[topic] open source release\"\n\"best [topic] resources [current year]\"\n```\n\n> **IMPORTANT**: Always check `` to ensure search queries use the correct temporal context. Never use hardcoded years.\n\n#### Step 2.2: Source Evaluation and Selection\n\nEvaluate each source and curate the best content:\n\n| Criterion | Priority |\n|-----------|----------|\n| **Recency** | Prefer content from the last 7-30 days |\n| **Authority** | Prioritize primary sources, official announcements, established publications |\n| **Uniqueness** | Select stories that offer fresh perspective or are underreported |\n| **Relevance** | Every item must clearly connect to the newsletter's stated topic(s) |\n| **Actionability** | Prefer content readers can act on (tools, insights, strategies) |\n| **Diversity** | Mix of news, analysis, data, and practical resources |\n\n#### Step 2.3: Deep Content Extraction\n\nFor key stories, use `web_fetch` to read full articles and extract:\n\n1. **Core facts** — What happened, who is involved, when\n2. **Context** — Why this matters, background information\n3. **Data points** — Specific numbers, metrics, or statistics\n4. **Quotes** — Relevant expert quotes or official statements\n5. **Implications** — What this means for the reader\n\n### Phase 3: Writing\n\n#### Step 3.1: Newsletter Header\n\nEvery newsletter starts with a consistent header:\n\n```markdown\n# [Newsletter Name]\n\n*[Tagline or description] — [Date]*\n\n---\n\n[Optional: One-sentence preview of what's inside]\n```\n\n#### Step 3.2: Section Writing Guidelines\n\n**Top Stories / Featured Items**:\n- **Headline**: Compelling, clear, benefit-oriented (not clickbait)\n- **Hook**: Opening sentence that makes the reader care (1-2 sentences)\n- **Body**: Key facts and context (2-4 paragraphs)\n- **Why it matters**: Connect to the reader's world (1 paragraph)\n- **Source link**: Always attribute and link to the original source\n\n**Quick Bites / Brief Items**:\n- **Format**: Bold headline + 2-3 sentence summary + source link\n- **Focus**: One key takeaway per item\n- **Efficiency**: Readers should get the essential insight without clicking through\n\n**Analysis / Commentary Sections**:\n- **Voice**: The newsletter's unique perspective on trends or developments\n- **Structure**: Observation → Context → Implication → (Optional) Actionable takeaway\n- **Evidence**: Every claim backed by data or sourced information\n\n#### Step 3.3: Writing Standards\n\n| Principle | Implementation |\n|-----------|---------------|\n| **Scannable** | Use headers, bold text, bullet points, and short paragraphs |\n| **Engaging** | Lead with the most interesting angle, not chronological order |\n| **Concise** | Every sentence earns its place — cut filler ruthlessly |\n| **Accurate** | Every fact is sourced, every number is verified |\n| **Attributive** | Always credit original sources with inline links |\n| **Human** | Write like a knowledgeable friend, not a press release |\n\n**Tone Calibration by Audience**:\n\n| Audience | Tone | Example |\n|----------|------|---------|\n| **Technical** | Precise, no jargon explanations, assumed expertise | \"The new API supports gRPC streaming with backpressure handling via flow control windows.\" |\n| **Executive** | Impact-focused, bottom-line, strategic | \"This acquisition gives Company X a 40% market share in the enterprise segment, directly threatening Incumbent Y's pricing power.\" |\n| **General** | Accessible, analogies, explains concepts | \"Think of it like a universal translator for data — it lets any app talk to any database without learning a new language.\" |\n\n### Phase 4: Assembly & Polish\n\n#### Step 4.1: Assemble the Newsletter\n\nCombine all sections into the final document following the chosen structure template.\n\n#### Step 4.2: Footer\n\nEvery newsletter ends with:\n\n```markdown\n---\n\n*[Newsletter Name] is [description of what it is].*\n*[How to subscribe/share/give feedback]*\n\n*Sources: All links are provided inline. This newsletter curates and summarizes\npublicly available information with original commentary.*\n```\n\n#### Step 4.3: Quality Checklist\n\nBefore finalizing, verify:\n\n- [ ] **Every factual claim has a source link** — No unsourced assertions\n- [ ] **All links are functional** — Verified URLs from search results\n- [ ] **Date references use the actual current date** — No hardcoded or assumed dates\n- [ ] **Content is current** — All major items are from within the expected timeframe\n- [ ] **No duplicate stories** — Each item appears only once\n- [ ] **Consistent formatting** — Headers, bullets, links use the same style throughout\n- [ ] **Balanced coverage** — Not dominated by a single source or perspective\n- [ ] **Appropriate length** — Matches the specified length target\n- [ ] **Engaging opening** — The first 2 sentences make the reader want to continue\n- [ ] **Clear closing** — The newsletter ends with a memorable or actionable note\n- [ ] **Proofread** — No typos, broken formatting, or incomplete sentences\n\n## Newsletter Output Template\n\n```markdown\n# [Newsletter Name]\n\n*[Tagline] — [Full date, e.g., April 4, 2026]*\n\n---\n\n[Preview sentence: \"This week: [topic 1], [topic 2], and [topic 3].\"]\n\n## 🔥 Top Stories\n\n### [Headline 1]\n\n[Hook — why this matters in 1-2 sentences.]\n\n[Body — 2-4 paragraphs covering key facts, context, and implications.]\n\n**Why it matters:** [1 paragraph connecting to reader's interests or industry impact.]\n\n📎 [Source: Publication Name](URL)\n\n### [Headline 2]\n\n[Same structure as above]\n\n## 📊 Trends & Analysis\n\n### [Trend Title]\n\n[Original commentary on an emerging trend, backed by data from research.]\n\n[Key data points presented clearly — consider inline stats or a brief comparison.]\n\n**The bottom line:** [One-sentence takeaway.]\n\n## ⚡ Quick Bites\n\n- **[Headline]** — [2-3 sentence summary with key takeaway.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n\n## 🛠️ Tools & Resources\n\n- **[Tool/Resource Name]** — [What it does and why it's useful.] [Link](URL)\n- **[Tool/Resource Name]** — [Description.] [Link](URL)\n\n## 💬 One More Thing\n\n[Closing thought, insightful quote, or forward-looking statement.]\n\n---\n\n*[Newsletter Name] curates the most important [topic] news and analysis.*\n*Found this useful? Share it with a colleague.*\n\n*All sources are linked inline. Views and commentary are original.*\n```\n\n## Adaptation Examples\n\n### Technology Newsletter\n- Emoji usage: ✅ Moderate (section headers)\n- Sections: Top Stories, Deep Dive, Quick Bites, Open Source Spotlight, Dev Tools\n- Tone: Technical-conversational\n\n### Business/Finance Newsletter\n- Emoji usage: ❌ Minimal to none\n- Sections: Market Overview, Deal Flow, Company News, Data Corner, Outlook\n- Tone: Professional-analytical\n\n### Industry-Specific Newsletter\n- Emoji usage: Moderate\n- Sections: Regulatory Updates, Market Data, Innovation Watch, People Moves, Events\n- Tone: Expert-authoritative\n\n### Creative/Marketing Newsletter\n- Emoji usage: ✅ Liberal\n- Sections: Campaign Spotlight, Trend Watch, Viral This Week, Tools We Love, Inspiration\n- Tone: Enthusiastic-professional\n\n## Output Handling\n\nAfter generation:\n\n- Save the newsletter to `/mnt/user-data/outputs/newsletter-{topic}-{date}.md`\n- Present the newsletter to the user using the `present_files` tool\n- Offer to adjust sections, tone, length, or focus areas\n- If the user wants HTML output, note that the Markdown can be converted using standard tools\n\n## Notes\n\n- This skill works best in combination with the `deep-research` skill for comprehensive topic coverage — load both for newsletters requiring deep analysis\n- Always use `` for temporal context in searches and date references in the newsletter\n- For recurring newsletters, suggest maintaining a consistent structure so readers develop expectations\n- When curating, quality beats quantity — 5 excellent items beat 15 mediocre ones\n- Attribute all content properly — newsletters build trust through transparent sourcing\n- Avoid summarizing paywalled content that the reader cannot access\n- If the user provides specific URLs or articles to include, incorporate them alongside your curated findings\n- The newsletter should provide enough value in the summaries that readers benefit even without clicking through to every link\n","skills/public/ppt-generation/SKILL.md":"---\nname: ppt-generation\ndescription: Use this skill when the user requests to generate, create, or make presentations (PPT/PPTX). Creates visually rich slides by generating images for each slide and composing them into a PowerPoint file.\n---\n\n# PPT Generation Skill\n\n## Overview\n\nThis skill generates professional PowerPoint presentations by creating AI-generated images for each slide and composing them into a PPTX file. The workflow includes planning the presentation structure with a consistent visual style, generating slide images sequentially (using the previous slide as a reference for style consistency), and assembling them into a final presentation.\n\n## Core Capabilities\n\n- Plan and structure multi-slide presentations with unified visual style\n- Support multiple presentation styles: Business, Academic, Minimal, Apple Keynote, Creative\n- Generate unique AI images for each slide using image-generation skill\n- Maintain visual consistency by using previous slide as reference image\n- Compose images into a professional PPTX file\n\n## Presentation Styles\n\nChoose one of the following styles when creating the presentation plan:\n\n| Style | Description | Best For |\n|-------|-------------|----------|\n| **glassmorphism** | Frosted glass panels with blur effects, floating translucent cards, vibrant gradient backgrounds, depth through layering | Tech products, AI/SaaS demos, futuristic pitches |\n| **dark-premium** | Rich black backgrounds (#0a0a0a), luminous accent colors, subtle glow effects, luxury brand aesthetic | Premium products, executive presentations, high-end brands |\n| **gradient-modern** | Bold mesh gradients, fluid color transitions, contemporary typography, vibrant yet sophisticated | Startups, creative agencies, brand launches |\n| **neo-brutalist** | Raw bold typography, high contrast, intentional \"ugly\" aesthetic, anti-design as design, Memphis-inspired | Edgy brands, Gen-Z targeting, disruptive startups |\n| **3d-isometric** | Clean isometric illustrations, floating 3D elements, soft shadows, tech-forward aesthetic | Tech explainers, product features, SaaS presentations |\n| **editorial** | Magazine-quality layouts, sophisticated typography hierarchy, dramatic photography, Vogue/Bloomberg aesthetic | Annual reports, luxury brands, thought leadership |\n| **minimal-swiss** | Grid-based precision, Helvetica-inspired typography, bold use of negative space, timeless modernism | Architecture, design firms, premium consulting |\n| **keynote** | Apple-inspired aesthetic with bold typography, dramatic imagery, high contrast, cinematic feel | Keynotes, product reveals, inspirational talks |\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests presentation generation, identify:\n\n- Topic/subject: What is the presentation about\n- Number of slides: How many slides are needed (default: 5-10)\n- **Style**: business / academic / minimal / keynote / creative\n- Aspect ratio: Standard (16:9) or classic (4:3)\n- Content outline: Key points for each slide\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Presentation Plan\n\nCreate a JSON file in `/mnt/user-data/workspace/` with the presentation structure. **Important**: Include the `style` field to define the overall visual consistency.\n\n```json\n{\n \"title\": \"Presentation Title\",\n \"style\": \"keynote\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep black backgrounds, white text, single accent color (blue or orange)\",\n \"typography\": \"Bold sans-serif headlines, clean body text, dramatic size contrast\",\n \"imagery\": \"High-quality photography, full-bleed images, cinematic composition\",\n \"layout\": \"Generous whitespace, centered focus, minimal elements per slide\"\n },\n \"aspect_ratio\": \"16:9\",\n \"slides\": [\n {\n \"slide_number\": 1,\n \"type\": \"title\",\n \"title\": \"Main Title\",\n \"subtitle\": \"Subtitle or tagline\",\n \"visual_description\": \"Detailed description for image generation\"\n },\n {\n \"slide_number\": 2,\n \"type\": \"content\",\n \"title\": \"Slide Title\",\n \"key_points\": [\"Point 1\", \"Point 2\", \"Point 3\"],\n \"visual_description\": \"Detailed description for image generation\"\n }\n ]\n}\n```\n\n### Step 3: Generate Slide Images Sequentially\n\n**IMPORTANT**: Generate slides **strictly one by one, in order**. Do NOT parallelize or batch image generation. Each slide depends on the previous slide's output as a reference image. Generating slides in parallel will break visual consistency and is not allowed.\n\n1. Read the image-generation skill: `/mnt/skills/public/image-generation/SKILL.md`\n\n2. **For the FIRST slide (slide 1)**, create a prompt that establishes the visual style:\n\n```json\n{\n \"prompt\": \"Professional presentation slide. [style_guidelines from plan]. Title: 'Your Title'. [visual_description]. This slide establishes the visual language for the entire presentation.\",\n \"style\": \"[Based on chosen style - e.g., Apple Keynote aesthetic, dramatic lighting, cinematic]\",\n \"composition\": \"Clean layout with clear text hierarchy, [style-specific composition]\",\n \"color_palette\": \"[From style_guidelines]\",\n \"typography\": \"[From style_guidelines]\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-01-prompt.json \\\n --output-file /mnt/user-data/outputs/slide-01.jpg \\\n --aspect-ratio 16:9\n```\n\n3. **For subsequent slides (slide 2+)**, use the PREVIOUS slide as a reference image:\n\n```json\n{\n \"prompt\": \"Professional presentation slide continuing the visual style from the reference image. Maintain the same color palette, typography style, and overall aesthetic. Title: 'Slide Title'. [visual_description]. Keep visual consistency with the reference.\",\n \"style\": \"Match the style of the reference image exactly\",\n \"composition\": \"Similar layout principles as reference, adapted for this content\",\n \"color_palette\": \"Same as reference image\",\n \"consistency_note\": \"This slide must look like it belongs in the same presentation as the reference image\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-02-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-01.jpg \\\n --output-file /mnt/user-data/outputs/slide-02.jpg \\\n --aspect-ratio 16:9\n```\n\n4. **Continue for all remaining slides**, always referencing the previous slide:\n\n```bash\n# Slide 3 references slide 2\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-03-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-02.jpg \\\n --output-file /mnt/user-data/outputs/slide-03.jpg \\\n --aspect-ratio 16:9\n\n# Slide 4 references slide 3\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-04-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-03.jpg \\\n --output-file /mnt/user-data/outputs/slide-04.jpg \\\n --aspect-ratio 16:9\n```\n\n### Step 4: Compose PPT\n\nAfter all slide images are generated, call the composition script:\n\n```bash\npython /mnt/skills/public/ppt-generation/scripts/generate.py \\\n --plan-file /mnt/user-data/workspace/presentation-plan.json \\\n --slide-images /mnt/user-data/outputs/slide-01.jpg /mnt/user-data/outputs/slide-02.jpg /mnt/user-data/outputs/slide-03.jpg \\\n --output-file /mnt/user-data/outputs/presentation.pptx\n```\n\nParameters:\n\n- `--plan-file`: Absolute path to the presentation plan JSON file (required)\n- `--slide-images`: Absolute paths to slide images in order (required, space-separated)\n- `--output-file`: Absolute path to output PPTX file (required)\n\n[!NOTE]\nDo NOT read the python file, just call it with the parameters.\n\n## Complete Example: Glassmorphism Style (最现代前卫)\n\nUser request: \"Create a presentation about AI product launch\"\n\n### Step 1: Create presentation plan\n\nCreate `/mnt/user-data/workspace/ai-product-plan.json`:\n```json\n{\n \"title\": \"Introducing Nova AI\",\n \"style\": \"glassmorphism\",\n \"style_guidelines\": {\n \"color_palette\": \"Vibrant purple-to-cyan gradient background (#667eea→#00d4ff), frosted glass panels with 15-20% white opacity, electric accents\",\n \"typography\": \"SF Pro Display style, bold 700 weight white titles with subtle text-shadow, clean 400 weight body text, excellent contrast on glass\",\n \"imagery\": \"Abstract 3D glass spheres, floating translucent geometric shapes, soft luminous orbs, depth through layered transparency\",\n \"layout\": \"Centered frosted glass cards with 32px rounded corners, 48-64px padding, floating above gradient, layered depth with soft shadows\",\n \"effects\": \"Backdrop blur 20-40px on glass panels, subtle white border glow, soft colored shadows matching gradient, light refraction effects\",\n \"visual_language\": \"Apple Vision Pro / visionOS aesthetic, premium depth through transparency, futuristic yet approachable, 2024 design trends\"\n },\n \"aspect_ratio\": \"16:9\",\n \"slides\": [\n {\n \"slide_number\": 1,\n \"type\": \"title\",\n \"title\": \"Introducing Nova AI\",\n \"subtitle\": \"Intelligence, Reimagined\",\n \"visual_description\": \"Stunning gradient background flowing from deep purple (#667eea) through magenta to cyan (#00d4ff). Center: large frosted glass panel with strong backdrop blur, containing bold white title 'Introducing Nova AI' and lighter subtitle. Floating 3D glass spheres and abstract shapes around the card creating depth. Soft glow emanating from behind the glass panel. Premium visionOS aesthetic. The glass card has subtle white border (1px rgba 255,255,255,0.3) and soft purple-tinted shadow.\"\n },\n {\n \"slide_number\": 2,\n \"type\": \"content\",\n \"title\": \"Why Nova?\",\n \"key_points\": [\"10x faster processing\", \"Human-like understanding\", \"Enterprise-grade security\"],\n \"visual_description\": \"Same purple-cyan gradient background. Left side: floating frosted glass card with title 'Why Nova?' in bold white, three key points below with subtle glass pill badges. Right side: abstract 3D visualization of neural network as interconnected glass nodes with soft glow. Floating translucent geometric shapes (icosahedrons, tori) adding depth. Consistent glassmorphism aesthetic with previous slide.\"\n },\n {\n \"slide_number\": 3,\n \"type\": \"content\",\n \"title\": \"How It Works\",\n \"key_points\": [\"Natural language input\", \"Multi-modal processing\", \"Instant insights\"],\n \"visual_description\": \"Gradient background consistent with previous slides. Central composition: three stacked frosted glass cards at slight angles showing the workflow steps, connected by soft glowing lines. Each card has an abstract icon. Floating glass orbs and light particles around the composition. Title 'How It Works' in bold white at top. Depth created through card layering and transparency.\"\n },\n {\n \"slide_number\": 4,\n \"type\": \"content\",\n \"title\": \"Built for Scale\",\n \"key_points\": [\"1M+ concurrent users\", \"99.99% uptime\", \"Global infrastructure\"],\n \"visual_description\": \"Same gradient background. Asymmetric layout: right side features large frosted glass panel with metrics displayed in bold typography. Left side: abstract 3D globe made of glass panels and connection lines, representing global scale. Floating data visualization elements as small glass cards with numbers. Soft ambient glow throughout. Premium tech aesthetic.\"\n },\n {\n \"slide_number\": 5,\n \"type\": \"conclusion\",\n \"title\": \"The Future Starts Now\",\n \"subtitle\": \"Join the waitlist\",\n \"visual_description\": \"Dramatic finale slide. Gradient background with slightly increased vibrancy. Central frosted glass card with bold title 'The Future Starts Now' and call-to-action subtitle. Behind the card: burst of soft light rays and floating glass particles creating celebration effect. Multiple layered glass shapes creating depth. The most visually impactful slide while maintaining style consistency.\"\n }\n ]\n}\n```\n\n### Step 2: Read image-generation skill\n\nRead `/mnt/skills/public/image-generation/SKILL.md` to understand how to generate images.\n\n### Step 3: Generate slide images sequentially with reference chaining\n\n**Slide 1 - Title (establishes the visual language):**\n\nCreate `/mnt/user-data/workspace/nova-slide-01.json`:\n```json\n{\n \"prompt\": \"Ultra-premium presentation title slide with glassmorphism design. Background: smooth flowing gradient from deep purple (#667eea) through magenta (#f093fb) to cyan (#00d4ff), soft and vibrant. Center: large frosted glass panel with strong backdrop blur effect, rounded corners 32px, containing bold white sans-serif title 'Introducing Nova AI' (72pt, SF Pro Display style, font-weight 700) with subtle text shadow, subtitle 'Intelligence, Reimagined' below in lighter weight. The glass panel has subtle white border (1px rgba 255,255,255,0.25) and soft purple-tinted drop shadow. Floating around the card: 3D glass spheres with refraction, translucent geometric shapes (icosahedrons, abstract blobs), creating depth and dimension. Soft luminous glow emanating from behind the glass panel. Small floating particles of light. Apple Vision Pro / visionOS UI aesthetic. Professional presentation slide, 16:9 aspect ratio. Hyper-modern, premium tech product launch feel.\",\n \"style\": \"Glassmorphism, visionOS aesthetic, Apple Vision Pro UI style, premium tech, 2024 design trends\",\n \"composition\": \"Centered glass card as focal point, floating 3D elements creating depth at edges, 40% negative space, clear visual hierarchy\",\n \"lighting\": \"Soft ambient glow from gradient, light refraction through glass elements, subtle rim lighting on 3D shapes\",\n \"color_palette\": \"Purple gradient #667eea, magenta #f093fb, cyan #00d4ff, frosted white rgba(255,255,255,0.15), pure white text #ffffff\",\n \"effects\": \"Backdrop blur on glass panels, soft drop shadows with color tint, light refraction, subtle noise texture on glass, floating particles\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/nova-slide-01.json \\\n --output-file /mnt/user-data/outputs/nova-slide-01.jpg \\\n --aspect-ratio 16:9\n```\n\n**Slide 2 - Content (MUST reference slide 1 for consistency):**\n\nCreate `/mnt/user-data/workspace/nova-slide-02.json`:\n```json\n{\n \"prompt\": \"Presentation slide continuing EXACT visual style from reference image. SAME purple-to-cyan gradient background, SAME glassmorphism aesthetic, SAME typography style. Left side: frosted glass card with backdrop blur containing title 'Why Nova?' in bold white (matching reference font style), three feature points as subtle glass pill badges below. Right side: abstract 3D neural network visualization made of interconnected glass nodes with soft cyan glow, floating in space. Floating translucent geometric shapes (matching style from reference) adding depth. The frosted glass has identical treatment: white border, purple-tinted shadow, same blur intensity. CRITICAL: This slide must look like it belongs in the exact same presentation as the reference image - same colors, same glass treatment, same overall aesthetic.\",\n \"style\": \"MATCH REFERENCE EXACTLY - Glassmorphism, visionOS aesthetic, same visual language\",\n \"composition\": \"Asymmetric split: glass card left (40%), 3D visualization right (40%), breathing room between elements\",\n \"color_palette\": \"EXACTLY match reference: purple #667eea, cyan #00d4ff gradient, same frosted white treatment, same text white\",\n \"consistency_note\": \"CRITICAL: Must be visually identical in style to reference image. Same gradient colors, same glass blur intensity, same shadow treatment, same typography weight and style. Viewer should immediately recognize this as the same presentation.\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/nova-slide-02.json \\\n --reference-images /mnt/user-data/outputs/nova-slide-01.jpg \\\n --output-file /mnt/user-data/outputs/nova-slide-02.jpg \\\n --aspect-ratio 16:9\n```\n\n**Slides 3-5: Continue the same pattern, each referencing the previous slide**\n\nKey consistency rules for subsequent slides:\n- Always include \"continuing EXACT visual style from reference image\" in prompt\n- Specify \"SAME gradient background\", \"SAME glass treatment\", \"SAME typography\"\n- Include `consistency_note` emphasizing style matching\n- Reference the immediately previous slide image\n\n### Step 4: Compose final PPT\n\n```bash\npython /mnt/skills/public/ppt-generation/scripts/generate.py \\\n --plan-file /mnt/user-data/workspace/nova-plan.json \\\n --slide-images /mnt/user-data/outputs/nova-slide-01.jpg /mnt/user-data/outputs/nova-slide-02.jpg /mnt/user-data/outputs/nova-slide-03.jpg /mnt/user-data/outputs/nova-slide-04.jpg /mnt/user-data/outputs/nova-slide-05.jpg \\\n --output-file /mnt/user-data/outputs/nova-presentation.pptx\n```\n\n## Style-Specific Guidelines\n\n### Glassmorphism Style (推荐 - 最现代前卫)\n```json\n{\n \"style\": \"glassmorphism\",\n \"style_guidelines\": {\n \"color_palette\": \"Vibrant gradient backgrounds (purple #667eea to pink #f093fb, or cyan #4facfe to blue #00f2fe), frosted white panels with 20% opacity, accent colors that pop against the gradient\",\n \"typography\": \"SF Pro Display or Inter font style, bold 600-700 weight titles, clean 400 weight body, white text with subtle drop shadow for readability on glass\",\n \"imagery\": \"Abstract 3D shapes floating in space, soft blurred orbs, geometric primitives with glass material, depth through overlapping translucent layers\",\n \"layout\": \"Floating card panels with backdrop-blur effect, generous padding (48-64px), rounded corners (24-32px radius), layered depth with subtle shadows\",\n \"effects\": \"Frosted glass blur (backdrop-filter: blur 20px), subtle white border (1px rgba 255,255,255,0.2), soft glow behind panels, floating elements with drop shadows\",\n \"visual_language\": \"Premium tech aesthetic like Apple Vision Pro UI, depth through transparency, light refracting through glass surfaces\"\n }\n}\n```\n\n### Dark Premium Style\n```json\n{\n \"style\": \"dark-premium\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep black base (#0a0a0a to #121212), luminous accent color (electric blue #00d4ff, neon purple #bf5af2, or gold #ffd700), subtle gray gradients for depth (#1a1a1a to #0a0a0a)\",\n \"typography\": \"Elegant sans-serif (Neue Haas Grotesk or Suisse Int'l style), dramatic size contrast (72pt+ headlines, 18pt body), letter-spacing -0.02em for headlines, pure white (#ffffff) text\",\n \"imagery\": \"Dramatic studio lighting, rim lights and edge glow, cinematic product shots, abstract light trails, premium material textures (brushed metal, matte surfaces)\",\n \"layout\": \"Generous negative space (60%+), asymmetric balance, content anchored to grid but with breathing room, single focal point per slide\",\n \"effects\": \"Subtle ambient glow behind key elements, light bloom effects, grain texture overlay (2-3% opacity), vignette on edges\",\n \"visual_language\": \"Luxury tech brand aesthetic (Bang & Olufsen, Porsche Design), sophistication through restraint, every element intentional\"\n }\n}\n```\n\n### Gradient Modern Style\n```json\n{\n \"style\": \"gradient-modern\",\n \"style_guidelines\": {\n \"color_palette\": \"Bold mesh gradients (Stripe/Linear style: purple-pink-orange #7c3aed→#ec4899→#f97316, or cool tones: cyan-blue-purple #06b6d4→#3b82f6→#8b5cf6), white or dark text depending on background intensity\",\n \"typography\": \"Modern geometric sans-serif (Satoshi, General Sans, or Clash Display style), variable font weights, oversized bold headlines (80pt+), comfortable body text (20pt)\",\n \"imagery\": \"Abstract fluid shapes, morphing gradients, 3D rendered abstract objects, soft organic forms, floating geometric primitives\",\n \"layout\": \"Dynamic asymmetric compositions, overlapping elements with blend modes, text integrated with gradient flows, full-bleed backgrounds\",\n \"effects\": \"Smooth gradient transitions, subtle noise texture (3-5% for depth), soft shadows with color tint matching gradient, motion blur suggesting movement\",\n \"visual_language\": \"Contemporary SaaS aesthetic (Stripe, Linear, Vercel), energetic yet professional, forward-thinking tech vibes\"\n }\n}\n```\n\n### Neo-Brutalist Style\n```json\n{\n \"style\": \"neo-brutalist\",\n \"style_guidelines\": {\n \"color_palette\": \"High contrast primaries: stark black, pure white, with bold accent (hot pink #ff0080, electric yellow #ffff00, or raw red #ff0000), optional: Memphis-inspired pastels as secondary\",\n \"typography\": \"Ultra-bold condensed type (Impact, Druk, or Bebas Neue style), UPPERCASE headlines, extreme size contrast, intentionally tight or overlapping letter-spacing\",\n \"imagery\": \"Raw unfiltered photography, intentional visual noise, halftone patterns, cut-out collage aesthetic, hand-drawn elements, stickers and stamps\",\n \"layout\": \"Broken grid, overlapping elements, thick black borders (4-8px), visible structure, anti-whitespace (dense but organized chaos)\",\n \"effects\": \"Hard shadows (no blur, offset 8-12px), pixelation accents, scan lines, CRT screen effects, intentional 'mistakes'\",\n \"visual_language\": \"Anti-corporate rebellion, DIY zine aesthetic meets digital, raw authenticity, memorable through boldness\"\n }\n}\n```\n\n### 3D Isometric Style\n```json\n{\n \"style\": \"3d-isometric\",\n \"style_guidelines\": {\n \"color_palette\": \"Soft contemporary palette: muted purples (#8b5cf6), teals (#14b8a6), warm corals (#fb7185), with cream or light gray backgrounds (#fafafa), consistent saturation across elements\",\n \"typography\": \"Friendly geometric sans-serif (Circular, Gilroy, or Quicksand style), medium weight headlines, excellent readability, comfortable 24pt body text\",\n \"imagery\": \"Clean isometric 3D illustrations, consistent 30° isometric angle, soft clay-render aesthetic, floating platforms and devices, cute simplified objects\",\n \"layout\": \"Central isometric scene as hero, text balanced around 3D elements, clear visual hierarchy, comfortable margins (64px+)\",\n \"effects\": \"Soft drop shadows (20px blur, 30% opacity), ambient occlusion on 3D objects, subtle gradients on surfaces, consistent light source (top-left)\",\n \"visual_language\": \"Friendly tech illustration (Slack, Notion, Asana style), approachable complexity, clarity through simplification\"\n }\n}\n```\n\n### Editorial Style\n```json\n{\n \"style\": \"editorial\",\n \"style_guidelines\": {\n \"color_palette\": \"Sophisticated neutrals: off-white (#f5f5f0), charcoal (#2d2d2d), with single accent color (burgundy #7c2d12, forest #14532d, or navy #1e3a5f), occasional full-color photography\",\n \"typography\": \"Refined serif for headlines (Playfair Display, Freight, or Editorial New style), clean sans-serif for body (Söhne, Graphik), dramatic size hierarchy (96pt headlines, 16pt body), generous line-height 1.6\",\n \"imagery\": \"Magazine-quality photography, dramatic crops, full-bleed images, portraits with intentional negative space, editorial lighting (Vogue, Bloomberg Businessweek style)\",\n \"layout\": \"Sophisticated grid system (12-column), intentional asymmetry, pull quotes as design elements, text wrapping around images, elegant margins\",\n \"effects\": \"Minimal effects - let photography and typography shine, subtle image treatments (slight desaturation, film grain), elegant borders and rules\",\n \"visual_language\": \"High-end magazine aesthetic, intellectual sophistication, content elevated through design restraint\"\n }\n}\n```\n\n### Minimal Swiss Style\n```json\n{\n \"style\": \"minimal-swiss\",\n \"style_guidelines\": {\n \"color_palette\": \"Pure white (#ffffff) or off-white (#fafaf9) backgrounds, true black (#000000) text, single bold accent (Swiss red #ff0000, Klein blue #002fa7, or signal yellow #ffcc00)\",\n \"typography\": \"Helvetica Neue or Aktiv Grotesk, strict type scale (12/16/24/48/96), medium weight for body, bold for emphasis only, flush-left ragged-right alignment\",\n \"imagery\": \"Objective photography, geometric shapes, clean iconography, mathematical precision, intentional empty space as compositional element\",\n \"layout\": \"Strict grid adherence (baseline grid visible in spirit), modular compositions, generous whitespace (40%+ of slide), content aligned to invisible grid lines\",\n \"effects\": \"None - purity of form, no shadows, no gradients, no decorative elements, occasional single hairline rules\",\n \"visual_language\": \"International Typographic Style, form follows function, timeless modernism, Dieter Rams-inspired restraint\"\n }\n}\n```\n\n### Keynote Style (Apple风格)\n```json\n{\n \"style\": \"keynote\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep blacks (#000000 to #1d1d1f), pure white text, signature blue (#0071e3) or gradient accents (purple-pink for creative, blue-teal for tech)\",\n \"typography\": \"San Francisco Pro Display, extreme weight contrast (bold 80pt+ titles, light 24pt body), negative letter-spacing on headlines (-0.03em), optical alignment\",\n \"imagery\": \"Cinematic photography, shallow depth of field, dramatic lighting (rim lights, spot lighting), product hero shots with reflections, full-bleed imagery\",\n \"layout\": \"Maximum negative space, single powerful image or statement per slide, content centered or dramatically offset, no clutter\",\n \"effects\": \"Subtle gradient overlays, light bloom and glow on key elements, reflection on surfaces, smooth gradient backgrounds\",\n \"visual_language\": \"Apple WWDC keynote aesthetic, confidence through simplicity, every pixel considered, theatrical presentation\"\n }\n}\n```\n\n## Output Handling\n\nAfter generation:\n\n- The PPTX file is saved in `/mnt/user-data/outputs/`\n- Share the generated presentation with user using `present_files` tool\n- Also share the individual slide images if requested\n- Provide brief description of the presentation\n- Offer to iterate or regenerate specific slides if needed\n\n## Notes\n\n### Critical Quality Guidelines\n\n**Prompt Engineering for Professional Results:**\n- Always use English for image prompts regardless of user's language\n- Be EXTREMELY specific about visual details - vague prompts produce generic results\n- Include exact hex color codes (e.g., #667eea not \"purple\")\n- Specify typography details: font weight (400/700), size hierarchy, letter-spacing\n- Describe effects precisely: \"backdrop blur 20px\", \"drop shadow 8px blur 30% opacity\"\n- Reference real design systems: \"visionOS aesthetic\", \"Stripe website style\", \"Bloomberg Businessweek layout\"\n\n**Visual Consistency (Most Important):**\n- **Generate slides sequentially** - each slide MUST reference the previous one\n- The first slide is critical - it establishes the visual language for the entire presentation\n- In every subsequent slide prompt, explicitly state: \"continuing EXACT visual style from reference image\"\n- Use SAME, EXACT, MATCH keywords emphatically in prompts to enforce consistency\n- Include a `consistency_note` field in every JSON prompt after slide 1\n- If a slide looks inconsistent, regenerate it with STRONGER reference emphasis\n\n**Design Principles for Modern Aesthetics:**\n- Embrace negative space - 40-60% empty space creates premium feel\n- Limit elements per slide - one focal point, one message\n- Use depth through layering (shadows, transparency, z-depth)\n- Typography hierarchy: massive headlines (72pt+), comfortable body (18-24pt)\n- Color restraint: one primary palette, 1-2 accent colors maximum\n\n**Common Mistakes to Avoid:**\n- ❌ Generic prompts like \"professional slide\" - be specific\n- ❌ Too many elements/text per slide - cluttered = unprofessional\n- ❌ Inconsistent colors between slides - always reference previous slide\n- ❌ Skipping the reference image parameter - this breaks visual consistency\n- ❌ Using different design styles within one presentation\n- ❌ Generating slides in parallel - slides MUST be generated one at a time in order (slide 1 → 2 → 3 ...), never concurrently\n\n**Recommended Styles for Different Contexts:**\n- Tech product launch → `glassmorphism` or `gradient-modern`\n- Luxury/premium brand → `dark-premium` or `editorial`\n- Startup pitch → `gradient-modern` or `minimal-swiss`\n- Executive presentation → `dark-premium` or `keynote`\n- Creative agency → `neo-brutalist` or `gradient-modern`\n- Data/analytics → `minimal-swiss` or `3d-isometric`\n","skills/public/github-deep-research/SKILL.md":"---\nname: github-deep-research\ndescription: Conduct multi-round deep research on any GitHub Repo. Use when users request comprehensive analysis, timeline reconstruction, competitive analysis, or in-depth investigation of GitHub. Produces structured markdown reports with executive summaries, chronological timelines, metrics analysis, and Mermaid diagrams. Triggers on Github repository URL or open source projects.\n---\n\n# GitHub Deep Research Skill\n\nMulti-round research combining GitHub API, web_search, web_fetch to produce comprehensive markdown reports.\n\n## Research Workflow\n\n- Round 1: GitHub API\n- Round 2: Discovery\n- Round 3: Deep Investigation\n- Round 4: Deep Dive\n\n## Core Methodology\n\n### Query Strategy\n\n**Broad to Narrow**: Start with GitHub API, then general queries, refine based on findings.\n\n```\nRound 1: GitHub API\nRound 2: \"{topic} overview\"\nRound 3: \"{topic} architecture\", \"{topic} vs alternatives\"\nRound 4: \"{topic} issues\", \"{topic} roadmap\", \"site:github.com {topic}\"\n```\n\n**Source Prioritization**:\n1. Official docs/repos (highest weight)\n2. Technical blogs (Medium, Dev.to)\n3. News articles (verified outlets)\n4. Community discussions (Reddit, HN)\n5. Social media (lowest weight, for sentiment)\n\n### Research Rounds\n\n**Round 1 - GitHub API**\nDirectly execute `scripts/github_api.py` without `read_file()`:\n```bash\npython /path/to/skill/scripts/github_api.py summary\npython /path/to/skill/scripts/github_api.py readme\npython /path/to/skill/scripts/github_api.py tree\n```\n\n**Available commands (the last argument of `github_api.py`):**\n- summary\n- info\n- readme\n- tree\n- languages\n- contributors\n- commits\n- issues\n- prs\n- releases\n\n**Round 2 - Discovery (3-5 web_search)**\n- Get overview and identify key terms\n- Find official website/repo\n- Identify main players/competitors\n\n**Round 3 - Deep Investigation (5-10 web_search + web_fetch)**\n- Technical architecture details\n- Timeline of key events\n- Community sentiment\n- Use web_fetch on valuable URLs for full content\n\n**Round 4 - Deep Dive**\n- Analyze commit history for timeline\n- Review issues/PRs for feature evolution\n- Check contributor activity\n\n## Report Structure\n\nFollow template in `assets/report_template.md`:\n\n1. **Metadata Block** - Date, confidence level, subject\n2. **Executive Summary** - 2-3 sentence overview with key metrics\n3. **Chronological Timeline** - Phased breakdown with dates\n4. **Key Analysis Sections** - Topic-specific deep dives\n5. **Metrics & Comparisons** - Tables, growth charts\n6. **Strengths & Weaknesses** - Balanced assessment\n7. **Sources** - Categorized references\n8. **Confidence Assessment** - Claims by confidence level\n9. **Methodology** - Research approach used\n\n### Mermaid Diagrams\n\nInclude diagrams where helpful:\n\n**Timeline (Gantt)**:\n```mermaid\ngantt\n title Project Timeline\n dateFormat YYYY-MM-DD\n section Phase 1\n Development :2025-01-01, 2025-03-01\n section Phase 2\n Launch :2025-03-01, 2025-04-01\n```\n\n**Architecture (Flowchart)**:\n```mermaid\nflowchart TD\n A[User] --> B[Coordinator]\n B --> C[Planner]\n C --> D[Research Team]\n D --> E[Reporter]\n```\n\n**Comparison (Pie/Bar)**:\n```mermaid\npie title Market Share\n \"Project A\" : 45\n \"Project B\" : 30\n \"Others\" : 25\n```\n\n## Confidence Scoring\n\nAssign confidence based on source quality:\n\n| Confidence | Criteria |\n|------------|----------|\n| High (90%+) | Official docs, GitHub data, multiple corroborating sources |\n| Medium (70-89%) | Single reliable source, recent articles |\n| Low (50-69%) | Social media, unverified claims, outdated info |\n\n## Output\n\nSave report as: `research_{topic}_{YYYYMMDD}.md`\n\n### Formatting Rules\n\n- Chinese content: Use full-width punctuation（，。：；！？）\n- Technical terms: Provide Wiki/doc URL on first mention\n- Tables: Use for metrics, comparisons\n- Code blocks: For technical examples\n- Mermaid: For architecture, timelines, flows\n\n## Best Practices\n\n1. **Start with official sources** - Repo, docs, company blog\n2. **Verify dates from commits/PRs** - More reliable than articles\n3. **Triangulate claims** - 2+ independent sources\n4. **Note conflicting info** - Don't hide contradictions\n5. **Distinguish fact vs opinion** - Label speculation clearly\n6. **CRITICAL: Always include inline citations** - Use `[citation:Title](URL)` format immediately after each claim from external sources\n7. **Extract URLs from search results** - web_search returns {title, url, snippet} - always use the URL field\n8. **Update as you go** - Don't wait until end to synthesize\n\n### Citation Examples\n\n**Good - With inline citations:**\n```markdown\nThe project gained 10,000 stars within 3 months of launch [citation:GitHub Stats](https://github.com/owner/repo).\nThe architecture uses LangGraph for workflow orchestration [citation:LangGraph Docs](https://langchain.com/langgraph).\n```\n\n**Bad - Without citations:**\n```markdown\nThe project gained 10,000 stars within 3 months of launch.\nThe architecture uses LangGraph for workflow orchestration.\n```\n","skills/public/skill-creator/SKILL.md":"---\nname: skill-creator\ndescription: Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.\n---\n\n# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nAt a high level, the process of creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft of the skill\n- Create a few test prompts and run claude-with-access-to-the-skill on them\n- Help the user evaluate the results both qualitatively and quantitatively\n - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)\n - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics\n- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like \"I want to make a skill for X\". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.\n\nOn the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.\n\nOf course, you should always be flexible and if the user is like \"I don't need to run a bunch of evaluations, just vibe with me\", you can do that instead.\n\nThen after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.\n\nCool? Cool.\n\n---\n\n## DeerFlow Environment (⚠️ READ THIS FIRST)\n\nIf you are running inside a **DeerFlow** sandboxed agent environment (you have access to the `skill_manage` tool), you MUST follow these rules for all skill file operations. These override the generic file-writing and packaging instructions below.\n\n### Why this matters\n\nIn DeerFlow, the sandbox filesystem is isolated. Files written with `write_file` land in `/mnt/user-data/outputs/`, which is a **per-thread output directory** — new chats cannot see files there. Skills must be persisted through the dedicated `skill_manage` tool so they are stored in the per-user skill directory and immediately visible to all future chats.\n\n### Use `skill_manage` for all skill file operations\n\n| Operation | skill_manage action | Example |\n|-----------|---------------------|---------|\n| Create a new skill | `action=\"create\"` | `skill_manage(action=\"create\", name=\"my-skill\", content=\"---\\nname: my-skill\\n---\\n...\")` |\n| Replace entire SKILL.md | `action=\"edit\"` | `skill_manage(action=\"edit\", name=\"my-skill\", content=\"updated SKILL.md\")` |\n| Partial edit (find & replace) | `action=\"patch\"` | `skill_manage(action=\"patch\", name=\"my-skill\", find=\"old text\", replace=\"new text\")` |\n| Delete a skill | `action=\"delete\"` | `skill_manage(action=\"delete\", name=\"my-skill\")` |\n| Add a supporting file | `action=\"write_file\"` | `skill_manage(action=\"write_file\", name=\"my-skill\", path=\"scripts/helper.py\", content=\"...\")` |\n| Remove a supporting file | `action=\"remove_file\"` | `skill_manage(action=\"remove_file\", name=\"my-skill\", path=\"scripts/helper.py\")` |\n\n### Key rules\n\n1. **NEVER use sandbox `write_file` to create or modify skill files** (SKILL.md, scripts/, references/, assets/). These would land in `/mnt/user-data/outputs/` and be invisible to future chats. Always use `skill_manage` instead.\n\n2. **Skip the `package_skill.py` step**. In DeerFlow, `skill_manage` already persists the skill to the correct per-user directory. No `.skill` packaging or manual install is needed. The skill is immediately available in all new chats.\n\n3. **Skip the `present_files` step for skills**. Skills are NOT deliverables — they are persisted via `skill_manage` and auto-loaded by the skill system. Only use `present_files` for non-skill outputs (eval reports, benchmarks, etc.).\n\n4. **Eval workspace files are OK in sandbox**. Test prompts, benchmark data, eval viewer HTML, grading results, etc. are NOT skill files — you can write these to `/mnt/user-data/outputs/` or `/mnt/user-data/workspace/` using sandbox `write_file` as usual.\n\n5. **To read an existing skill's SKILL.md**, use `read_file(\"/mnt/skills/custom//SKILL.md\")` in the sandbox (it maps to the per-user skill directory).\n\n6. **Updating an existing skill**: use `skill_manage(action=\"edit\")` or `skill_manage(action=\"patch\")`. Do NOT copy to `/tmp/` first — `skill_manage` handles the per-user storage directly.\n\n### Workflow in DeerFlow\n\nThe core loop is the same, but the persistence mechanism changes:\n\n1. Capture intent → interview → draft SKILL.md content\n2. **Call `skill_manage(action=\"create\", name=, content=)`** to persist the skill\n3. Run test cases (eval workspace files use sandbox `write_file`)\n4. Evaluate results, gather feedback\n5. **Call `skill_manage(action=\"edit\")` or `skill_manage(action=\"patch\")`** to improve the skill\n6. Repeat until satisfied\n7. **Done — no packaging needed.** The skill is already persisted and visible to all future chats.\n\n---\n\n## Communicating with the user\n\nThe skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google \"how to install npm\". On the other hand, the bulk of users are probably fairly computer-literate.\n\nSo please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:\n\n- \"evaluation\" and \"benchmark\" are borderline, but OK\n- for \"JSON\" and \"assertion\" you want to see serious cues from the user that they know what those things are before using them without explaining them\n\nIt's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.\n\n---\n\n## Creating a skill\n\n### Capture Intent\n\nStart by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say \"turn this into a skill\"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.\n\n1. What should this skill enable Claude to do?\n2. When should this skill trigger? (what user phrases/contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.\n\n### Interview and Research\n\nProactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.\n\nCheck available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.\n\n### Write the SKILL.md\n\nBased on the user interview, fill in these components:\n\n- **name**: Skill identifier\n- **description**: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All \"when to use\" info goes here, not in the body. Note: currently Claude has a tendency to \"undertrigger\" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit \"pushy\". So for instance, instead of \"How to build a simple fast dashboard to display internal Anthropic data.\", you might write \"How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **compatibility**: Required tools, dependencies (optional, rarely needed)\n- **the rest of the skill :)**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name/\n├── SKILL.md (required)\n│ ├── YAML frontmatter (name, description required)\n│ └── Markdown instructions\n└── Bundled Resources (optional)\n ├── scripts/ - Executable code for deterministic/repetitive tasks\n ├── references/ - Docs loaded into context as needed\n └── assets/ - Files used in output (templates, icons, fonts)\n```\n\n#### Progressive Disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description) - Always in context (~100 words)\n2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)\n3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)\n\nThese word counts are approximate and you can feel free to go longer if needed.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.\n- Reference files clearly from SKILL.md with guidance on when to read them\n- For large reference files (>300 lines), include a table of contents\n\n**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:\n```\ncloud-deploy/\n├── SKILL.md (workflow + selection)\n└── references/\n ├── aws.md\n ├── gcp.md\n └── azure.md\n```\nClaude reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nThis goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a \"roleplay as an XYZ\" are OK though.\n\n#### Writing Patterns\n\nPrefer using the imperative form in instructions.\n\n**Defining output formats** - You can do it like this:\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** - It's useful to include examples. You can format them like this (but if \"Input\" and \"Output\" are in the examples you might want to deviate a little):\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n### Writing Style\n\nTry to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.\n\n### Test Cases\n\nAfter writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.\n\n```json\n{\n \"skill_name\": \"example-skill\",\n \"evals\": [\n {\n \"id\": 1,\n \"prompt\": \"User's task prompt\",\n \"expected_output\": \"Description of expected result\",\n \"files\": []\n }\n ]\n}\n```\n\nSee `references/schemas.md` for the full schema (including the `assertions` field, which you'll add later).\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill.\n\nPut results in `-workspace/` as a sibling to the skill directory. Within the workspace, organize results by iteration (`iteration-1/`, `iteration-2/`, etc.) and within that, each test case gets a directory (`eval-0/`, `eval-1/`, etc.). Don't create all of this upfront — just create directories as you go.\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: \n- Task: \n- Input files: \n- Save outputs to: /iteration-/eval-/with_skill/outputs/\n- Outputs to save: \n```\n\n**Baseline run** (same prompt, but the baseline depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, save to `without_skill/outputs/`.\n- **Improving an existing skill**: the old version. Before editing, snapshot the skill (`cp -r /skill-snapshot/`), then point the baseline subagent at the snapshot. Save to `old_skill/outputs/`.\n\nWrite an `eval_metadata.json` for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just \"eval-0\". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.\n\n```json\n{\n \"eval_id\": 0,\n \"eval_name\": \"descriptive-name-here\",\n \"prompt\": \"The user's task prompt\",\n \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in `evals/evals.json`, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.\n\nUpdate the `eval_metadata.json` files and `evals/evals.json` with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, you receive a notification containing `total_tokens` and `duration_ms`. Save this data immediately to `timing.json` in the run directory:\n\n```json\n{\n \"total_tokens\": 84852,\n \"duration_ms\": 23332,\n \"total_duration_seconds\": 23.3\n}\n```\n\nThis is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — spawn a grader subagent (or grade inline) that reads `agents/grader.md` and evaluates each assertion against the outputs. Save results to `grading.json` in each run directory. The grading.json expectations array must use the fields `text`, `passed`, and `evidence` (not `name`/`met`/`details` or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.\n\n2. **Aggregate into benchmark** — run the aggregation script from the skill-creator directory:\n ```bash\n python -m scripts.aggregate_benchmark /iteration-N --skill-name \n ```\n This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see `references/schemas.md` for the exact schema the viewer expects.\nPut each with_skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregate stats might hide. See `agents/analyzer.md` (the \"Analyzing Benchmark Results\" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n ```bash\n nohup python /eval-viewer/generate_review.py \\\n /iteration-N \\\n --skill-name \"my-skill\" \\\n --benchmark /iteration-N/benchmark.json \\\n > /dev/null 2>&1 &\n VIEWER_PID=$!\n ```\n For iteration 2+, also pass `--previous-workspace /iteration-`.\n\n **Cowork / headless environments:** If `webbrowser.open()` is not available or the environment has no display, use `--static ` to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a `feedback.json` file when the user clicks \"Submit All Reviews\". After download, copy `feedback.json` into the workspace directory for the next iteration to pick up.\n\nNote: please use generate_review.py to create the viewer; there's no need to write custom HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): collapsed section showing last iteration's output\n- **Formal Grades** (if grading was run): collapsed section showing assertion pass/fail\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, shown below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.\n\nNavigation is via prev/next buttons or arrow keys. When done, they click \"Submit All Reviews\" which saves all feedback to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user tells you they're done, read `feedback.json`:\n\n```json\n{\n \"reviews\": [\n {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n ],\n \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.\n\nKill the viewer server when you're done with it:\n\n```bash\nkill $VIEWER_PID 2>/dev/null\n```\n\n---\n\n## Improving the skill\n\nThis is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.\n\n3. **Explain the why.** Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.\n\n4. **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts/`, and tell the skill to use it. This saves every future invocation from reinventing the wheel.\n\nThis task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply your improvements to the skill\n2. Rerun all test cases into a new `iteration-/` directory, including baseline runs. If you're creating a new skill, the baseline is always `without_skill` (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and tell you they're done\n5. Read the new feedback, improve again, repeat\n\nKeep going until:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n---\n\n## Advanced: Blind comparison\n\nFor situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks \"is the new version actually better?\"), there's a blind comparison system. Read `agents/comparator.md` and `agents/analyzer.md` for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.\n\nThis is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n---\n\n## Description Optimization\n\nThe description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n {\"query\": \"the user prompt\", \"should_trigger\": true},\n {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nFor the **should-trigger** queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.\n\nFor the **should-not-trigger** queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.\n\nThe key thing to avoid: don't make should-not-trigger queries obviously irrelevant. \"Write a fibonacci function\" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.\n\n### Step 2: Review with user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read the template from `assets/eval_review.html`\n2. Replace the placeholders:\n - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no quotes around it — it's a JS variable assignment)\n - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file (e.g., `/tmp/eval_review_.html`) and open it: `open /tmp/eval_review_.html`\n4. The user can edit queries, toggle should-trigger, add/remove entries, then click \"Export Eval Set\"\n5. The file downloads to `~/Downloads/eval_set.json` — check the Downloads folder for the most recent version in case there are multiple (e.g., `eval_set (1).json`)\n\nThis step matters — bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take some time — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run in the background:\n\n```bash\npython -m scripts.run_loop \\\n --eval-set \\\n --skill-path \\\n --model \\\n --max-iterations 5 \\\n --verbose\n```\n\nUse the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.\n\nWhile it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.\n\nThis handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with `best_description` — selected by test score rather than train score to avoid overfitting.\n\n### How skill triggering works\n\nUnderstanding the triggering mechanism helps design better eval queries. Skills appear in Claude's `available_skills` list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like \"read this PDF\" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.\n\nThis means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like \"read file X\" are poor test cases — they won't trigger skills regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.\n\n---\n\n### Package and Present (only if `present_files` tool is available)\n\nCheck whether you have access to the `present_files` tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:\n\n```bash\npython -m scripts.package_skill \n```\n\nAfter packaging, direct the user to the resulting `.skill` file path so they can install it.\n\n---\n\n## Claude.ai-specific instructions\n\nIn Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:\n\n**Running test cases**: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.\n\n**Reviewing results**: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: \"How does this look? Anything you'd change?\"\n\n**Benchmarking**: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.\n\n**The iteration loop**: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.\n\n**Description optimization**: This section requires the `claude` CLI tool (specifically `claude -p`) which is only available in Claude Code. Skip it if you're on Claude.ai.\n\n**Blind comparison**: Requires subagents. Skip it.\n\n**Packaging**: The `package_skill.py` script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting `.skill` file.\n\n**Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. In this case:\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field -- use them unchanged. E.g., if the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`).\n- **Copy to a writeable location before editing.** The installed skill path may be read-only. Copy to `/tmp/skill-name/`, edit there, and package from the copy.\n- **If packaging manually, stage in `/tmp/` first**, then copy to the output directory -- direct writes may fail due to permissions.\n\n---\n\n## Cowork-Specific Instructions\n\nIf you're in Cowork, the main things to know are:\n\n- You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)\n- You don't have a browser or display, so when generating the eval viewer, use `--static ` to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.\n- For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using `generate_review.py` (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER *BEFORE* evaluating inputs yourself. You want to get them in front of the human ASAP!\n- Feedback works differently: since there's no running server, the viewer's \"Submit All Reviews\" button will download `feedback.json` as a file. You can then read it from there (you may have to request access first).\n- Packaging works — `package_skill.py` just needs Python and a filesystem.\n- Description optimization (`run_loop.py` / `run_eval.py`) should work in Cowork just fine since it uses `claude -p` via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.\n- **Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.\n\n---\n\n## Reference files\n\nThe agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.\n\n- `agents/grader.md` — How to evaluate assertions against outputs\n- `agents/comparator.md` — How to do blind A/B comparison between two outputs\n- `agents/analyzer.md` — How to analyze why one version beat another\n\nThe references/ directory has additional documentation:\n- `references/schemas.md` — JSON structures for evals.json, grading.json, etc.\n\n---\n\nRepeating one more time the core loop here for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill\n- Run claude-with-access-to-the-skill on test prompts\n- With the user, evaluate the outputs:\n - Create benchmark.json and run `eval-viewer/generate_review.py` to help the user review them\n - Run quantitative evals\n- Repeat until you and the user are satisfied\n- Package the final skill and return it to the user.\n\nPlease add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put \"Create evals JSON and run `eval-viewer/generate_review.py` so human can review test cases\" in your TodoList to make sure it happens.\n\nGood luck!\n","skills/public/frontend-design/SKILL.md":"# frontend-design\n\nPath: `skills/public/frontend-design/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/frontend-design/SKILL.md)","skills/public/find-skills/SKILL.md":"# find-skills\n\nPath: `skills/public/find-skills/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/find-skills/SKILL.md)","skills/public/deep-research/SKILL.md":"# deep-research\n\nPath: `skills/public/deep-research/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/deep-research/SKILL.md)","skills/public/data-analysis/SKILL.md":"# data-analysis\n\nPath: `skills/public/data-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/data-analysis/SKILL.md)","skills/public/consulting-analysis/SKILL.md":"# consulting-analysis\n\nPath: `skills/public/consulting-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/consulting-analysis/SKILL.md)","skills/public/code-documentation/SKILL.md":"# code-documentation\n\nPath: `skills/public/code-documentation/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/code-documentation/SKILL.md)","skills/public/claude-to-deerflow/SKILL.md":"# claude-to-deerflow\n\nPath: `skills/public/claude-to-deerflow/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/claude-to-deerflow/SKILL.md)","skills/public/chart-visualization/SKILL.md":"# chart-visualization\n\nPath: `skills/public/chart-visualization/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/SKILL.md)","skills/public/bootstrap/SKILL.md":"# bootstrap\n\nPath: `skills/public/bootstrap/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/SKILL.md)","skills/public/academic-paper-review/SKILL.md":"# academic-paper-review\n\nPath: `skills/public/academic-paper-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/academic-paper-review/SKILL.md)",".github/copilot-instructions.md":"# GitHub Copilot Instructions\n\nPath: `.github/copilot-instructions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.github/copilot-instructions.md)","backend/AGENTS.md":"# backend - AI Agent Protocol & Instructions\n\nPath: `backend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/AGENTS.md)","backend/CLAUDE.md":"# backend - Claude Agent Guidelines & System Prompt\n\nPath: `backend/CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/CLAUDE.md)","frontend/AGENTS.md":"# frontend - AI Agent Protocol & Instructions\n\nPath: `frontend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/AGENTS.md)","frontend/CLAUDE.md":"# frontend - Claude Agent Guidelines & System Prompt\n\nPath: `frontend/CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/CLAUDE.md)",".agent/skills/smoke-test/references/SOP.md":"# References Skill\n\nPath: `.agent/skills/smoke-test/references/SOP.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/SOP.md)",".agent/skills/smoke-test/references/troubleshooting.md":"# References Skill\n\nPath: `.agent/skills/smoke-test/references/troubleshooting.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/troubleshooting.md)",".agent/skills/smoke-test/templates/report.docker.template.md":"# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.docker.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.docker.template.md)",".agent/skills/smoke-test/templates/report.local.template.md":"# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.local.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.local.template.md)","skills/public/systematic-literature-review/evals/evals.json":"# Evals Skill\n\nPath: `skills/public/systematic-literature-review/evals/evals.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/evals.json)","skills/public/systematic-literature-review/evals/trigger_eval_set.json":"# Evals Skill\n\nPath: `skills/public/systematic-literature-review/evals/trigger_eval_set.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/trigger_eval_set.json)","skills/public/systematic-literature-review/templates/apa.md":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/apa.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/apa.md)","skills/public/systematic-literature-review/templates/bibtex.md":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/bibtex.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/bibtex.md)","skills/public/systematic-literature-review/templates/ieee.md":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/ieee.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/ieee.md)","skills/public/skill-creator/agents/analyzer.md":"# Subagent: analyzer\n\nPath: `skills/public/skill-creator/agents/analyzer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/analyzer.md)","skills/public/skill-creator/agents/comparator.md":"# Subagent: comparator\n\nPath: `skills/public/skill-creator/agents/comparator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/comparator.md)","skills/public/skill-creator/agents/grader.md":"# Subagent: grader\n\nPath: `skills/public/skill-creator/agents/grader.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/grader.md)","skills/public/skill-creator/references/output-patterns.md":"# References Skill\n\nPath: `skills/public/skill-creator/references/output-patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/output-patterns.md)","skills/public/skill-creator/references/schemas.md":"# References Skill\n\nPath: `skills/public/skill-creator/references/schemas.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/schemas.md)","skills/public/skill-creator/references/workflows.md":"# References Skill\n\nPath: `skills/public/skill-creator/references/workflows.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/workflows.md)","skills/public/podcast-generation/templates/tech-explainer.md":"# Templates Skill\n\nPath: `skills/public/podcast-generation/templates/tech-explainer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/podcast-generation/templates/tech-explainer.md)","skills/public/image-generation/templates/doraemon.md":"# Templates Skill\n\nPath: `skills/public/image-generation/templates/doraemon.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/image-generation/templates/doraemon.md)","skills/public/github-deep-research/assets/report_template.md":"# Assets Skill\n\nPath: `skills/public/github-deep-research/assets/report_template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/github-deep-research/assets/report_template.md)","skills/public/chart-visualization/references/generate_area_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_area_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_area_chart.md)","skills/public/chart-visualization/references/generate_bar_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_bar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_bar_chart.md)","skills/public/chart-visualization/references/generate_boxplot_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_boxplot_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_boxplot_chart.md)","skills/public/chart-visualization/references/generate_column_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_column_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_column_chart.md)","skills/public/chart-visualization/references/generate_district_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_district_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_district_map.md)","skills/public/chart-visualization/references/generate_dual_axes_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_dual_axes_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_dual_axes_chart.md)","skills/public/chart-visualization/references/generate_fishbone_diagram.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_fishbone_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_fishbone_diagram.md)","skills/public/chart-visualization/references/generate_flow_diagram.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_flow_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_flow_diagram.md)","skills/public/chart-visualization/references/generate_funnel_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_funnel_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_funnel_chart.md)","skills/public/chart-visualization/references/generate_histogram_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_histogram_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_histogram_chart.md)","skills/public/chart-visualization/references/generate_line_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_line_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_line_chart.md)","skills/public/chart-visualization/references/generate_liquid_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_liquid_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_liquid_chart.md)","skills/public/chart-visualization/references/generate_mind_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_mind_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_mind_map.md)","skills/public/chart-visualization/references/generate_network_graph.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_network_graph.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_network_graph.md)","skills/public/chart-visualization/references/generate_organization_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_organization_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_organization_chart.md)","skills/public/chart-visualization/references/generate_path_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_path_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_path_map.md)","skills/public/chart-visualization/references/generate_pie_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pie_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pie_chart.md)","skills/public/chart-visualization/references/generate_pin_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pin_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pin_map.md)","skills/public/chart-visualization/references/generate_radar_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_radar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_radar_chart.md)","skills/public/chart-visualization/references/generate_sankey_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_sankey_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_sankey_chart.md)","skills/public/chart-visualization/references/generate_scatter_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_scatter_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_scatter_chart.md)","skills/public/chart-visualization/references/generate_spreadsheet.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_spreadsheet.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_spreadsheet.md)","skills/public/chart-visualization/references/generate_treemap_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_treemap_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_treemap_chart.md)","skills/public/chart-visualization/references/generate_venn_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_venn_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_venn_chart.md)","skills/public/chart-visualization/references/generate_violin_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_violin_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_violin_chart.md)","skills/public/chart-visualization/references/generate_word_cloud_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_word_cloud_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_word_cloud_chart.md)","skills/public/bootstrap/references/conversation-guide.md":"# References Skill\n\nPath: `skills/public/bootstrap/references/conversation-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/references/conversation-guide.md)","skills/public/bootstrap/templates/SOUL.template.md":"# Templates Skill\n\nPath: `skills/public/bootstrap/templates/SOUL.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/templates/SOUL.template.md)"},"files":{"skills/public/video-generation/SKILL.md":"---\nname: video-generation\ndescription: Use this skill when the user requests to generate, create, or imagine videos. Supports structured prompts and reference image for guided generation.\n---\n\n# Video Generation Skill\n\n## Overview\n\nThis skill generates high-quality videos using structured prompts and a Python script. The workflow includes creating JSON-formatted prompts and executing video generation with optional reference image.\n\n## Core Capabilities\n\n- Create structured JSON prompts for AIGC video generation\n- Support reference image as guidance or the first/last frame of the video\n- Generate videos through automated Python script execution\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests video generation, identify:\n\n- Subject/content: What should be in the image\n- Style preferences: Art style, mood, color palette\n- Technical specs: Aspect ratio, composition, lighting\n- Reference image: Any image to guide generation\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Prompt\n\nGenerate a structured JSON file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}.json`\n\n### Step 3: Create Reference Image (Optional when image-generation skill is available)\n\nGenerate reference image for the video generation.\n\n- If only 1 image is provided, use it as the guided frame of the video\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/video-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/prompt-file.json \\\n --reference-images /path/to/ref1.jpg \\\n --output-file /mnt/user-data/outputs/generated-video.mp4 \\\n --aspect-ratio 16:9\n```\n\nParameters:\n\n- `--prompt-file`: Absolute path to JSON prompt file (required)\n- `--reference-images`: Absolute paths to reference image (optional)\n- `--output-file`: Absolute path to output image file (required)\n- `--aspect-ratio`: Aspect ratio of the generated image (optional, default: 16:9)\n\n[!NOTE]\nDo NOT read the python file, instead just call it with the parameters.\n\n## Video Generation Example\n\nUser request: \"Generate a short video clip depicting the opening scene from \"The Chronicles of Narnia: The Lion, the Witch and the Wardrobe\"\n\nStep 1: Search for the opening scene of \"The Chronicles of Narnia: The Lion, the Witch and the Wardrobe\" online\n\nStep 2: Create a JSON prompt file with the following content:\n\n```json\n{\n \"title\": \"The Chronicles of Narnia - Train Station Farewell\",\n \"background\": {\n \"description\": \"World War II evacuation scene at a crowded London train station. Steam and smoke fill the air as children are being sent to the countryside to escape the Blitz.\",\n \"era\": \"1940s wartime Britain\",\n \"location\": \"London railway station platform\"\n },\n \"characters\": [\"Mrs. Pevensie\", \"Lucy Pevensie\"],\n \"camera\": {\n \"type\": \"Close-up two-shot\",\n \"movement\": \"Static with subtle handheld movement\",\n \"angle\": \"Profile view, intimate framing\",\n \"focus\": \"Both faces in focus, background soft bokeh\"\n },\n \"dialogue\": [\n {\n \"character\": \"Mrs. Pevensie\",\n \"text\": \"You must be brave for me, darling. I'll come for you... I promise.\"\n },\n {\n \"character\": \"Lucy Pevensie\",\n \"text\": \"I will be, mother. I promise.\"\n }\n ],\n \"audio\": [\n {\n \"type\": \"Train whistle blows (signaling departure)\",\n \"volume\": 1\n },\n {\n \"type\": \"Strings swell emotionally, then fade\",\n \"volume\": 0.5\n },\n {\n \"type\": \"Ambient sound of the train station\",\n \"volume\": 0.5\n }\n ]\n}\n```\n\nStep 3: Use the image-generation skill to generate the reference image\n\nLoad the image-generation skill and generate a single reference image `narnia-farewell-scene-01.jpg` according to the skill.\n\nStep 4: Use the generate.py script to generate the video\n```bash\npython /mnt/skills/public/video-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/narnia-farewell-scene.json \\\n --reference-images /mnt/user-data/outputs/narnia-farewell-scene-01.jpg \\\n --output-file /mnt/user-data/outputs/narnia-farewell-scene-01.mp4 \\\n --aspect-ratio 16:9\n```\n> Do NOT read the python file, just call it with the parameters.\n\n## Output Handling\n\nAfter generation:\n\n- Videos are typically saved in `/mnt/user-data/outputs/`\n- Share generated videos (come first) with user as well as generated image if applicable, using `present_files` tool\n- Provide brief description of the generation result\n- Offer to iterate if adjustments needed\n\n## Notes\n\n- Always use English for prompts regardless of user's language\n- JSON format ensures structured, parsable prompts\n- Reference image enhance generation quality significantly\n- Iterative refinement is normal for optimal results\n\n## Providers (Gemini / MiniMax)\n\nProvider credentials are read from the runtime environment, not embedded in the\nscript. Do not put their values in prompt files or command-line arguments.\n\nAuto-selected by environment variables (CLI unchanged):\n\n- `GEMINI_API_KEY` set → Gemini Veo (default, unchanged).\n- Only `MINIMAX_API_KEY` set → MiniMax video (`/v1/video_generation`, async 3-step poll/download).\n- Force with `VIDEO_GENERATION_PROVIDER=gemini|minimax`.\n\nMiniMax overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_VIDEO_MODEL` (default `MiniMax-Hailuo-2.3`). The first reference image is used\nas MiniMax `first_frame_image`. MiniMax ignores `--aspect-ratio` (it uses resolution/duration).\n","skills/public/web-design-guidelines/SKILL.md":"---\nname: web-design-guidelines\ndescription: Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".\nmetadata:\n author: vercel\n version: \"1.0.0\"\n argument-hint: \n---\n\n# Web Interface Guidelines\n\nReview files for compliance with Web Interface Guidelines.\n\n## How It Works\n\n1. Fetch the latest guidelines from the source URL below\n2. Read the specified files (or prompt user for files/pattern)\n3. Check against all rules in the fetched guidelines\n4. Output findings in the terse `file:line` format\n\n## Guidelines Source\n\nFetch fresh guidelines before each review:\n\n```\nhttps://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md\n```\n\nUse WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.\n\n## Usage\n\nWhen a user provides a file or pattern argument:\n1. Fetch guidelines from the source URL above\n2. Read the specified files\n3. Apply all rules from the fetched guidelines\n4. Output findings using the format specified in the guidelines\n\nIf no files specified, ask the user which files to review.\n","skills/public/surprise-me/SKILL.md":"---\nname: surprise-me\ndescription: Create a delightful, unexpected \"wow\" experience for the user by dynamically discovering and creatively combining other enabled skills. Triggers when the user says \"surprise me\" or any request expressing a desire for an unexpected creative showcase. Also triggers when the user is bored, wants inspiration, or asks for \"something interesting\".\n---\n\n# Surprise Me\n\nDeliver an unexpected, delightful experience by dynamically discovering available skills and combining them creatively.\n\n## Workflow\n\n### Step 1: Discover Available Skills\n\nRead all the skills listed in the .\n\n### Step 2: Plan the Surprise\n\nSelect **1 to 3** skills and design a creative mashup. The goal is a single cohesive deliverable, not separate demos.\n\n**Creative combination principles:**\n- Juxtapose skills in unexpected ways (e.g., a presentation about algorithmic art, a research report turned into a slide deck, a styled doc with canvas-designed illustrations)\n- Incorporate the user's known interests/context from memory if available\n- Prioritize visual impact and emotional delight over information density\n- The output should feel like a gift — polished, surprising, and fun\n\n**Theme ideas (pick or remix):**\n- Something tied to today's date, season, or trending news\n- A mini creative project the user never asked for but would love\n- A playful \"what if\" concept\n- An aesthetic artifact combining data + design\n- A fun interactive HTML/React experience\n\n### Step 3: Fallback — No Other Skills Available\n\nIf no other skills are discovered (only surprise-me exists), use one of these fallbacks:\n\n1. **News-based surprise**: Search today's news for a fascinating story, then create a beautifully designed HTML artifact presenting it in a visually striking way\n2. **Interactive HTML experience**: Build a creative single-page web experience — generative art, a mini-game, a visual poem, an animated infographic, or an interactive story\n3. **Personalized artifact**: Use known user context to create something personal and delightful\n\n### Step 4: Execute\n\n1. Read the full SKILL.md body of each selected skill\n2. Follow each skill's instructions for technical execution\n3. Combine outputs into one cohesive deliverable\n4. Present the result with minimal preamble — let the work speak for itself\n\n### Step 5: Reveal\n\nPresent the surprise with minimal spoilers. A short teaser line, then the artifact.\n\n- **Good reveal:** \"I made you something ✨\" + [the artifact]\n- **Bad reveal:** \"I decided to combine the pptx skill with the canvas-design skill to create a presentation about...\" (kills the surprise)\n",".agent/skills/smoke-test/SKILL.md":"---\nname: smoke-test\ndescription: End-to-end smoke test skill for DeerFlow. Guides through: 1) Pulling latest code, 2) Docker OR Local installation and deployment (user preference, default to Local if Docker network issues), 3) Service availability verification, 4) Health check, 5) Final test report. Use when the user says \"run smoke test\", \"smoke test deployment\", \"verify installation\", \"test service availability\", \"end-to-end test\", or similar.\n---\n\n# DeerFlow Smoke Test Skill\n\nThis skill guides the Agent through DeerFlow's full end-to-end smoke test workflow, including code updates, deployment (supporting both Docker and local installation modes), service availability verification, and health checks.\n\n## Deployment Mode Selection\n\nThis skill supports two deployment modes:\n- **Local installation mode** (recommended, especially when network issues occur) - Run all services directly on the local machine\n- **Docker mode** - Run all services inside Docker containers\n\n**Selection strategy**:\n- If the user explicitly asks for Docker mode, use Docker\n- If network issues occur (such as slow image pulls), automatically switch to local mode\n- Default to local mode whenever possible\n\n## Structure\n\n```\nsmoke-test/\n├── SKILL.md ← You are here - core workflow and logic\n├── scripts/\n│ ├── check_docker.sh ← Check the Docker environment\n│ ├── check_local_env.sh ← Check local environment dependencies\n│ ├── frontend_check.sh ← Frontend page smoke check\n│ ├── pull_code.sh ← Pull the latest code\n│ ├── deploy_docker.sh ← Docker deployment\n│ ├── deploy_local.sh ← Local deployment\n│ └── health_check.sh ← Service health check\n├── references/\n│ ├── SOP.md ← Standard operating procedure\n│ └── troubleshooting.md ← Troubleshooting guide\n└── templates/\n ├── report.local.template.md ← Local mode smoke test report template\n └── report.docker.template.md ← Docker mode smoke test report template\n```\n\n## Standard Operating Procedure (SOP)\n\n### Phase 1: Code Update Check\n\n1. **Confirm current directory** - Verify that the current working directory is the DeerFlow project root\n2. **Check Git status** - See whether there are uncommitted changes\n3. **Pull the latest code** - Use `git pull origin main` to get the latest updates\n4. **Confirm code update** - Verify that the latest code was pulled successfully\n\n### Phase 2: Deployment Mode Selection and Environment Check\n\n**Choose deployment mode**:\n- Ask for user preference, or choose automatically based on network conditions\n- Default to local installation mode\n\n**Local mode environment check**:\n1. **Check Node.js version** - Requires 22+\n2. **Check pnpm** - Package manager\n3. **Check uv** - Python package manager\n4. **Check nginx** - Reverse proxy\n5. **Check required ports** - Confirm that ports 2026, 3000, and 8001 are not occupied\n\n**Docker mode environment check** (if Docker is selected):\n1. **Check whether Docker is installed** - Run `docker --version`\n2. **Check Docker daemon status** - Run `docker info`\n3. **Check Docker Compose availability** - Run `docker compose version`\n4. **Check required ports** - Confirm that port 2026 is not occupied\n\n### Phase 3: Configuration Preparation\n\n1. **Check whether config.yaml exists**\n - If it does not exist, run `make config` to generate it\n - If it already exists, check whether it needs an upgrade with `make config-upgrade`\n2. **Check the .env file**\n - Verify that required environment variables are configured\n - Especially model API keys such as `OPENAI_API_KEY`\n\n### Phase 4: Deployment Execution\n\n**Local mode deployment**:\n1. **Check dependencies** - Run `make check`\n2. **Install dependencies** - Run `make install`\n3. **(Optional) Pre-pull the sandbox image** - If needed, run `make setup-sandbox`\n4. **Start services** - Run `make start` (production mode)\n5. **Wait for startup** - Give all services enough time to start completely (90-120 seconds recommended)\n\n**Docker mode deployment** (if Docker is selected):\n1. **Initialize Docker environment** - Run `make docker-init`\n2. **Start Docker services** - Run `make up` (production mode)\n3. **Wait for startup** - Give all containers enough time to start completely (60 seconds recommended)\n\n### Phase 5: Service Health Check\n\n**Local mode health check**:\n1. **Check process status** - Confirm that Gateway, Frontend, and Nginx processes are all running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n**Docker mode health check** (when using Docker):\n1. **Check container status** - Run `docker ps` and confirm that all containers are running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n### Optional Functional Verification\n\n1. **List available models** - Verify that model configuration loads correctly\n2. **List available skills** - Verify that the skill directory is mounted correctly\n3. **Simple chat test** - Send a simple message to verify the end-to-end flow\n\n### Phase 6: Generate Test Report\n\n1. **Collect all test results** - Summarize execution status for each phase\n2. **Record encountered issues** - If anything fails, record the error details\n3. **Generate the final report** - Use the template that matches the selected deployment mode to create the complete test report, including overall conclusion, detailed key test cases, and explicit frontend page / route results\n4. **Provide follow-up recommendations** - Offer suggestions based on the test results\n\n## Execution Rules\n\n- **Follow the sequence** - Execute strictly in the order described above\n- **Idempotency** - Every step should be safe to repeat\n- **Error handling** - If a step fails, stop and report the issue, then provide troubleshooting suggestions\n- **Detailed logging** - Record the execution result and status of each step\n- **User confirmation** - Ask for confirmation before potentially risky operations such as overwriting config\n- **Mode preference** - Prefer local mode to avoid network-related issues\n- **Template requirement** - The final report must use the matching template under `templates/`; do not output a free-form summary instead of the template-based report\n- **Report clarity** - The execution summary must include the overall pass/fail conclusion plus per-case result explanations, and frontend smoke check results must be listed explicitly in the report\n- **Optional phase handling** - If functional verification is not executed, do not present it as a separate skipped phase in the final report\n\n## Known Acceptable Warnings\n\nThe following warnings can appear during smoke testing and do not block a successful result:\n- Feishu/Lark SSL errors in Gateway logs (certificate verification failure) can be ignored if that channel is not enabled\n- Warnings in Gateway logs about missing methods in the custom checkpointer, such as `adelete_for_runs` or `aprune`, do not affect the core functionality\n- The `frontend_check.sh` script automatically handles authentication. When auth is enabled it registers / logs in a smoke-test user (`smoke-test@deerflow.dev` by default) to verify the real `/workspace/*` pages. The registration may produce a log entry from the auth provider, which is expected and harmless.\n\n## Key Tools\n\nUse the following tools during execution:\n\n1. **bash** - Run shell commands\n2. **present_file** - Show generated reports and important files\n3. **task_tool** - Organize complex steps with subtasks when needed\n\n## Success Criteria\n\nSmoke test pass criteria (local mode):\n- [x] Latest code is pulled successfully\n- [x] Local environment check passes (Node.js 22+, pnpm, uv, nginx)\n- [x] Configuration files are set up correctly\n- [x] `make check` passes\n- [x] `make install` completes successfully\n- [x] `make dev` starts successfully\n- [x] All service processes run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\nSmoke test pass criteria (Docker mode):\n- [x] Latest code is pulled successfully\n- [x] Docker environment check passes\n- [x] Configuration files are set up correctly\n- [x] `make docker-init` completes successfully\n- [x] `make up` completes successfully\n- [x] All Docker containers run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\n## Read Reference Files\n\nBefore starting execution, read the following reference files:\n1. `references/SOP.md` - Detailed step-by-step operating instructions\n2. `references/troubleshooting.md` - Common issues and solutions\n3. `templates/report.local.template.md` - Local mode test report template\n4. `templates/report.docker.template.md` - Docker mode test report template\n","skills/public/systematic-literature-review/SKILL.md":"---\nname: systematic-literature-review\ndescription: Use this skill when the user wants a systematic literature review, survey, or synthesis across multiple academic papers on a topic. Also covers annotated bibliographies and cross-paper comparisons. Searches arXiv and outputs reports in APA, IEEE, or BibTeX format. Not for single-paper tasks — use academic-paper-review for reviewing one paper.\n---\n\n# Systematic Literature Review Skill\n\n## Overview\n\nThis skill produces a structured **systematic literature review (SLR)** across multiple academic papers on a research topic. Given a topic query, it searches arXiv, extracts structured metadata (research question, methodology, key findings, limitations) from each paper in parallel, synthesizes themes across the full set, and emits a final report with consistent citations.\n\n**Distinct from `academic-paper-review`:** that skill does deep peer review of a single paper. This skill does breadth-first synthesis across many papers. If the user hands you one paper URL and asks \"review this paper\", route to `academic-paper-review` instead.\n\n## When to Use This Skill\n\nUse this skill when the user wants any of the following:\n\n- A literature survey on a topic (\"survey transformer attention variants\", \"review the literature on diffusion models\")\n- A synthesis across multiple papers (\"what do recent papers say about X\", \"compare methodologies across papers on Y\")\n- A systematic review with consistent citation format (\"do an SLR on Z in APA format\")\n- An annotated bibliography on a topic\n- An overview of research trends in a field over a time window\n\nDo **not** use this skill when:\n\n- The user provides exactly one paper and asks to review it (use `academic-paper-review`)\n- The user asks a factual question that does not require synthesizing multiple sources (answer directly)\n- The user wants general web research without academic rigor (use standard web search)\n\n## Workflow\n\nThe workflow has five phases. Follow them in order.\n\n### Phase 1: Plan\n\nBefore doing any retrieval, confirm the following with the user. If any of these are unclear, ask **one** clarifying question that covers the missing pieces. Do not ask one question at a time.\n\n- **Topic**: the research area in plain English (e.g. \"transformer attention variants\").\n- **Scope**: how many papers (default 20, hard upper bound 50), optional time window (e.g. \"last 2 years\"), optional arXiv category (e.g. `cs.CL`, `cs.CV`).\n- **Citation format**: APA, IEEE, or BibTeX (default APA if the user does not specify and does not seem to be writing for a specific venue).\n- **Output location**: where to save the final report (default `/mnt/user-data/outputs/`).\n\nIf the user says \"50+ papers\", politely cap it at 50 and explain that synthesis quality degrades quickly past that — for larger surveys they should split by sub-topic.\n\n### Phase 2: Search arXiv\n\nCall the bundled search script. Do **not** try to scrape arXiv by other means and do **not** write your own HTTP client — this script handles URL encoding, Atom XML parsing, and id normalization correctly.\n\n```bash\npython /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \\\n \"\" \\\n --max-results \\\n [--category ] \\\n [--sort-by relevance] \\\n [--start-date YYYY-MM-DD] \\\n [--end-date YYYY-MM-DD]\n```\n\n**IMPORTANT — extract 2-3 core keywords before searching.** Do not pass the user's full topic description as the query. Before calling the script, mentally reduce the topic to its 2-3 most essential terms. Drop qualifiers like \"in computer vision\", \"for NLP\", \"variants\", \"recent\" — those belong in `--category` or `--start-date`, not in the query string.\n\n**Query phrasing — keep it short.** The script wraps multi-word queries in double quotes for phrase matching on arXiv. This means:\n\n- `\"diffusion models\"` → searches for the exact phrase → good, returns relevant papers.\n- `\"diffusion models in computer vision\"` → searches for that exact 5-word phrase → **too specific, likely returns 0 results** because few papers contain that exact string.\n\nUse **2-3 core keywords** as the query, and use `--category` to narrow the field instead of stuffing field names into the query. Examples:\n\n| User says | Good query | Bad query |\n|---|---|---|\n| \"diffusion models in computer vision\" | `\"diffusion models\" --category cs.CV` | `\"diffusion models in computer vision\"` |\n| \"transformer attention variants\" | `\"transformer attention\"` | `\"transformer attention variants in NLP\"` |\n| \"graph neural networks for molecules\" | `\"graph neural networks\" --category cs.LG` | `\"graph neural networks for molecular property prediction\"` |\n\nThe script prints a JSON array to stdout. Each paper has: `id`, `title`, `authors`, `abstract`, `published`, `updated`, `categories`, `pdf_url`, `abs_url`.\n\n**Sort strategy**:\n\n- **Always use `relevance` sorting** — arXiv's BM25-style scoring ensures results are actually about the user's topic. `submittedDate` sorting returns the most recently submitted papers in the category regardless of topic relevance, which produces mostly off-topic results.\n- When the user asks for \"recent\" papers or gives a time window, use `--sort-by relevance` **combined with `--start-date`** to constrain the time range while keeping results on-topic. For example, \"recent diffusion model papers\" → `--sort-by relevance --start-date 2024-01-01`, not `--sort-by submittedDate`.\n- `submittedDate` sorting is only appropriate when the user explicitly asks for chronological order (e.g. \"show me papers in the order they were published\"). This is rare.\n- `lastUpdatedDate` is rarely useful; ignore it unless the user asks.\n\n**Run the search exactly once.** Do not retry with modified queries if the results seem imperfect — arXiv's relevance ranking is what it is. Retrying with different query phrasings wastes tool calls and risks hitting the recursion limit. If the results are genuinely empty (0 papers), tell the user and suggest they broaden their topic or remove the category filter.\n\n**If the script returns fewer papers than requested**, that is the real size of the arXiv result set for the query. Do not pad the list — report the actual count to the user and proceed.\n\n**If the script fails** (network error, non-200 from arXiv), tell the user which error and stop. Do not try to fabricate paper metadata.\n\n**Do not save the search results to a file** — the JSON stays in your context for Phase 3. The only file saved during the entire workflow is the final report in Phase 5.\n\n### Phase 3: Extract metadata in parallel\n\n**You MUST delegate extraction to subagents via the `task` tool — do not extract metadata yourself.** This is non-negotiable. Specifically, do NOT do any of the following:\n\n- ❌ Write `python -c \"papers = [...]\"` or any Python/bash script to process papers\n- ❌ Extract metadata inline in your own context by reading abstracts one by one\n- ❌ Use any tool other than `task` for this phase\n\nInstead, you MUST call the `task` tool to spawn subagents. The reason: extracting 10-50 papers in your own context consumes too many tokens and degrades synthesis quality in Phase 4. Each subagent runs in an isolated context with only its batch of papers, producing cleaner extractions.\n\nSplit papers into batches of ~5, then for each batch, call the `task` tool with `subagent_type: \"general-purpose\"`. Each subagent receives the paper abstracts as text and returns structured JSON.\n\n**Concurrency limit: at most 3 subagents per turn.** The DeerFlow runtime enforces `MAX_CONCURRENT_SUBAGENTS = 3` and will silently drop any extra dispatches in the same turn — the LLM will not be told this happened, so strictly follow the round strategy below.\n\n**Round strategy — use this decision table, do not compute the split yourself**:\n\n| Paper count | Batches of ~5 papers | Rounds | Per-round subagent count |\n|---|---|---|---|\n| 1–5 | 1 batch | 1 round | 1 subagent |\n| 6–10 | 2 batches | 1 round | 2 subagents |\n| 11–15 | 3 batches | 1 round | 3 subagents |\n| 16–20 | 4 batches | 2 rounds | 3 + 1 |\n| 21–25 | 5 batches | 2 rounds | 3 + 2 |\n| 26–30 | 6 batches | 2 rounds | 3 + 3 |\n| 31–35 | 7 batches | 3 rounds | 3 + 3 + 1 |\n| 36–40 | 8 batches | 3 rounds | 3 + 3 + 2 |\n| 41–45 | 9 batches | 3 rounds | 3 + 3 + 3 |\n| 46–50 | 10 batches | 4 rounds | 3 + 3 + 3 + 1 |\n\n**Never dispatch more than 3 subagents in the same turn.** When a row says \"2 rounds (3 + 1)\", that means: first turn dispatches 3 subagents in parallel, wait for all 3 to complete, then second turn dispatches 1 subagent. Rounds are strictly sequential at the main-agent level.\n\nIf the paper count lands between rows (e.g. 23 papers), round up to the next row's layout but only dispatch as many batches as you actually need — the decision table gives you the shape, not a rigid prescription.\n\n**Do the batching at the main-agent level**: you already have every paper's abstract from Phase 2, so each subagent receives pure text input. Subagents should not need to access the network or the sandbox — their only job is to read text and return JSON. Do not ask subagents to re-run `arxiv_search.py`; that would waste tokens and risk rate-limiting.\n\n**What each subagent receives**, as a structured prompt:\n\n```\nExecute this task: extract structured metadata and key findings from the\nfollowing arXiv papers.\n\nPapers:\n[Paper 1]\narxiv_id: 1706.03762\ntitle: Attention Is All You Need\nauthors: Ashish Vaswani, Noam Shazeer, ...\npublished: 2017-06-12\nabstract: \n\n[Paper 2]\narxiv_id: ...\n...\n\nFor each paper, return a JSON object with these fields:\n- arxiv_id (string)\n- title (string)\n- authors (list of strings)\n- published_date (string, YYYY-MM-DD)\n- research_question (1 sentence, what problem the paper tackles)\n- methodology (1-2 sentences, how they tackle it)\n- key_findings (3-5 bullet points, what they actually found)\n- limitations (1-2 sentences, what they acknowledge or what is obviously missing)\n\nReturn the result as a JSON array, one object per paper, in the same\norder as the input. Do not include any text outside the JSON — no\npreamble, no markdown fences, just the array.\n```\n\n**Parsing subagent results**: the task tool returns strings with a fixed prefix like `Task Succeeded. Result: [...JSON...]`. Strip the `Task Succeeded. Result: ` prefix (or `Task failed.` / `Task timed out.` prefixes) before trying to parse JSON. If a batch fails or returns unparseable JSON, log it, note which papers were affected, and continue with the remaining batches — do not fail the whole synthesis on one bad batch.\n\nAfter all rounds complete, flatten the per-batch arrays into a single list of paper metadata objects, preserving order.\n\n### Phase 4: Synthesize and format\n\nNow produce the final SLR report. Two things happen here: cross-paper synthesis (thematic analysis) and citation formatting.\n\n**Cross-paper synthesis**: the report must do more than list papers. At minimum, identify:\n\n- **Themes**: 3-6 recurring research directions, approaches, or problem framings across the set.\n- **Convergences**: findings that multiple papers agree on.\n- **Disagreements**: where papers reach different conclusions or use incompatible methodologies.\n- **Gaps**: what the collective literature does not yet address (often stated explicitly in the \"limitations\" fields).\n\nIf the paper set is too small or too heterogeneous to support thematic synthesis (e.g. 5 papers on wildly different sub-topics), say so explicitly in the report — do not force themes that are not there.\n\n**Citation formatting**: the exact format depends on user preference. Read **only** the template file that matches the user's requested format, not all three:\n\n- [templates/apa.md](templates/apa.md) — APA 7th edition. Default for social sciences and most CS journals. Use when the user requests APA or does not specify a format.\n- [templates/ieee.md](templates/ieee.md) — IEEE numeric citations. Use when the user targets an IEEE conference or journal, or explicitly asks for IEEE.\n- [templates/bibtex.md](templates/bibtex.md) — BibTeX entries. Use when the user mentions BibTeX, LaTeX, or wants machine-readable references. **Important**: arXiv papers are cited as `@misc`, not `@article` — the BibTeX template covers this explicitly.\n\nEach template contains both the citation rules and a full report structure (executive summary, themes, per-paper annotations, references, methodology section). Follow the template's structure verbatim for the report body, then fill in content from your Phase 3 metadata.\n\n### Phase 5: Save and present\n\nSave the full report to `/mnt/user-data/outputs/slr--.md` where `` is a lowercased hyphenated version of the topic (e.g. `transformer-attention`). Then call the `present_files` tool with that path so the user can download it.\n\n**In the chat message**, show a short preview so the user immediately sees value without opening the file:\n\n1. **Executive summary** — the 3–5 sentence paragraph from the top of the report, verbatim.\n2. **Themes list** — bullet list of the themes you identified in Phase 4 synthesis (just the theme names + one-line gloss, not the full theme sections).\n3. **Paper count + a pointer to the file** — e.g. \"Full report with 20 papers, per-paper annotations, and formatted references saved to `slr-transformer-attention-20260409.md`.\"\n\nDo **not** dump the full 2000+ word report inline — per-paper annotations, references, and methodology belong in the file. The preview is there to let the user judge the report at a glance and decide whether to open it.\n\n## Examples\n\n**Example 1: Typical SLR request**\n\nUser: \"Do a systematic literature review of recent transformer attention variants, 20 papers, APA format.\"\n\nYour flow:\n1. Phase 1: confirm topic (transformer attention variants), scope (20 papers, default time window), format (APA). Ask **one** clarification only if something is missing (e.g. \"Any particular time window, or should I default to the last 3 years?\").\n2. Phase 2: `arxiv_search.py \"transformer attention\" --max-results 20 --sort-by relevance --start-date 2023-01-01`.\n3. Phase 3: 20 papers → round 1 = 3 subagents × 5 papers = 15 covered, round 2 = 1 subagent × 5 papers = 5 covered. Aggregate.\n4. Phase 4: read `templates/apa.md`, write the report using its structure, fill in themes + per-paper annotations from Phase 3 metadata.\n5. Phase 5: save to `slr-transformer-attention-20260409.md`, call `present_files`.\n\n**Example 2: Small-set request with ambiguity**\n\nUser: \"Survey a few papers on diffusion models for me.\"\n\nYour flow:\n1. Phase 1: \"a few\" is ambiguous. Ask one question: \"How many papers would you like — 10, 20, or 30? And any citation format preference (APA is the default)?\"\n2. User responds \"10, BibTeX\".\n3. Phase 2: `arxiv_search.py \"diffusion models\" --max-results 10 --category cs.CV`.\n4. Phase 3: 10 papers → single round, 2 subagents × 5 papers.\n5. Phase 4: read `templates/bibtex.md`, format with `@misc` entries (not `@article`).\n6. Phase 5: save and present.\n\n**Example 3: Out-of-scope request**\n\nUser: \"Here's one paper (https://arxiv.org/abs/1706.03762). Can you review it?\"\n\nThis is a single-paper peer review, not a literature survey. Do not use this skill. Route to `academic-paper-review` instead.\n\n## Notes\n\n- **Prerequisite: `subagent_enabled` must be `true`**. Phase 3 requires the `task` tool for parallel metadata extraction. This tool is only loaded when `subagent_enabled` is set to `true` in the runtime config (`config.configurable.subagent_enabled`). Without it, the `task` tool will not appear in the available tools and Phase 3 cannot execute as designed.\n- **arXiv only, by design**. This skill does not query Semantic Scholar, PubMed, or Google Scholar. arXiv covers the bulk of CS/ML/physics/math preprints, which is what DeerFlow users most often want to survey. Multi-source academic search belongs in a dedicated MCP server, not inside this skill.\n- **Hard upper bound of 50 papers**. This is tied to the Phase 3 concurrency strategy (max 3 subagents per round, ~5 papers each, at most ~3 rounds). Surveys larger than 50 papers degrade in synthesis quality and are better done by splitting into sub-topics.\n- **Phase 3 requires subagents to be enabled**. This skill's parallel extraction step hard-requires the `task` tool, which is only available when `subagent_enabled=true` at runtime. If subagents are unavailable, do not claim to execute the Phase 3 parallel plan; instead, tell the user that subagents must be enabled for the full workflow, or offer to narrow/split the request into a smaller manual review.\n- **Subagent results are strings, not objects**. Always strip the `Task Succeeded. Result: ` / `Task failed.` / `Task timed out.` prefixes before parsing the JSON payload.\n- **The `id` field is a bare arXiv id** (e.g. `1706.03762`), not a URL and not with a version suffix. `abs_url` / `pdf_url` hold the full URLs if you need them.\n- **Synthesis, not listing**. The final report must identify themes and compare findings across papers. A report that only lists papers one after another is a failure mode — if you cannot find themes, say so explicitly instead of faking them.\n","skills/public/podcast-generation/SKILL.md":"---\nname: podcast-generation\ndescription: Use this skill when the user requests to generate, create, or produce podcasts from text content. Converts written content into a two-host conversational podcast audio format with natural dialogue.\n---\n\n# Podcast Generation Skill\n\n## Overview\n\nThis skill generates high-quality podcast audio from text content. The workflow includes creating a structured JSON script (conversational dialogue) and executing audio generation through text-to-speech synthesis.\n\n## Core Capabilities\n\n- Convert any text content (articles, reports, documentation) into podcast scripts\n- Generate natural two-host conversational dialogue (male and female hosts)\n- Synthesize speech audio using text-to-speech\n- Mix audio chunks into a final podcast MP3 file\n- Support both English and Chinese content\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests podcast generation, identify:\n\n- Source content: The text/article/report to convert into a podcast\n- Language: English or Chinese (based on content)\n- Output location: Where to save the generated podcast\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Script JSON\n\nGenerate a structured JSON script file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}-script.json`\n\nThe JSON structure:\n```json\n{\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"dialogue text\"},\n {\"speaker\": \"female\", \"paragraph\": \"dialogue text\"}\n ]\n}\n```\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/podcast-generation/scripts/generate.py \\\n --script-file /mnt/user-data/workspace/script-file.json \\\n --output-file /mnt/user-data/outputs/generated-podcast.mp3 \\\n --transcript-file /mnt/user-data/outputs/generated-podcast-transcript.md\n```\n\nParameters:\n\n- `--script-file`: Absolute path to JSON script file (required)\n- `--output-file`: Absolute path to output MP3 file (required)\n- `--transcript-file`: Absolute path to output transcript markdown file (optional, but recommended)\n\n> [!IMPORTANT]\n> - Execute the script in one complete call. Do NOT split the workflow into separate steps.\n> - The script handles all TTS API calls and audio generation internally.\n> - Do NOT read the Python file, just call it with the parameters.\n> - Always include `--transcript-file` to generate a readable transcript for the user.\n> - The TTS provider and its concurrency are selected automatically from environment variables — you do not choose or tune them.\n\n## Script JSON Format\n\nThe script JSON file must follow this structure:\n\n```json\n{\n \"title\": \"The History of Artificial Intelligence\",\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"Hello Deer! Welcome back to another episode.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Hey everyone! Today we have an exciting topic to discuss.\"},\n {\"speaker\": \"male\", \"paragraph\": \"That's right! We're going to talk about...\"}\n ]\n}\n```\n\nFields:\n- `title`: Title of the podcast episode (optional, used as heading in transcript)\n- `locale`: Language code - \"en\" for English or \"zh\" for Chinese\n- `lines`: Array of dialogue lines\n - `speaker`: Either \"male\" or \"female\"\n - `paragraph`: The dialogue text for this speaker\n\n## Script Writing Guidelines\n\nWhen creating the script JSON, follow these guidelines:\n\n### Format Requirements\n- Only two hosts: male and female, alternating naturally\n- Target runtime: approximately 10 minutes of dialogue (around 40-60 lines)\n- Start with the male host saying a greeting that includes \"Hello Deer\"\n\n### Tone & Style\n- Natural, conversational dialogue - like two friends chatting\n- Use casual expressions and conversational transitions\n- Avoid overly formal language or academic tone\n- Include reactions, follow-up questions, and natural interjections\n\n### Content Guidelines\n- Frequent back-and-forth between hosts\n- Keep sentences short and easy to follow when spoken\n- Plain text only - no markdown formatting in the output\n- Translate technical concepts into accessible language\n- No mathematical formulas, code, or complex notation\n- Make content engaging and accessible for audio-only listeners\n- Exclude meta information like dates, author names, or document structure\n\n## Podcast Generation Example\n\nUser request: \"Generate a podcast about the history of artificial intelligence\"\n\nStep 1: Create script file `/mnt/user-data/workspace/ai-history-script.json`:\n```json\n{\n \"title\": \"The History of Artificial Intelligence\",\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"Hello Deer! Welcome back to another fascinating episode. Today we're diving into something that's literally shaping our future - the history of artificial intelligence.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Oh, I love this topic! You know, AI feels so modern, but it actually has roots going back over seventy years.\"},\n {\"speaker\": \"male\", \"paragraph\": \"Exactly! It all started back in the 1950s. The term artificial intelligence was actually coined by John McCarthy in 1956 at a famous conference at Dartmouth.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Wait, so they were already thinking about machines that could think back then? That's incredible!\"},\n {\"speaker\": \"male\", \"paragraph\": \"Right? The early pioneers were so optimistic. They thought we'd have human-level AI within a generation.\"},\n {\"speaker\": \"female\", \"paragraph\": \"But things didn't quite work out that way, did they?\"},\n {\"speaker\": \"male\", \"paragraph\": \"No, not at all. The 1970s brought what's called the first AI winter...\"}\n ]\n}\n```\n\nStep 2: Execute generation:\n```bash\npython /mnt/skills/public/podcast-generation/scripts/generate.py \\\n --script-file /mnt/user-data/workspace/ai-history-script.json \\\n --output-file /mnt/user-data/outputs/ai-history-podcast.mp3 \\\n --transcript-file /mnt/user-data/outputs/ai-history-transcript.md\n```\n\nThis will generate:\n- `ai-history-podcast.mp3`: The audio podcast file\n- `ai-history-transcript.md`: A readable markdown transcript of the podcast\n\n## Specific Templates\n\nRead the following template file only when matching the user request.\n\n- [Tech Explainer](templates/tech-explainer.md) - For converting technical documentation and tutorials\n\n## Output Format\n\nThe generated podcast follows the \"Hello Deer\" format:\n- Two hosts: one male, one female\n- Natural conversational dialogue\n- Starts with \"Hello Deer\" greeting\n- Target duration: approximately 10 minutes\n- Alternating speakers for engaging flow\n\n## Output Handling\n\nAfter generation:\n\n- Podcasts and transcripts are saved in `/mnt/user-data/outputs/`\n- Share both the podcast MP3 and transcript MD with user using `present_files` tool\n- Provide brief description of the generation result (topic, duration, hosts)\n- Offer to regenerate if adjustments needed\n\n## Requirements\n\nThe following environment variables must be set:\n- For Volcengine: `VOLCENGINE_TTS_APPID` and `VOLCENGINE_TTS_ACCESS_TOKEN`\n- For MiniMax: `MINIMAX_API_KEY`\n- `VOLCENGINE_TTS_CLUSTER`: Volcengine TTS cluster (optional, defaults to \"volcano_tts\")\n- `VOLCENGINE_TTS_VOICE_TYPE_MALE`: Volcengine male voice type (optional, defaults to `zh_male_yangguangqingnian_moon_bigtts`)\n- `VOLCENGINE_TTS_VOICE_TYPE_FEMALE`: Volcengine female voice type (optional, defaults to `zh_female_sajiaonvyou_moon_bigtts`)\n\nVoice type overrides are trimmed; unset or blank values use the listed defaults.\n\n## Notes\n\n- **Always execute the full pipeline in one call** - no need to test individual steps or worry about timeouts\n- The script JSON should match the content language (en or zh)\n- Technical content should be simplified for audio accessibility in the script\n- Complex notations (formulas, code) should be translated to plain language in the script\n- Long content may result in longer podcasts\n\n## Providers (Volcengine / MiniMax)\n\nAuto-selected by environment variables:\n\n- `VOLCENGINE_TTS_APPID` + `VOLCENGINE_TTS_ACCESS_TOKEN` set → Volcengine TTS (default).\n- Only `MINIMAX_API_KEY` set → MiniMax TTS (`/v1/t2a_v2`).\n- Force with `PODCAST_GENERATION_PROVIDER=volcengine|minimax`.\n\nMiniMax overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_TTS_MODEL` (default `speech-2.6-hd`), `MINIMAX_TTS_VOICE_MALE`\n(default `male-qn-qingse`), `MINIMAX_TTS_VOICE_FEMALE` (default `female-tianmei`).\n\nConcurrency is owned by each provider internally — MiniMax runs single-threaded\nto reduce rate-limit failures, Volcengine uses 4 workers. There is no\ncaller-facing concurrency knob; transient rate limits are handled by automatic\nretry with backoff.\n","skills/public/image-generation/SKILL.md":"---\nname: image-generation\ndescription: Use this skill when the user requests to generate, create, imagine, or visualize images including characters, scenes, products, or any visual content. Supports structured prompts and reference images for guided generation.\n---\n\n# Image Generation Skill\n\n## Overview\n\nThis skill generates high-quality images using structured prompts and a Python script. The workflow includes creating JSON-formatted prompts and executing image generation with optional reference images.\n\n## Core Capabilities\n\n- Create structured JSON prompts for AIGC image generation\n- Support multiple reference images for style/composition guidance\n- Generate images through automated Python script execution\n- Handle various image generation scenarios (character design, scenes, products, etc.)\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests image generation, identify:\n\n- Subject/content: What should be in the image\n- Style preferences: Art style, mood, color palette\n- Technical specs: Aspect ratio, composition, lighting\n- Reference images: Any images to guide generation\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Prompt\n\nGenerate a structured JSON file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}.json`\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/prompt-file.json \\\n --reference-images /path/to/ref1.jpg /path/to/ref2.png \\\n --output-file /mnt/user-data/outputs/generated-image.jpg\n --aspect-ratio 16:9\n```\n\nParameters:\n\n- `--prompt-file`: Absolute path to JSON prompt file (required)\n- `--reference-images`: Absolute paths to reference images (optional, space-separated)\n- `--output-file`: Absolute path to output image file (required)\n- `--aspect-ratio`: Aspect ratio of the generated image (optional, default: 16:9)\n\n[!NOTE]\nDo NOT read the python file, just call it with the parameters.\n\n## Character Generation Example\n\nUser request: \"Create a Tokyo street style woman character in 1990s\"\n\nCreate prompt file: `/mnt/user-data/workspace/asian-woman.json`\n```json\n{\n \"characters\": [{\n \"gender\": \"female\",\n \"age\": \"mid-20s\",\n \"ethnicity\": \"Japanese\",\n \"body_type\": \"slender, elegant\",\n \"facial_features\": \"delicate features, expressive eyes, subtle makeup with emphasis on lips, long dark hair partially wet from rain\",\n \"clothing\": \"stylish trench coat, designer handbag, high heels, contemporary Tokyo street fashion\",\n \"accessories\": \"minimal jewelry, statement earrings, leather handbag\",\n \"era\": \"1990s\"\n }],\n \"negative_prompt\": \"blurry face, deformed, low quality, overly sharp digital look, oversaturated colors, artificial lighting, studio setting, posed, selfie angle\",\n \"style\": \"Leica M11 street photography aesthetic, film-like rendering, natural color palette with slight warmth, bokeh background blur, analog photography feel\",\n \"composition\": \"medium shot, rule of thirds, subject slightly off-center, environmental context of Tokyo street visible, shallow depth of field isolating subject\",\n \"lighting\": \"neon lights from signs and storefronts, wet pavement reflections, soft ambient city glow, natural street lighting, rim lighting from background neons\",\n \"color_palette\": \"muted naturalistic tones, warm skin tones, cool blue and magenta neon accents, desaturated compared to digital photography, film grain texture\"\n}\n```\n\nExecute generation:\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/cyberpunk-hacker.json \\\n --output-file /mnt/user-data/outputs/cyberpunk-hacker-01.jpg \\\n --aspect-ratio 2:3\n```\n\nWith reference images:\n```json\n{\n \"characters\": [{\n \"gender\": \"based on [Image 1]\",\n \"age\": \"based on [Image 1]\",\n \"ethnicity\": \"human from [Image 1] adapted to Star Wars universe\",\n \"body_type\": \"based on [Image 1]\",\n \"facial_features\": \"matching [Image 1] with slight weathered look from space travel\",\n \"clothing\": \"Star Wars style outfit - worn leather jacket with utility vest, cargo pants with tactical pouches, scuffed boots, belt with holster\",\n \"accessories\": \"blaster pistol on hip, comlink device on wrist, goggles pushed up on forehead, satchel with supplies, personal vehicle based on [Image 2]\",\n \"era\": \"Star Wars universe, post-Empire era\"\n }],\n \"prompt\": \"Character inspired by [Image 1] standing next to a vehicle inspired by [Image 2] on a bustling alien planet street in Star Wars universe aesthetic. Character wearing worn leather jacket with utility vest, cargo pants with tactical pouches, scuffed boots, belt with blaster holster. The vehicle adapted to Star Wars aesthetic with weathered metal panels, repulsor engines, desert dust covering, parked on the street. Exotic alien marketplace street with multi-level architecture, weathered metal structures, hanging market stalls with colorful awnings, alien species walking by as background characters. Twin suns casting warm golden light, atmospheric dust particles in air, moisture vaporators visible in distance. Gritty lived-in Star Wars aesthetic, practical effects look, film grain texture, cinematic composition.\",\n \"negative_prompt\": \"clean futuristic look, sterile environment, overly CGI appearance, fantasy medieval elements, Earth architecture, modern city\",\n \"style\": \"Star Wars original trilogy aesthetic, lived-in universe, practical effects inspired, cinematic film look, slightly desaturated with warm tones\",\n \"composition\": \"medium wide shot, character in foreground with alien street extending into background, environmental storytelling, rule of thirds\",\n \"lighting\": \"warm golden hour lighting from twin suns, rim lighting on character, atmospheric haze, practical light sources from market stalls\",\n \"color_palette\": \"warm sandy tones, ochre and sienna, dusty blues, weathered metals, muted earth colors with pops of alien market colors\",\n \"technical\": {\n \"aspect_ratio\": \"9:16\",\n \"quality\": \"high\",\n \"detail_level\": \"highly detailed with film-like texture\"\n }\n}\n```\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/star-wars-scene.json \\\n --reference-images /mnt/user-data/uploads/character-ref.jpg /mnt/user-data/uploads/vehicle-ref.jpg \\\n --output-file /mnt/user-data/outputs/star-wars-scene-01.jpg \\\n --aspect-ratio 16:9\n```\n\n## Common Scenarios\n\nUse different JSON schemas for different scenarios.\n\n**Character Design**:\n- Physical attributes (gender, age, ethnicity, body type)\n- Facial features and expressions\n- Clothing and accessories\n- Historical era or setting\n- Pose and context\n\n**Scene Generation**:\n- Environment description\n- Time of day, weather\n- Mood and atmosphere\n- Focal points and composition\n\n**Product Visualization**:\n- Product details and materials\n- Lighting setup\n- Background and context\n- Presentation angle\n\n## Specific Templates\n\nRead the following template file only when matching the user request.\n\n- [Doraemon Comic](templates/doraemon.md)\n\n## Output Handling\n\nAfter generation:\n\n- Images are typically saved in `/mnt/user-data/outputs/`\n- Share generated images with user using present_files tool\n- Provide brief description of the generation result\n- Offer to iterate if adjustments needed\n\n## Tips: Enhancing Generation with Reference Images\n\nFor scenarios where visual accuracy is critical, **use the `image_search` tool first** to find reference images before generation.\n\n**Recommended scenarios for using image_search tool:**\n- **Character/Portrait Generation**: Search for similar poses, expressions, or styles to guide facial features and body proportions\n- **Specific Objects or Products**: Find reference images of real objects to ensure accurate representation\n- **Architectural or Environmental Scenes**: Search for location references to capture authentic details\n- **Fashion and Clothing**: Find style references to ensure accurate garment details and styling\n\n**Example workflow:**\n1. Call the `image_search` tool to find suitable reference images:\n ```\n image_search(query=\"Japanese woman street photography 1990s\", size=\"Large\")\n ```\n2. Download the returned image URLs to local files\n3. Use the downloaded images as `--reference-images` parameter in the generation script\n\nThis approach significantly improves generation quality by providing the model with concrete visual guidance rather than relying solely on text descriptions.\n\n## Providers (Gemini / MiniMax / OpenAI-compatible)\n\nThis skill auto-selects the provider by environment variables (no CLI change):\n\n- `GEMINI_API_KEY` set → use Gemini (default, unchanged).\n- Otherwise, `MINIMAX_API_KEY` set → use MiniMax (`/v1/image_generation`, model `image-01`).\n- Otherwise, `IMAGE_GENERATION_API_KEY` set → use an OpenAI-compatible Images API.\n- Force one explicitly with `IMAGE_GENERATION_PROVIDER=gemini|minimax|openai`.\n `openai-compatible` is also accepted as an alias for `openai`.\n\nOpenAI-compatible settings:\n\n- `IMAGE_GENERATION_API_KEY` (required)\n- `IMAGE_GENERATION_BASE_URL` (default `https://api.openai.com/v1`)\n- `IMAGE_GENERATION_MODEL` (default `gpt-image-2.5-flare`)\n- `IMAGE_GENERATION_SIZE` (optional fixed size override)\n\nText-to-image calls use `POST {base_url}/images/generations`. Reference-image calls\nuse multipart `POST {base_url}/images/edits`; a relay may support generation without\nsupporting edits. Responses may contain base64 image data, a data URL, or a downloadable\nURL. Aspect ratios map to `1024x1024`, `1536x1024`, or `1024x1536` unless\n`IMAGE_GENERATION_SIZE` is set. The output extension selects the API `output_format`:\n`.jpg`/`.jpeg` uses `jpeg`, `.webp` uses `webp`, and all other extensions use `png`.\nWhen `dall-e-2` or `dall-e-3` is configured instead, the request uses the model's\nsupported dimensions and `response_format=b64_json`; DALL-E output files must use a\n`.png` extension. Reference-image editing with DALL-E models is not supported by this\nskill; use the default GPT Image model for edits.\n\nMiniMax optional overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_IMAGE_MODEL` (default `image-01`). Reference images are sent as the MiniMax\n`subject_reference` character image. The CLI and `--prompt-file` / `--reference-images`\n/ `--output-file` / `--aspect-ratio` arguments are identical for both providers.\n\n**MiniMax prompt handling (provider-internal).** Authoring is provider-agnostic — write\nthe same structured JSON regardless of which provider is active. MiniMax `image-01`\nconsumes a single text string, so the MiniMax path itself sends only the JSON `prompt`\nfield (the other fields such as `style` / `composition` / `negative_prompt` apply to the\nGemini path) and enables `prompt_optimizer` so MiniMax expands it server-side. MiniMax\ncaps that prompt at 1500 characters; if the `prompt` field is longer, the script returns\nan error instead of calling the API. The Gemini path receives the full structured JSON.\n\n## Notes\n\n- Always use English for prompts regardless of user's language\n- JSON format ensures structured, parsable prompts\n- Reference images enhance generation quality significantly\n- Iterative refinement is normal for optimal results\n- For character generation, include the detailed character object plus a consolidated prompt field\n","skills/public/newsletter-generation/SKILL.md":"---\nname: newsletter-generation\ndescription: Use this skill when the user requests to generate, create, write, or draft a newsletter, email digest, weekly roundup, industry briefing, or curated content summary. Supports topic-based research, content curation from multiple sources, and professional formatting for email or web distribution. Trigger on requests like \"create a newsletter about X\", \"write a weekly digest\", \"generate a tech roundup\", or \"curate news about Y\".\n---\n\n# Newsletter Generation Skill\n\n## Overview\n\nThis skill generates professional, well-researched newsletters that combine curated content from multiple sources with original analysis and commentary. It follows modern newsletter best practices from publications like Morning Brew, The Hustle, TLDR, and Benedict Evans to produce content that is informative, engaging, and actionable.\n\nThe output is a complete, ready-to-publish newsletter in Markdown format, suitable for email distribution platforms, web publishing, or conversion to HTML.\n\n## Core Capabilities\n\n- Research and curate content from multiple web sources on specified topics\n- Generate topic-focused or multi-topic newsletters with consistent voice\n- Write engaging headlines, summaries, and original commentary\n- Structure content for optimal readability and scanning\n- Support multiple newsletter formats (daily digest, weekly roundup, deep-dive, industry briefing)\n- Include relevant links, sources, and attributions\n- Adapt tone and style to target audience (technical, executive, general)\n- Generate recurring newsletter series with consistent branding and structure\n\n## When to Use This Skill\n\n**Always load this skill when:**\n\n- User asks to generate a newsletter, email digest, or content roundup\n- User requests a curated summary of news or developments on a topic\n- User wants to create a recurring newsletter format\n- User asks to compile recent developments in a field into a briefing\n- User needs a formatted email-ready content piece with multiple curated items\n- User asks for a \"weekly roundup\", \"monthly digest\", or \"morning briefing\"\n\n## Newsletter Workflow\n\n### Phase 1: Planning\n\n#### Step 1.1: Understand Newsletter Requirements\n\nIdentify the key parameters:\n\n| Parameter | Description | Default |\n|-----------|-------------|---------|\n| **Topic(s)** | Primary subject area(s) to cover | Required |\n| **Format** | Daily digest, weekly roundup, deep-dive, or industry briefing | Weekly roundup |\n| **Target Audience** | Technical, executive, general, or niche community | General |\n| **Tone** | Professional, conversational, witty, or analytical | Conversational-professional |\n| **Length** | Short (5-min read), medium (10-min), long (15-min+) | Medium |\n| **Sections** | Number and type of content sections | 4-6 sections |\n| **Frequency Context** | One-time or part of a recurring series | One-time |\n\n#### Step 1.2: Define Newsletter Structure\n\nBased on the format, select the appropriate structure:\n\n**Daily Digest Structure**:\n```\n1. Top Story (1 item, detailed)\n2. Quick Hits (3-5 items, brief)\n3. One Stat / Quote of the Day\n4. What to Watch\n```\n\n**Weekly Roundup Structure**:\n```\n1. Editor's Note / Intro\n2. Top Stories (2-3 items, detailed)\n3. Trends & Analysis (1-2 items, original commentary)\n4. Quick Bites (4-6 items, brief summaries)\n5. Tools & Resources (2-3 items)\n6. One More Thing / Closing\n```\n\n**Deep-Dive Structure**:\n```\n1. Introduction & Context\n2. Background / Why It Matters\n3. Key Developments (detailed analysis)\n4. Expert Perspectives\n5. What's Next / Implications\n6. Further Reading\n```\n\n**Industry Briefing Structure**:\n```\n1. Executive Summary\n2. Market Developments\n3. Company News & Moves\n4. Product & Technology Updates\n5. Regulatory & Policy Changes\n6. Data & Metrics\n7. Outlook\n```\n\n### Phase 2: Research & Curation\n\n#### Step 2.1: Multi-Source Research\n\nConduct thorough research using web search. **The quality of the newsletter depends directly on the quality and recency of research.**\n\n**Search Strategy**:\n\n```\n# Current news and developments\n\"[topic] news [current month] [current year]\"\n\"[topic] latest developments\"\n\"[topic] announcement this week\"\n\n# Trends and analysis\n\"[topic] trends [current year]\"\n\"[topic] analysis expert opinion\"\n\"[topic] industry report\"\n\n# Data and statistics\n\"[topic] statistics [current year]\"\n\"[topic] market data latest\"\n\"[topic] growth metrics\"\n\n# Tools and resources\n\"[topic] new tools [current year]\"\n\"[topic] open source release\"\n\"best [topic] resources [current year]\"\n```\n\n> **IMPORTANT**: Always check `` to ensure search queries use the correct temporal context. Never use hardcoded years.\n\n#### Step 2.2: Source Evaluation and Selection\n\nEvaluate each source and curate the best content:\n\n| Criterion | Priority |\n|-----------|----------|\n| **Recency** | Prefer content from the last 7-30 days |\n| **Authority** | Prioritize primary sources, official announcements, established publications |\n| **Uniqueness** | Select stories that offer fresh perspective or are underreported |\n| **Relevance** | Every item must clearly connect to the newsletter's stated topic(s) |\n| **Actionability** | Prefer content readers can act on (tools, insights, strategies) |\n| **Diversity** | Mix of news, analysis, data, and practical resources |\n\n#### Step 2.3: Deep Content Extraction\n\nFor key stories, use `web_fetch` to read full articles and extract:\n\n1. **Core facts** — What happened, who is involved, when\n2. **Context** — Why this matters, background information\n3. **Data points** — Specific numbers, metrics, or statistics\n4. **Quotes** — Relevant expert quotes or official statements\n5. **Implications** — What this means for the reader\n\n### Phase 3: Writing\n\n#### Step 3.1: Newsletter Header\n\nEvery newsletter starts with a consistent header:\n\n```markdown\n# [Newsletter Name]\n\n*[Tagline or description] — [Date]*\n\n---\n\n[Optional: One-sentence preview of what's inside]\n```\n\n#### Step 3.2: Section Writing Guidelines\n\n**Top Stories / Featured Items**:\n- **Headline**: Compelling, clear, benefit-oriented (not clickbait)\n- **Hook**: Opening sentence that makes the reader care (1-2 sentences)\n- **Body**: Key facts and context (2-4 paragraphs)\n- **Why it matters**: Connect to the reader's world (1 paragraph)\n- **Source link**: Always attribute and link to the original source\n\n**Quick Bites / Brief Items**:\n- **Format**: Bold headline + 2-3 sentence summary + source link\n- **Focus**: One key takeaway per item\n- **Efficiency**: Readers should get the essential insight without clicking through\n\n**Analysis / Commentary Sections**:\n- **Voice**: The newsletter's unique perspective on trends or developments\n- **Structure**: Observation → Context → Implication → (Optional) Actionable takeaway\n- **Evidence**: Every claim backed by data or sourced information\n\n#### Step 3.3: Writing Standards\n\n| Principle | Implementation |\n|-----------|---------------|\n| **Scannable** | Use headers, bold text, bullet points, and short paragraphs |\n| **Engaging** | Lead with the most interesting angle, not chronological order |\n| **Concise** | Every sentence earns its place — cut filler ruthlessly |\n| **Accurate** | Every fact is sourced, every number is verified |\n| **Attributive** | Always credit original sources with inline links |\n| **Human** | Write like a knowledgeable friend, not a press release |\n\n**Tone Calibration by Audience**:\n\n| Audience | Tone | Example |\n|----------|------|---------|\n| **Technical** | Precise, no jargon explanations, assumed expertise | \"The new API supports gRPC streaming with backpressure handling via flow control windows.\" |\n| **Executive** | Impact-focused, bottom-line, strategic | \"This acquisition gives Company X a 40% market share in the enterprise segment, directly threatening Incumbent Y's pricing power.\" |\n| **General** | Accessible, analogies, explains concepts | \"Think of it like a universal translator for data — it lets any app talk to any database without learning a new language.\" |\n\n### Phase 4: Assembly & Polish\n\n#### Step 4.1: Assemble the Newsletter\n\nCombine all sections into the final document following the chosen structure template.\n\n#### Step 4.2: Footer\n\nEvery newsletter ends with:\n\n```markdown\n---\n\n*[Newsletter Name] is [description of what it is].*\n*[How to subscribe/share/give feedback]*\n\n*Sources: All links are provided inline. This newsletter curates and summarizes\npublicly available information with original commentary.*\n```\n\n#### Step 4.3: Quality Checklist\n\nBefore finalizing, verify:\n\n- [ ] **Every factual claim has a source link** — No unsourced assertions\n- [ ] **All links are functional** — Verified URLs from search results\n- [ ] **Date references use the actual current date** — No hardcoded or assumed dates\n- [ ] **Content is current** — All major items are from within the expected timeframe\n- [ ] **No duplicate stories** — Each item appears only once\n- [ ] **Consistent formatting** — Headers, bullets, links use the same style throughout\n- [ ] **Balanced coverage** — Not dominated by a single source or perspective\n- [ ] **Appropriate length** — Matches the specified length target\n- [ ] **Engaging opening** — The first 2 sentences make the reader want to continue\n- [ ] **Clear closing** — The newsletter ends with a memorable or actionable note\n- [ ] **Proofread** — No typos, broken formatting, or incomplete sentences\n\n## Newsletter Output Template\n\n```markdown\n# [Newsletter Name]\n\n*[Tagline] — [Full date, e.g., April 4, 2026]*\n\n---\n\n[Preview sentence: \"This week: [topic 1], [topic 2], and [topic 3].\"]\n\n## 🔥 Top Stories\n\n### [Headline 1]\n\n[Hook — why this matters in 1-2 sentences.]\n\n[Body — 2-4 paragraphs covering key facts, context, and implications.]\n\n**Why it matters:** [1 paragraph connecting to reader's interests or industry impact.]\n\n📎 [Source: Publication Name](URL)\n\n### [Headline 2]\n\n[Same structure as above]\n\n## 📊 Trends & Analysis\n\n### [Trend Title]\n\n[Original commentary on an emerging trend, backed by data from research.]\n\n[Key data points presented clearly — consider inline stats or a brief comparison.]\n\n**The bottom line:** [One-sentence takeaway.]\n\n## ⚡ Quick Bites\n\n- **[Headline]** — [2-3 sentence summary with key takeaway.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n\n## 🛠️ Tools & Resources\n\n- **[Tool/Resource Name]** — [What it does and why it's useful.] [Link](URL)\n- **[Tool/Resource Name]** — [Description.] [Link](URL)\n\n## 💬 One More Thing\n\n[Closing thought, insightful quote, or forward-looking statement.]\n\n---\n\n*[Newsletter Name] curates the most important [topic] news and analysis.*\n*Found this useful? Share it with a colleague.*\n\n*All sources are linked inline. Views and commentary are original.*\n```\n\n## Adaptation Examples\n\n### Technology Newsletter\n- Emoji usage: ✅ Moderate (section headers)\n- Sections: Top Stories, Deep Dive, Quick Bites, Open Source Spotlight, Dev Tools\n- Tone: Technical-conversational\n\n### Business/Finance Newsletter\n- Emoji usage: ❌ Minimal to none\n- Sections: Market Overview, Deal Flow, Company News, Data Corner, Outlook\n- Tone: Professional-analytical\n\n### Industry-Specific Newsletter\n- Emoji usage: Moderate\n- Sections: Regulatory Updates, Market Data, Innovation Watch, People Moves, Events\n- Tone: Expert-authoritative\n\n### Creative/Marketing Newsletter\n- Emoji usage: ✅ Liberal\n- Sections: Campaign Spotlight, Trend Watch, Viral This Week, Tools We Love, Inspiration\n- Tone: Enthusiastic-professional\n\n## Output Handling\n\nAfter generation:\n\n- Save the newsletter to `/mnt/user-data/outputs/newsletter-{topic}-{date}.md`\n- Present the newsletter to the user using the `present_files` tool\n- Offer to adjust sections, tone, length, or focus areas\n- If the user wants HTML output, note that the Markdown can be converted using standard tools\n\n## Notes\n\n- This skill works best in combination with the `deep-research` skill for comprehensive topic coverage — load both for newsletters requiring deep analysis\n- Always use `` for temporal context in searches and date references in the newsletter\n- For recurring newsletters, suggest maintaining a consistent structure so readers develop expectations\n- When curating, quality beats quantity — 5 excellent items beat 15 mediocre ones\n- Attribute all content properly — newsletters build trust through transparent sourcing\n- Avoid summarizing paywalled content that the reader cannot access\n- If the user provides specific URLs or articles to include, incorporate them alongside your curated findings\n- The newsletter should provide enough value in the summaries that readers benefit even without clicking through to every link\n","skills/public/ppt-generation/SKILL.md":"---\nname: ppt-generation\ndescription: Use this skill when the user requests to generate, create, or make presentations (PPT/PPTX). Creates visually rich slides by generating images for each slide and composing them into a PowerPoint file.\n---\n\n# PPT Generation Skill\n\n## Overview\n\nThis skill generates professional PowerPoint presentations by creating AI-generated images for each slide and composing them into a PPTX file. The workflow includes planning the presentation structure with a consistent visual style, generating slide images sequentially (using the previous slide as a reference for style consistency), and assembling them into a final presentation.\n\n## Core Capabilities\n\n- Plan and structure multi-slide presentations with unified visual style\n- Support multiple presentation styles: Business, Academic, Minimal, Apple Keynote, Creative\n- Generate unique AI images for each slide using image-generation skill\n- Maintain visual consistency by using previous slide as reference image\n- Compose images into a professional PPTX file\n\n## Presentation Styles\n\nChoose one of the following styles when creating the presentation plan:\n\n| Style | Description | Best For |\n|-------|-------------|----------|\n| **glassmorphism** | Frosted glass panels with blur effects, floating translucent cards, vibrant gradient backgrounds, depth through layering | Tech products, AI/SaaS demos, futuristic pitches |\n| **dark-premium** | Rich black backgrounds (#0a0a0a), luminous accent colors, subtle glow effects, luxury brand aesthetic | Premium products, executive presentations, high-end brands |\n| **gradient-modern** | Bold mesh gradients, fluid color transitions, contemporary typography, vibrant yet sophisticated | Startups, creative agencies, brand launches |\n| **neo-brutalist** | Raw bold typography, high contrast, intentional \"ugly\" aesthetic, anti-design as design, Memphis-inspired | Edgy brands, Gen-Z targeting, disruptive startups |\n| **3d-isometric** | Clean isometric illustrations, floating 3D elements, soft shadows, tech-forward aesthetic | Tech explainers, product features, SaaS presentations |\n| **editorial** | Magazine-quality layouts, sophisticated typography hierarchy, dramatic photography, Vogue/Bloomberg aesthetic | Annual reports, luxury brands, thought leadership |\n| **minimal-swiss** | Grid-based precision, Helvetica-inspired typography, bold use of negative space, timeless modernism | Architecture, design firms, premium consulting |\n| **keynote** | Apple-inspired aesthetic with bold typography, dramatic imagery, high contrast, cinematic feel | Keynotes, product reveals, inspirational talks |\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests presentation generation, identify:\n\n- Topic/subject: What is the presentation about\n- Number of slides: How many slides are needed (default: 5-10)\n- **Style**: business / academic / minimal / keynote / creative\n- Aspect ratio: Standard (16:9) or classic (4:3)\n- Content outline: Key points for each slide\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Presentation Plan\n\nCreate a JSON file in `/mnt/user-data/workspace/` with the presentation structure. **Important**: Include the `style` field to define the overall visual consistency.\n\n```json\n{\n \"title\": \"Presentation Title\",\n \"style\": \"keynote\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep black backgrounds, white text, single accent color (blue or orange)\",\n \"typography\": \"Bold sans-serif headlines, clean body text, dramatic size contrast\",\n \"imagery\": \"High-quality photography, full-bleed images, cinematic composition\",\n \"layout\": \"Generous whitespace, centered focus, minimal elements per slide\"\n },\n \"aspect_ratio\": \"16:9\",\n \"slides\": [\n {\n \"slide_number\": 1,\n \"type\": \"title\",\n \"title\": \"Main Title\",\n \"subtitle\": \"Subtitle or tagline\",\n \"visual_description\": \"Detailed description for image generation\"\n },\n {\n \"slide_number\": 2,\n \"type\": \"content\",\n \"title\": \"Slide Title\",\n \"key_points\": [\"Point 1\", \"Point 2\", \"Point 3\"],\n \"visual_description\": \"Detailed description for image generation\"\n }\n ]\n}\n```\n\n### Step 3: Generate Slide Images Sequentially\n\n**IMPORTANT**: Generate slides **strictly one by one, in order**. Do NOT parallelize or batch image generation. Each slide depends on the previous slide's output as a reference image. Generating slides in parallel will break visual consistency and is not allowed.\n\n1. Read the image-generation skill: `/mnt/skills/public/image-generation/SKILL.md`\n\n2. **For the FIRST slide (slide 1)**, create a prompt that establishes the visual style:\n\n```json\n{\n \"prompt\": \"Professional presentation slide. [style_guidelines from plan]. Title: 'Your Title'. [visual_description]. This slide establishes the visual language for the entire presentation.\",\n \"style\": \"[Based on chosen style - e.g., Apple Keynote aesthetic, dramatic lighting, cinematic]\",\n \"composition\": \"Clean layout with clear text hierarchy, [style-specific composition]\",\n \"color_palette\": \"[From style_guidelines]\",\n \"typography\": \"[From style_guidelines]\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-01-prompt.json \\\n --output-file /mnt/user-data/outputs/slide-01.jpg \\\n --aspect-ratio 16:9\n```\n\n3. **For subsequent slides (slide 2+)**, use the PREVIOUS slide as a reference image:\n\n```json\n{\n \"prompt\": \"Professional presentation slide continuing the visual style from the reference image. Maintain the same color palette, typography style, and overall aesthetic. Title: 'Slide Title'. [visual_description]. Keep visual consistency with the reference.\",\n \"style\": \"Match the style of the reference image exactly\",\n \"composition\": \"Similar layout principles as reference, adapted for this content\",\n \"color_palette\": \"Same as reference image\",\n \"consistency_note\": \"This slide must look like it belongs in the same presentation as the reference image\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-02-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-01.jpg \\\n --output-file /mnt/user-data/outputs/slide-02.jpg \\\n --aspect-ratio 16:9\n```\n\n4. **Continue for all remaining slides**, always referencing the previous slide:\n\n```bash\n# Slide 3 references slide 2\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-03-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-02.jpg \\\n --output-file /mnt/user-data/outputs/slide-03.jpg \\\n --aspect-ratio 16:9\n\n# Slide 4 references slide 3\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-04-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-03.jpg \\\n --output-file /mnt/user-data/outputs/slide-04.jpg \\\n --aspect-ratio 16:9\n```\n\n### Step 4: Compose PPT\n\nAfter all slide images are generated, call the composition script:\n\n```bash\npython /mnt/skills/public/ppt-generation/scripts/generate.py \\\n --plan-file /mnt/user-data/workspace/presentation-plan.json \\\n --slide-images /mnt/user-data/outputs/slide-01.jpg /mnt/user-data/outputs/slide-02.jpg /mnt/user-data/outputs/slide-03.jpg \\\n --output-file /mnt/user-data/outputs/presentation.pptx\n```\n\nParameters:\n\n- `--plan-file`: Absolute path to the presentation plan JSON file (required)\n- `--slide-images`: Absolute paths to slide images in order (required, space-separated)\n- `--output-file`: Absolute path to output PPTX file (required)\n\n[!NOTE]\nDo NOT read the python file, just call it with the parameters.\n\n## Complete Example: Glassmorphism Style (最现代前卫)\n\nUser request: \"Create a presentation about AI product launch\"\n\n### Step 1: Create presentation plan\n\nCreate `/mnt/user-data/workspace/ai-product-plan.json`:\n```json\n{\n \"title\": \"Introducing Nova AI\",\n \"style\": \"glassmorphism\",\n \"style_guidelines\": {\n \"color_palette\": \"Vibrant purple-to-cyan gradient background (#667eea→#00d4ff), frosted glass panels with 15-20% white opacity, electric accents\",\n \"typography\": \"SF Pro Display style, bold 700 weight white titles with subtle text-shadow, clean 400 weight body text, excellent contrast on glass\",\n \"imagery\": \"Abstract 3D glass spheres, floating translucent geometric shapes, soft luminous orbs, depth through layered transparency\",\n \"layout\": \"Centered frosted glass cards with 32px rounded corners, 48-64px padding, floating above gradient, layered depth with soft shadows\",\n \"effects\": \"Backdrop blur 20-40px on glass panels, subtle white border glow, soft colored shadows matching gradient, light refraction effects\",\n \"visual_language\": \"Apple Vision Pro / visionOS aesthetic, premium depth through transparency, futuristic yet approachable, 2024 design trends\"\n },\n \"aspect_ratio\": \"16:9\",\n \"slides\": [\n {\n \"slide_number\": 1,\n \"type\": \"title\",\n \"title\": \"Introducing Nova AI\",\n \"subtitle\": \"Intelligence, Reimagined\",\n \"visual_description\": \"Stunning gradient background flowing from deep purple (#667eea) through magenta to cyan (#00d4ff). Center: large frosted glass panel with strong backdrop blur, containing bold white title 'Introducing Nova AI' and lighter subtitle. Floating 3D glass spheres and abstract shapes around the card creating depth. Soft glow emanating from behind the glass panel. Premium visionOS aesthetic. The glass card has subtle white border (1px rgba 255,255,255,0.3) and soft purple-tinted shadow.\"\n },\n {\n \"slide_number\": 2,\n \"type\": \"content\",\n \"title\": \"Why Nova?\",\n \"key_points\": [\"10x faster processing\", \"Human-like understanding\", \"Enterprise-grade security\"],\n \"visual_description\": \"Same purple-cyan gradient background. Left side: floating frosted glass card with title 'Why Nova?' in bold white, three key points below with subtle glass pill badges. Right side: abstract 3D visualization of neural network as interconnected glass nodes with soft glow. Floating translucent geometric shapes (icosahedrons, tori) adding depth. Consistent glassmorphism aesthetic with previous slide.\"\n },\n {\n \"slide_number\": 3,\n \"type\": \"content\",\n \"title\": \"How It Works\",\n \"key_points\": [\"Natural language input\", \"Multi-modal processing\", \"Instant insights\"],\n \"visual_description\": \"Gradient background consistent with previous slides. Central composition: three stacked frosted glass cards at slight angles showing the workflow steps, connected by soft glowing lines. Each card has an abstract icon. Floating glass orbs and light particles around the composition. Title 'How It Works' in bold white at top. Depth created through card layering and transparency.\"\n },\n {\n \"slide_number\": 4,\n \"type\": \"content\",\n \"title\": \"Built for Scale\",\n \"key_points\": [\"1M+ concurrent users\", \"99.99% uptime\", \"Global infrastructure\"],\n \"visual_description\": \"Same gradient background. Asymmetric layout: right side features large frosted glass panel with metrics displayed in bold typography. Left side: abstract 3D globe made of glass panels and connection lines, representing global scale. Floating data visualization elements as small glass cards with numbers. Soft ambient glow throughout. Premium tech aesthetic.\"\n },\n {\n \"slide_number\": 5,\n \"type\": \"conclusion\",\n \"title\": \"The Future Starts Now\",\n \"subtitle\": \"Join the waitlist\",\n \"visual_description\": \"Dramatic finale slide. Gradient background with slightly increased vibrancy. Central frosted glass card with bold title 'The Future Starts Now' and call-to-action subtitle. Behind the card: burst of soft light rays and floating glass particles creating celebration effect. Multiple layered glass shapes creating depth. The most visually impactful slide while maintaining style consistency.\"\n }\n ]\n}\n```\n\n### Step 2: Read image-generation skill\n\nRead `/mnt/skills/public/image-generation/SKILL.md` to understand how to generate images.\n\n### Step 3: Generate slide images sequentially with reference chaining\n\n**Slide 1 - Title (establishes the visual language):**\n\nCreate `/mnt/user-data/workspace/nova-slide-01.json`:\n```json\n{\n \"prompt\": \"Ultra-premium presentation title slide with glassmorphism design. Background: smooth flowing gradient from deep purple (#667eea) through magenta (#f093fb) to cyan (#00d4ff), soft and vibrant. Center: large frosted glass panel with strong backdrop blur effect, rounded corners 32px, containing bold white sans-serif title 'Introducing Nova AI' (72pt, SF Pro Display style, font-weight 700) with subtle text shadow, subtitle 'Intelligence, Reimagined' below in lighter weight. The glass panel has subtle white border (1px rgba 255,255,255,0.25) and soft purple-tinted drop shadow. Floating around the card: 3D glass spheres with refraction, translucent geometric shapes (icosahedrons, abstract blobs), creating depth and dimension. Soft luminous glow emanating from behind the glass panel. Small floating particles of light. Apple Vision Pro / visionOS UI aesthetic. Professional presentation slide, 16:9 aspect ratio. Hyper-modern, premium tech product launch feel.\",\n \"style\": \"Glassmorphism, visionOS aesthetic, Apple Vision Pro UI style, premium tech, 2024 design trends\",\n \"composition\": \"Centered glass card as focal point, floating 3D elements creating depth at edges, 40% negative space, clear visual hierarchy\",\n \"lighting\": \"Soft ambient glow from gradient, light refraction through glass elements, subtle rim lighting on 3D shapes\",\n \"color_palette\": \"Purple gradient #667eea, magenta #f093fb, cyan #00d4ff, frosted white rgba(255,255,255,0.15), pure white text #ffffff\",\n \"effects\": \"Backdrop blur on glass panels, soft drop shadows with color tint, light refraction, subtle noise texture on glass, floating particles\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/nova-slide-01.json \\\n --output-file /mnt/user-data/outputs/nova-slide-01.jpg \\\n --aspect-ratio 16:9\n```\n\n**Slide 2 - Content (MUST reference slide 1 for consistency):**\n\nCreate `/mnt/user-data/workspace/nova-slide-02.json`:\n```json\n{\n \"prompt\": \"Presentation slide continuing EXACT visual style from reference image. SAME purple-to-cyan gradient background, SAME glassmorphism aesthetic, SAME typography style. Left side: frosted glass card with backdrop blur containing title 'Why Nova?' in bold white (matching reference font style), three feature points as subtle glass pill badges below. Right side: abstract 3D neural network visualization made of interconnected glass nodes with soft cyan glow, floating in space. Floating translucent geometric shapes (matching style from reference) adding depth. The frosted glass has identical treatment: white border, purple-tinted shadow, same blur intensity. CRITICAL: This slide must look like it belongs in the exact same presentation as the reference image - same colors, same glass treatment, same overall aesthetic.\",\n \"style\": \"MATCH REFERENCE EXACTLY - Glassmorphism, visionOS aesthetic, same visual language\",\n \"composition\": \"Asymmetric split: glass card left (40%), 3D visualization right (40%), breathing room between elements\",\n \"color_palette\": \"EXACTLY match reference: purple #667eea, cyan #00d4ff gradient, same frosted white treatment, same text white\",\n \"consistency_note\": \"CRITICAL: Must be visually identical in style to reference image. Same gradient colors, same glass blur intensity, same shadow treatment, same typography weight and style. Viewer should immediately recognize this as the same presentation.\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/nova-slide-02.json \\\n --reference-images /mnt/user-data/outputs/nova-slide-01.jpg \\\n --output-file /mnt/user-data/outputs/nova-slide-02.jpg \\\n --aspect-ratio 16:9\n```\n\n**Slides 3-5: Continue the same pattern, each referencing the previous slide**\n\nKey consistency rules for subsequent slides:\n- Always include \"continuing EXACT visual style from reference image\" in prompt\n- Specify \"SAME gradient background\", \"SAME glass treatment\", \"SAME typography\"\n- Include `consistency_note` emphasizing style matching\n- Reference the immediately previous slide image\n\n### Step 4: Compose final PPT\n\n```bash\npython /mnt/skills/public/ppt-generation/scripts/generate.py \\\n --plan-file /mnt/user-data/workspace/nova-plan.json \\\n --slide-images /mnt/user-data/outputs/nova-slide-01.jpg /mnt/user-data/outputs/nova-slide-02.jpg /mnt/user-data/outputs/nova-slide-03.jpg /mnt/user-data/outputs/nova-slide-04.jpg /mnt/user-data/outputs/nova-slide-05.jpg \\\n --output-file /mnt/user-data/outputs/nova-presentation.pptx\n```\n\n## Style-Specific Guidelines\n\n### Glassmorphism Style (推荐 - 最现代前卫)\n```json\n{\n \"style\": \"glassmorphism\",\n \"style_guidelines\": {\n \"color_palette\": \"Vibrant gradient backgrounds (purple #667eea to pink #f093fb, or cyan #4facfe to blue #00f2fe), frosted white panels with 20% opacity, accent colors that pop against the gradient\",\n \"typography\": \"SF Pro Display or Inter font style, bold 600-700 weight titles, clean 400 weight body, white text with subtle drop shadow for readability on glass\",\n \"imagery\": \"Abstract 3D shapes floating in space, soft blurred orbs, geometric primitives with glass material, depth through overlapping translucent layers\",\n \"layout\": \"Floating card panels with backdrop-blur effect, generous padding (48-64px), rounded corners (24-32px radius), layered depth with subtle shadows\",\n \"effects\": \"Frosted glass blur (backdrop-filter: blur 20px), subtle white border (1px rgba 255,255,255,0.2), soft glow behind panels, floating elements with drop shadows\",\n \"visual_language\": \"Premium tech aesthetic like Apple Vision Pro UI, depth through transparency, light refracting through glass surfaces\"\n }\n}\n```\n\n### Dark Premium Style\n```json\n{\n \"style\": \"dark-premium\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep black base (#0a0a0a to #121212), luminous accent color (electric blue #00d4ff, neon purple #bf5af2, or gold #ffd700), subtle gray gradients for depth (#1a1a1a to #0a0a0a)\",\n \"typography\": \"Elegant sans-serif (Neue Haas Grotesk or Suisse Int'l style), dramatic size contrast (72pt+ headlines, 18pt body), letter-spacing -0.02em for headlines, pure white (#ffffff) text\",\n \"imagery\": \"Dramatic studio lighting, rim lights and edge glow, cinematic product shots, abstract light trails, premium material textures (brushed metal, matte surfaces)\",\n \"layout\": \"Generous negative space (60%+), asymmetric balance, content anchored to grid but with breathing room, single focal point per slide\",\n \"effects\": \"Subtle ambient glow behind key elements, light bloom effects, grain texture overlay (2-3% opacity), vignette on edges\",\n \"visual_language\": \"Luxury tech brand aesthetic (Bang & Olufsen, Porsche Design), sophistication through restraint, every element intentional\"\n }\n}\n```\n\n### Gradient Modern Style\n```json\n{\n \"style\": \"gradient-modern\",\n \"style_guidelines\": {\n \"color_palette\": \"Bold mesh gradients (Stripe/Linear style: purple-pink-orange #7c3aed→#ec4899→#f97316, or cool tones: cyan-blue-purple #06b6d4→#3b82f6→#8b5cf6), white or dark text depending on background intensity\",\n \"typography\": \"Modern geometric sans-serif (Satoshi, General Sans, or Clash Display style), variable font weights, oversized bold headlines (80pt+), comfortable body text (20pt)\",\n \"imagery\": \"Abstract fluid shapes, morphing gradients, 3D rendered abstract objects, soft organic forms, floating geometric primitives\",\n \"layout\": \"Dynamic asymmetric compositions, overlapping elements with blend modes, text integrated with gradient flows, full-bleed backgrounds\",\n \"effects\": \"Smooth gradient transitions, subtle noise texture (3-5% for depth), soft shadows with color tint matching gradient, motion blur suggesting movement\",\n \"visual_language\": \"Contemporary SaaS aesthetic (Stripe, Linear, Vercel), energetic yet professional, forward-thinking tech vibes\"\n }\n}\n```\n\n### Neo-Brutalist Style\n```json\n{\n \"style\": \"neo-brutalist\",\n \"style_guidelines\": {\n \"color_palette\": \"High contrast primaries: stark black, pure white, with bold accent (hot pink #ff0080, electric yellow #ffff00, or raw red #ff0000), optional: Memphis-inspired pastels as secondary\",\n \"typography\": \"Ultra-bold condensed type (Impact, Druk, or Bebas Neue style), UPPERCASE headlines, extreme size contrast, intentionally tight or overlapping letter-spacing\",\n \"imagery\": \"Raw unfiltered photography, intentional visual noise, halftone patterns, cut-out collage aesthetic, hand-drawn elements, stickers and stamps\",\n \"layout\": \"Broken grid, overlapping elements, thick black borders (4-8px), visible structure, anti-whitespace (dense but organized chaos)\",\n \"effects\": \"Hard shadows (no blur, offset 8-12px), pixelation accents, scan lines, CRT screen effects, intentional 'mistakes'\",\n \"visual_language\": \"Anti-corporate rebellion, DIY zine aesthetic meets digital, raw authenticity, memorable through boldness\"\n }\n}\n```\n\n### 3D Isometric Style\n```json\n{\n \"style\": \"3d-isometric\",\n \"style_guidelines\": {\n \"color_palette\": \"Soft contemporary palette: muted purples (#8b5cf6), teals (#14b8a6), warm corals (#fb7185), with cream or light gray backgrounds (#fafafa), consistent saturation across elements\",\n \"typography\": \"Friendly geometric sans-serif (Circular, Gilroy, or Quicksand style), medium weight headlines, excellent readability, comfortable 24pt body text\",\n \"imagery\": \"Clean isometric 3D illustrations, consistent 30° isometric angle, soft clay-render aesthetic, floating platforms and devices, cute simplified objects\",\n \"layout\": \"Central isometric scene as hero, text balanced around 3D elements, clear visual hierarchy, comfortable margins (64px+)\",\n \"effects\": \"Soft drop shadows (20px blur, 30% opacity), ambient occlusion on 3D objects, subtle gradients on surfaces, consistent light source (top-left)\",\n \"visual_language\": \"Friendly tech illustration (Slack, Notion, Asana style), approachable complexity, clarity through simplification\"\n }\n}\n```\n\n### Editorial Style\n```json\n{\n \"style\": \"editorial\",\n \"style_guidelines\": {\n \"color_palette\": \"Sophisticated neutrals: off-white (#f5f5f0), charcoal (#2d2d2d), with single accent color (burgundy #7c2d12, forest #14532d, or navy #1e3a5f), occasional full-color photography\",\n \"typography\": \"Refined serif for headlines (Playfair Display, Freight, or Editorial New style), clean sans-serif for body (Söhne, Graphik), dramatic size hierarchy (96pt headlines, 16pt body), generous line-height 1.6\",\n \"imagery\": \"Magazine-quality photography, dramatic crops, full-bleed images, portraits with intentional negative space, editorial lighting (Vogue, Bloomberg Businessweek style)\",\n \"layout\": \"Sophisticated grid system (12-column), intentional asymmetry, pull quotes as design elements, text wrapping around images, elegant margins\",\n \"effects\": \"Minimal effects - let photography and typography shine, subtle image treatments (slight desaturation, film grain), elegant borders and rules\",\n \"visual_language\": \"High-end magazine aesthetic, intellectual sophistication, content elevated through design restraint\"\n }\n}\n```\n\n### Minimal Swiss Style\n```json\n{\n \"style\": \"minimal-swiss\",\n \"style_guidelines\": {\n \"color_palette\": \"Pure white (#ffffff) or off-white (#fafaf9) backgrounds, true black (#000000) text, single bold accent (Swiss red #ff0000, Klein blue #002fa7, or signal yellow #ffcc00)\",\n \"typography\": \"Helvetica Neue or Aktiv Grotesk, strict type scale (12/16/24/48/96), medium weight for body, bold for emphasis only, flush-left ragged-right alignment\",\n \"imagery\": \"Objective photography, geometric shapes, clean iconography, mathematical precision, intentional empty space as compositional element\",\n \"layout\": \"Strict grid adherence (baseline grid visible in spirit), modular compositions, generous whitespace (40%+ of slide), content aligned to invisible grid lines\",\n \"effects\": \"None - purity of form, no shadows, no gradients, no decorative elements, occasional single hairline rules\",\n \"visual_language\": \"International Typographic Style, form follows function, timeless modernism, Dieter Rams-inspired restraint\"\n }\n}\n```\n\n### Keynote Style (Apple风格)\n```json\n{\n \"style\": \"keynote\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep blacks (#000000 to #1d1d1f), pure white text, signature blue (#0071e3) or gradient accents (purple-pink for creative, blue-teal for tech)\",\n \"typography\": \"San Francisco Pro Display, extreme weight contrast (bold 80pt+ titles, light 24pt body), negative letter-spacing on headlines (-0.03em), optical alignment\",\n \"imagery\": \"Cinematic photography, shallow depth of field, dramatic lighting (rim lights, spot lighting), product hero shots with reflections, full-bleed imagery\",\n \"layout\": \"Maximum negative space, single powerful image or statement per slide, content centered or dramatically offset, no clutter\",\n \"effects\": \"Subtle gradient overlays, light bloom and glow on key elements, reflection on surfaces, smooth gradient backgrounds\",\n \"visual_language\": \"Apple WWDC keynote aesthetic, confidence through simplicity, every pixel considered, theatrical presentation\"\n }\n}\n```\n\n## Output Handling\n\nAfter generation:\n\n- The PPTX file is saved in `/mnt/user-data/outputs/`\n- Share the generated presentation with user using `present_files` tool\n- Also share the individual slide images if requested\n- Provide brief description of the presentation\n- Offer to iterate or regenerate specific slides if needed\n\n## Notes\n\n### Critical Quality Guidelines\n\n**Prompt Engineering for Professional Results:**\n- Always use English for image prompts regardless of user's language\n- Be EXTREMELY specific about visual details - vague prompts produce generic results\n- Include exact hex color codes (e.g., #667eea not \"purple\")\n- Specify typography details: font weight (400/700), size hierarchy, letter-spacing\n- Describe effects precisely: \"backdrop blur 20px\", \"drop shadow 8px blur 30% opacity\"\n- Reference real design systems: \"visionOS aesthetic\", \"Stripe website style\", \"Bloomberg Businessweek layout\"\n\n**Visual Consistency (Most Important):**\n- **Generate slides sequentially** - each slide MUST reference the previous one\n- The first slide is critical - it establishes the visual language for the entire presentation\n- In every subsequent slide prompt, explicitly state: \"continuing EXACT visual style from reference image\"\n- Use SAME, EXACT, MATCH keywords emphatically in prompts to enforce consistency\n- Include a `consistency_note` field in every JSON prompt after slide 1\n- If a slide looks inconsistent, regenerate it with STRONGER reference emphasis\n\n**Design Principles for Modern Aesthetics:**\n- Embrace negative space - 40-60% empty space creates premium feel\n- Limit elements per slide - one focal point, one message\n- Use depth through layering (shadows, transparency, z-depth)\n- Typography hierarchy: massive headlines (72pt+), comfortable body (18-24pt)\n- Color restraint: one primary palette, 1-2 accent colors maximum\n\n**Common Mistakes to Avoid:**\n- ❌ Generic prompts like \"professional slide\" - be specific\n- ❌ Too many elements/text per slide - cluttered = unprofessional\n- ❌ Inconsistent colors between slides - always reference previous slide\n- ❌ Skipping the reference image parameter - this breaks visual consistency\n- ❌ Using different design styles within one presentation\n- ❌ Generating slides in parallel - slides MUST be generated one at a time in order (slide 1 → 2 → 3 ...), never concurrently\n\n**Recommended Styles for Different Contexts:**\n- Tech product launch → `glassmorphism` or `gradient-modern`\n- Luxury/premium brand → `dark-premium` or `editorial`\n- Startup pitch → `gradient-modern` or `minimal-swiss`\n- Executive presentation → `dark-premium` or `keynote`\n- Creative agency → `neo-brutalist` or `gradient-modern`\n- Data/analytics → `minimal-swiss` or `3d-isometric`\n","skills/public/github-deep-research/SKILL.md":"---\nname: github-deep-research\ndescription: Conduct multi-round deep research on any GitHub Repo. Use when users request comprehensive analysis, timeline reconstruction, competitive analysis, or in-depth investigation of GitHub. Produces structured markdown reports with executive summaries, chronological timelines, metrics analysis, and Mermaid diagrams. Triggers on Github repository URL or open source projects.\n---\n\n# GitHub Deep Research Skill\n\nMulti-round research combining GitHub API, web_search, web_fetch to produce comprehensive markdown reports.\n\n## Research Workflow\n\n- Round 1: GitHub API\n- Round 2: Discovery\n- Round 3: Deep Investigation\n- Round 4: Deep Dive\n\n## Core Methodology\n\n### Query Strategy\n\n**Broad to Narrow**: Start with GitHub API, then general queries, refine based on findings.\n\n```\nRound 1: GitHub API\nRound 2: \"{topic} overview\"\nRound 3: \"{topic} architecture\", \"{topic} vs alternatives\"\nRound 4: \"{topic} issues\", \"{topic} roadmap\", \"site:github.com {topic}\"\n```\n\n**Source Prioritization**:\n1. Official docs/repos (highest weight)\n2. Technical blogs (Medium, Dev.to)\n3. News articles (verified outlets)\n4. Community discussions (Reddit, HN)\n5. Social media (lowest weight, for sentiment)\n\n### Research Rounds\n\n**Round 1 - GitHub API**\nDirectly execute `scripts/github_api.py` without `read_file()`:\n```bash\npython /path/to/skill/scripts/github_api.py summary\npython /path/to/skill/scripts/github_api.py readme\npython /path/to/skill/scripts/github_api.py tree\n```\n\n**Available commands (the last argument of `github_api.py`):**\n- summary\n- info\n- readme\n- tree\n- languages\n- contributors\n- commits\n- issues\n- prs\n- releases\n\n**Round 2 - Discovery (3-5 web_search)**\n- Get overview and identify key terms\n- Find official website/repo\n- Identify main players/competitors\n\n**Round 3 - Deep Investigation (5-10 web_search + web_fetch)**\n- Technical architecture details\n- Timeline of key events\n- Community sentiment\n- Use web_fetch on valuable URLs for full content\n\n**Round 4 - Deep Dive**\n- Analyze commit history for timeline\n- Review issues/PRs for feature evolution\n- Check contributor activity\n\n## Report Structure\n\nFollow template in `assets/report_template.md`:\n\n1. **Metadata Block** - Date, confidence level, subject\n2. **Executive Summary** - 2-3 sentence overview with key metrics\n3. **Chronological Timeline** - Phased breakdown with dates\n4. **Key Analysis Sections** - Topic-specific deep dives\n5. **Metrics & Comparisons** - Tables, growth charts\n6. **Strengths & Weaknesses** - Balanced assessment\n7. **Sources** - Categorized references\n8. **Confidence Assessment** - Claims by confidence level\n9. **Methodology** - Research approach used\n\n### Mermaid Diagrams\n\nInclude diagrams where helpful:\n\n**Timeline (Gantt)**:\n```mermaid\ngantt\n title Project Timeline\n dateFormat YYYY-MM-DD\n section Phase 1\n Development :2025-01-01, 2025-03-01\n section Phase 2\n Launch :2025-03-01, 2025-04-01\n```\n\n**Architecture (Flowchart)**:\n```mermaid\nflowchart TD\n A[User] --> B[Coordinator]\n B --> C[Planner]\n C --> D[Research Team]\n D --> E[Reporter]\n```\n\n**Comparison (Pie/Bar)**:\n```mermaid\npie title Market Share\n \"Project A\" : 45\n \"Project B\" : 30\n \"Others\" : 25\n```\n\n## Confidence Scoring\n\nAssign confidence based on source quality:\n\n| Confidence | Criteria |\n|------------|----------|\n| High (90%+) | Official docs, GitHub data, multiple corroborating sources |\n| Medium (70-89%) | Single reliable source, recent articles |\n| Low (50-69%) | Social media, unverified claims, outdated info |\n\n## Output\n\nSave report as: `research_{topic}_{YYYYMMDD}.md`\n\n### Formatting Rules\n\n- Chinese content: Use full-width punctuation（，。：；！？）\n- Technical terms: Provide Wiki/doc URL on first mention\n- Tables: Use for metrics, comparisons\n- Code blocks: For technical examples\n- Mermaid: For architecture, timelines, flows\n\n## Best Practices\n\n1. **Start with official sources** - Repo, docs, company blog\n2. **Verify dates from commits/PRs** - More reliable than articles\n3. **Triangulate claims** - 2+ independent sources\n4. **Note conflicting info** - Don't hide contradictions\n5. **Distinguish fact vs opinion** - Label speculation clearly\n6. **CRITICAL: Always include inline citations** - Use `[citation:Title](URL)` format immediately after each claim from external sources\n7. **Extract URLs from search results** - web_search returns {title, url, snippet} - always use the URL field\n8. **Update as you go** - Don't wait until end to synthesize\n\n### Citation Examples\n\n**Good - With inline citations:**\n```markdown\nThe project gained 10,000 stars within 3 months of launch [citation:GitHub Stats](https://github.com/owner/repo).\nThe architecture uses LangGraph for workflow orchestration [citation:LangGraph Docs](https://langchain.com/langgraph).\n```\n\n**Bad - Without citations:**\n```markdown\nThe project gained 10,000 stars within 3 months of launch.\nThe architecture uses LangGraph for workflow orchestration.\n```\n","skills/public/skill-creator/SKILL.md":"---\nname: skill-creator\ndescription: Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.\n---\n\n# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nAt a high level, the process of creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft of the skill\n- Create a few test prompts and run claude-with-access-to-the-skill on them\n- Help the user evaluate the results both qualitatively and quantitatively\n - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)\n - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics\n- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like \"I want to make a skill for X\". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.\n\nOn the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.\n\nOf course, you should always be flexible and if the user is like \"I don't need to run a bunch of evaluations, just vibe with me\", you can do that instead.\n\nThen after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.\n\nCool? Cool.\n\n---\n\n## DeerFlow Environment (⚠️ READ THIS FIRST)\n\nIf you are running inside a **DeerFlow** sandboxed agent environment (you have access to the `skill_manage` tool), you MUST follow these rules for all skill file operations. These override the generic file-writing and packaging instructions below.\n\n### Why this matters\n\nIn DeerFlow, the sandbox filesystem is isolated. Files written with `write_file` land in `/mnt/user-data/outputs/`, which is a **per-thread output directory** — new chats cannot see files there. Skills must be persisted through the dedicated `skill_manage` tool so they are stored in the per-user skill directory and immediately visible to all future chats.\n\n### Use `skill_manage` for all skill file operations\n\n| Operation | skill_manage action | Example |\n|-----------|---------------------|---------|\n| Create a new skill | `action=\"create\"` | `skill_manage(action=\"create\", name=\"my-skill\", content=\"---\\nname: my-skill\\n---\\n...\")` |\n| Replace entire SKILL.md | `action=\"edit\"` | `skill_manage(action=\"edit\", name=\"my-skill\", content=\"updated SKILL.md\")` |\n| Partial edit (find & replace) | `action=\"patch\"` | `skill_manage(action=\"patch\", name=\"my-skill\", find=\"old text\", replace=\"new text\")` |\n| Delete a skill | `action=\"delete\"` | `skill_manage(action=\"delete\", name=\"my-skill\")` |\n| Add a supporting file | `action=\"write_file\"` | `skill_manage(action=\"write_file\", name=\"my-skill\", path=\"scripts/helper.py\", content=\"...\")` |\n| Remove a supporting file | `action=\"remove_file\"` | `skill_manage(action=\"remove_file\", name=\"my-skill\", path=\"scripts/helper.py\")` |\n\n### Key rules\n\n1. **NEVER use sandbox `write_file` to create or modify skill files** (SKILL.md, scripts/, references/, assets/). These would land in `/mnt/user-data/outputs/` and be invisible to future chats. Always use `skill_manage` instead.\n\n2. **Skip the `package_skill.py` step**. In DeerFlow, `skill_manage` already persists the skill to the correct per-user directory. No `.skill` packaging or manual install is needed. The skill is immediately available in all new chats.\n\n3. **Skip the `present_files` step for skills**. Skills are NOT deliverables — they are persisted via `skill_manage` and auto-loaded by the skill system. Only use `present_files` for non-skill outputs (eval reports, benchmarks, etc.).\n\n4. **Eval workspace files are OK in sandbox**. Test prompts, benchmark data, eval viewer HTML, grading results, etc. are NOT skill files — you can write these to `/mnt/user-data/outputs/` or `/mnt/user-data/workspace/` using sandbox `write_file` as usual.\n\n5. **To read an existing skill's SKILL.md**, use `read_file(\"/mnt/skills/custom//SKILL.md\")` in the sandbox (it maps to the per-user skill directory).\n\n6. **Updating an existing skill**: use `skill_manage(action=\"edit\")` or `skill_manage(action=\"patch\")`. Do NOT copy to `/tmp/` first — `skill_manage` handles the per-user storage directly.\n\n### Workflow in DeerFlow\n\nThe core loop is the same, but the persistence mechanism changes:\n\n1. Capture intent → interview → draft SKILL.md content\n2. **Call `skill_manage(action=\"create\", name=, content=)`** to persist the skill\n3. Run test cases (eval workspace files use sandbox `write_file`)\n4. Evaluate results, gather feedback\n5. **Call `skill_manage(action=\"edit\")` or `skill_manage(action=\"patch\")`** to improve the skill\n6. Repeat until satisfied\n7. **Done — no packaging needed.** The skill is already persisted and visible to all future chats.\n\n---\n\n## Communicating with the user\n\nThe skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google \"how to install npm\". On the other hand, the bulk of users are probably fairly computer-literate.\n\nSo please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:\n\n- \"evaluation\" and \"benchmark\" are borderline, but OK\n- for \"JSON\" and \"assertion\" you want to see serious cues from the user that they know what those things are before using them without explaining them\n\nIt's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.\n\n---\n\n## Creating a skill\n\n### Capture Intent\n\nStart by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say \"turn this into a skill\"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.\n\n1. What should this skill enable Claude to do?\n2. When should this skill trigger? (what user phrases/contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.\n\n### Interview and Research\n\nProactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.\n\nCheck available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.\n\n### Write the SKILL.md\n\nBased on the user interview, fill in these components:\n\n- **name**: Skill identifier\n- **description**: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All \"when to use\" info goes here, not in the body. Note: currently Claude has a tendency to \"undertrigger\" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit \"pushy\". So for instance, instead of \"How to build a simple fast dashboard to display internal Anthropic data.\", you might write \"How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **compatibility**: Required tools, dependencies (optional, rarely needed)\n- **the rest of the skill :)**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name/\n├── SKILL.md (required)\n│ ├── YAML frontmatter (name, description required)\n│ └── Markdown instructions\n└── Bundled Resources (optional)\n ├── scripts/ - Executable code for deterministic/repetitive tasks\n ├── references/ - Docs loaded into context as needed\n └── assets/ - Files used in output (templates, icons, fonts)\n```\n\n#### Progressive Disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description) - Always in context (~100 words)\n2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)\n3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)\n\nThese word counts are approximate and you can feel free to go longer if needed.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.\n- Reference files clearly from SKILL.md with guidance on when to read them\n- For large reference files (>300 lines), include a table of contents\n\n**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:\n```\ncloud-deploy/\n├── SKILL.md (workflow + selection)\n└── references/\n ├── aws.md\n ├── gcp.md\n └── azure.md\n```\nClaude reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nThis goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a \"roleplay as an XYZ\" are OK though.\n\n#### Writing Patterns\n\nPrefer using the imperative form in instructions.\n\n**Defining output formats** - You can do it like this:\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** - It's useful to include examples. You can format them like this (but if \"Input\" and \"Output\" are in the examples you might want to deviate a little):\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n### Writing Style\n\nTry to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.\n\n### Test Cases\n\nAfter writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.\n\n```json\n{\n \"skill_name\": \"example-skill\",\n \"evals\": [\n {\n \"id\": 1,\n \"prompt\": \"User's task prompt\",\n \"expected_output\": \"Description of expected result\",\n \"files\": []\n }\n ]\n}\n```\n\nSee `references/schemas.md` for the full schema (including the `assertions` field, which you'll add later).\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill.\n\nPut results in `-workspace/` as a sibling to the skill directory. Within the workspace, organize results by iteration (`iteration-1/`, `iteration-2/`, etc.) and within that, each test case gets a directory (`eval-0/`, `eval-1/`, etc.). Don't create all of this upfront — just create directories as you go.\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: \n- Task: \n- Input files: \n- Save outputs to: /iteration-/eval-/with_skill/outputs/\n- Outputs to save: \n```\n\n**Baseline run** (same prompt, but the baseline depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, save to `without_skill/outputs/`.\n- **Improving an existing skill**: the old version. Before editing, snapshot the skill (`cp -r /skill-snapshot/`), then point the baseline subagent at the snapshot. Save to `old_skill/outputs/`.\n\nWrite an `eval_metadata.json` for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just \"eval-0\". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.\n\n```json\n{\n \"eval_id\": 0,\n \"eval_name\": \"descriptive-name-here\",\n \"prompt\": \"The user's task prompt\",\n \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in `evals/evals.json`, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.\n\nUpdate the `eval_metadata.json` files and `evals/evals.json` with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, you receive a notification containing `total_tokens` and `duration_ms`. Save this data immediately to `timing.json` in the run directory:\n\n```json\n{\n \"total_tokens\": 84852,\n \"duration_ms\": 23332,\n \"total_duration_seconds\": 23.3\n}\n```\n\nThis is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — spawn a grader subagent (or grade inline) that reads `agents/grader.md` and evaluates each assertion against the outputs. Save results to `grading.json` in each run directory. The grading.json expectations array must use the fields `text`, `passed`, and `evidence` (not `name`/`met`/`details` or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.\n\n2. **Aggregate into benchmark** — run the aggregation script from the skill-creator directory:\n ```bash\n python -m scripts.aggregate_benchmark /iteration-N --skill-name \n ```\n This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see `references/schemas.md` for the exact schema the viewer expects.\nPut each with_skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregate stats might hide. See `agents/analyzer.md` (the \"Analyzing Benchmark Results\" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n ```bash\n nohup python /eval-viewer/generate_review.py \\\n /iteration-N \\\n --skill-name \"my-skill\" \\\n --benchmark /iteration-N/benchmark.json \\\n > /dev/null 2>&1 &\n VIEWER_PID=$!\n ```\n For iteration 2+, also pass `--previous-workspace /iteration-`.\n\n **Cowork / headless environments:** If `webbrowser.open()` is not available or the environment has no display, use `--static ` to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a `feedback.json` file when the user clicks \"Submit All Reviews\". After download, copy `feedback.json` into the workspace directory for the next iteration to pick up.\n\nNote: please use generate_review.py to create the viewer; there's no need to write custom HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): collapsed section showing last iteration's output\n- **Formal Grades** (if grading was run): collapsed section showing assertion pass/fail\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, shown below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.\n\nNavigation is via prev/next buttons or arrow keys. When done, they click \"Submit All Reviews\" which saves all feedback to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user tells you they're done, read `feedback.json`:\n\n```json\n{\n \"reviews\": [\n {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n ],\n \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.\n\nKill the viewer server when you're done with it:\n\n```bash\nkill $VIEWER_PID 2>/dev/null\n```\n\n---\n\n## Improving the skill\n\nThis is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.\n\n3. **Explain the why.** Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.\n\n4. **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts/`, and tell the skill to use it. This saves every future invocation from reinventing the wheel.\n\nThis task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply your improvements to the skill\n2. Rerun all test cases into a new `iteration-/` directory, including baseline runs. If you're creating a new skill, the baseline is always `without_skill` (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and tell you they're done\n5. Read the new feedback, improve again, repeat\n\nKeep going until:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n---\n\n## Advanced: Blind comparison\n\nFor situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks \"is the new version actually better?\"), there's a blind comparison system. Read `agents/comparator.md` and `agents/analyzer.md` for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.\n\nThis is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n---\n\n## Description Optimization\n\nThe description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n {\"query\": \"the user prompt\", \"should_trigger\": true},\n {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nFor the **should-trigger** queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.\n\nFor the **should-not-trigger** queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.\n\nThe key thing to avoid: don't make should-not-trigger queries obviously irrelevant. \"Write a fibonacci function\" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.\n\n### Step 2: Review with user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read the template from `assets/eval_review.html`\n2. Replace the placeholders:\n - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no quotes around it — it's a JS variable assignment)\n - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file (e.g., `/tmp/eval_review_.html`) and open it: `open /tmp/eval_review_.html`\n4. The user can edit queries, toggle should-trigger, add/remove entries, then click \"Export Eval Set\"\n5. The file downloads to `~/Downloads/eval_set.json` — check the Downloads folder for the most recent version in case there are multiple (e.g., `eval_set (1).json`)\n\nThis step matters — bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take some time — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run in the background:\n\n```bash\npython -m scripts.run_loop \\\n --eval-set \\\n --skill-path \\\n --model \\\n --max-iterations 5 \\\n --verbose\n```\n\nUse the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.\n\nWhile it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.\n\nThis handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with `best_description` — selected by test score rather than train score to avoid overfitting.\n\n### How skill triggering works\n\nUnderstanding the triggering mechanism helps design better eval queries. Skills appear in Claude's `available_skills` list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like \"read this PDF\" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.\n\nThis means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like \"read file X\" are poor test cases — they won't trigger skills regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.\n\n---\n\n### Package and Present (only if `present_files` tool is available)\n\nCheck whether you have access to the `present_files` tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:\n\n```bash\npython -m scripts.package_skill \n```\n\nAfter packaging, direct the user to the resulting `.skill` file path so they can install it.\n\n---\n\n## Claude.ai-specific instructions\n\nIn Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:\n\n**Running test cases**: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.\n\n**Reviewing results**: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: \"How does this look? Anything you'd change?\"\n\n**Benchmarking**: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.\n\n**The iteration loop**: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.\n\n**Description optimization**: This section requires the `claude` CLI tool (specifically `claude -p`) which is only available in Claude Code. Skip it if you're on Claude.ai.\n\n**Blind comparison**: Requires subagents. Skip it.\n\n**Packaging**: The `package_skill.py` script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting `.skill` file.\n\n**Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. In this case:\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field -- use them unchanged. E.g., if the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`).\n- **Copy to a writeable location before editing.** The installed skill path may be read-only. Copy to `/tmp/skill-name/`, edit there, and package from the copy.\n- **If packaging manually, stage in `/tmp/` first**, then copy to the output directory -- direct writes may fail due to permissions.\n\n---\n\n## Cowork-Specific Instructions\n\nIf you're in Cowork, the main things to know are:\n\n- You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)\n- You don't have a browser or display, so when generating the eval viewer, use `--static ` to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.\n- For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using `generate_review.py` (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER *BEFORE* evaluating inputs yourself. You want to get them in front of the human ASAP!\n- Feedback works differently: since there's no running server, the viewer's \"Submit All Reviews\" button will download `feedback.json` as a file. You can then read it from there (you may have to request access first).\n- Packaging works — `package_skill.py` just needs Python and a filesystem.\n- Description optimization (`run_loop.py` / `run_eval.py`) should work in Cowork just fine since it uses `claude -p` via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.\n- **Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.\n\n---\n\n## Reference files\n\nThe agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.\n\n- `agents/grader.md` — How to evaluate assertions against outputs\n- `agents/comparator.md` — How to do blind A/B comparison between two outputs\n- `agents/analyzer.md` — How to analyze why one version beat another\n\nThe references/ directory has additional documentation:\n- `references/schemas.md` — JSON structures for evals.json, grading.json, etc.\n\n---\n\nRepeating one more time the core loop here for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill\n- Run claude-with-access-to-the-skill on test prompts\n- With the user, evaluate the outputs:\n - Create benchmark.json and run `eval-viewer/generate_review.py` to help the user review them\n - Run quantitative evals\n- Repeat until you and the user are satisfied\n- Package the final skill and return it to the user.\n\nPlease add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put \"Create evals JSON and run `eval-viewer/generate_review.py` so human can review test cases\" in your TodoList to make sure it happens.\n\nGood luck!\n","skills/public/frontend-design/SKILL.md":"# frontend-design\n\nPath: `skills/public/frontend-design/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/frontend-design/SKILL.md)","skills/public/find-skills/SKILL.md":"# find-skills\n\nPath: `skills/public/find-skills/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/find-skills/SKILL.md)","skills/public/deep-research/SKILL.md":"# deep-research\n\nPath: `skills/public/deep-research/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/deep-research/SKILL.md)","skills/public/data-analysis/SKILL.md":"# data-analysis\n\nPath: `skills/public/data-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/data-analysis/SKILL.md)","skills/public/consulting-analysis/SKILL.md":"# consulting-analysis\n\nPath: `skills/public/consulting-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/consulting-analysis/SKILL.md)","skills/public/code-documentation/SKILL.md":"# code-documentation\n\nPath: `skills/public/code-documentation/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/code-documentation/SKILL.md)","skills/public/claude-to-deerflow/SKILL.md":"# claude-to-deerflow\n\nPath: `skills/public/claude-to-deerflow/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/claude-to-deerflow/SKILL.md)","skills/public/chart-visualization/SKILL.md":"# chart-visualization\n\nPath: `skills/public/chart-visualization/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/SKILL.md)","skills/public/bootstrap/SKILL.md":"# bootstrap\n\nPath: `skills/public/bootstrap/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/SKILL.md)","skills/public/academic-paper-review/SKILL.md":"# academic-paper-review\n\nPath: `skills/public/academic-paper-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/academic-paper-review/SKILL.md)",".github/copilot-instructions.md":"# GitHub Copilot Instructions\n\nPath: `.github/copilot-instructions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.github/copilot-instructions.md)","backend/AGENTS.md":"# backend - AI Agent Protocol & Instructions\n\nPath: `backend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/AGENTS.md)","backend/CLAUDE.md":"# backend - Claude Agent Guidelines & System Prompt\n\nPath: `backend/CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/CLAUDE.md)","frontend/AGENTS.md":"# frontend - AI Agent Protocol & Instructions\n\nPath: `frontend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/AGENTS.md)","frontend/CLAUDE.md":"# frontend - Claude Agent Guidelines & System Prompt\n\nPath: `frontend/CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/CLAUDE.md)",".agent/skills/smoke-test/references/SOP.md":"# References Skill\n\nPath: `.agent/skills/smoke-test/references/SOP.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/SOP.md)",".agent/skills/smoke-test/references/troubleshooting.md":"# References Skill\n\nPath: `.agent/skills/smoke-test/references/troubleshooting.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/troubleshooting.md)",".agent/skills/smoke-test/templates/report.docker.template.md":"# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.docker.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.docker.template.md)",".agent/skills/smoke-test/templates/report.local.template.md":"# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.local.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.local.template.md)","skills/public/systematic-literature-review/evals/evals.json":"# Evals Skill\n\nPath: `skills/public/systematic-literature-review/evals/evals.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/evals.json)","skills/public/systematic-literature-review/evals/trigger_eval_set.json":"# Evals Skill\n\nPath: `skills/public/systematic-literature-review/evals/trigger_eval_set.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/trigger_eval_set.json)","skills/public/systematic-literature-review/templates/apa.md":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/apa.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/apa.md)","skills/public/systematic-literature-review/templates/bibtex.md":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/bibtex.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/bibtex.md)","skills/public/systematic-literature-review/templates/ieee.md":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/ieee.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/ieee.md)","skills/public/skill-creator/agents/analyzer.md":"# Subagent: analyzer\n\nPath: `skills/public/skill-creator/agents/analyzer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/analyzer.md)","skills/public/skill-creator/agents/comparator.md":"# Subagent: comparator\n\nPath: `skills/public/skill-creator/agents/comparator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/comparator.md)","skills/public/skill-creator/agents/grader.md":"# Subagent: grader\n\nPath: `skills/public/skill-creator/agents/grader.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/grader.md)","skills/public/skill-creator/references/output-patterns.md":"# References Skill\n\nPath: `skills/public/skill-creator/references/output-patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/output-patterns.md)","skills/public/skill-creator/references/schemas.md":"# References Skill\n\nPath: `skills/public/skill-creator/references/schemas.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/schemas.md)","skills/public/skill-creator/references/workflows.md":"# References Skill\n\nPath: `skills/public/skill-creator/references/workflows.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/workflows.md)","skills/public/podcast-generation/templates/tech-explainer.md":"# Templates Skill\n\nPath: `skills/public/podcast-generation/templates/tech-explainer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/podcast-generation/templates/tech-explainer.md)","skills/public/image-generation/templates/doraemon.md":"# Templates Skill\n\nPath: `skills/public/image-generation/templates/doraemon.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/image-generation/templates/doraemon.md)","skills/public/github-deep-research/assets/report_template.md":"# Assets Skill\n\nPath: `skills/public/github-deep-research/assets/report_template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/github-deep-research/assets/report_template.md)","skills/public/chart-visualization/references/generate_area_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_area_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_area_chart.md)","skills/public/chart-visualization/references/generate_bar_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_bar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_bar_chart.md)","skills/public/chart-visualization/references/generate_boxplot_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_boxplot_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_boxplot_chart.md)","skills/public/chart-visualization/references/generate_column_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_column_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_column_chart.md)","skills/public/chart-visualization/references/generate_district_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_district_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_district_map.md)","skills/public/chart-visualization/references/generate_dual_axes_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_dual_axes_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_dual_axes_chart.md)","skills/public/chart-visualization/references/generate_fishbone_diagram.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_fishbone_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_fishbone_diagram.md)","skills/public/chart-visualization/references/generate_flow_diagram.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_flow_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_flow_diagram.md)","skills/public/chart-visualization/references/generate_funnel_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_funnel_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_funnel_chart.md)","skills/public/chart-visualization/references/generate_histogram_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_histogram_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_histogram_chart.md)","skills/public/chart-visualization/references/generate_line_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_line_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_line_chart.md)","skills/public/chart-visualization/references/generate_liquid_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_liquid_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_liquid_chart.md)","skills/public/chart-visualization/references/generate_mind_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_mind_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_mind_map.md)","skills/public/chart-visualization/references/generate_network_graph.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_network_graph.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_network_graph.md)","skills/public/chart-visualization/references/generate_organization_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_organization_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_organization_chart.md)","skills/public/chart-visualization/references/generate_path_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_path_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_path_map.md)","skills/public/chart-visualization/references/generate_pie_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pie_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pie_chart.md)","skills/public/chart-visualization/references/generate_pin_map.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pin_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pin_map.md)","skills/public/chart-visualization/references/generate_radar_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_radar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_radar_chart.md)","skills/public/chart-visualization/references/generate_sankey_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_sankey_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_sankey_chart.md)","skills/public/chart-visualization/references/generate_scatter_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_scatter_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_scatter_chart.md)","skills/public/chart-visualization/references/generate_spreadsheet.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_spreadsheet.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_spreadsheet.md)","skills/public/chart-visualization/references/generate_treemap_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_treemap_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_treemap_chart.md)","skills/public/chart-visualization/references/generate_venn_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_venn_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_venn_chart.md)","skills/public/chart-visualization/references/generate_violin_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_violin_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_violin_chart.md)","skills/public/chart-visualization/references/generate_word_cloud_chart.md":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_word_cloud_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_word_cloud_chart.md)","skills/public/bootstrap/references/conversation-guide.md":"# References Skill\n\nPath: `skills/public/bootstrap/references/conversation-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/references/conversation-guide.md)","skills/public/bootstrap/templates/SOUL.template.md":"# Templates Skill\n\nPath: `skills/public/bootstrap/templates/SOUL.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/templates/SOUL.template.md)"},"items":[{"name":"AGENTS.md","path":"backend/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/AGENTS.md","title":"backend - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# backend - AI Agent Protocol & Instructions\n\nPath: `backend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/AGENTS.md)","tokens":300,"sizeBytes":179},{"name":"AGENTS.md","path":"frontend/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/AGENTS.md","title":"frontend - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# frontend - AI Agent Protocol & Instructions\n\nPath: `frontend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/AGENTS.md)","tokens":300,"sizeBytes":182},{"name":"SOP.md","path":".agent/skills/smoke-test/references/SOP.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/SOP.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agent/skills/smoke-test/references/SOP.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/SOP.md)","tokens":300,"sizeBytes":203},{"name":"troubleshooting.md","path":".agent/skills/smoke-test/references/troubleshooting.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/troubleshooting.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agent/skills/smoke-test/references/troubleshooting.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/troubleshooting.md)","tokens":300,"sizeBytes":227},{"name":"SKILL.md","path":".agent/skills/smoke-test/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/SKILL.md","title":"smoke-test","category":"anthropic-skill","format":"markdown","content":"---\nname: smoke-test\ndescription: End-to-end smoke test skill for DeerFlow. Guides through: 1) Pulling latest code, 2) Docker OR Local installation and deployment (user preference, default to Local if Docker network issues), 3) Service availability verification, 4) Health check, 5) Final test report. Use when the user says \"run smoke test\", \"smoke test deployment\", \"verify installation\", \"test service availability\", \"end-to-end test\", or similar.\n---\n\n# DeerFlow Smoke Test Skill\n\nThis skill guides the Agent through DeerFlow's full end-to-end smoke test workflow, including code updates, deployment (supporting both Docker and local installation modes), service availability verification, and health checks.\n\n## Deployment Mode Selection\n\nThis skill supports two deployment modes:\n- **Local installation mode** (recommended, especially when network issues occur) - Run all services directly on the local machine\n- **Docker mode** - Run all services inside Docker containers\n\n**Selection strategy**:\n- If the user explicitly asks for Docker mode, use Docker\n- If network issues occur (such as slow image pulls), automatically switch to local mode\n- Default to local mode whenever possible\n\n## Structure\n\n```\nsmoke-test/\n├── SKILL.md ← You are here - core workflow and logic\n├── scripts/\n│ ├── check_docker.sh ← Check the Docker environment\n│ ├── check_local_env.sh ← Check local environment dependencies\n│ ├── frontend_check.sh ← Frontend page smoke check\n│ ├── pull_code.sh ← Pull the latest code\n│ ├── deploy_docker.sh ← Docker deployment\n│ ├── deploy_local.sh ← Local deployment\n│ └── health_check.sh ← Service health check\n├── references/\n│ ├── SOP.md ← Standard operating procedure\n│ └── troubleshooting.md ← Troubleshooting guide\n└── templates/\n ├── report.local.template.md ← Local mode smoke test report template\n └── report.docker.template.md ← Docker mode smoke test report template\n```\n\n## Standard Operating Procedure (SOP)\n\n### Phase 1: Code Update Check\n\n1. **Confirm current directory** - Verify that the current working directory is the DeerFlow project root\n2. **Check Git status** - See whether there are uncommitted changes\n3. **Pull the latest code** - Use `git pull origin main` to get the latest updates\n4. **Confirm code update** - Verify that the latest code was pulled successfully\n\n### Phase 2: Deployment Mode Selection and Environment Check\n\n**Choose deployment mode**:\n- Ask for user preference, or choose automatically based on network conditions\n- Default to local installation mode\n\n**Local mode environment check**:\n1. **Check Node.js version** - Requires 22+\n2. **Check pnpm** - Package manager\n3. **Check uv** - Python package manager\n4. **Check nginx** - Reverse proxy\n5. **Check required ports** - Confirm that ports 2026, 3000, and 8001 are not occupied\n\n**Docker mode environment check** (if Docker is selected):\n1. **Check whether Docker is installed** - Run `docker --version`\n2. **Check Docker daemon status** - Run `docker info`\n3. **Check Docker Compose availability** - Run `docker compose version`\n4. **Check required ports** - Confirm that port 2026 is not occupied\n\n### Phase 3: Configuration Preparation\n\n1. **Check whether config.yaml exists**\n - If it does not exist, run `make config` to generate it\n - If it already exists, check whether it needs an upgrade with `make config-upgrade`\n2. **Check the .env file**\n - Verify that required environment variables are configured\n - Especially model API keys such as `OPENAI_API_KEY`\n\n### Phase 4: Deployment Execution\n\n**Local mode deployment**:\n1. **Check dependencies** - Run `make check`\n2. **Install dependencies** - Run `make install`\n3. **(Optional) Pre-pull the sandbox image** - If needed, run `make setup-sandbox`\n4. **Start services** - Run `make start` (production mode)\n5. **Wait for startup** - Give all services enough time to start completely (90-120 seconds recommended)\n\n**Docker mode deployment** (if Docker is selected):\n1. **Initialize Docker environment** - Run `make docker-init`\n2. **Start Docker services** - Run `make up` (production mode)\n3. **Wait for startup** - Give all containers enough time to start completely (60 seconds recommended)\n\n### Phase 5: Service Health Check\n\n**Local mode health check**:\n1. **Check process status** - Confirm that Gateway, Frontend, and Nginx processes are all running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n**Docker mode health check** (when using Docker):\n1. **Check container status** - Run `docker ps` and confirm that all containers are running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n### Optional Functional Verification\n\n1. **List available models** - Verify that model configuration loads correctly\n2. **List available skills** - Verify that the skill directory is mounted correctly\n3. **Simple chat test** - Send a simple message to verify the end-to-end flow\n\n### Phase 6: Generate Test Report\n\n1. **Collect all test results** - Summarize execution status for each phase\n2. **Record encountered issues** - If anything fails, record the error details\n3. **Generate the final report** - Use the template that matches the selected deployment mode to create the complete test report, including overall conclusion, detailed key test cases, and explicit frontend page / route results\n4. **Provide follow-up recommendations** - Offer suggestions based on the test results\n\n## Execution Rules\n\n- **Follow the sequence** - Execute strictly in the order described above\n- **Idempotency** - Every step should be safe to repeat\n- **Error handling** - If a step fails, stop and report the issue, then provide troubleshooting suggestions\n- **Detailed logging** - Record the execution result and status of each step\n- **User confirmation** - Ask for confirmation before potentially risky operations such as overwriting config\n- **Mode preference** - Prefer local mode to avoid network-related issues\n- **Template requirement** - The final report must use the matching template under `templates/`; do not output a free-form summary instead of the template-based report\n- **Report clarity** - The execution summary must include the overall pass/fail conclusion plus per-case result explanations, and frontend smoke check results must be listed explicitly in the report\n- **Optional phase handling** - If functional verification is not executed, do not present it as a separate skipped phase in the final report\n\n## Known Acceptable Warnings\n\nThe following warnings can appear during smoke testing and do not block a successful result:\n- Feishu/Lark SSL errors in Gateway logs (certificate verification failure) can be ignored if that channel is not enabled\n- Warnings in Gateway logs about missing methods in the custom checkpointer, such as `adelete_for_runs` or `aprune`, do not affect the core functionality\n- The `frontend_check.sh` script automatically handles authentication. When auth is enabled it registers / logs in a smoke-test user (`smoke-test@deerflow.dev` by default) to verify the real `/workspace/*` pages. The registration may produce a log entry from the auth provider, which is expected and harmless.\n\n## Key Tools\n\nUse the following tools during execution:\n\n1. **bash** - Run shell commands\n2. **present_file** - Show generated reports and important files\n3. **task_tool** - Organize complex steps with subtasks when needed\n\n## Success Criteria\n\nSmoke test pass criteria (local mode):\n- [x] Latest code is pulled successfully\n- [x] Local environment check passes (Node.js 22+, pnpm, uv, nginx)\n- [x] Configuration files are set up correctly\n- [x] `make check` passes\n- [x] `make install` completes successfully\n- [x] `make dev` starts successfully\n- [x] All service processes run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\nSmoke test pass criteria (Docker mode):\n- [x] Latest code is pulled successfully\n- [x] Docker environment check passes\n- [x] Configuration files are set up correctly\n- [x] `make docker-init` completes successfully\n- [x] `make up` completes successfully\n- [x] All Docker containers run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\n## Read Reference Files\n\nBefore starting execution, read the following reference files:\n1. `references/SOP.md` - Detailed step-by-step operating instructions\n2. `references/troubleshooting.md` - Common issues and solutions\n3. `templates/report.local.template.md` - Local mode test report template\n4. `templates/report.docker.template.md` - Docker mode test report template\n","isInternal":false,"tokens":2231,"sizeBytes":10097},{"name":"report.docker.template.md","path":".agent/skills/smoke-test/templates/report.docker.template.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.docker.template.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.docker.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.docker.template.md)","tokens":300,"sizeBytes":238},{"name":"report.local.template.md","path":".agent/skills/smoke-test/templates/report.local.template.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.local.template.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.local.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.local.template.md)","tokens":300,"sizeBytes":236},{"name":"SKILL.md","path":"skills/public/academic-paper-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/academic-paper-review/SKILL.md","title":"academic-paper-review","category":"anthropic-skill","format":"markdown","content":"# academic-paper-review\n\nPath: `skills/public/academic-paper-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/academic-paper-review/SKILL.md)","tokens":300,"sizeBytes":212},{"name":"conversation-guide.md","path":"skills/public/bootstrap/references/conversation-guide.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/references/conversation-guide.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/bootstrap/references/conversation-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/references/conversation-guide.md)","tokens":300,"sizeBytes":231},{"name":"SKILL.md","path":"skills/public/bootstrap/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/SKILL.md","title":"bootstrap","category":"anthropic-skill","format":"markdown","content":"# bootstrap\n\nPath: `skills/public/bootstrap/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/SKILL.md)","tokens":300,"sizeBytes":176},{"name":"SOUL.template.md","path":"skills/public/bootstrap/templates/SOUL.template.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/templates/SOUL.template.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `skills/public/bootstrap/templates/SOUL.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/templates/SOUL.template.md)","tokens":300,"sizeBytes":218},{"name":"generate_area_chart.md","path":"skills/public/chart-visualization/references/generate_area_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_area_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_area_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_area_chart.md)","tokens":300,"sizeBytes":253},{"name":"generate_bar_chart.md","path":"skills/public/chart-visualization/references/generate_bar_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_bar_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_bar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_bar_chart.md)","tokens":300,"sizeBytes":251},{"name":"generate_boxplot_chart.md","path":"skills/public/chart-visualization/references/generate_boxplot_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_boxplot_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_boxplot_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_boxplot_chart.md)","tokens":300,"sizeBytes":259},{"name":"generate_column_chart.md","path":"skills/public/chart-visualization/references/generate_column_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_column_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_column_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_column_chart.md)","tokens":300,"sizeBytes":257},{"name":"generate_district_map.md","path":"skills/public/chart-visualization/references/generate_district_map.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_district_map.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_district_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_district_map.md)","tokens":300,"sizeBytes":257},{"name":"generate_dual_axes_chart.md","path":"skills/public/chart-visualization/references/generate_dual_axes_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_dual_axes_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_dual_axes_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_dual_axes_chart.md)","tokens":300,"sizeBytes":263},{"name":"generate_fishbone_diagram.md","path":"skills/public/chart-visualization/references/generate_fishbone_diagram.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_fishbone_diagram.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_fishbone_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_fishbone_diagram.md)","tokens":300,"sizeBytes":265},{"name":"generate_flow_diagram.md","path":"skills/public/chart-visualization/references/generate_flow_diagram.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_flow_diagram.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_flow_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_flow_diagram.md)","tokens":300,"sizeBytes":257},{"name":"generate_funnel_chart.md","path":"skills/public/chart-visualization/references/generate_funnel_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_funnel_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_funnel_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_funnel_chart.md)","tokens":300,"sizeBytes":257},{"name":"generate_histogram_chart.md","path":"skills/public/chart-visualization/references/generate_histogram_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_histogram_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_histogram_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_histogram_chart.md)","tokens":300,"sizeBytes":263},{"name":"generate_line_chart.md","path":"skills/public/chart-visualization/references/generate_line_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_line_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_line_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_line_chart.md)","tokens":300,"sizeBytes":253},{"name":"generate_liquid_chart.md","path":"skills/public/chart-visualization/references/generate_liquid_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_liquid_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_liquid_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_liquid_chart.md)","tokens":300,"sizeBytes":257},{"name":"generate_mind_map.md","path":"skills/public/chart-visualization/references/generate_mind_map.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_mind_map.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_mind_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_mind_map.md)","tokens":300,"sizeBytes":249},{"name":"generate_network_graph.md","path":"skills/public/chart-visualization/references/generate_network_graph.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_network_graph.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_network_graph.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_network_graph.md)","tokens":300,"sizeBytes":259},{"name":"generate_organization_chart.md","path":"skills/public/chart-visualization/references/generate_organization_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_organization_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_organization_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_organization_chart.md)","tokens":300,"sizeBytes":269},{"name":"generate_path_map.md","path":"skills/public/chart-visualization/references/generate_path_map.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_path_map.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_path_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_path_map.md)","tokens":300,"sizeBytes":249},{"name":"generate_pie_chart.md","path":"skills/public/chart-visualization/references/generate_pie_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pie_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pie_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pie_chart.md)","tokens":300,"sizeBytes":251},{"name":"generate_pin_map.md","path":"skills/public/chart-visualization/references/generate_pin_map.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pin_map.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pin_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pin_map.md)","tokens":300,"sizeBytes":247},{"name":"generate_radar_chart.md","path":"skills/public/chart-visualization/references/generate_radar_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_radar_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_radar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_radar_chart.md)","tokens":300,"sizeBytes":255},{"name":"generate_sankey_chart.md","path":"skills/public/chart-visualization/references/generate_sankey_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_sankey_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_sankey_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_sankey_chart.md)","tokens":300,"sizeBytes":257},{"name":"generate_scatter_chart.md","path":"skills/public/chart-visualization/references/generate_scatter_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_scatter_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_scatter_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_scatter_chart.md)","tokens":300,"sizeBytes":259},{"name":"generate_spreadsheet.md","path":"skills/public/chart-visualization/references/generate_spreadsheet.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_spreadsheet.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_spreadsheet.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_spreadsheet.md)","tokens":300,"sizeBytes":255},{"name":"generate_treemap_chart.md","path":"skills/public/chart-visualization/references/generate_treemap_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_treemap_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_treemap_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_treemap_chart.md)","tokens":300,"sizeBytes":259},{"name":"generate_venn_chart.md","path":"skills/public/chart-visualization/references/generate_venn_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_venn_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_venn_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_venn_chart.md)","tokens":300,"sizeBytes":253},{"name":"generate_violin_chart.md","path":"skills/public/chart-visualization/references/generate_violin_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_violin_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_violin_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_violin_chart.md)","tokens":300,"sizeBytes":257},{"name":"generate_word_cloud_chart.md","path":"skills/public/chart-visualization/references/generate_word_cloud_chart.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_word_cloud_chart.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_word_cloud_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_word_cloud_chart.md)","tokens":300,"sizeBytes":265},{"name":"SKILL.md","path":"skills/public/chart-visualization/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/SKILL.md","title":"chart-visualization","category":"anthropic-skill","format":"markdown","content":"# chart-visualization\n\nPath: `skills/public/chart-visualization/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/SKILL.md)","tokens":300,"sizeBytes":206},{"name":"SKILL.md","path":"skills/public/claude-to-deerflow/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/claude-to-deerflow/SKILL.md","title":"claude-to-deerflow","category":"anthropic-skill","format":"markdown","content":"# claude-to-deerflow\n\nPath: `skills/public/claude-to-deerflow/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/claude-to-deerflow/SKILL.md)","tokens":300,"sizeBytes":203},{"name":"SKILL.md","path":"skills/public/code-documentation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/code-documentation/SKILL.md","title":"code-documentation","category":"anthropic-skill","format":"markdown","content":"# code-documentation\n\nPath: `skills/public/code-documentation/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/code-documentation/SKILL.md)","tokens":300,"sizeBytes":203},{"name":"SKILL.md","path":"skills/public/consulting-analysis/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/consulting-analysis/SKILL.md","title":"consulting-analysis","category":"anthropic-skill","format":"markdown","content":"# consulting-analysis\n\nPath: `skills/public/consulting-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/consulting-analysis/SKILL.md)","tokens":300,"sizeBytes":206},{"name":"SKILL.md","path":"skills/public/data-analysis/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/data-analysis/SKILL.md","title":"data-analysis","category":"anthropic-skill","format":"markdown","content":"# data-analysis\n\nPath: `skills/public/data-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/data-analysis/SKILL.md)","tokens":300,"sizeBytes":188},{"name":"SKILL.md","path":"skills/public/deep-research/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/deep-research/SKILL.md","title":"deep-research","category":"anthropic-skill","format":"markdown","content":"# deep-research\n\nPath: `skills/public/deep-research/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/deep-research/SKILL.md)","tokens":300,"sizeBytes":188},{"name":"SKILL.md","path":"skills/public/find-skills/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/find-skills/SKILL.md","title":"find-skills","category":"anthropic-skill","format":"markdown","content":"# find-skills\n\nPath: `skills/public/find-skills/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/find-skills/SKILL.md)","tokens":300,"sizeBytes":182},{"name":"SKILL.md","path":"skills/public/frontend-design/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/frontend-design/SKILL.md","title":"frontend-design","category":"anthropic-skill","format":"markdown","content":"# frontend-design\n\nPath: `skills/public/frontend-design/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/frontend-design/SKILL.md)","tokens":300,"sizeBytes":194},{"name":"report_template.md","path":"skills/public/github-deep-research/assets/report_template.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/github-deep-research/assets/report_template.md","title":"Assets Skill","category":"anthropic-skill","format":"markdown","content":"# Assets Skill\n\nPath: `skills/public/github-deep-research/assets/report_template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/github-deep-research/assets/report_template.md)","tokens":300,"sizeBytes":235},{"name":"SKILL.md","path":"skills/public/github-deep-research/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/github-deep-research/SKILL.md","title":"github-deep-research","category":"anthropic-skill","format":"markdown","content":"---\nname: github-deep-research\ndescription: Conduct multi-round deep research on any GitHub Repo. Use when users request comprehensive analysis, timeline reconstruction, competitive analysis, or in-depth investigation of GitHub. Produces structured markdown reports with executive summaries, chronological timelines, metrics analysis, and Mermaid diagrams. Triggers on Github repository URL or open source projects.\n---\n\n# GitHub Deep Research Skill\n\nMulti-round research combining GitHub API, web_search, web_fetch to produce comprehensive markdown reports.\n\n## Research Workflow\n\n- Round 1: GitHub API\n- Round 2: Discovery\n- Round 3: Deep Investigation\n- Round 4: Deep Dive\n\n## Core Methodology\n\n### Query Strategy\n\n**Broad to Narrow**: Start with GitHub API, then general queries, refine based on findings.\n\n```\nRound 1: GitHub API\nRound 2: \"{topic} overview\"\nRound 3: \"{topic} architecture\", \"{topic} vs alternatives\"\nRound 4: \"{topic} issues\", \"{topic} roadmap\", \"site:github.com {topic}\"\n```\n\n**Source Prioritization**:\n1. Official docs/repos (highest weight)\n2. Technical blogs (Medium, Dev.to)\n3. News articles (verified outlets)\n4. Community discussions (Reddit, HN)\n5. Social media (lowest weight, for sentiment)\n\n### Research Rounds\n\n**Round 1 - GitHub API**\nDirectly execute `scripts/github_api.py` without `read_file()`:\n```bash\npython /path/to/skill/scripts/github_api.py summary\npython /path/to/skill/scripts/github_api.py readme\npython /path/to/skill/scripts/github_api.py tree\n```\n\n**Available commands (the last argument of `github_api.py`):**\n- summary\n- info\n- readme\n- tree\n- languages\n- contributors\n- commits\n- issues\n- prs\n- releases\n\n**Round 2 - Discovery (3-5 web_search)**\n- Get overview and identify key terms\n- Find official website/repo\n- Identify main players/competitors\n\n**Round 3 - Deep Investigation (5-10 web_search + web_fetch)**\n- Technical architecture details\n- Timeline of key events\n- Community sentiment\n- Use web_fetch on valuable URLs for full content\n\n**Round 4 - Deep Dive**\n- Analyze commit history for timeline\n- Review issues/PRs for feature evolution\n- Check contributor activity\n\n## Report Structure\n\nFollow template in `assets/report_template.md`:\n\n1. **Metadata Block** - Date, confidence level, subject\n2. **Executive Summary** - 2-3 sentence overview with key metrics\n3. **Chronological Timeline** - Phased breakdown with dates\n4. **Key Analysis Sections** - Topic-specific deep dives\n5. **Metrics & Comparisons** - Tables, growth charts\n6. **Strengths & Weaknesses** - Balanced assessment\n7. **Sources** - Categorized references\n8. **Confidence Assessment** - Claims by confidence level\n9. **Methodology** - Research approach used\n\n### Mermaid Diagrams\n\nInclude diagrams where helpful:\n\n**Timeline (Gantt)**:\n```mermaid\ngantt\n title Project Timeline\n dateFormat YYYY-MM-DD\n section Phase 1\n Development :2025-01-01, 2025-03-01\n section Phase 2\n Launch :2025-03-01, 2025-04-01\n```\n\n**Architecture (Flowchart)**:\n```mermaid\nflowchart TD\n A[User] --> B[Coordinator]\n B --> C[Planner]\n C --> D[Research Team]\n D --> E[Reporter]\n```\n\n**Comparison (Pie/Bar)**:\n```mermaid\npie title Market Share\n \"Project A\" : 45\n \"Project B\" : 30\n \"Others\" : 25\n```\n\n## Confidence Scoring\n\nAssign confidence based on source quality:\n\n| Confidence | Criteria |\n|------------|----------|\n| High (90%+) | Official docs, GitHub data, multiple corroborating sources |\n| Medium (70-89%) | Single reliable source, recent articles |\n| Low (50-69%) | Social media, unverified claims, outdated info |\n\n## Output\n\nSave report as: `research_{topic}_{YYYYMMDD}.md`\n\n### Formatting Rules\n\n- Chinese content: Use full-width punctuation（，。：；！？）\n- Technical terms: Provide Wiki/doc URL on first mention\n- Tables: Use for metrics, comparisons\n- Code blocks: For technical examples\n- Mermaid: For architecture, timelines, flows\n\n## Best Practices\n\n1. **Start with official sources** - Repo, docs, company blog\n2. **Verify dates from commits/PRs** - More reliable than articles\n3. **Triangulate claims** - 2+ independent sources\n4. **Note conflicting info** - Don't hide contradictions\n5. **Distinguish fact vs opinion** - Label speculation clearly\n6. **CRITICAL: Always include inline citations** - Use `[citation:Title](URL)` format immediately after each claim from external sources\n7. **Extract URLs from search results** - web_search returns {title, url, snippet} - always use the URL field\n8. **Update as you go** - Don't wait until end to synthesize\n\n### Citation Examples\n\n**Good - With inline citations:**\n```markdown\nThe project gained 10,000 stars within 3 months of launch [citation:GitHub Stats](https://github.com/owner/repo).\nThe architecture uses LangGraph for workflow orchestration [citation:LangGraph Docs](https://langchain.com/langgraph).\n```\n\n**Bad - Without citations:**\n```markdown\nThe project gained 10,000 stars within 3 months of launch.\nThe architecture uses LangGraph for workflow orchestration.\n```\n","frontmatter":{"name":"github-deep-research","description":"Conduct multi-round deep research on any GitHub Repo. Use when users request comprehensive analysis, timeline reconstruction, competitive analysis, or in-depth investigation of GitHub. Produces structured markdown reports with executive summaries, chronological timelines, metrics analysis, and Mermaid diagrams. Triggers on Github repository URL or open source projects."},"isInternal":false,"tokens":1244,"sizeBytes":5055},{"name":"SKILL.md","path":"skills/public/image-generation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/image-generation/SKILL.md","title":"image-generation","category":"anthropic-skill","format":"markdown","content":"---\nname: image-generation\ndescription: Use this skill when the user requests to generate, create, imagine, or visualize images including characters, scenes, products, or any visual content. Supports structured prompts and reference images for guided generation.\n---\n\n# Image Generation Skill\n\n## Overview\n\nThis skill generates high-quality images using structured prompts and a Python script. The workflow includes creating JSON-formatted prompts and executing image generation with optional reference images.\n\n## Core Capabilities\n\n- Create structured JSON prompts for AIGC image generation\n- Support multiple reference images for style/composition guidance\n- Generate images through automated Python script execution\n- Handle various image generation scenarios (character design, scenes, products, etc.)\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests image generation, identify:\n\n- Subject/content: What should be in the image\n- Style preferences: Art style, mood, color palette\n- Technical specs: Aspect ratio, composition, lighting\n- Reference images: Any images to guide generation\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Prompt\n\nGenerate a structured JSON file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}.json`\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/prompt-file.json \\\n --reference-images /path/to/ref1.jpg /path/to/ref2.png \\\n --output-file /mnt/user-data/outputs/generated-image.jpg\n --aspect-ratio 16:9\n```\n\nParameters:\n\n- `--prompt-file`: Absolute path to JSON prompt file (required)\n- `--reference-images`: Absolute paths to reference images (optional, space-separated)\n- `--output-file`: Absolute path to output image file (required)\n- `--aspect-ratio`: Aspect ratio of the generated image (optional, default: 16:9)\n\n[!NOTE]\nDo NOT read the python file, just call it with the parameters.\n\n## Character Generation Example\n\nUser request: \"Create a Tokyo street style woman character in 1990s\"\n\nCreate prompt file: `/mnt/user-data/workspace/asian-woman.json`\n```json\n{\n \"characters\": [{\n \"gender\": \"female\",\n \"age\": \"mid-20s\",\n \"ethnicity\": \"Japanese\",\n \"body_type\": \"slender, elegant\",\n \"facial_features\": \"delicate features, expressive eyes, subtle makeup with emphasis on lips, long dark hair partially wet from rain\",\n \"clothing\": \"stylish trench coat, designer handbag, high heels, contemporary Tokyo street fashion\",\n \"accessories\": \"minimal jewelry, statement earrings, leather handbag\",\n \"era\": \"1990s\"\n }],\n \"negative_prompt\": \"blurry face, deformed, low quality, overly sharp digital look, oversaturated colors, artificial lighting, studio setting, posed, selfie angle\",\n \"style\": \"Leica M11 street photography aesthetic, film-like rendering, natural color palette with slight warmth, bokeh background blur, analog photography feel\",\n \"composition\": \"medium shot, rule of thirds, subject slightly off-center, environmental context of Tokyo street visible, shallow depth of field isolating subject\",\n \"lighting\": \"neon lights from signs and storefronts, wet pavement reflections, soft ambient city glow, natural street lighting, rim lighting from background neons\",\n \"color_palette\": \"muted naturalistic tones, warm skin tones, cool blue and magenta neon accents, desaturated compared to digital photography, film grain texture\"\n}\n```\n\nExecute generation:\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/cyberpunk-hacker.json \\\n --output-file /mnt/user-data/outputs/cyberpunk-hacker-01.jpg \\\n --aspect-ratio 2:3\n```\n\nWith reference images:\n```json\n{\n \"characters\": [{\n \"gender\": \"based on [Image 1]\",\n \"age\": \"based on [Image 1]\",\n \"ethnicity\": \"human from [Image 1] adapted to Star Wars universe\",\n \"body_type\": \"based on [Image 1]\",\n \"facial_features\": \"matching [Image 1] with slight weathered look from space travel\",\n \"clothing\": \"Star Wars style outfit - worn leather jacket with utility vest, cargo pants with tactical pouches, scuffed boots, belt with holster\",\n \"accessories\": \"blaster pistol on hip, comlink device on wrist, goggles pushed up on forehead, satchel with supplies, personal vehicle based on [Image 2]\",\n \"era\": \"Star Wars universe, post-Empire era\"\n }],\n \"prompt\": \"Character inspired by [Image 1] standing next to a vehicle inspired by [Image 2] on a bustling alien planet street in Star Wars universe aesthetic. Character wearing worn leather jacket with utility vest, cargo pants with tactical pouches, scuffed boots, belt with blaster holster. The vehicle adapted to Star Wars aesthetic with weathered metal panels, repulsor engines, desert dust covering, parked on the street. Exotic alien marketplace street with multi-level architecture, weathered metal structures, hanging market stalls with colorful awnings, alien species walking by as background characters. Twin suns casting warm golden light, atmospheric dust particles in air, moisture vaporators visible in distance. Gritty lived-in Star Wars aesthetic, practical effects look, film grain texture, cinematic composition.\",\n \"negative_prompt\": \"clean futuristic look, sterile environment, overly CGI appearance, fantasy medieval elements, Earth architecture, modern city\",\n \"style\": \"Star Wars original trilogy aesthetic, lived-in universe, practical effects inspired, cinematic film look, slightly desaturated with warm tones\",\n \"composition\": \"medium wide shot, character in foreground with alien street extending into background, environmental storytelling, rule of thirds\",\n \"lighting\": \"warm golden hour lighting from twin suns, rim lighting on character, atmospheric haze, practical light sources from market stalls\",\n \"color_palette\": \"warm sandy tones, ochre and sienna, dusty blues, weathered metals, muted earth colors with pops of alien market colors\",\n \"technical\": {\n \"aspect_ratio\": \"9:16\",\n \"quality\": \"high\",\n \"detail_level\": \"highly detailed with film-like texture\"\n }\n}\n```\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/star-wars-scene.json \\\n --reference-images /mnt/user-data/uploads/character-ref.jpg /mnt/user-data/uploads/vehicle-ref.jpg \\\n --output-file /mnt/user-data/outputs/star-wars-scene-01.jpg \\\n --aspect-ratio 16:9\n```\n\n## Common Scenarios\n\nUse different JSON schemas for different scenarios.\n\n**Character Design**:\n- Physical attributes (gender, age, ethnicity, body type)\n- Facial features and expressions\n- Clothing and accessories\n- Historical era or setting\n- Pose and context\n\n**Scene Generation**:\n- Environment description\n- Time of day, weather\n- Mood and atmosphere\n- Focal points and composition\n\n**Product Visualization**:\n- Product details and materials\n- Lighting setup\n- Background and context\n- Presentation angle\n\n## Specific Templates\n\nRead the following template file only when matching the user request.\n\n- [Doraemon Comic](templates/doraemon.md)\n\n## Output Handling\n\nAfter generation:\n\n- Images are typically saved in `/mnt/user-data/outputs/`\n- Share generated images with user using present_files tool\n- Provide brief description of the generation result\n- Offer to iterate if adjustments needed\n\n## Tips: Enhancing Generation with Reference Images\n\nFor scenarios where visual accuracy is critical, **use the `image_search` tool first** to find reference images before generation.\n\n**Recommended scenarios for using image_search tool:**\n- **Character/Portrait Generation**: Search for similar poses, expressions, or styles to guide facial features and body proportions\n- **Specific Objects or Products**: Find reference images of real objects to ensure accurate representation\n- **Architectural or Environmental Scenes**: Search for location references to capture authentic details\n- **Fashion and Clothing**: Find style references to ensure accurate garment details and styling\n\n**Example workflow:**\n1. Call the `image_search` tool to find suitable reference images:\n ```\n image_search(query=\"Japanese woman street photography 1990s\", size=\"Large\")\n ```\n2. Download the returned image URLs to local files\n3. Use the downloaded images as `--reference-images` parameter in the generation script\n\nThis approach significantly improves generation quality by providing the model with concrete visual guidance rather than relying solely on text descriptions.\n\n## Providers (Gemini / MiniMax / OpenAI-compatible)\n\nThis skill auto-selects the provider by environment variables (no CLI change):\n\n- `GEMINI_API_KEY` set → use Gemini (default, unchanged).\n- Otherwise, `MINIMAX_API_KEY` set → use MiniMax (`/v1/image_generation`, model `image-01`).\n- Otherwise, `IMAGE_GENERATION_API_KEY` set → use an OpenAI-compatible Images API.\n- Force one explicitly with `IMAGE_GENERATION_PROVIDER=gemini|minimax|openai`.\n `openai-compatible` is also accepted as an alias for `openai`.\n\nOpenAI-compatible settings:\n\n- `IMAGE_GENERATION_API_KEY` (required)\n- `IMAGE_GENERATION_BASE_URL` (default `https://api.openai.com/v1`)\n- `IMAGE_GENERATION_MODEL` (default `gpt-image-2.5-flare`)\n- `IMAGE_GENERATION_SIZE` (optional fixed size override)\n\nText-to-image calls use `POST {base_url}/images/generations`. Reference-image calls\nuse multipart `POST {base_url}/images/edits`; a relay may support generation without\nsupporting edits. Responses may contain base64 image data, a data URL, or a downloadable\nURL. Aspect ratios map to `1024x1024`, `1536x1024`, or `1024x1536` unless\n`IMAGE_GENERATION_SIZE` is set. The output extension selects the API `output_format`:\n`.jpg`/`.jpeg` uses `jpeg`, `.webp` uses `webp`, and all other extensions use `png`.\nWhen `dall-e-2` or `dall-e-3` is configured instead, the request uses the model's\nsupported dimensions and `response_format=b64_json`; DALL-E output files must use a\n`.png` extension. Reference-image editing with DALL-E models is not supported by this\nskill; use the default GPT Image model for edits.\n\nMiniMax optional overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_IMAGE_MODEL` (default `image-01`). Reference images are sent as the MiniMax\n`subject_reference` character image. The CLI and `--prompt-file` / `--reference-images`\n/ `--output-file` / `--aspect-ratio` arguments are identical for both providers.\n\n**MiniMax prompt handling (provider-internal).** Authoring is provider-agnostic — write\nthe same structured JSON regardless of which provider is active. MiniMax `image-01`\nconsumes a single text string, so the MiniMax path itself sends only the JSON `prompt`\nfield (the other fields such as `style` / `composition` / `negative_prompt` apply to the\nGemini path) and enables `prompt_optimizer` so MiniMax expands it server-side. MiniMax\ncaps that prompt at 1500 characters; if the `prompt` field is longer, the script returns\nan error instead of calling the API. The Gemini path receives the full structured JSON.\n\n## Notes\n\n- Always use English for prompts regardless of user's language\n- JSON format ensures structured, parsable prompts\n- Reference images enhance generation quality significantly\n- Iterative refinement is normal for optimal results\n- For character generation, include the detailed character object plus a consolidated prompt field\n","frontmatter":{"name":"image-generation","description":"Use this skill when the user requests to generate, create, imagine, or visualize images including characters, scenes, products, or any visual content. Supports structured prompts and reference images for guided generation."},"isInternal":false,"tokens":2546,"sizeBytes":11444},{"name":"doraemon.md","path":"skills/public/image-generation/templates/doraemon.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/image-generation/templates/doraemon.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `skills/public/image-generation/templates/doraemon.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/image-generation/templates/doraemon.md)","tokens":300,"sizeBytes":222},{"name":"SKILL.md","path":"skills/public/newsletter-generation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/newsletter-generation/SKILL.md","title":"newsletter-generation","category":"anthropic-skill","format":"markdown","content":"---\nname: newsletter-generation\ndescription: Use this skill when the user requests to generate, create, write, or draft a newsletter, email digest, weekly roundup, industry briefing, or curated content summary. Supports topic-based research, content curation from multiple sources, and professional formatting for email or web distribution. Trigger on requests like \"create a newsletter about X\", \"write a weekly digest\", \"generate a tech roundup\", or \"curate news about Y\".\n---\n\n# Newsletter Generation Skill\n\n## Overview\n\nThis skill generates professional, well-researched newsletters that combine curated content from multiple sources with original analysis and commentary. It follows modern newsletter best practices from publications like Morning Brew, The Hustle, TLDR, and Benedict Evans to produce content that is informative, engaging, and actionable.\n\nThe output is a complete, ready-to-publish newsletter in Markdown format, suitable for email distribution platforms, web publishing, or conversion to HTML.\n\n## Core Capabilities\n\n- Research and curate content from multiple web sources on specified topics\n- Generate topic-focused or multi-topic newsletters with consistent voice\n- Write engaging headlines, summaries, and original commentary\n- Structure content for optimal readability and scanning\n- Support multiple newsletter formats (daily digest, weekly roundup, deep-dive, industry briefing)\n- Include relevant links, sources, and attributions\n- Adapt tone and style to target audience (technical, executive, general)\n- Generate recurring newsletter series with consistent branding and structure\n\n## When to Use This Skill\n\n**Always load this skill when:**\n\n- User asks to generate a newsletter, email digest, or content roundup\n- User requests a curated summary of news or developments on a topic\n- User wants to create a recurring newsletter format\n- User asks to compile recent developments in a field into a briefing\n- User needs a formatted email-ready content piece with multiple curated items\n- User asks for a \"weekly roundup\", \"monthly digest\", or \"morning briefing\"\n\n## Newsletter Workflow\n\n### Phase 1: Planning\n\n#### Step 1.1: Understand Newsletter Requirements\n\nIdentify the key parameters:\n\n| Parameter | Description | Default |\n|-----------|-------------|---------|\n| **Topic(s)** | Primary subject area(s) to cover | Required |\n| **Format** | Daily digest, weekly roundup, deep-dive, or industry briefing | Weekly roundup |\n| **Target Audience** | Technical, executive, general, or niche community | General |\n| **Tone** | Professional, conversational, witty, or analytical | Conversational-professional |\n| **Length** | Short (5-min read), medium (10-min), long (15-min+) | Medium |\n| **Sections** | Number and type of content sections | 4-6 sections |\n| **Frequency Context** | One-time or part of a recurring series | One-time |\n\n#### Step 1.2: Define Newsletter Structure\n\nBased on the format, select the appropriate structure:\n\n**Daily Digest Structure**:\n```\n1. Top Story (1 item, detailed)\n2. Quick Hits (3-5 items, brief)\n3. One Stat / Quote of the Day\n4. What to Watch\n```\n\n**Weekly Roundup Structure**:\n```\n1. Editor's Note / Intro\n2. Top Stories (2-3 items, detailed)\n3. Trends & Analysis (1-2 items, original commentary)\n4. Quick Bites (4-6 items, brief summaries)\n5. Tools & Resources (2-3 items)\n6. One More Thing / Closing\n```\n\n**Deep-Dive Structure**:\n```\n1. Introduction & Context\n2. Background / Why It Matters\n3. Key Developments (detailed analysis)\n4. Expert Perspectives\n5. What's Next / Implications\n6. Further Reading\n```\n\n**Industry Briefing Structure**:\n```\n1. Executive Summary\n2. Market Developments\n3. Company News & Moves\n4. Product & Technology Updates\n5. Regulatory & Policy Changes\n6. Data & Metrics\n7. Outlook\n```\n\n### Phase 2: Research & Curation\n\n#### Step 2.1: Multi-Source Research\n\nConduct thorough research using web search. **The quality of the newsletter depends directly on the quality and recency of research.**\n\n**Search Strategy**:\n\n```\n# Current news and developments\n\"[topic] news [current month] [current year]\"\n\"[topic] latest developments\"\n\"[topic] announcement this week\"\n\n# Trends and analysis\n\"[topic] trends [current year]\"\n\"[topic] analysis expert opinion\"\n\"[topic] industry report\"\n\n# Data and statistics\n\"[topic] statistics [current year]\"\n\"[topic] market data latest\"\n\"[topic] growth metrics\"\n\n# Tools and resources\n\"[topic] new tools [current year]\"\n\"[topic] open source release\"\n\"best [topic] resources [current year]\"\n```\n\n> **IMPORTANT**: Always check `` to ensure search queries use the correct temporal context. Never use hardcoded years.\n\n#### Step 2.2: Source Evaluation and Selection\n\nEvaluate each source and curate the best content:\n\n| Criterion | Priority |\n|-----------|----------|\n| **Recency** | Prefer content from the last 7-30 days |\n| **Authority** | Prioritize primary sources, official announcements, established publications |\n| **Uniqueness** | Select stories that offer fresh perspective or are underreported |\n| **Relevance** | Every item must clearly connect to the newsletter's stated topic(s) |\n| **Actionability** | Prefer content readers can act on (tools, insights, strategies) |\n| **Diversity** | Mix of news, analysis, data, and practical resources |\n\n#### Step 2.3: Deep Content Extraction\n\nFor key stories, use `web_fetch` to read full articles and extract:\n\n1. **Core facts** — What happened, who is involved, when\n2. **Context** — Why this matters, background information\n3. **Data points** — Specific numbers, metrics, or statistics\n4. **Quotes** — Relevant expert quotes or official statements\n5. **Implications** — What this means for the reader\n\n### Phase 3: Writing\n\n#### Step 3.1: Newsletter Header\n\nEvery newsletter starts with a consistent header:\n\n```markdown\n# [Newsletter Name]\n\n*[Tagline or description] — [Date]*\n\n---\n\n[Optional: One-sentence preview of what's inside]\n```\n\n#### Step 3.2: Section Writing Guidelines\n\n**Top Stories / Featured Items**:\n- **Headline**: Compelling, clear, benefit-oriented (not clickbait)\n- **Hook**: Opening sentence that makes the reader care (1-2 sentences)\n- **Body**: Key facts and context (2-4 paragraphs)\n- **Why it matters**: Connect to the reader's world (1 paragraph)\n- **Source link**: Always attribute and link to the original source\n\n**Quick Bites / Brief Items**:\n- **Format**: Bold headline + 2-3 sentence summary + source link\n- **Focus**: One key takeaway per item\n- **Efficiency**: Readers should get the essential insight without clicking through\n\n**Analysis / Commentary Sections**:\n- **Voice**: The newsletter's unique perspective on trends or developments\n- **Structure**: Observation → Context → Implication → (Optional) Actionable takeaway\n- **Evidence**: Every claim backed by data or sourced information\n\n#### Step 3.3: Writing Standards\n\n| Principle | Implementation |\n|-----------|---------------|\n| **Scannable** | Use headers, bold text, bullet points, and short paragraphs |\n| **Engaging** | Lead with the most interesting angle, not chronological order |\n| **Concise** | Every sentence earns its place — cut filler ruthlessly |\n| **Accurate** | Every fact is sourced, every number is verified |\n| **Attributive** | Always credit original sources with inline links |\n| **Human** | Write like a knowledgeable friend, not a press release |\n\n**Tone Calibration by Audience**:\n\n| Audience | Tone | Example |\n|----------|------|---------|\n| **Technical** | Precise, no jargon explanations, assumed expertise | \"The new API supports gRPC streaming with backpressure handling via flow control windows.\" |\n| **Executive** | Impact-focused, bottom-line, strategic | \"This acquisition gives Company X a 40% market share in the enterprise segment, directly threatening Incumbent Y's pricing power.\" |\n| **General** | Accessible, analogies, explains concepts | \"Think of it like a universal translator for data — it lets any app talk to any database without learning a new language.\" |\n\n### Phase 4: Assembly & Polish\n\n#### Step 4.1: Assemble the Newsletter\n\nCombine all sections into the final document following the chosen structure template.\n\n#### Step 4.2: Footer\n\nEvery newsletter ends with:\n\n```markdown\n---\n\n*[Newsletter Name] is [description of what it is].*\n*[How to subscribe/share/give feedback]*\n\n*Sources: All links are provided inline. This newsletter curates and summarizes\npublicly available information with original commentary.*\n```\n\n#### Step 4.3: Quality Checklist\n\nBefore finalizing, verify:\n\n- [ ] **Every factual claim has a source link** — No unsourced assertions\n- [ ] **All links are functional** — Verified URLs from search results\n- [ ] **Date references use the actual current date** — No hardcoded or assumed dates\n- [ ] **Content is current** — All major items are from within the expected timeframe\n- [ ] **No duplicate stories** — Each item appears only once\n- [ ] **Consistent formatting** — Headers, bullets, links use the same style throughout\n- [ ] **Balanced coverage** — Not dominated by a single source or perspective\n- [ ] **Appropriate length** — Matches the specified length target\n- [ ] **Engaging opening** — The first 2 sentences make the reader want to continue\n- [ ] **Clear closing** — The newsletter ends with a memorable or actionable note\n- [ ] **Proofread** — No typos, broken formatting, or incomplete sentences\n\n## Newsletter Output Template\n\n```markdown\n# [Newsletter Name]\n\n*[Tagline] — [Full date, e.g., April 4, 2026]*\n\n---\n\n[Preview sentence: \"This week: [topic 1], [topic 2], and [topic 3].\"]\n\n## 🔥 Top Stories\n\n### [Headline 1]\n\n[Hook — why this matters in 1-2 sentences.]\n\n[Body — 2-4 paragraphs covering key facts, context, and implications.]\n\n**Why it matters:** [1 paragraph connecting to reader's interests or industry impact.]\n\n📎 [Source: Publication Name](URL)\n\n### [Headline 2]\n\n[Same structure as above]\n\n## 📊 Trends & Analysis\n\n### [Trend Title]\n\n[Original commentary on an emerging trend, backed by data from research.]\n\n[Key data points presented clearly — consider inline stats or a brief comparison.]\n\n**The bottom line:** [One-sentence takeaway.]\n\n## ⚡ Quick Bites\n\n- **[Headline]** — [2-3 sentence summary with key takeaway.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n- **[Headline]** — [2-3 sentence summary.] [Source](URL)\n\n## 🛠️ Tools & Resources\n\n- **[Tool/Resource Name]** — [What it does and why it's useful.] [Link](URL)\n- **[Tool/Resource Name]** — [Description.] [Link](URL)\n\n## 💬 One More Thing\n\n[Closing thought, insightful quote, or forward-looking statement.]\n\n---\n\n*[Newsletter Name] curates the most important [topic] news and analysis.*\n*Found this useful? Share it with a colleague.*\n\n*All sources are linked inline. Views and commentary are original.*\n```\n\n## Adaptation Examples\n\n### Technology Newsletter\n- Emoji usage: ✅ Moderate (section headers)\n- Sections: Top Stories, Deep Dive, Quick Bites, Open Source Spotlight, Dev Tools\n- Tone: Technical-conversational\n\n### Business/Finance Newsletter\n- Emoji usage: ❌ Minimal to none\n- Sections: Market Overview, Deal Flow, Company News, Data Corner, Outlook\n- Tone: Professional-analytical\n\n### Industry-Specific Newsletter\n- Emoji usage: Moderate\n- Sections: Regulatory Updates, Market Data, Innovation Watch, People Moves, Events\n- Tone: Expert-authoritative\n\n### Creative/Marketing Newsletter\n- Emoji usage: ✅ Liberal\n- Sections: Campaign Spotlight, Trend Watch, Viral This Week, Tools We Love, Inspiration\n- Tone: Enthusiastic-professional\n\n## Output Handling\n\nAfter generation:\n\n- Save the newsletter to `/mnt/user-data/outputs/newsletter-{topic}-{date}.md`\n- Present the newsletter to the user using the `present_files` tool\n- Offer to adjust sections, tone, length, or focus areas\n- If the user wants HTML output, note that the Markdown can be converted using standard tools\n\n## Notes\n\n- This skill works best in combination with the `deep-research` skill for comprehensive topic coverage — load both for newsletters requiring deep analysis\n- Always use `` for temporal context in searches and date references in the newsletter\n- For recurring newsletters, suggest maintaining a consistent structure so readers develop expectations\n- When curating, quality beats quantity — 5 excellent items beat 15 mediocre ones\n- Attribute all content properly — newsletters build trust through transparent sourcing\n- Avoid summarizing paywalled content that the reader cannot access\n- If the user provides specific URLs or articles to include, incorporate them alongside your curated findings\n- The newsletter should provide enough value in the summaries that readers benefit even without clicking through to every link\n","frontmatter":{"name":"newsletter-generation","description":"Use this skill when the user requests to generate, create, write, or draft a newsletter, email digest, weekly roundup, industry briefing, or curated content summary. Supports topic-based research, content curation from multiple sources, and professional formatting for email or web distribution. Trigger on requests like \"create a newsletter about X\", \"write a weekly digest\", \"generate a tech roundup\", or \"curate news about Y\"."},"isInternal":false,"tokens":2888,"sizeBytes":12859},{"name":"SKILL.md","path":"skills/public/podcast-generation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/podcast-generation/SKILL.md","title":"podcast-generation","category":"anthropic-skill","format":"markdown","content":"---\nname: podcast-generation\ndescription: Use this skill when the user requests to generate, create, or produce podcasts from text content. Converts written content into a two-host conversational podcast audio format with natural dialogue.\n---\n\n# Podcast Generation Skill\n\n## Overview\n\nThis skill generates high-quality podcast audio from text content. The workflow includes creating a structured JSON script (conversational dialogue) and executing audio generation through text-to-speech synthesis.\n\n## Core Capabilities\n\n- Convert any text content (articles, reports, documentation) into podcast scripts\n- Generate natural two-host conversational dialogue (male and female hosts)\n- Synthesize speech audio using text-to-speech\n- Mix audio chunks into a final podcast MP3 file\n- Support both English and Chinese content\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests podcast generation, identify:\n\n- Source content: The text/article/report to convert into a podcast\n- Language: English or Chinese (based on content)\n- Output location: Where to save the generated podcast\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Script JSON\n\nGenerate a structured JSON script file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}-script.json`\n\nThe JSON structure:\n```json\n{\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"dialogue text\"},\n {\"speaker\": \"female\", \"paragraph\": \"dialogue text\"}\n ]\n}\n```\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/podcast-generation/scripts/generate.py \\\n --script-file /mnt/user-data/workspace/script-file.json \\\n --output-file /mnt/user-data/outputs/generated-podcast.mp3 \\\n --transcript-file /mnt/user-data/outputs/generated-podcast-transcript.md\n```\n\nParameters:\n\n- `--script-file`: Absolute path to JSON script file (required)\n- `--output-file`: Absolute path to output MP3 file (required)\n- `--transcript-file`: Absolute path to output transcript markdown file (optional, but recommended)\n\n> [!IMPORTANT]\n> - Execute the script in one complete call. Do NOT split the workflow into separate steps.\n> - The script handles all TTS API calls and audio generation internally.\n> - Do NOT read the Python file, just call it with the parameters.\n> - Always include `--transcript-file` to generate a readable transcript for the user.\n> - The TTS provider and its concurrency are selected automatically from environment variables — you do not choose or tune them.\n\n## Script JSON Format\n\nThe script JSON file must follow this structure:\n\n```json\n{\n \"title\": \"The History of Artificial Intelligence\",\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"Hello Deer! Welcome back to another episode.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Hey everyone! Today we have an exciting topic to discuss.\"},\n {\"speaker\": \"male\", \"paragraph\": \"That's right! We're going to talk about...\"}\n ]\n}\n```\n\nFields:\n- `title`: Title of the podcast episode (optional, used as heading in transcript)\n- `locale`: Language code - \"en\" for English or \"zh\" for Chinese\n- `lines`: Array of dialogue lines\n - `speaker`: Either \"male\" or \"female\"\n - `paragraph`: The dialogue text for this speaker\n\n## Script Writing Guidelines\n\nWhen creating the script JSON, follow these guidelines:\n\n### Format Requirements\n- Only two hosts: male and female, alternating naturally\n- Target runtime: approximately 10 minutes of dialogue (around 40-60 lines)\n- Start with the male host saying a greeting that includes \"Hello Deer\"\n\n### Tone & Style\n- Natural, conversational dialogue - like two friends chatting\n- Use casual expressions and conversational transitions\n- Avoid overly formal language or academic tone\n- Include reactions, follow-up questions, and natural interjections\n\n### Content Guidelines\n- Frequent back-and-forth between hosts\n- Keep sentences short and easy to follow when spoken\n- Plain text only - no markdown formatting in the output\n- Translate technical concepts into accessible language\n- No mathematical formulas, code, or complex notation\n- Make content engaging and accessible for audio-only listeners\n- Exclude meta information like dates, author names, or document structure\n\n## Podcast Generation Example\n\nUser request: \"Generate a podcast about the history of artificial intelligence\"\n\nStep 1: Create script file `/mnt/user-data/workspace/ai-history-script.json`:\n```json\n{\n \"title\": \"The History of Artificial Intelligence\",\n \"locale\": \"en\",\n \"lines\": [\n {\"speaker\": \"male\", \"paragraph\": \"Hello Deer! Welcome back to another fascinating episode. Today we're diving into something that's literally shaping our future - the history of artificial intelligence.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Oh, I love this topic! You know, AI feels so modern, but it actually has roots going back over seventy years.\"},\n {\"speaker\": \"male\", \"paragraph\": \"Exactly! It all started back in the 1950s. The term artificial intelligence was actually coined by John McCarthy in 1956 at a famous conference at Dartmouth.\"},\n {\"speaker\": \"female\", \"paragraph\": \"Wait, so they were already thinking about machines that could think back then? That's incredible!\"},\n {\"speaker\": \"male\", \"paragraph\": \"Right? The early pioneers were so optimistic. They thought we'd have human-level AI within a generation.\"},\n {\"speaker\": \"female\", \"paragraph\": \"But things didn't quite work out that way, did they?\"},\n {\"speaker\": \"male\", \"paragraph\": \"No, not at all. The 1970s brought what's called the first AI winter...\"}\n ]\n}\n```\n\nStep 2: Execute generation:\n```bash\npython /mnt/skills/public/podcast-generation/scripts/generate.py \\\n --script-file /mnt/user-data/workspace/ai-history-script.json \\\n --output-file /mnt/user-data/outputs/ai-history-podcast.mp3 \\\n --transcript-file /mnt/user-data/outputs/ai-history-transcript.md\n```\n\nThis will generate:\n- `ai-history-podcast.mp3`: The audio podcast file\n- `ai-history-transcript.md`: A readable markdown transcript of the podcast\n\n## Specific Templates\n\nRead the following template file only when matching the user request.\n\n- [Tech Explainer](templates/tech-explainer.md) - For converting technical documentation and tutorials\n\n## Output Format\n\nThe generated podcast follows the \"Hello Deer\" format:\n- Two hosts: one male, one female\n- Natural conversational dialogue\n- Starts with \"Hello Deer\" greeting\n- Target duration: approximately 10 minutes\n- Alternating speakers for engaging flow\n\n## Output Handling\n\nAfter generation:\n\n- Podcasts and transcripts are saved in `/mnt/user-data/outputs/`\n- Share both the podcast MP3 and transcript MD with user using `present_files` tool\n- Provide brief description of the generation result (topic, duration, hosts)\n- Offer to regenerate if adjustments needed\n\n## Requirements\n\nThe following environment variables must be set:\n- For Volcengine: `VOLCENGINE_TTS_APPID` and `VOLCENGINE_TTS_ACCESS_TOKEN`\n- For MiniMax: `MINIMAX_API_KEY`\n- `VOLCENGINE_TTS_CLUSTER`: Volcengine TTS cluster (optional, defaults to \"volcano_tts\")\n- `VOLCENGINE_TTS_VOICE_TYPE_MALE`: Volcengine male voice type (optional, defaults to `zh_male_yangguangqingnian_moon_bigtts`)\n- `VOLCENGINE_TTS_VOICE_TYPE_FEMALE`: Volcengine female voice type (optional, defaults to `zh_female_sajiaonvyou_moon_bigtts`)\n\nVoice type overrides are trimmed; unset or blank values use the listed defaults.\n\n## Notes\n\n- **Always execute the full pipeline in one call** - no need to test individual steps or worry about timeouts\n- The script JSON should match the content language (en or zh)\n- Technical content should be simplified for audio accessibility in the script\n- Complex notations (formulas, code) should be translated to plain language in the script\n- Long content may result in longer podcasts\n\n## Providers (Volcengine / MiniMax)\n\nAuto-selected by environment variables:\n\n- `VOLCENGINE_TTS_APPID` + `VOLCENGINE_TTS_ACCESS_TOKEN` set → Volcengine TTS (default).\n- Only `MINIMAX_API_KEY` set → MiniMax TTS (`/v1/t2a_v2`).\n- Force with `PODCAST_GENERATION_PROVIDER=volcengine|minimax`.\n\nMiniMax overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_TTS_MODEL` (default `speech-2.6-hd`), `MINIMAX_TTS_VOICE_MALE`\n(default `male-qn-qingse`), `MINIMAX_TTS_VOICE_FEMALE` (default `female-tianmei`).\n\nConcurrency is owned by each provider internally — MiniMax runs single-threaded\nto reduce rate-limit failures, Volcengine uses 4 workers. There is no\ncaller-facing concurrency knob; transient rate limits are handled by automatic\nretry with backoff.\n","frontmatter":{"name":"podcast-generation","description":"Use this skill when the user requests to generate, create, or produce podcasts from text content. Converts written content into a two-host conversational podcast audio format with natural dialogue."},"isInternal":false,"tokens":1987,"sizeBytes":8630},{"name":"tech-explainer.md","path":"skills/public/podcast-generation/templates/tech-explainer.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/podcast-generation/templates/tech-explainer.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `skills/public/podcast-generation/templates/tech-explainer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/podcast-generation/templates/tech-explainer.md)","tokens":300,"sizeBytes":238},{"name":"SKILL.md","path":"skills/public/ppt-generation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/ppt-generation/SKILL.md","title":"ppt-generation","category":"anthropic-skill","format":"markdown","content":"---\nname: ppt-generation\ndescription: Use this skill when the user requests to generate, create, or make presentations (PPT/PPTX). Creates visually rich slides by generating images for each slide and composing them into a PowerPoint file.\n---\n\n# PPT Generation Skill\n\n## Overview\n\nThis skill generates professional PowerPoint presentations by creating AI-generated images for each slide and composing them into a PPTX file. The workflow includes planning the presentation structure with a consistent visual style, generating slide images sequentially (using the previous slide as a reference for style consistency), and assembling them into a final presentation.\n\n## Core Capabilities\n\n- Plan and structure multi-slide presentations with unified visual style\n- Support multiple presentation styles: Business, Academic, Minimal, Apple Keynote, Creative\n- Generate unique AI images for each slide using image-generation skill\n- Maintain visual consistency by using previous slide as reference image\n- Compose images into a professional PPTX file\n\n## Presentation Styles\n\nChoose one of the following styles when creating the presentation plan:\n\n| Style | Description | Best For |\n|-------|-------------|----------|\n| **glassmorphism** | Frosted glass panels with blur effects, floating translucent cards, vibrant gradient backgrounds, depth through layering | Tech products, AI/SaaS demos, futuristic pitches |\n| **dark-premium** | Rich black backgrounds (#0a0a0a), luminous accent colors, subtle glow effects, luxury brand aesthetic | Premium products, executive presentations, high-end brands |\n| **gradient-modern** | Bold mesh gradients, fluid color transitions, contemporary typography, vibrant yet sophisticated | Startups, creative agencies, brand launches |\n| **neo-brutalist** | Raw bold typography, high contrast, intentional \"ugly\" aesthetic, anti-design as design, Memphis-inspired | Edgy brands, Gen-Z targeting, disruptive startups |\n| **3d-isometric** | Clean isometric illustrations, floating 3D elements, soft shadows, tech-forward aesthetic | Tech explainers, product features, SaaS presentations |\n| **editorial** | Magazine-quality layouts, sophisticated typography hierarchy, dramatic photography, Vogue/Bloomberg aesthetic | Annual reports, luxury brands, thought leadership |\n| **minimal-swiss** | Grid-based precision, Helvetica-inspired typography, bold use of negative space, timeless modernism | Architecture, design firms, premium consulting |\n| **keynote** | Apple-inspired aesthetic with bold typography, dramatic imagery, high contrast, cinematic feel | Keynotes, product reveals, inspirational talks |\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests presentation generation, identify:\n\n- Topic/subject: What is the presentation about\n- Number of slides: How many slides are needed (default: 5-10)\n- **Style**: business / academic / minimal / keynote / creative\n- Aspect ratio: Standard (16:9) or classic (4:3)\n- Content outline: Key points for each slide\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Presentation Plan\n\nCreate a JSON file in `/mnt/user-data/workspace/` with the presentation structure. **Important**: Include the `style` field to define the overall visual consistency.\n\n```json\n{\n \"title\": \"Presentation Title\",\n \"style\": \"keynote\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep black backgrounds, white text, single accent color (blue or orange)\",\n \"typography\": \"Bold sans-serif headlines, clean body text, dramatic size contrast\",\n \"imagery\": \"High-quality photography, full-bleed images, cinematic composition\",\n \"layout\": \"Generous whitespace, centered focus, minimal elements per slide\"\n },\n \"aspect_ratio\": \"16:9\",\n \"slides\": [\n {\n \"slide_number\": 1,\n \"type\": \"title\",\n \"title\": \"Main Title\",\n \"subtitle\": \"Subtitle or tagline\",\n \"visual_description\": \"Detailed description for image generation\"\n },\n {\n \"slide_number\": 2,\n \"type\": \"content\",\n \"title\": \"Slide Title\",\n \"key_points\": [\"Point 1\", \"Point 2\", \"Point 3\"],\n \"visual_description\": \"Detailed description for image generation\"\n }\n ]\n}\n```\n\n### Step 3: Generate Slide Images Sequentially\n\n**IMPORTANT**: Generate slides **strictly one by one, in order**. Do NOT parallelize or batch image generation. Each slide depends on the previous slide's output as a reference image. Generating slides in parallel will break visual consistency and is not allowed.\n\n1. Read the image-generation skill: `/mnt/skills/public/image-generation/SKILL.md`\n\n2. **For the FIRST slide (slide 1)**, create a prompt that establishes the visual style:\n\n```json\n{\n \"prompt\": \"Professional presentation slide. [style_guidelines from plan]. Title: 'Your Title'. [visual_description]. This slide establishes the visual language for the entire presentation.\",\n \"style\": \"[Based on chosen style - e.g., Apple Keynote aesthetic, dramatic lighting, cinematic]\",\n \"composition\": \"Clean layout with clear text hierarchy, [style-specific composition]\",\n \"color_palette\": \"[From style_guidelines]\",\n \"typography\": \"[From style_guidelines]\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-01-prompt.json \\\n --output-file /mnt/user-data/outputs/slide-01.jpg \\\n --aspect-ratio 16:9\n```\n\n3. **For subsequent slides (slide 2+)**, use the PREVIOUS slide as a reference image:\n\n```json\n{\n \"prompt\": \"Professional presentation slide continuing the visual style from the reference image. Maintain the same color palette, typography style, and overall aesthetic. Title: 'Slide Title'. [visual_description]. Keep visual consistency with the reference.\",\n \"style\": \"Match the style of the reference image exactly\",\n \"composition\": \"Similar layout principles as reference, adapted for this content\",\n \"color_palette\": \"Same as reference image\",\n \"consistency_note\": \"This slide must look like it belongs in the same presentation as the reference image\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-02-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-01.jpg \\\n --output-file /mnt/user-data/outputs/slide-02.jpg \\\n --aspect-ratio 16:9\n```\n\n4. **Continue for all remaining slides**, always referencing the previous slide:\n\n```bash\n# Slide 3 references slide 2\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-03-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-02.jpg \\\n --output-file /mnt/user-data/outputs/slide-03.jpg \\\n --aspect-ratio 16:9\n\n# Slide 4 references slide 3\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/slide-04-prompt.json \\\n --reference-images /mnt/user-data/outputs/slide-03.jpg \\\n --output-file /mnt/user-data/outputs/slide-04.jpg \\\n --aspect-ratio 16:9\n```\n\n### Step 4: Compose PPT\n\nAfter all slide images are generated, call the composition script:\n\n```bash\npython /mnt/skills/public/ppt-generation/scripts/generate.py \\\n --plan-file /mnt/user-data/workspace/presentation-plan.json \\\n --slide-images /mnt/user-data/outputs/slide-01.jpg /mnt/user-data/outputs/slide-02.jpg /mnt/user-data/outputs/slide-03.jpg \\\n --output-file /mnt/user-data/outputs/presentation.pptx\n```\n\nParameters:\n\n- `--plan-file`: Absolute path to the presentation plan JSON file (required)\n- `--slide-images`: Absolute paths to slide images in order (required, space-separated)\n- `--output-file`: Absolute path to output PPTX file (required)\n\n[!NOTE]\nDo NOT read the python file, just call it with the parameters.\n\n## Complete Example: Glassmorphism Style (最现代前卫)\n\nUser request: \"Create a presentation about AI product launch\"\n\n### Step 1: Create presentation plan\n\nCreate `/mnt/user-data/workspace/ai-product-plan.json`:\n```json\n{\n \"title\": \"Introducing Nova AI\",\n \"style\": \"glassmorphism\",\n \"style_guidelines\": {\n \"color_palette\": \"Vibrant purple-to-cyan gradient background (#667eea→#00d4ff), frosted glass panels with 15-20% white opacity, electric accents\",\n \"typography\": \"SF Pro Display style, bold 700 weight white titles with subtle text-shadow, clean 400 weight body text, excellent contrast on glass\",\n \"imagery\": \"Abstract 3D glass spheres, floating translucent geometric shapes, soft luminous orbs, depth through layered transparency\",\n \"layout\": \"Centered frosted glass cards with 32px rounded corners, 48-64px padding, floating above gradient, layered depth with soft shadows\",\n \"effects\": \"Backdrop blur 20-40px on glass panels, subtle white border glow, soft colored shadows matching gradient, light refraction effects\",\n \"visual_language\": \"Apple Vision Pro / visionOS aesthetic, premium depth through transparency, futuristic yet approachable, 2024 design trends\"\n },\n \"aspect_ratio\": \"16:9\",\n \"slides\": [\n {\n \"slide_number\": 1,\n \"type\": \"title\",\n \"title\": \"Introducing Nova AI\",\n \"subtitle\": \"Intelligence, Reimagined\",\n \"visual_description\": \"Stunning gradient background flowing from deep purple (#667eea) through magenta to cyan (#00d4ff). Center: large frosted glass panel with strong backdrop blur, containing bold white title 'Introducing Nova AI' and lighter subtitle. Floating 3D glass spheres and abstract shapes around the card creating depth. Soft glow emanating from behind the glass panel. Premium visionOS aesthetic. The glass card has subtle white border (1px rgba 255,255,255,0.3) and soft purple-tinted shadow.\"\n },\n {\n \"slide_number\": 2,\n \"type\": \"content\",\n \"title\": \"Why Nova?\",\n \"key_points\": [\"10x faster processing\", \"Human-like understanding\", \"Enterprise-grade security\"],\n \"visual_description\": \"Same purple-cyan gradient background. Left side: floating frosted glass card with title 'Why Nova?' in bold white, three key points below with subtle glass pill badges. Right side: abstract 3D visualization of neural network as interconnected glass nodes with soft glow. Floating translucent geometric shapes (icosahedrons, tori) adding depth. Consistent glassmorphism aesthetic with previous slide.\"\n },\n {\n \"slide_number\": 3,\n \"type\": \"content\",\n \"title\": \"How It Works\",\n \"key_points\": [\"Natural language input\", \"Multi-modal processing\", \"Instant insights\"],\n \"visual_description\": \"Gradient background consistent with previous slides. Central composition: three stacked frosted glass cards at slight angles showing the workflow steps, connected by soft glowing lines. Each card has an abstract icon. Floating glass orbs and light particles around the composition. Title 'How It Works' in bold white at top. Depth created through card layering and transparency.\"\n },\n {\n \"slide_number\": 4,\n \"type\": \"content\",\n \"title\": \"Built for Scale\",\n \"key_points\": [\"1M+ concurrent users\", \"99.99% uptime\", \"Global infrastructure\"],\n \"visual_description\": \"Same gradient background. Asymmetric layout: right side features large frosted glass panel with metrics displayed in bold typography. Left side: abstract 3D globe made of glass panels and connection lines, representing global scale. Floating data visualization elements as small glass cards with numbers. Soft ambient glow throughout. Premium tech aesthetic.\"\n },\n {\n \"slide_number\": 5,\n \"type\": \"conclusion\",\n \"title\": \"The Future Starts Now\",\n \"subtitle\": \"Join the waitlist\",\n \"visual_description\": \"Dramatic finale slide. Gradient background with slightly increased vibrancy. Central frosted glass card with bold title 'The Future Starts Now' and call-to-action subtitle. Behind the card: burst of soft light rays and floating glass particles creating celebration effect. Multiple layered glass shapes creating depth. The most visually impactful slide while maintaining style consistency.\"\n }\n ]\n}\n```\n\n### Step 2: Read image-generation skill\n\nRead `/mnt/skills/public/image-generation/SKILL.md` to understand how to generate images.\n\n### Step 3: Generate slide images sequentially with reference chaining\n\n**Slide 1 - Title (establishes the visual language):**\n\nCreate `/mnt/user-data/workspace/nova-slide-01.json`:\n```json\n{\n \"prompt\": \"Ultra-premium presentation title slide with glassmorphism design. Background: smooth flowing gradient from deep purple (#667eea) through magenta (#f093fb) to cyan (#00d4ff), soft and vibrant. Center: large frosted glass panel with strong backdrop blur effect, rounded corners 32px, containing bold white sans-serif title 'Introducing Nova AI' (72pt, SF Pro Display style, font-weight 700) with subtle text shadow, subtitle 'Intelligence, Reimagined' below in lighter weight. The glass panel has subtle white border (1px rgba 255,255,255,0.25) and soft purple-tinted drop shadow. Floating around the card: 3D glass spheres with refraction, translucent geometric shapes (icosahedrons, abstract blobs), creating depth and dimension. Soft luminous glow emanating from behind the glass panel. Small floating particles of light. Apple Vision Pro / visionOS UI aesthetic. Professional presentation slide, 16:9 aspect ratio. Hyper-modern, premium tech product launch feel.\",\n \"style\": \"Glassmorphism, visionOS aesthetic, Apple Vision Pro UI style, premium tech, 2024 design trends\",\n \"composition\": \"Centered glass card as focal point, floating 3D elements creating depth at edges, 40% negative space, clear visual hierarchy\",\n \"lighting\": \"Soft ambient glow from gradient, light refraction through glass elements, subtle rim lighting on 3D shapes\",\n \"color_palette\": \"Purple gradient #667eea, magenta #f093fb, cyan #00d4ff, frosted white rgba(255,255,255,0.15), pure white text #ffffff\",\n \"effects\": \"Backdrop blur on glass panels, soft drop shadows with color tint, light refraction, subtle noise texture on glass, floating particles\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/nova-slide-01.json \\\n --output-file /mnt/user-data/outputs/nova-slide-01.jpg \\\n --aspect-ratio 16:9\n```\n\n**Slide 2 - Content (MUST reference slide 1 for consistency):**\n\nCreate `/mnt/user-data/workspace/nova-slide-02.json`:\n```json\n{\n \"prompt\": \"Presentation slide continuing EXACT visual style from reference image. SAME purple-to-cyan gradient background, SAME glassmorphism aesthetic, SAME typography style. Left side: frosted glass card with backdrop blur containing title 'Why Nova?' in bold white (matching reference font style), three feature points as subtle glass pill badges below. Right side: abstract 3D neural network visualization made of interconnected glass nodes with soft cyan glow, floating in space. Floating translucent geometric shapes (matching style from reference) adding depth. The frosted glass has identical treatment: white border, purple-tinted shadow, same blur intensity. CRITICAL: This slide must look like it belongs in the exact same presentation as the reference image - same colors, same glass treatment, same overall aesthetic.\",\n \"style\": \"MATCH REFERENCE EXACTLY - Glassmorphism, visionOS aesthetic, same visual language\",\n \"composition\": \"Asymmetric split: glass card left (40%), 3D visualization right (40%), breathing room between elements\",\n \"color_palette\": \"EXACTLY match reference: purple #667eea, cyan #00d4ff gradient, same frosted white treatment, same text white\",\n \"consistency_note\": \"CRITICAL: Must be visually identical in style to reference image. Same gradient colors, same glass blur intensity, same shadow treatment, same typography weight and style. Viewer should immediately recognize this as the same presentation.\"\n}\n```\n\n```bash\npython /mnt/skills/public/image-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/nova-slide-02.json \\\n --reference-images /mnt/user-data/outputs/nova-slide-01.jpg \\\n --output-file /mnt/user-data/outputs/nova-slide-02.jpg \\\n --aspect-ratio 16:9\n```\n\n**Slides 3-5: Continue the same pattern, each referencing the previous slide**\n\nKey consistency rules for subsequent slides:\n- Always include \"continuing EXACT visual style from reference image\" in prompt\n- Specify \"SAME gradient background\", \"SAME glass treatment\", \"SAME typography\"\n- Include `consistency_note` emphasizing style matching\n- Reference the immediately previous slide image\n\n### Step 4: Compose final PPT\n\n```bash\npython /mnt/skills/public/ppt-generation/scripts/generate.py \\\n --plan-file /mnt/user-data/workspace/nova-plan.json \\\n --slide-images /mnt/user-data/outputs/nova-slide-01.jpg /mnt/user-data/outputs/nova-slide-02.jpg /mnt/user-data/outputs/nova-slide-03.jpg /mnt/user-data/outputs/nova-slide-04.jpg /mnt/user-data/outputs/nova-slide-05.jpg \\\n --output-file /mnt/user-data/outputs/nova-presentation.pptx\n```\n\n## Style-Specific Guidelines\n\n### Glassmorphism Style (推荐 - 最现代前卫)\n```json\n{\n \"style\": \"glassmorphism\",\n \"style_guidelines\": {\n \"color_palette\": \"Vibrant gradient backgrounds (purple #667eea to pink #f093fb, or cyan #4facfe to blue #00f2fe), frosted white panels with 20% opacity, accent colors that pop against the gradient\",\n \"typography\": \"SF Pro Display or Inter font style, bold 600-700 weight titles, clean 400 weight body, white text with subtle drop shadow for readability on glass\",\n \"imagery\": \"Abstract 3D shapes floating in space, soft blurred orbs, geometric primitives with glass material, depth through overlapping translucent layers\",\n \"layout\": \"Floating card panels with backdrop-blur effect, generous padding (48-64px), rounded corners (24-32px radius), layered depth with subtle shadows\",\n \"effects\": \"Frosted glass blur (backdrop-filter: blur 20px), subtle white border (1px rgba 255,255,255,0.2), soft glow behind panels, floating elements with drop shadows\",\n \"visual_language\": \"Premium tech aesthetic like Apple Vision Pro UI, depth through transparency, light refracting through glass surfaces\"\n }\n}\n```\n\n### Dark Premium Style\n```json\n{\n \"style\": \"dark-premium\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep black base (#0a0a0a to #121212), luminous accent color (electric blue #00d4ff, neon purple #bf5af2, or gold #ffd700), subtle gray gradients for depth (#1a1a1a to #0a0a0a)\",\n \"typography\": \"Elegant sans-serif (Neue Haas Grotesk or Suisse Int'l style), dramatic size contrast (72pt+ headlines, 18pt body), letter-spacing -0.02em for headlines, pure white (#ffffff) text\",\n \"imagery\": \"Dramatic studio lighting, rim lights and edge glow, cinematic product shots, abstract light trails, premium material textures (brushed metal, matte surfaces)\",\n \"layout\": \"Generous negative space (60%+), asymmetric balance, content anchored to grid but with breathing room, single focal point per slide\",\n \"effects\": \"Subtle ambient glow behind key elements, light bloom effects, grain texture overlay (2-3% opacity), vignette on edges\",\n \"visual_language\": \"Luxury tech brand aesthetic (Bang & Olufsen, Porsche Design), sophistication through restraint, every element intentional\"\n }\n}\n```\n\n### Gradient Modern Style\n```json\n{\n \"style\": \"gradient-modern\",\n \"style_guidelines\": {\n \"color_palette\": \"Bold mesh gradients (Stripe/Linear style: purple-pink-orange #7c3aed→#ec4899→#f97316, or cool tones: cyan-blue-purple #06b6d4→#3b82f6→#8b5cf6), white or dark text depending on background intensity\",\n \"typography\": \"Modern geometric sans-serif (Satoshi, General Sans, or Clash Display style), variable font weights, oversized bold headlines (80pt+), comfortable body text (20pt)\",\n \"imagery\": \"Abstract fluid shapes, morphing gradients, 3D rendered abstract objects, soft organic forms, floating geometric primitives\",\n \"layout\": \"Dynamic asymmetric compositions, overlapping elements with blend modes, text integrated with gradient flows, full-bleed backgrounds\",\n \"effects\": \"Smooth gradient transitions, subtle noise texture (3-5% for depth), soft shadows with color tint matching gradient, motion blur suggesting movement\",\n \"visual_language\": \"Contemporary SaaS aesthetic (Stripe, Linear, Vercel), energetic yet professional, forward-thinking tech vibes\"\n }\n}\n```\n\n### Neo-Brutalist Style\n```json\n{\n \"style\": \"neo-brutalist\",\n \"style_guidelines\": {\n \"color_palette\": \"High contrast primaries: stark black, pure white, with bold accent (hot pink #ff0080, electric yellow #ffff00, or raw red #ff0000), optional: Memphis-inspired pastels as secondary\",\n \"typography\": \"Ultra-bold condensed type (Impact, Druk, or Bebas Neue style), UPPERCASE headlines, extreme size contrast, intentionally tight or overlapping letter-spacing\",\n \"imagery\": \"Raw unfiltered photography, intentional visual noise, halftone patterns, cut-out collage aesthetic, hand-drawn elements, stickers and stamps\",\n \"layout\": \"Broken grid, overlapping elements, thick black borders (4-8px), visible structure, anti-whitespace (dense but organized chaos)\",\n \"effects\": \"Hard shadows (no blur, offset 8-12px), pixelation accents, scan lines, CRT screen effects, intentional 'mistakes'\",\n \"visual_language\": \"Anti-corporate rebellion, DIY zine aesthetic meets digital, raw authenticity, memorable through boldness\"\n }\n}\n```\n\n### 3D Isometric Style\n```json\n{\n \"style\": \"3d-isometric\",\n \"style_guidelines\": {\n \"color_palette\": \"Soft contemporary palette: muted purples (#8b5cf6), teals (#14b8a6), warm corals (#fb7185), with cream or light gray backgrounds (#fafafa), consistent saturation across elements\",\n \"typography\": \"Friendly geometric sans-serif (Circular, Gilroy, or Quicksand style), medium weight headlines, excellent readability, comfortable 24pt body text\",\n \"imagery\": \"Clean isometric 3D illustrations, consistent 30° isometric angle, soft clay-render aesthetic, floating platforms and devices, cute simplified objects\",\n \"layout\": \"Central isometric scene as hero, text balanced around 3D elements, clear visual hierarchy, comfortable margins (64px+)\",\n \"effects\": \"Soft drop shadows (20px blur, 30% opacity), ambient occlusion on 3D objects, subtle gradients on surfaces, consistent light source (top-left)\",\n \"visual_language\": \"Friendly tech illustration (Slack, Notion, Asana style), approachable complexity, clarity through simplification\"\n }\n}\n```\n\n### Editorial Style\n```json\n{\n \"style\": \"editorial\",\n \"style_guidelines\": {\n \"color_palette\": \"Sophisticated neutrals: off-white (#f5f5f0), charcoal (#2d2d2d), with single accent color (burgundy #7c2d12, forest #14532d, or navy #1e3a5f), occasional full-color photography\",\n \"typography\": \"Refined serif for headlines (Playfair Display, Freight, or Editorial New style), clean sans-serif for body (Söhne, Graphik), dramatic size hierarchy (96pt headlines, 16pt body), generous line-height 1.6\",\n \"imagery\": \"Magazine-quality photography, dramatic crops, full-bleed images, portraits with intentional negative space, editorial lighting (Vogue, Bloomberg Businessweek style)\",\n \"layout\": \"Sophisticated grid system (12-column), intentional asymmetry, pull quotes as design elements, text wrapping around images, elegant margins\",\n \"effects\": \"Minimal effects - let photography and typography shine, subtle image treatments (slight desaturation, film grain), elegant borders and rules\",\n \"visual_language\": \"High-end magazine aesthetic, intellectual sophistication, content elevated through design restraint\"\n }\n}\n```\n\n### Minimal Swiss Style\n```json\n{\n \"style\": \"minimal-swiss\",\n \"style_guidelines\": {\n \"color_palette\": \"Pure white (#ffffff) or off-white (#fafaf9) backgrounds, true black (#000000) text, single bold accent (Swiss red #ff0000, Klein blue #002fa7, or signal yellow #ffcc00)\",\n \"typography\": \"Helvetica Neue or Aktiv Grotesk, strict type scale (12/16/24/48/96), medium weight for body, bold for emphasis only, flush-left ragged-right alignment\",\n \"imagery\": \"Objective photography, geometric shapes, clean iconography, mathematical precision, intentional empty space as compositional element\",\n \"layout\": \"Strict grid adherence (baseline grid visible in spirit), modular compositions, generous whitespace (40%+ of slide), content aligned to invisible grid lines\",\n \"effects\": \"None - purity of form, no shadows, no gradients, no decorative elements, occasional single hairline rules\",\n \"visual_language\": \"International Typographic Style, form follows function, timeless modernism, Dieter Rams-inspired restraint\"\n }\n}\n```\n\n### Keynote Style (Apple风格)\n```json\n{\n \"style\": \"keynote\",\n \"style_guidelines\": {\n \"color_palette\": \"Deep blacks (#000000 to #1d1d1f), pure white text, signature blue (#0071e3) or gradient accents (purple-pink for creative, blue-teal for tech)\",\n \"typography\": \"San Francisco Pro Display, extreme weight contrast (bold 80pt+ titles, light 24pt body), negative letter-spacing on headlines (-0.03em), optical alignment\",\n \"imagery\": \"Cinematic photography, shallow depth of field, dramatic lighting (rim lights, spot lighting), product hero shots with reflections, full-bleed imagery\",\n \"layout\": \"Maximum negative space, single powerful image or statement per slide, content centered or dramatically offset, no clutter\",\n \"effects\": \"Subtle gradient overlays, light bloom and glow on key elements, reflection on surfaces, smooth gradient backgrounds\",\n \"visual_language\": \"Apple WWDC keynote aesthetic, confidence through simplicity, every pixel considered, theatrical presentation\"\n }\n}\n```\n\n## Output Handling\n\nAfter generation:\n\n- The PPTX file is saved in `/mnt/user-data/outputs/`\n- Share the generated presentation with user using `present_files` tool\n- Also share the individual slide images if requested\n- Provide brief description of the presentation\n- Offer to iterate or regenerate specific slides if needed\n\n## Notes\n\n### Critical Quality Guidelines\n\n**Prompt Engineering for Professional Results:**\n- Always use English for image prompts regardless of user's language\n- Be EXTREMELY specific about visual details - vague prompts produce generic results\n- Include exact hex color codes (e.g., #667eea not \"purple\")\n- Specify typography details: font weight (400/700), size hierarchy, letter-spacing\n- Describe effects precisely: \"backdrop blur 20px\", \"drop shadow 8px blur 30% opacity\"\n- Reference real design systems: \"visionOS aesthetic\", \"Stripe website style\", \"Bloomberg Businessweek layout\"\n\n**Visual Consistency (Most Important):**\n- **Generate slides sequentially** - each slide MUST reference the previous one\n- The first slide is critical - it establishes the visual language for the entire presentation\n- In every subsequent slide prompt, explicitly state: \"continuing EXACT visual style from reference image\"\n- Use SAME, EXACT, MATCH keywords emphatically in prompts to enforce consistency\n- Include a `consistency_note` field in every JSON prompt after slide 1\n- If a slide looks inconsistent, regenerate it with STRONGER reference emphasis\n\n**Design Principles for Modern Aesthetics:**\n- Embrace negative space - 40-60% empty space creates premium feel\n- Limit elements per slide - one focal point, one message\n- Use depth through layering (shadows, transparency, z-depth)\n- Typography hierarchy: massive headlines (72pt+), comfortable body (18-24pt)\n- Color restraint: one primary palette, 1-2 accent colors maximum\n\n**Common Mistakes to Avoid:**\n- ❌ Generic prompts like \"professional slide\" - be specific\n- ❌ Too many elements/text per slide - cluttered = unprofessional\n- ❌ Inconsistent colors between slides - always reference previous slide\n- ❌ Skipping the reference image parameter - this breaks visual consistency\n- ❌ Using different design styles within one presentation\n- ❌ Generating slides in parallel - slides MUST be generated one at a time in order (slide 1 → 2 → 3 ...), never concurrently\n\n**Recommended Styles for Different Contexts:**\n- Tech product launch → `glassmorphism` or `gradient-modern`\n- Luxury/premium brand → `dark-premium` or `editorial`\n- Startup pitch → `gradient-modern` or `minimal-swiss`\n- Executive presentation → `dark-premium` or `keynote`\n- Creative agency → `neo-brutalist` or `gradient-modern`\n- Data/analytics → `minimal-swiss` or `3d-isometric`\n","frontmatter":{"name":"ppt-generation","description":"Use this skill when the user requests to generate, create, or make presentations (PPT/PPTX). Creates visually rich slides by generating images for each slide and composing them into a PowerPoint file."},"isInternal":false,"tokens":6534,"sizeBytes":28359},{"name":"output-patterns.md","path":"skills/public/skill-creator/references/output-patterns.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/output-patterns.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/skill-creator/references/output-patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/output-patterns.md)","tokens":300,"sizeBytes":233},{"name":"schemas.md","path":"skills/public/skill-creator/references/schemas.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/schemas.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/skill-creator/references/schemas.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/schemas.md)","tokens":300,"sizeBytes":217},{"name":"workflows.md","path":"skills/public/skill-creator/references/workflows.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/workflows.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `skills/public/skill-creator/references/workflows.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/references/workflows.md)","tokens":300,"sizeBytes":221},{"name":"SKILL.md","path":"skills/public/skill-creator/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/SKILL.md","title":"skill-creator","category":"anthropic-skill","format":"markdown","content":"---\nname: skill-creator\ndescription: Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.\n---\n\n# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nAt a high level, the process of creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft of the skill\n- Create a few test prompts and run claude-with-access-to-the-skill on them\n- Help the user evaluate the results both qualitatively and quantitatively\n - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)\n - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics\n- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like \"I want to make a skill for X\". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.\n\nOn the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.\n\nOf course, you should always be flexible and if the user is like \"I don't need to run a bunch of evaluations, just vibe with me\", you can do that instead.\n\nThen after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.\n\nCool? Cool.\n\n---\n\n## DeerFlow Environment (⚠️ READ THIS FIRST)\n\nIf you are running inside a **DeerFlow** sandboxed agent environment (you have access to the `skill_manage` tool), you MUST follow these rules for all skill file operations. These override the generic file-writing and packaging instructions below.\n\n### Why this matters\n\nIn DeerFlow, the sandbox filesystem is isolated. Files written with `write_file` land in `/mnt/user-data/outputs/`, which is a **per-thread output directory** — new chats cannot see files there. Skills must be persisted through the dedicated `skill_manage` tool so they are stored in the per-user skill directory and immediately visible to all future chats.\n\n### Use `skill_manage` for all skill file operations\n\n| Operation | skill_manage action | Example |\n|-----------|---------------------|---------|\n| Create a new skill | `action=\"create\"` | `skill_manage(action=\"create\", name=\"my-skill\", content=\"---\\nname: my-skill\\n---\\n...\")` |\n| Replace entire SKILL.md | `action=\"edit\"` | `skill_manage(action=\"edit\", name=\"my-skill\", content=\"updated SKILL.md\")` |\n| Partial edit (find & replace) | `action=\"patch\"` | `skill_manage(action=\"patch\", name=\"my-skill\", find=\"old text\", replace=\"new text\")` |\n| Delete a skill | `action=\"delete\"` | `skill_manage(action=\"delete\", name=\"my-skill\")` |\n| Add a supporting file | `action=\"write_file\"` | `skill_manage(action=\"write_file\", name=\"my-skill\", path=\"scripts/helper.py\", content=\"...\")` |\n| Remove a supporting file | `action=\"remove_file\"` | `skill_manage(action=\"remove_file\", name=\"my-skill\", path=\"scripts/helper.py\")` |\n\n### Key rules\n\n1. **NEVER use sandbox `write_file` to create or modify skill files** (SKILL.md, scripts/, references/, assets/). These would land in `/mnt/user-data/outputs/` and be invisible to future chats. Always use `skill_manage` instead.\n\n2. **Skip the `package_skill.py` step**. In DeerFlow, `skill_manage` already persists the skill to the correct per-user directory. No `.skill` packaging or manual install is needed. The skill is immediately available in all new chats.\n\n3. **Skip the `present_files` step for skills**. Skills are NOT deliverables — they are persisted via `skill_manage` and auto-loaded by the skill system. Only use `present_files` for non-skill outputs (eval reports, benchmarks, etc.).\n\n4. **Eval workspace files are OK in sandbox**. Test prompts, benchmark data, eval viewer HTML, grading results, etc. are NOT skill files — you can write these to `/mnt/user-data/outputs/` or `/mnt/user-data/workspace/` using sandbox `write_file` as usual.\n\n5. **To read an existing skill's SKILL.md**, use `read_file(\"/mnt/skills/custom//SKILL.md\")` in the sandbox (it maps to the per-user skill directory).\n\n6. **Updating an existing skill**: use `skill_manage(action=\"edit\")` or `skill_manage(action=\"patch\")`. Do NOT copy to `/tmp/` first — `skill_manage` handles the per-user storage directly.\n\n### Workflow in DeerFlow\n\nThe core loop is the same, but the persistence mechanism changes:\n\n1. Capture intent → interview → draft SKILL.md content\n2. **Call `skill_manage(action=\"create\", name=, content=)`** to persist the skill\n3. Run test cases (eval workspace files use sandbox `write_file`)\n4. Evaluate results, gather feedback\n5. **Call `skill_manage(action=\"edit\")` or `skill_manage(action=\"patch\")`** to improve the skill\n6. Repeat until satisfied\n7. **Done — no packaging needed.** The skill is already persisted and visible to all future chats.\n\n---\n\n## Communicating with the user\n\nThe skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google \"how to install npm\". On the other hand, the bulk of users are probably fairly computer-literate.\n\nSo please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:\n\n- \"evaluation\" and \"benchmark\" are borderline, but OK\n- for \"JSON\" and \"assertion\" you want to see serious cues from the user that they know what those things are before using them without explaining them\n\nIt's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.\n\n---\n\n## Creating a skill\n\n### Capture Intent\n\nStart by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say \"turn this into a skill\"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.\n\n1. What should this skill enable Claude to do?\n2. When should this skill trigger? (what user phrases/contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.\n\n### Interview and Research\n\nProactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.\n\nCheck available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.\n\n### Write the SKILL.md\n\nBased on the user interview, fill in these components:\n\n- **name**: Skill identifier\n- **description**: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All \"when to use\" info goes here, not in the body. Note: currently Claude has a tendency to \"undertrigger\" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit \"pushy\". So for instance, instead of \"How to build a simple fast dashboard to display internal Anthropic data.\", you might write \"How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **compatibility**: Required tools, dependencies (optional, rarely needed)\n- **the rest of the skill :)**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name/\n├── SKILL.md (required)\n│ ├── YAML frontmatter (name, description required)\n│ └── Markdown instructions\n└── Bundled Resources (optional)\n ├── scripts/ - Executable code for deterministic/repetitive tasks\n ├── references/ - Docs loaded into context as needed\n └── assets/ - Files used in output (templates, icons, fonts)\n```\n\n#### Progressive Disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description) - Always in context (~100 words)\n2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)\n3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)\n\nThese word counts are approximate and you can feel free to go longer if needed.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.\n- Reference files clearly from SKILL.md with guidance on when to read them\n- For large reference files (>300 lines), include a table of contents\n\n**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:\n```\ncloud-deploy/\n├── SKILL.md (workflow + selection)\n└── references/\n ├── aws.md\n ├── gcp.md\n └── azure.md\n```\nClaude reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nThis goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a \"roleplay as an XYZ\" are OK though.\n\n#### Writing Patterns\n\nPrefer using the imperative form in instructions.\n\n**Defining output formats** - You can do it like this:\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** - It's useful to include examples. You can format them like this (but if \"Input\" and \"Output\" are in the examples you might want to deviate a little):\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n### Writing Style\n\nTry to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.\n\n### Test Cases\n\nAfter writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.\n\n```json\n{\n \"skill_name\": \"example-skill\",\n \"evals\": [\n {\n \"id\": 1,\n \"prompt\": \"User's task prompt\",\n \"expected_output\": \"Description of expected result\",\n \"files\": []\n }\n ]\n}\n```\n\nSee `references/schemas.md` for the full schema (including the `assertions` field, which you'll add later).\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill.\n\nPut results in `-workspace/` as a sibling to the skill directory. Within the workspace, organize results by iteration (`iteration-1/`, `iteration-2/`, etc.) and within that, each test case gets a directory (`eval-0/`, `eval-1/`, etc.). Don't create all of this upfront — just create directories as you go.\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: \n- Task: \n- Input files: \n- Save outputs to: /iteration-/eval-/with_skill/outputs/\n- Outputs to save: \n```\n\n**Baseline run** (same prompt, but the baseline depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, save to `without_skill/outputs/`.\n- **Improving an existing skill**: the old version. Before editing, snapshot the skill (`cp -r /skill-snapshot/`), then point the baseline subagent at the snapshot. Save to `old_skill/outputs/`.\n\nWrite an `eval_metadata.json` for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just \"eval-0\". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.\n\n```json\n{\n \"eval_id\": 0,\n \"eval_name\": \"descriptive-name-here\",\n \"prompt\": \"The user's task prompt\",\n \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in `evals/evals.json`, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.\n\nUpdate the `eval_metadata.json` files and `evals/evals.json` with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, you receive a notification containing `total_tokens` and `duration_ms`. Save this data immediately to `timing.json` in the run directory:\n\n```json\n{\n \"total_tokens\": 84852,\n \"duration_ms\": 23332,\n \"total_duration_seconds\": 23.3\n}\n```\n\nThis is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — spawn a grader subagent (or grade inline) that reads `agents/grader.md` and evaluates each assertion against the outputs. Save results to `grading.json` in each run directory. The grading.json expectations array must use the fields `text`, `passed`, and `evidence` (not `name`/`met`/`details` or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.\n\n2. **Aggregate into benchmark** — run the aggregation script from the skill-creator directory:\n ```bash\n python -m scripts.aggregate_benchmark /iteration-N --skill-name \n ```\n This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see `references/schemas.md` for the exact schema the viewer expects.\nPut each with_skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregate stats might hide. See `agents/analyzer.md` (the \"Analyzing Benchmark Results\" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n ```bash\n nohup python /eval-viewer/generate_review.py \\\n /iteration-N \\\n --skill-name \"my-skill\" \\\n --benchmark /iteration-N/benchmark.json \\\n > /dev/null 2>&1 &\n VIEWER_PID=$!\n ```\n For iteration 2+, also pass `--previous-workspace /iteration-`.\n\n **Cowork / headless environments:** If `webbrowser.open()` is not available or the environment has no display, use `--static ` to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a `feedback.json` file when the user clicks \"Submit All Reviews\". After download, copy `feedback.json` into the workspace directory for the next iteration to pick up.\n\nNote: please use generate_review.py to create the viewer; there's no need to write custom HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): collapsed section showing last iteration's output\n- **Formal Grades** (if grading was run): collapsed section showing assertion pass/fail\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, shown below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.\n\nNavigation is via prev/next buttons or arrow keys. When done, they click \"Submit All Reviews\" which saves all feedback to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user tells you they're done, read `feedback.json`:\n\n```json\n{\n \"reviews\": [\n {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n ],\n \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.\n\nKill the viewer server when you're done with it:\n\n```bash\nkill $VIEWER_PID 2>/dev/null\n```\n\n---\n\n## Improving the skill\n\nThis is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.\n\n3. **Explain the why.** Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.\n\n4. **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts/`, and tell the skill to use it. This saves every future invocation from reinventing the wheel.\n\nThis task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply your improvements to the skill\n2. Rerun all test cases into a new `iteration-/` directory, including baseline runs. If you're creating a new skill, the baseline is always `without_skill` (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and tell you they're done\n5. Read the new feedback, improve again, repeat\n\nKeep going until:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n---\n\n## Advanced: Blind comparison\n\nFor situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks \"is the new version actually better?\"), there's a blind comparison system. Read `agents/comparator.md` and `agents/analyzer.md` for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.\n\nThis is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n---\n\n## Description Optimization\n\nThe description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n {\"query\": \"the user prompt\", \"should_trigger\": true},\n {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nFor the **should-trigger** queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.\n\nFor the **should-not-trigger** queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.\n\nThe key thing to avoid: don't make should-not-trigger queries obviously irrelevant. \"Write a fibonacci function\" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.\n\n### Step 2: Review with user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read the template from `assets/eval_review.html`\n2. Replace the placeholders:\n - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no quotes around it — it's a JS variable assignment)\n - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file (e.g., `/tmp/eval_review_.html`) and open it: `open /tmp/eval_review_.html`\n4. The user can edit queries, toggle should-trigger, add/remove entries, then click \"Export Eval Set\"\n5. The file downloads to `~/Downloads/eval_set.json` — check the Downloads folder for the most recent version in case there are multiple (e.g., `eval_set (1).json`)\n\nThis step matters — bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take some time — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run in the background:\n\n```bash\npython -m scripts.run_loop \\\n --eval-set \\\n --skill-path \\\n --model \\\n --max-iterations 5 \\\n --verbose\n```\n\nUse the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.\n\nWhile it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.\n\nThis handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with `best_description` — selected by test score rather than train score to avoid overfitting.\n\n### How skill triggering works\n\nUnderstanding the triggering mechanism helps design better eval queries. Skills appear in Claude's `available_skills` list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like \"read this PDF\" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.\n\nThis means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like \"read file X\" are poor test cases — they won't trigger skills regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.\n\n---\n\n### Package and Present (only if `present_files` tool is available)\n\nCheck whether you have access to the `present_files` tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:\n\n```bash\npython -m scripts.package_skill \n```\n\nAfter packaging, direct the user to the resulting `.skill` file path so they can install it.\n\n---\n\n## Claude.ai-specific instructions\n\nIn Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:\n\n**Running test cases**: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.\n\n**Reviewing results**: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: \"How does this look? Anything you'd change?\"\n\n**Benchmarking**: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.\n\n**The iteration loop**: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.\n\n**Description optimization**: This section requires the `claude` CLI tool (specifically `claude -p`) which is only available in Claude Code. Skip it if you're on Claude.ai.\n\n**Blind comparison**: Requires subagents. Skip it.\n\n**Packaging**: The `package_skill.py` script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting `.skill` file.\n\n**Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. In this case:\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field -- use them unchanged. E.g., if the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`).\n- **Copy to a writeable location before editing.** The installed skill path may be read-only. Copy to `/tmp/skill-name/`, edit there, and package from the copy.\n- **If packaging manually, stage in `/tmp/` first**, then copy to the output directory -- direct writes may fail due to permissions.\n\n---\n\n## Cowork-Specific Instructions\n\nIf you're in Cowork, the main things to know are:\n\n- You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)\n- You don't have a browser or display, so when generating the eval viewer, use `--static ` to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.\n- For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using `generate_review.py` (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER *BEFORE* evaluating inputs yourself. You want to get them in front of the human ASAP!\n- Feedback works differently: since there's no running server, the viewer's \"Submit All Reviews\" button will download `feedback.json` as a file. You can then read it from there (you may have to request access first).\n- Packaging works — `package_skill.py` just needs Python and a filesystem.\n- Description optimization (`run_loop.py` / `run_eval.py`) should work in Cowork just fine since it uses `claude -p` via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.\n- **Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.\n\n---\n\n## Reference files\n\nThe agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.\n\n- `agents/grader.md` — How to evaluate assertions against outputs\n- `agents/comparator.md` — How to do blind A/B comparison between two outputs\n- `agents/analyzer.md` — How to analyze why one version beat another\n\nThe references/ directory has additional documentation:\n- `references/schemas.md` — JSON structures for evals.json, grading.json, etc.\n\n---\n\nRepeating one more time the core loop here for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill\n- Run claude-with-access-to-the-skill on test prompts\n- With the user, evaluate the outputs:\n - Create benchmark.json and run `eval-viewer/generate_review.py` to help the user review them\n - Run quantitative evals\n- Repeat until you and the user are satisfied\n- Package the final skill and return it to the user.\n\nPlease add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put \"Create evals JSON and run `eval-viewer/generate_review.py` so human can review test cases\" in your TodoList to make sure it happens.\n\nGood luck!\n","frontmatter":{"name":"skill-creator","description":"Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy."},"isInternal":false,"tokens":8171,"sizeBytes":36683},{"name":"SKILL.md","path":"skills/public/surprise-me/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/surprise-me/SKILL.md","title":"surprise-me","category":"anthropic-skill","format":"markdown","content":"---\nname: surprise-me\ndescription: Create a delightful, unexpected \"wow\" experience for the user by dynamically discovering and creatively combining other enabled skills. Triggers when the user says \"surprise me\" or any request expressing a desire for an unexpected creative showcase. Also triggers when the user is bored, wants inspiration, or asks for \"something interesting\".\n---\n\n# Surprise Me\n\nDeliver an unexpected, delightful experience by dynamically discovering available skills and combining them creatively.\n\n## Workflow\n\n### Step 1: Discover Available Skills\n\nRead all the skills listed in the .\n\n### Step 2: Plan the Surprise\n\nSelect **1 to 3** skills and design a creative mashup. The goal is a single cohesive deliverable, not separate demos.\n\n**Creative combination principles:**\n- Juxtapose skills in unexpected ways (e.g., a presentation about algorithmic art, a research report turned into a slide deck, a styled doc with canvas-designed illustrations)\n- Incorporate the user's known interests/context from memory if available\n- Prioritize visual impact and emotional delight over information density\n- The output should feel like a gift — polished, surprising, and fun\n\n**Theme ideas (pick or remix):**\n- Something tied to today's date, season, or trending news\n- A mini creative project the user never asked for but would love\n- A playful \"what if\" concept\n- An aesthetic artifact combining data + design\n- A fun interactive HTML/React experience\n\n### Step 3: Fallback — No Other Skills Available\n\nIf no other skills are discovered (only surprise-me exists), use one of these fallbacks:\n\n1. **News-based surprise**: Search today's news for a fascinating story, then create a beautifully designed HTML artifact presenting it in a visually striking way\n2. **Interactive HTML experience**: Build a creative single-page web experience — generative art, a mini-game, a visual poem, an animated infographic, or an interactive story\n3. **Personalized artifact**: Use known user context to create something personal and delightful\n\n### Step 4: Execute\n\n1. Read the full SKILL.md body of each selected skill\n2. Follow each skill's instructions for technical execution\n3. Combine outputs into one cohesive deliverable\n4. Present the result with minimal preamble — let the work speak for itself\n\n### Step 5: Reveal\n\nPresent the surprise with minimal spoilers. A short teaser line, then the artifact.\n\n- **Good reveal:** \"I made you something ✨\" + [the artifact]\n- **Bad reveal:** \"I decided to combine the pptx skill with the canvas-design skill to create a presentation about...\" (kills the surprise)\n","frontmatter":{"name":"surprise-me","description":"Create a delightful, unexpected \"wow\" experience for the user by dynamically discovering and creatively combining other enabled skills. Triggers when the user says \"surprise me\" or any request expressing a desire for an unexpected creative showcase. Also triggers when the user is bored, wants inspiration, or asks for \"something interesting\"."},"isInternal":false,"tokens":548,"sizeBytes":2640},{"name":"evals.json","path":"skills/public/systematic-literature-review/evals/evals.json","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/evals.json","title":"Evals Skill","category":"anthropic-skill","format":"json","content":"# Evals Skill\n\nPath: `skills/public/systematic-literature-review/evals/evals.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/evals.json)","tokens":300,"sizeBytes":232},{"name":"trigger_eval_set.json","path":"skills/public/systematic-literature-review/evals/trigger_eval_set.json","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/trigger_eval_set.json","title":"Evals Skill","category":"anthropic-skill","format":"json","content":"# Evals Skill\n\nPath: `skills/public/systematic-literature-review/evals/trigger_eval_set.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/evals/trigger_eval_set.json)","tokens":300,"sizeBytes":254},{"name":"SKILL.md","path":"skills/public/systematic-literature-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/SKILL.md","title":"systematic-literature-review","category":"anthropic-skill","format":"markdown","content":"---\nname: systematic-literature-review\ndescription: Use this skill when the user wants a systematic literature review, survey, or synthesis across multiple academic papers on a topic. Also covers annotated bibliographies and cross-paper comparisons. Searches arXiv and outputs reports in APA, IEEE, or BibTeX format. Not for single-paper tasks — use academic-paper-review for reviewing one paper.\n---\n\n# Systematic Literature Review Skill\n\n## Overview\n\nThis skill produces a structured **systematic literature review (SLR)** across multiple academic papers on a research topic. Given a topic query, it searches arXiv, extracts structured metadata (research question, methodology, key findings, limitations) from each paper in parallel, synthesizes themes across the full set, and emits a final report with consistent citations.\n\n**Distinct from `academic-paper-review`:** that skill does deep peer review of a single paper. This skill does breadth-first synthesis across many papers. If the user hands you one paper URL and asks \"review this paper\", route to `academic-paper-review` instead.\n\n## When to Use This Skill\n\nUse this skill when the user wants any of the following:\n\n- A literature survey on a topic (\"survey transformer attention variants\", \"review the literature on diffusion models\")\n- A synthesis across multiple papers (\"what do recent papers say about X\", \"compare methodologies across papers on Y\")\n- A systematic review with consistent citation format (\"do an SLR on Z in APA format\")\n- An annotated bibliography on a topic\n- An overview of research trends in a field over a time window\n\nDo **not** use this skill when:\n\n- The user provides exactly one paper and asks to review it (use `academic-paper-review`)\n- The user asks a factual question that does not require synthesizing multiple sources (answer directly)\n- The user wants general web research without academic rigor (use standard web search)\n\n## Workflow\n\nThe workflow has five phases. Follow them in order.\n\n### Phase 1: Plan\n\nBefore doing any retrieval, confirm the following with the user. If any of these are unclear, ask **one** clarifying question that covers the missing pieces. Do not ask one question at a time.\n\n- **Topic**: the research area in plain English (e.g. \"transformer attention variants\").\n- **Scope**: how many papers (default 20, hard upper bound 50), optional time window (e.g. \"last 2 years\"), optional arXiv category (e.g. `cs.CL`, `cs.CV`).\n- **Citation format**: APA, IEEE, or BibTeX (default APA if the user does not specify and does not seem to be writing for a specific venue).\n- **Output location**: where to save the final report (default `/mnt/user-data/outputs/`).\n\nIf the user says \"50+ papers\", politely cap it at 50 and explain that synthesis quality degrades quickly past that — for larger surveys they should split by sub-topic.\n\n### Phase 2: Search arXiv\n\nCall the bundled search script. Do **not** try to scrape arXiv by other means and do **not** write your own HTTP client — this script handles URL encoding, Atom XML parsing, and id normalization correctly.\n\n```bash\npython /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \\\n \"\" \\\n --max-results \\\n [--category ] \\\n [--sort-by relevance] \\\n [--start-date YYYY-MM-DD] \\\n [--end-date YYYY-MM-DD]\n```\n\n**IMPORTANT — extract 2-3 core keywords before searching.** Do not pass the user's full topic description as the query. Before calling the script, mentally reduce the topic to its 2-3 most essential terms. Drop qualifiers like \"in computer vision\", \"for NLP\", \"variants\", \"recent\" — those belong in `--category` or `--start-date`, not in the query string.\n\n**Query phrasing — keep it short.** The script wraps multi-word queries in double quotes for phrase matching on arXiv. This means:\n\n- `\"diffusion models\"` → searches for the exact phrase → good, returns relevant papers.\n- `\"diffusion models in computer vision\"` → searches for that exact 5-word phrase → **too specific, likely returns 0 results** because few papers contain that exact string.\n\nUse **2-3 core keywords** as the query, and use `--category` to narrow the field instead of stuffing field names into the query. Examples:\n\n| User says | Good query | Bad query |\n|---|---|---|\n| \"diffusion models in computer vision\" | `\"diffusion models\" --category cs.CV` | `\"diffusion models in computer vision\"` |\n| \"transformer attention variants\" | `\"transformer attention\"` | `\"transformer attention variants in NLP\"` |\n| \"graph neural networks for molecules\" | `\"graph neural networks\" --category cs.LG` | `\"graph neural networks for molecular property prediction\"` |\n\nThe script prints a JSON array to stdout. Each paper has: `id`, `title`, `authors`, `abstract`, `published`, `updated`, `categories`, `pdf_url`, `abs_url`.\n\n**Sort strategy**:\n\n- **Always use `relevance` sorting** — arXiv's BM25-style scoring ensures results are actually about the user's topic. `submittedDate` sorting returns the most recently submitted papers in the category regardless of topic relevance, which produces mostly off-topic results.\n- When the user asks for \"recent\" papers or gives a time window, use `--sort-by relevance` **combined with `--start-date`** to constrain the time range while keeping results on-topic. For example, \"recent diffusion model papers\" → `--sort-by relevance --start-date 2024-01-01`, not `--sort-by submittedDate`.\n- `submittedDate` sorting is only appropriate when the user explicitly asks for chronological order (e.g. \"show me papers in the order they were published\"). This is rare.\n- `lastUpdatedDate` is rarely useful; ignore it unless the user asks.\n\n**Run the search exactly once.** Do not retry with modified queries if the results seem imperfect — arXiv's relevance ranking is what it is. Retrying with different query phrasings wastes tool calls and risks hitting the recursion limit. If the results are genuinely empty (0 papers), tell the user and suggest they broaden their topic or remove the category filter.\n\n**If the script returns fewer papers than requested**, that is the real size of the arXiv result set for the query. Do not pad the list — report the actual count to the user and proceed.\n\n**If the script fails** (network error, non-200 from arXiv), tell the user which error and stop. Do not try to fabricate paper metadata.\n\n**Do not save the search results to a file** — the JSON stays in your context for Phase 3. The only file saved during the entire workflow is the final report in Phase 5.\n\n### Phase 3: Extract metadata in parallel\n\n**You MUST delegate extraction to subagents via the `task` tool — do not extract metadata yourself.** This is non-negotiable. Specifically, do NOT do any of the following:\n\n- ❌ Write `python -c \"papers = [...]\"` or any Python/bash script to process papers\n- ❌ Extract metadata inline in your own context by reading abstracts one by one\n- ❌ Use any tool other than `task` for this phase\n\nInstead, you MUST call the `task` tool to spawn subagents. The reason: extracting 10-50 papers in your own context consumes too many tokens and degrades synthesis quality in Phase 4. Each subagent runs in an isolated context with only its batch of papers, producing cleaner extractions.\n\nSplit papers into batches of ~5, then for each batch, call the `task` tool with `subagent_type: \"general-purpose\"`. Each subagent receives the paper abstracts as text and returns structured JSON.\n\n**Concurrency limit: at most 3 subagents per turn.** The DeerFlow runtime enforces `MAX_CONCURRENT_SUBAGENTS = 3` and will silently drop any extra dispatches in the same turn — the LLM will not be told this happened, so strictly follow the round strategy below.\n\n**Round strategy — use this decision table, do not compute the split yourself**:\n\n| Paper count | Batches of ~5 papers | Rounds | Per-round subagent count |\n|---|---|---|---|\n| 1–5 | 1 batch | 1 round | 1 subagent |\n| 6–10 | 2 batches | 1 round | 2 subagents |\n| 11–15 | 3 batches | 1 round | 3 subagents |\n| 16–20 | 4 batches | 2 rounds | 3 + 1 |\n| 21–25 | 5 batches | 2 rounds | 3 + 2 |\n| 26–30 | 6 batches | 2 rounds | 3 + 3 |\n| 31–35 | 7 batches | 3 rounds | 3 + 3 + 1 |\n| 36–40 | 8 batches | 3 rounds | 3 + 3 + 2 |\n| 41–45 | 9 batches | 3 rounds | 3 + 3 + 3 |\n| 46–50 | 10 batches | 4 rounds | 3 + 3 + 3 + 1 |\n\n**Never dispatch more than 3 subagents in the same turn.** When a row says \"2 rounds (3 + 1)\", that means: first turn dispatches 3 subagents in parallel, wait for all 3 to complete, then second turn dispatches 1 subagent. Rounds are strictly sequential at the main-agent level.\n\nIf the paper count lands between rows (e.g. 23 papers), round up to the next row's layout but only dispatch as many batches as you actually need — the decision table gives you the shape, not a rigid prescription.\n\n**Do the batching at the main-agent level**: you already have every paper's abstract from Phase 2, so each subagent receives pure text input. Subagents should not need to access the network or the sandbox — their only job is to read text and return JSON. Do not ask subagents to re-run `arxiv_search.py`; that would waste tokens and risk rate-limiting.\n\n**What each subagent receives**, as a structured prompt:\n\n```\nExecute this task: extract structured metadata and key findings from the\nfollowing arXiv papers.\n\nPapers:\n[Paper 1]\narxiv_id: 1706.03762\ntitle: Attention Is All You Need\nauthors: Ashish Vaswani, Noam Shazeer, ...\npublished: 2017-06-12\nabstract: \n\n[Paper 2]\narxiv_id: ...\n...\n\nFor each paper, return a JSON object with these fields:\n- arxiv_id (string)\n- title (string)\n- authors (list of strings)\n- published_date (string, YYYY-MM-DD)\n- research_question (1 sentence, what problem the paper tackles)\n- methodology (1-2 sentences, how they tackle it)\n- key_findings (3-5 bullet points, what they actually found)\n- limitations (1-2 sentences, what they acknowledge or what is obviously missing)\n\nReturn the result as a JSON array, one object per paper, in the same\norder as the input. Do not include any text outside the JSON — no\npreamble, no markdown fences, just the array.\n```\n\n**Parsing subagent results**: the task tool returns strings with a fixed prefix like `Task Succeeded. Result: [...JSON...]`. Strip the `Task Succeeded. Result: ` prefix (or `Task failed.` / `Task timed out.` prefixes) before trying to parse JSON. If a batch fails or returns unparseable JSON, log it, note which papers were affected, and continue with the remaining batches — do not fail the whole synthesis on one bad batch.\n\nAfter all rounds complete, flatten the per-batch arrays into a single list of paper metadata objects, preserving order.\n\n### Phase 4: Synthesize and format\n\nNow produce the final SLR report. Two things happen here: cross-paper synthesis (thematic analysis) and citation formatting.\n\n**Cross-paper synthesis**: the report must do more than list papers. At minimum, identify:\n\n- **Themes**: 3-6 recurring research directions, approaches, or problem framings across the set.\n- **Convergences**: findings that multiple papers agree on.\n- **Disagreements**: where papers reach different conclusions or use incompatible methodologies.\n- **Gaps**: what the collective literature does not yet address (often stated explicitly in the \"limitations\" fields).\n\nIf the paper set is too small or too heterogeneous to support thematic synthesis (e.g. 5 papers on wildly different sub-topics), say so explicitly in the report — do not force themes that are not there.\n\n**Citation formatting**: the exact format depends on user preference. Read **only** the template file that matches the user's requested format, not all three:\n\n- [templates/apa.md](templates/apa.md) — APA 7th edition. Default for social sciences and most CS journals. Use when the user requests APA or does not specify a format.\n- [templates/ieee.md](templates/ieee.md) — IEEE numeric citations. Use when the user targets an IEEE conference or journal, or explicitly asks for IEEE.\n- [templates/bibtex.md](templates/bibtex.md) — BibTeX entries. Use when the user mentions BibTeX, LaTeX, or wants machine-readable references. **Important**: arXiv papers are cited as `@misc`, not `@article` — the BibTeX template covers this explicitly.\n\nEach template contains both the citation rules and a full report structure (executive summary, themes, per-paper annotations, references, methodology section). Follow the template's structure verbatim for the report body, then fill in content from your Phase 3 metadata.\n\n### Phase 5: Save and present\n\nSave the full report to `/mnt/user-data/outputs/slr--.md` where `` is a lowercased hyphenated version of the topic (e.g. `transformer-attention`). Then call the `present_files` tool with that path so the user can download it.\n\n**In the chat message**, show a short preview so the user immediately sees value without opening the file:\n\n1. **Executive summary** — the 3–5 sentence paragraph from the top of the report, verbatim.\n2. **Themes list** — bullet list of the themes you identified in Phase 4 synthesis (just the theme names + one-line gloss, not the full theme sections).\n3. **Paper count + a pointer to the file** — e.g. \"Full report with 20 papers, per-paper annotations, and formatted references saved to `slr-transformer-attention-20260409.md`.\"\n\nDo **not** dump the full 2000+ word report inline — per-paper annotations, references, and methodology belong in the file. The preview is there to let the user judge the report at a glance and decide whether to open it.\n\n## Examples\n\n**Example 1: Typical SLR request**\n\nUser: \"Do a systematic literature review of recent transformer attention variants, 20 papers, APA format.\"\n\nYour flow:\n1. Phase 1: confirm topic (transformer attention variants), scope (20 papers, default time window), format (APA). Ask **one** clarification only if something is missing (e.g. \"Any particular time window, or should I default to the last 3 years?\").\n2. Phase 2: `arxiv_search.py \"transformer attention\" --max-results 20 --sort-by relevance --start-date 2023-01-01`.\n3. Phase 3: 20 papers → round 1 = 3 subagents × 5 papers = 15 covered, round 2 = 1 subagent × 5 papers = 5 covered. Aggregate.\n4. Phase 4: read `templates/apa.md`, write the report using its structure, fill in themes + per-paper annotations from Phase 3 metadata.\n5. Phase 5: save to `slr-transformer-attention-20260409.md`, call `present_files`.\n\n**Example 2: Small-set request with ambiguity**\n\nUser: \"Survey a few papers on diffusion models for me.\"\n\nYour flow:\n1. Phase 1: \"a few\" is ambiguous. Ask one question: \"How many papers would you like — 10, 20, or 30? And any citation format preference (APA is the default)?\"\n2. User responds \"10, BibTeX\".\n3. Phase 2: `arxiv_search.py \"diffusion models\" --max-results 10 --category cs.CV`.\n4. Phase 3: 10 papers → single round, 2 subagents × 5 papers.\n5. Phase 4: read `templates/bibtex.md`, format with `@misc` entries (not `@article`).\n6. Phase 5: save and present.\n\n**Example 3: Out-of-scope request**\n\nUser: \"Here's one paper (https://arxiv.org/abs/1706.03762). Can you review it?\"\n\nThis is a single-paper peer review, not a literature survey. Do not use this skill. Route to `academic-paper-review` instead.\n\n## Notes\n\n- **Prerequisite: `subagent_enabled` must be `true`**. Phase 3 requires the `task` tool for parallel metadata extraction. This tool is only loaded when `subagent_enabled` is set to `true` in the runtime config (`config.configurable.subagent_enabled`). Without it, the `task` tool will not appear in the available tools and Phase 3 cannot execute as designed.\n- **arXiv only, by design**. This skill does not query Semantic Scholar, PubMed, or Google Scholar. arXiv covers the bulk of CS/ML/physics/math preprints, which is what DeerFlow users most often want to survey. Multi-source academic search belongs in a dedicated MCP server, not inside this skill.\n- **Hard upper bound of 50 papers**. This is tied to the Phase 3 concurrency strategy (max 3 subagents per round, ~5 papers each, at most ~3 rounds). Surveys larger than 50 papers degrade in synthesis quality and are better done by splitting into sub-topics.\n- **Phase 3 requires subagents to be enabled**. This skill's parallel extraction step hard-requires the `task` tool, which is only available when `subagent_enabled=true` at runtime. If subagents are unavailable, do not claim to execute the Phase 3 parallel plan; instead, tell the user that subagents must be enabled for the full workflow, or offer to narrow/split the request into a smaller manual review.\n- **Subagent results are strings, not objects**. Always strip the `Task Succeeded. Result: ` / `Task failed.` / `Task timed out.` prefixes before parsing the JSON payload.\n- **The `id` field is a bare arXiv id** (e.g. `1706.03762`), not a URL and not with a version suffix. `abs_url` / `pdf_url` hold the full URLs if you need them.\n- **Synthesis, not listing**. The final report must identify themes and compare findings across papers. A report that only lists papers one after another is a failure mode — if you cannot find themes, say so explicitly instead of faking them.\n","frontmatter":{"name":"systematic-literature-review","description":"Use this skill when the user wants a systematic literature review, survey, or synthesis across multiple academic papers on a topic. Also covers annotated bibliographies and cross-paper comparisons. Searches arXiv and outputs reports in APA, IEEE, or BibTeX format. Not for single-paper tasks — use academic-paper-review for reviewing one paper."},"isInternal":false,"tokens":4126,"sizeBytes":17256},{"name":"apa.md","path":"skills/public/systematic-literature-review/templates/apa.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/apa.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/apa.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/apa.md)","tokens":300,"sizeBytes":236},{"name":"bibtex.md","path":"skills/public/systematic-literature-review/templates/bibtex.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/bibtex.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/bibtex.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/bibtex.md)","tokens":300,"sizeBytes":242},{"name":"ieee.md","path":"skills/public/systematic-literature-review/templates/ieee.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/ieee.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"# Templates Skill\n\nPath: `skills/public/systematic-literature-review/templates/ieee.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/systematic-literature-review/templates/ieee.md)","tokens":300,"sizeBytes":238},{"name":"SKILL.md","path":"skills/public/video-generation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/video-generation/SKILL.md","title":"video-generation","category":"anthropic-skill","format":"markdown","content":"---\nname: video-generation\ndescription: Use this skill when the user requests to generate, create, or imagine videos. Supports structured prompts and reference image for guided generation.\n---\n\n# Video Generation Skill\n\n## Overview\n\nThis skill generates high-quality videos using structured prompts and a Python script. The workflow includes creating JSON-formatted prompts and executing video generation with optional reference image.\n\n## Core Capabilities\n\n- Create structured JSON prompts for AIGC video generation\n- Support reference image as guidance or the first/last frame of the video\n- Generate videos through automated Python script execution\n\n## Workflow\n\n### Step 1: Understand Requirements\n\nWhen a user requests video generation, identify:\n\n- Subject/content: What should be in the image\n- Style preferences: Art style, mood, color palette\n- Technical specs: Aspect ratio, composition, lighting\n- Reference image: Any image to guide generation\n- You don't need to check the folder under `/mnt/user-data`\n\n### Step 2: Create Structured Prompt\n\nGenerate a structured JSON file in `/mnt/user-data/workspace/` with naming pattern: `{descriptive-name}.json`\n\n### Step 3: Create Reference Image (Optional when image-generation skill is available)\n\nGenerate reference image for the video generation.\n\n- If only 1 image is provided, use it as the guided frame of the video\n\n### Step 3: Execute Generation\n\nCall the Python script:\n```bash\npython /mnt/skills/public/video-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/prompt-file.json \\\n --reference-images /path/to/ref1.jpg \\\n --output-file /mnt/user-data/outputs/generated-video.mp4 \\\n --aspect-ratio 16:9\n```\n\nParameters:\n\n- `--prompt-file`: Absolute path to JSON prompt file (required)\n- `--reference-images`: Absolute paths to reference image (optional)\n- `--output-file`: Absolute path to output image file (required)\n- `--aspect-ratio`: Aspect ratio of the generated image (optional, default: 16:9)\n\n[!NOTE]\nDo NOT read the python file, instead just call it with the parameters.\n\n## Video Generation Example\n\nUser request: \"Generate a short video clip depicting the opening scene from \"The Chronicles of Narnia: The Lion, the Witch and the Wardrobe\"\n\nStep 1: Search for the opening scene of \"The Chronicles of Narnia: The Lion, the Witch and the Wardrobe\" online\n\nStep 2: Create a JSON prompt file with the following content:\n\n```json\n{\n \"title\": \"The Chronicles of Narnia - Train Station Farewell\",\n \"background\": {\n \"description\": \"World War II evacuation scene at a crowded London train station. Steam and smoke fill the air as children are being sent to the countryside to escape the Blitz.\",\n \"era\": \"1940s wartime Britain\",\n \"location\": \"London railway station platform\"\n },\n \"characters\": [\"Mrs. Pevensie\", \"Lucy Pevensie\"],\n \"camera\": {\n \"type\": \"Close-up two-shot\",\n \"movement\": \"Static with subtle handheld movement\",\n \"angle\": \"Profile view, intimate framing\",\n \"focus\": \"Both faces in focus, background soft bokeh\"\n },\n \"dialogue\": [\n {\n \"character\": \"Mrs. Pevensie\",\n \"text\": \"You must be brave for me, darling. I'll come for you... I promise.\"\n },\n {\n \"character\": \"Lucy Pevensie\",\n \"text\": \"I will be, mother. I promise.\"\n }\n ],\n \"audio\": [\n {\n \"type\": \"Train whistle blows (signaling departure)\",\n \"volume\": 1\n },\n {\n \"type\": \"Strings swell emotionally, then fade\",\n \"volume\": 0.5\n },\n {\n \"type\": \"Ambient sound of the train station\",\n \"volume\": 0.5\n }\n ]\n}\n```\n\nStep 3: Use the image-generation skill to generate the reference image\n\nLoad the image-generation skill and generate a single reference image `narnia-farewell-scene-01.jpg` according to the skill.\n\nStep 4: Use the generate.py script to generate the video\n```bash\npython /mnt/skills/public/video-generation/scripts/generate.py \\\n --prompt-file /mnt/user-data/workspace/narnia-farewell-scene.json \\\n --reference-images /mnt/user-data/outputs/narnia-farewell-scene-01.jpg \\\n --output-file /mnt/user-data/outputs/narnia-farewell-scene-01.mp4 \\\n --aspect-ratio 16:9\n```\n> Do NOT read the python file, just call it with the parameters.\n\n## Output Handling\n\nAfter generation:\n\n- Videos are typically saved in `/mnt/user-data/outputs/`\n- Share generated videos (come first) with user as well as generated image if applicable, using `present_files` tool\n- Provide brief description of the generation result\n- Offer to iterate if adjustments needed\n\n## Notes\n\n- Always use English for prompts regardless of user's language\n- JSON format ensures structured, parsable prompts\n- Reference image enhance generation quality significantly\n- Iterative refinement is normal for optimal results\n\n## Providers (Gemini / MiniMax)\n\nProvider credentials are read from the runtime environment, not embedded in the\nscript. Do not put their values in prompt files or command-line arguments.\n\nAuto-selected by environment variables (CLI unchanged):\n\n- `GEMINI_API_KEY` set → Gemini Veo (default, unchanged).\n- Only `MINIMAX_API_KEY` set → MiniMax video (`/v1/video_generation`, async 3-step poll/download).\n- Force with `VIDEO_GENERATION_PROVIDER=gemini|minimax`.\n\nMiniMax overrides: `MINIMAX_API_HOST` (default `https://api.minimaxi.com`),\n`MINIMAX_VIDEO_MODEL` (default `MiniMax-Hailuo-2.3`). The first reference image is used\nas MiniMax `first_frame_image`. MiniMax ignores `--aspect-ratio` (it uses resolution/duration).\n","frontmatter":{"name":"video-generation","description":"Use this skill when the user requests to generate, create, or imagine videos. Supports structured prompts and reference image for guided generation."},"isInternal":false,"tokens":1295,"sizeBytes":5487},{"name":"SKILL.md","path":"skills/public/web-design-guidelines/SKILL.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/web-design-guidelines/SKILL.md","title":"web-design-guidelines","category":"anthropic-skill","format":"markdown","content":"---\nname: web-design-guidelines\ndescription: Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".\nmetadata:\n author: vercel\n version: \"1.0.0\"\n argument-hint: \n---\n\n# Web Interface Guidelines\n\nReview files for compliance with Web Interface Guidelines.\n\n## How It Works\n\n1. Fetch the latest guidelines from the source URL below\n2. Read the specified files (or prompt user for files/pattern)\n3. Check against all rules in the fetched guidelines\n4. Output findings in the terse `file:line` format\n\n## Guidelines Source\n\nFetch fresh guidelines before each review:\n\n```\nhttps://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md\n```\n\nUse WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.\n\n## Usage\n\nWhen a user provides a file or pattern argument:\n1. Fetch guidelines from the source URL above\n2. Read the specified files\n3. Apply all rules from the fetched guidelines\n4. Output findings using the format specified in the guidelines\n\nIf no files specified, ask the user which files to review.\n","frontmatter":{"name":"web-design-guidelines","description":"Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".","metadata":{"author":"vercel","version":"1.0.0","argument-hint":""}},"isInternal":false,"tokens":268,"sizeBytes":1231},{"name":"CLAUDE.md","path":"backend/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/CLAUDE.md","title":"backend - Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# backend - Claude Agent Guidelines & System Prompt\n\nPath: `backend/CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/CLAUDE.md)","tokens":300,"sizeBytes":186},{"name":"CLAUDE.md","path":"frontend/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/CLAUDE.md","title":"frontend - Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# frontend - Claude Agent Guidelines & System Prompt\n\nPath: `frontend/CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/CLAUDE.md)","tokens":300,"sizeBytes":189},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# GitHub Copilot Instructions\n\nPath: `.github/copilot-instructions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.github/copilot-instructions.md)","tokens":300,"sizeBytes":192},{"name":"analyzer.md","path":"skills/public/skill-creator/agents/analyzer.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/analyzer.md","title":"Subagent: analyzer","category":"subagent-persona","format":"markdown","content":"# Subagent: analyzer\n\nPath: `skills/public/skill-creator/agents/analyzer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/analyzer.md)","tokens":300,"sizeBytes":213},{"name":"comparator.md","path":"skills/public/skill-creator/agents/comparator.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/comparator.md","title":"Subagent: comparator","category":"subagent-persona","format":"markdown","content":"# Subagent: comparator\n\nPath: `skills/public/skill-creator/agents/comparator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/comparator.md)","tokens":300,"sizeBytes":219},{"name":"grader.md","path":"skills/public/skill-creator/agents/grader.md","rawUrl":"https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/grader.md","title":"Subagent: grader","category":"subagent-persona","format":"markdown","content":"# Subagent: grader\n\nPath: `skills/public/skill-creator/agents/grader.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/skill-creator/agents/grader.md)","tokens":300,"sizeBytes":207}],"systemPromptSnippet":"\n\n# backend - AI Agent Protocol & Instructions\n\nPath: `backend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/backend/AGENTS.md)\n\n\n# frontend - AI Agent Protocol & Instructions\n\nPath: `frontend/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/frontend/AGENTS.md)\n\n\n# References Skill\n\nPath: `.agent/skills/smoke-test/references/SOP.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/SOP.md)\n\n\n# References Skill\n\nPath: `.agent/skills/smoke-test/references/troubleshooting.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/references/troubleshooting.md)\n\n\n---\nname: smoke-test\ndescription: End-to-end smoke test skill for DeerFlow. Guides through: 1) Pulling latest code, 2) Docker OR Local installation and deployment (user preference, default to Local if Docker network issues), 3) Service availability verification, 4) Health check, 5) Final test report. Use when the user says \"run smoke test\", \"smoke test deployment\", \"verify installation\", \"test service availability\", \"end-to-end test\", or similar.\n---\n\n# DeerFlow Smoke Test Skill\n\nThis skill guides the Agent through DeerFlow's full end-to-end smoke test workflow, including code updates, deployment (supporting both Docker and local installation modes), service availability verification, and health checks.\n\n## Deployment Mode Selection\n\nThis skill supports two deployment modes:\n- **Local installation mode** (recommended, especially when network issues occur) - Run all services directly on the local machine\n- **Docker mode** - Run all services inside Docker containers\n\n**Selection strategy**:\n- If the user explicitly asks for Docker mode, use Docker\n- If network issues occur (such as slow image pulls), automatically switch to local mode\n- Default to local mode whenever possible\n\n## Structure\n\n```\nsmoke-test/\n├── SKILL.md ← You are here - core workflow and logic\n├── scripts/\n│ ├── check_docker.sh ← Check the Docker environment\n│ ├── check_local_env.sh ← Check local environment dependencies\n│ ├── frontend_check.sh ← Frontend page smoke check\n│ ├── pull_code.sh ← Pull the latest code\n│ ├── deploy_docker.sh ← Docker deployment\n│ ├── deploy_local.sh ← Local deployment\n│ └── health_check.sh ← Service health check\n├── references/\n│ ├── SOP.md ← Standard operating procedure\n│ └── troubleshooting.md ← Troubleshooting guide\n└── templates/\n ├── report.local.template.md ← Local mode smoke test report template\n └── report.docker.template.md ← Docker mode smoke test report template\n```\n\n## Standard Operating Procedure (SOP)\n\n### Phase 1: Code Update Check\n\n1. **Confirm current directory** - Verify that the current working directory is the DeerFlow project root\n2. **Check Git status** - See whether there are uncommitted changes\n3. **Pull the latest code** - Use `git pull origin main` to get the latest updates\n4. **Confirm code update** - Verify that the latest code was pulled successfully\n\n### Phase 2: Deployment Mode Selection and Environment Check\n\n**Choose deployment mode**:\n- Ask for user preference, or choose automatically based on network conditions\n- Default to local installation mode\n\n**Local mode environment check**:\n1. **Check Node.js version** - Requires 22+\n2. **Check pnpm** - Package manager\n3. **Check uv** - Python package manager\n4. **Check nginx** - Reverse proxy\n5. **Check required ports** - Confirm that ports 2026, 3000, and 8001 are not occupied\n\n**Docker mode environment check** (if Docker is selected):\n1. **Check whether Docker is installed** - Run `docker --version`\n2. **Check Docker daemon status** - Run `docker info`\n3. **Check Docker Compose availability** - Run `docker compose version`\n4. **Check required ports** - Confirm that port 2026 is not occupied\n\n### Phase 3: Configuration Preparation\n\n1. **Check whether config.yaml exists**\n - If it does not exist, run `make config` to generate it\n - If it already exists, check whether it needs an upgrade with `make config-upgrade`\n2. **Check the .env file**\n - Verify that required environment variables are configured\n - Especially model API keys such as `OPENAI_API_KEY`\n\n### Phase 4: Deployment Execution\n\n**Local mode deployment**:\n1. **Check dependencies** - Run `make check`\n2. **Install dependencies** - Run `make install`\n3. **(Optional) Pre-pull the sandbox image** - If needed, run `make setup-sandbox`\n4. **Start services** - Run `make start` (production mode)\n5. **Wait for startup** - Give all services enough time to start completely (90-120 seconds recommended)\n\n**Docker mode deployment** (if Docker is selected):\n1. **Initialize Docker environment** - Run `make docker-init`\n2. **Start Docker services** - Run `make up` (production mode)\n3. **Wait for startup** - Give all containers enough time to start completely (60 seconds recommended)\n\n### Phase 5: Service Health Check\n\n**Local mode health check**:\n1. **Check process status** - Confirm that Gateway, Frontend, and Nginx processes are all running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n**Docker mode health check** (when using Docker):\n1. **Check container status** - Run `docker ps` and confirm that all containers are running\n2. **Check frontend service** - Visit `http://localhost:2026` and verify that the page loads\n3. **Check API Gateway** - Verify the `http://localhost:2026/health` endpoint\n4. **Check LangGraph-compatible API** - Verify the `/api/langgraph/*` route exposed by Gateway\n5. **Frontend route smoke check** - Run `bash .agent/skills/smoke-test/scripts/frontend_check.sh` to verify key routes under `/workspace`. The script auto-detects whether authentication is enabled and, if so, registers / logs in a smoke-test user so the real pages are verified rather than the login redirect.\n\n### Optional Functional Verification\n\n1. **List available models** - Verify that model configuration loads correctly\n2. **List available skills** - Verify that the skill directory is mounted correctly\n3. **Simple chat test** - Send a simple message to verify the end-to-end flow\n\n### Phase 6: Generate Test Report\n\n1. **Collect all test results** - Summarize execution status for each phase\n2. **Record encountered issues** - If anything fails, record the error details\n3. **Generate the final report** - Use the template that matches the selected deployment mode to create the complete test report, including overall conclusion, detailed key test cases, and explicit frontend page / route results\n4. **Provide follow-up recommendations** - Offer suggestions based on the test results\n\n## Execution Rules\n\n- **Follow the sequence** - Execute strictly in the order described above\n- **Idempotency** - Every step should be safe to repeat\n- **Error handling** - If a step fails, stop and report the issue, then provide troubleshooting suggestions\n- **Detailed logging** - Record the execution result and status of each step\n- **User confirmation** - Ask for confirmation before potentially risky operations such as overwriting config\n- **Mode preference** - Prefer local mode to avoid network-related issues\n- **Template requirement** - The final report must use the matching template under `templates/`; do not output a free-form summary instead of the template-based report\n- **Report clarity** - The execution summary must include the overall pass/fail conclusion plus per-case result explanations, and frontend smoke check results must be listed explicitly in the report\n- **Optional phase handling** - If functional verification is not executed, do not present it as a separate skipped phase in the final report\n\n## Known Acceptable Warnings\n\nThe following warnings can appear during smoke testing and do not block a successful result:\n- Feishu/Lark SSL errors in Gateway logs (certificate verification failure) can be ignored if that channel is not enabled\n- Warnings in Gateway logs about missing methods in the custom checkpointer, such as `adelete_for_runs` or `aprune`, do not affect the core functionality\n- The `frontend_check.sh` script automatically handles authentication. When auth is enabled it registers / logs in a smoke-test user (`smoke-test@deerflow.dev` by default) to verify the real `/workspace/*` pages. The registration may produce a log entry from the auth provider, which is expected and harmless.\n\n## Key Tools\n\nUse the following tools during execution:\n\n1. **bash** - Run shell commands\n2. **present_file** - Show generated reports and important files\n3. **task_tool** - Organize complex steps with subtasks when needed\n\n## Success Criteria\n\nSmoke test pass criteria (local mode):\n- [x] Latest code is pulled successfully\n- [x] Local environment check passes (Node.js 22+, pnpm, uv, nginx)\n- [x] Configuration files are set up correctly\n- [x] `make check` passes\n- [x] `make install` completes successfully\n- [x] `make dev` starts successfully\n- [x] All service processes run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\nSmoke test pass criteria (Docker mode):\n- [x] Latest code is pulled successfully\n- [x] Docker environment check passes\n- [x] Configuration files are set up correctly\n- [x] `make docker-init` completes successfully\n- [x] `make up` completes successfully\n- [x] All Docker containers run normally\n- [x] Frontend page is accessible\n- [x] Frontend route smoke check passes (`/workspace` key routes)\n- [x] API Gateway health check passes\n- [x] Test report is generated completely\n\n## Read Reference Files\n\nBefore starting execution, read the following reference files:\n1. `references/SOP.md` - Detailed step-by-step operating instructions\n2. `references/troubleshooting.md` - Common issues and solutions\n3. `templates/report.local.template.md` - Local mode test report template\n4. `templates/report.docker.template.md` - Docker mode test report template\n\n\n# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.docker.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.docker.template.md)\n\n\n# Templates Skill\n\nPath: `.agent/skills/smoke-test/templates/report.local.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/.agent/skills/smoke-test/templates/report.local.template.md)\n\n\n# academic-paper-review\n\nPath: `skills/public/academic-paper-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/academic-paper-review/SKILL.md)\n\n\n# References Skill\n\nPath: `skills/public/bootstrap/references/conversation-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/references/conversation-guide.md)\n\n\n# bootstrap\n\nPath: `skills/public/bootstrap/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/SKILL.md)\n\n\n# Templates Skill\n\nPath: `skills/public/bootstrap/templates/SOUL.template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/bootstrap/templates/SOUL.template.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_area_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_area_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_bar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_bar_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_boxplot_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_boxplot_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_column_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_column_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_district_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_district_map.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_dual_axes_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_dual_axes_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_fishbone_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_fishbone_diagram.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_flow_diagram.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_flow_diagram.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_funnel_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_funnel_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_histogram_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_histogram_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_line_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_line_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_liquid_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_liquid_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_mind_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_mind_map.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_network_graph.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_network_graph.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_organization_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_organization_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_path_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_path_map.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pie_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pie_chart.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_pin_map.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_pin_map.md)\n\n\n# References Skill\n\nPath: `skills/public/chart-visualization/references/generate_radar_chart.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/bytedance/deer-flow/HEAD/skills/public/chart-visualization/references/generate_radar_chart.md)\n\n\n"}