zynkr-skill-builder

The READ half of Peter's support loop (formerly support-reply-drafter). Parses Peter's Gmail support + inbound-sales queues, detects unreplied inquiries, identifies each inquirer's intent, and matches it against the **Zynkr platform 知識庫** (platform.zynkr.ai/kb — the single source of truth since 2026-07-15, accessed via the `zynkr` MCP server's search_kb / get_kb_article) to draft a safe reply on the thread. Drafts match the inbound language (zh-TW or EN). When the KB has no confident answer it does NOT guess — it leaves a holding reply with an inline `[[NEEDS PETER: ...]]` block flagging exactly what's missing and notifies Peter. Once Peter supplies the real answer, this skill hands the resolved thread off to /zynkr-kms, which writes it into the platform KB so the next identical question resolves automatically. Trigger whenever Peter says '/zynkr-support', 'draft support replies', 'process support inbox', '回覆 support 信箱', '清 support queue', '幫我回 support 信', '回覆 inbound sales', '清 sales inbox', '處理詢價信', or oth

Streamline and re-sequence a business process into a clean 'ideal flow' BEFORE it gets re-architected or automated. Runs a lean optimization pass: validate Input→Process→Output on every step, map dependencies, eliminate friction (duplicative / looping / missing steps), then apply disciplined re-sequencing only where it buys less rework, lower risk, or higher throughput. Use it whenever a process feels bloated, out of order, or 不順暢 — when someone says '幫我把流程理順', '這流程可以更精簡嗎', 'streamline this workflow', 'is my process in the right order', or right after a SIPOC / as-is map and before FE/BE/DB architecture or Lucid. Enforces 'eliminate before you automate.' Does NOT do automation-feasibility scoring or FE/BE/DB layer assignment — hand off to operations-transformation for that.

Three-stage operations transformation pipeline — process discovery (SIPOC), digital transformation assessment, then automation-ready process redesign — to turn pain points into builder-ready blueprints.

The knowledge-curator (WRITE) half of Peter's support loop. After a support / inbound-sales ticket is resolved, zynkr-kms reads the thread, learns Peter's actual answer, and writes it as a clean, LLM-friendly card into the **Zynkr platform 知識庫** (platform.zynkr.ai/kb, via the `zynkr` MCP server) — the single source of truth since the 2026-07-15 cutover. Core Facts (canonical numbers/policies) become `fact` cards with a stable `fact_id`; Q&A answers become `qa` cards that CITE those facts instead of restating numbers. It reasons like a KMS specialist (intent taxonomy → which KB section → how to structure for retrieval), proposes entries, and only writes after Peter approves. /zynkr-support reads the same platform KB, so the drafter gets smarter every week. Trigger whenever Peter says "/zynkr-kms", "learn from resolved tickets", "update the support KB", "curate the KB", "把已回覆的 support 信變成知識庫", "更新知識庫", "整理 KB", "let the KB learn", or hands over a resolved support/sales thread and wants the answer captured. This

Runs AI background research on a company (and optionally a contact) in the Zynkr platform CRM and writes a concise, sales-context zh-TW brief into the company's 備註/description field. This is a Claude Code stand-in for the platform's own "AI 背景研究" button (app/lib/ai/research.ts) — that feature only exists in the platform.zynkr.ai web UI and is NOT exposed through the connected `zynkr` MCP server, which only offers CRUD tools (create_company, create_contact, update_company, etc.), so there is no MCP call to trigger it directly. This skill closes that gap by doing the same job — targeted web research (what the company does, industry, size/HQ, notable facts, and why they might need Zynkr) — then writing the result back via update_company / create_company. Trigger EAGERLY whenever Peter says "trigger company research", "research this company", "研究這間公司", "查一下這間公司背景", "幫我查一下[公司名]", "look into [company]", "跑一下背景研究", or asks to research/enrich/look up a company or contact that is or is about to be in the Zynkr CRM — e

Turn an audio/video file (.m4a/.mp3/.wav/.mp4…) into a timestamped .srt using local Whisper. Two modes: transcribe (fresh speech-to-text with audio-accurate timestamps) or retime (keep an existing transcript's exact wording and re-derive every timestamp from the audio via forced alignment). Use when the user says 'turn this m4a into an srt', 'transcribe this audio to subtitles', '把這段錄音轉成字幕', '幫我做 srt', 'the srt wording is right but the timing is wrong, realign it', or hands over an audio file wanting subtitles. This is the FIRST step before training-srt-optimizer — it produces the raw-STT .srt; the optimizer then cleans the text. It does NOT edit/clean subtitle wording (that is training-srt-optimizer) and does NOT summarize into a recap (that is training-lecture-recap).

Turn a finished sales DEMO / discovery call into a converting follow-up — the post-meeting counterpart to sales-outbound. Give it the demo transcript (a Google Doc URL or pasted notes) and it does two things in one pass: (1) drafts a pre-sales follow-up reply as a threaded Gmail DRAFT in Peter's inbox (never sends), in the prospect's language and Peter's voice — opening by mirroring the exact pain points they raised, mapping each to the matching Zynkr AI 平台 capability (zynkr.ai/ai-platform), and moving them toward adopting the solution, with a "sales kit attached manually" line; (2) syncs the EXISTING CRM deal — finds the deal / contact / company, logs the demo as a note activity, refreshes the deal summary, nudges the stage if warranted, closes the now-stale scheduling task, and creates the agreed follow-up task. Trigger on /sales-follow-up or when Peter hands over a demo / meeting transcript after a call and says "draft a follow-up", "draft the pre-sales follow-up", "follow up on this demo", "寫跟進信", "擬一封 de

The third leg of the slide-assistant three-leg relay (picks up after slide-page-splitter, then hands off to the slide-pptx skill for rendering): once it has the SLIDE_PACKET ▸ Pages, it decides page by page "what is the most effective visual treatment for this page?" (chart / bullets / diagram / image / comparison / big statement…), and converges each page into a render-ready per-page visual spec SLIDE_PACKET ▸ Visuals, handing it off to the installed slide-pptx skill to render into a .pptx. Trigger proactively when the user hands over a ▸ Pages handoff packet, or says 「挑視覺呈現」「選版式」「決定每頁要用什麼圖」「把分頁變成可算繪的視覺規格」「準備餵 slide-pptx」. Scope boundary: it only does the visual mapping and layout of 'content → layout archetype → pptxgenjs primitive'; it does not rewrite the storyline (that is slide-storyline-designer), does not re-paginate (that is slide-page-splitter), and does not actually generate the .pptx file (that is the slide-pptx skill).

The conductor of the slide relay (sitting above the three-stage relay): fires when the user says '做一份簡報／做個 deck／幫我把這些做成投影片／做季報簡報／all-hands 簡報／deep dive 簡報／pitch deck'. I do a one-shot intelligent intake — detecting which kind of deck this is (deep-dive / business-review / data-presentation / all-hands / planning / pitch / update / teach / fundraise), taking stock of the material and storyline the user has already given, proposing a page count for the user to confirm, and gathering the must-include material and mode — then assembling a SLIDE_PACKET ▸ Brief and driving slide-storyline-designer → slide-page-splitter → slide-visual-selector → the slide-pptx skill in sequence to render the .pptx. Defaults to express mode (ask everything up front once, only asking the user to sign off at two points: storyline finalization and final file); pass the guided parameter to retain each stage's own per-stage human review. Scope boundary: I only do intent detection, context convergence, ▸ Brief injection, and relay orchestr

Turn a pasted outreach conversation into a tracked lead AND a ready-to-send reply. Give it a copied DM / chat thread (Threads, IG, LINE, FB Messenger, WhatsApp, email — wherever a prospect showed interest), optionally with the person's profile link, and it does two things in one pass: (1) collects who they are — parsing the thread and enriching from any social/profile URL — and writes the client context into the Zynkr platform CRM (find-or-create company + contact, a new deal, a verbatim conversation note, and a follow-up task for the agreed next step); (2) drafts the outbound reply as a Gmail DRAFT in Peter's inbox (never sends), in the same language as the conversation and in Peter's voice, reflecting whatever was agreed (a demo, a call, sending info). Trigger on /sales-outbound or when Peter pastes a DM / outreach exchange and says "draft a reply", "draft an outbound mail", "回這個", "幫我擬回覆", "把這個 lead 建進 CRM 並擬信", "log this lead and draft the email", "turn this DM into a draft", or otherwise hands over a bac

Land a freshly-built SKILL.md into the Zynkr skills pipeline — the closing step of the canonical chain (/skill-sourcer → /skill-triager → /skill-creator → /skill-qa → /skill-publish). Attaches the artifact to the existing pipeline issue, fires the publish-skill workflow to open a PR, and hands off to /skill-triager confirm-ship for closure. Trigger on phrases like 'publish this skill', 'land this skill', 'I finished building, push it', 'register this skill', 'add this built skill', 'check category and dedup before upload', or '/skill-publish'. Use whenever the user has a finished SKILL.md and wants it landed in zynkr-skill-builder — whether it came from /skill-creator (happy path) or from elsewhere (fresh intake fallback).

Quality-gate a SKILL.md before it ships — runs the shared validate-skill.ts engine (frontmatter + body structure + absolute-path leak scan + synergy + IPO length + downloadability) and renders a per-check ✅/⚠️/❌ report with file:line and fix suggestions, optionally auto-fixing mechanical issues (strip leaked machine paths, repair the install snippet) with confirmation, then emits a PASS/FAIL verdict gated on ERROR-tier checks. The QA tollgate of the skill pipeline, between /skill-creator and /skill-publish — and the ad-hoc health-check /zynkr-skills routes to. Trigger on 'qa this skill', 'check this SKILL.md', 'is this skill ready to ship', 'lint the skill', '健檢', 'does <slug> pass QA', or '/skill-qa'.

The front-door router for the Zynkr assistant ecosystem. Takes ANY input from the user — a URL, a file path, a slug, a vague idea, a question about pipeline state — figures out which Zynkr skill it belongs to, reads the relevant state across GitHub Project / issues / on-disk / live marketplace, and either auto-invokes the right sub-skill or asks one targeted clarifying question. Use this skill whenever the user drops something into the conversation without specifying which skill should handle it — every undirected URL, file mention, idea, status question, or 'what should I do with this?' is a candidate. Especially fire on phrases like 'I found this', 'I just built X', 'where am I with Y', 'what's in my queue', 'I have an idea about', '幫我看一下這個', '/zynkr-skills', or when the user pastes a link with no further direction. Triggers MORE eagerly than the specific skills below it — when in doubt, route through /zynkr-skills rather than asking the user to remember the right slash command. Also fire on deck / 簡報 reque

The Stage-0 program-scale SEO strategy planner for any Zynkr product or website — it sits UPSTREAM of seo-article-pipeline and turns 'plan the whole product/site's SEO' into a repeatable, callable orchestration. It reuses the existing single-topic seo-* strategy skills at program scale (seo-persona-builder → seo-question-miner → seo-angle-finder → seo-keyword-mapper → seo-keyword-classifier → seo-demand-validator) AND adds the program-level synthesis those skills never do — defining content pillars, IA decisions (CMS articles + an existing /free-resource + a new category → /blog/<slug> SSR, no microsite), money pages + tech-SEO indexability recon, an AEO citation-gap pass, a CTA ladder + KPIs, governance guardrails, a topic backlog with win-first ordering, a month-by-month calendar, and the two durable deliverables: a 14-section plan Doc (imported to the '00 SEO Strategy & Plans' Drive bucket) and a 9-tab keyword/topic Sheet (built with openpyxl, imported to '01 Keyword Maps'). On finish it hands the backlog

Prepare Peter for an inbound PAID career / résumé consultation before it happens. Give it the booking — a Gmail thread, the appointment email, or just the client's name — and it reads the client's pre-consult reply + CV + LinkedIn, then builds a ready-to-use prep Doc in Peter's 職涯諮詢 folder: the GROW-model intake (Goal / Reality / Options / Will / Story / Summary) prefilled from the client's own words, an opener checklist of the make-or-break facts to confirm first (visa/work-rights for overseas moves, CV-vs-email inconsistencies), the client's own questions regrouped under GROW, a consultant-side CV health-check, and a 60-minute agenda. Trigger on /career-consult, "prep for my consult", "幫我準備諮詢", "準備職涯諮詢", "prep the career consultation", "我等等有一場付費諮詢", or whenever Peter forwards / points at a "職涯、履歷付費諮詢" appointment booking and wants something prepared ahead — even if he only gives the client's name or the calendar subject line. This is the PREP skill (build the briefing before the call). Distinct from cv-cust

Turn this week's inbound "AI 顧問服務" consulting inquiries (the website discovery-call emails from website@zynkr.ai) into tracked work: for each real lead it creates a CRM deal in Supabase, a numbered Google Drive project folder, and a kickoff doc inside that folder. Use this skill whenever Peter runs /consult-intake or says things like "process this week's consult inbounds", "處理本週顧問諮詢", "有沒有新的顧問諮詢", "check for new consulting leads", "turn the discovery-call inquiries into deals", "intake the consult requests", or otherwise asks to triage / log inbound AI-consulting requests — even if he doesn't name the CRM, the Drive folder, or the exact phrase. It is also the skill a scheduled weekly consult-intake run should invoke. When Peter mentions consult inbounds, discovery-call inquiries, or new 顧問 leads and wants them logged, prefer this skill.

Publishes a finalized post to your SOCIAL channels — Facebook, Threads & Instagram — via the Buffer API, with per-channel formatting, Instagram image support, and a preview-confirm gate before anything posts. Use when you say 'publish my post', 'post this to Threads/IG/FB', 'push this draft live to social', or 'schedule this post'. The SOCIAL publisher — not the website/blog one (seo-publish-article).

Put a newsletter in its proper place — reconcile it between Google Docs and the Notion Content DB in EITHER direction (Doc-first OR Notion-first), and file the Doc into the newsletter Drive folder. The goal is that the content ends up correctly placed and cross-linked regardless of which was created first. Use whenever the user shares a Google Doc and/or a Notion Content-DB page and wants them synced, filed, archived, or "put in the right place". Triggers on "幫我放上 Notion", "sync to Notion", "同步到 Notion", "add this to Notion", "幫我歸檔電子報", "file this newsletter", "put this in the right place", "從 Notion 的想法建 Doc", or any message pairing a Doc and/or a Notion page with sync / file / archive intent.

Drafts Peter's weekly Chinese newsletter from the user's article outline or topic idea, shaping it into a structured handoff for the /zynkr-content-writer pipeline. Use this skill whenever Peter says "幫我寫電子報", "來寫電子報", "寫newsletter", "電子報大綱", or shares a topic/outline and wants it shaped into a newsletter. Trigger even if Peter only gives a rough idea — the skill will structure it into a full outline.

Publishes a FINISHED SEO blog article to the live website (e.g. zynkr.ai/blog) by writing it straight into the CMS's Supabase `articles` table — the fast path, because the CMS admin page (e.g. cms.zynkr.ai/content) is an auth-gated dashboard, not a write API. Reads the article from a Google Doc (body + the embedded 「SEO 交付物」block for slug/seo_title/meta_description/keywords/category), converts it to CMS-safe Tiptap JSON + content_html (tables→lists, ▋ headings, schema-validated so it never corrupts on a later in-CMS edit), shows a preview, and on your explicit confirm publishes it live (status=published + published_at) then verifies the public URL renders. Use whenever the user already has a finished/proofed article and says 上架文章 / 發佈到網站 / 把這篇放到部落格 / 上線這篇文章 / publish this article to the blog / push this post live on the site / put this on the web — or hands over a finished article Doc and wants it on the web. Boundaries — this is the WEB/CMS publisher and should win against, but NOT be confused with: /publish

Orchestrates the full article writing pipeline — from ideation through drafting, editing, titles, and CTA. Invoke with /zynkr-content-writer or when the user wants to start writing an article from scratch.

Third leg of the SEO pipeline: working from an SEO expert's perspective plus competitor URLs, surface the content angles and differentiation opportunities for 'where we can do better.' Maps to the v2 flow diagram step 'think about strengthening from the SEO angle + reference competitor URLs to think about strengthening.' Triggers when the user hands over a Questions handoff packet, provides competitor URLs, or says 「找 SEO 切角」. It only finds angles — it does not build the keyword map and does not write the article.

The final leg of the SEO pipeline: add internal/backlinks, a meta description, and structured data (schema) to an already-proofed article, then assemble it into a publish-ready Google Doc (article body + a 「SEO 交付物」block carrying slug/seo_title/meta_description/keywords/category + links/schema) for seo-publish-article. Corresponds to node (11) of the v2 flow diagram — 'list which paragraphs can take links + add the meta description' and 'article settings'. Triggers when the user hands over an already-proofed article and says '做 SEO 設定', '上 meta', '準備上架', or '產出可上架的 Google Doc'. Does pre-publish settings + assembles the Doc; does not rewrite content, and does not publish/move/track (that's seo-publish-article).

The orchestrator for Zynkr SEO content production: it chains the stages of the v2 flowchart into one pipeline running from brand material all the way to a published article on the live website. The first half (persona → seed questions → angles → keyword map → intent classification → demand validation → Brief → outline/FAQ) calls each SEO skill; the second half (drafting → titling → proofreading) reuses the existing write-article sub-agents; then it does SEO setup (`seo-article-finalizer` produces a publish-ready Google Doc), publishes to the live website via `seo-publish-article` (which also archives the Doc + updates the SEO tracker), and optionally produces the EN flagship. Triggers when the user says 「跑 SEO 文章流程」, 「開始寫一篇 SEO 文章」, 「/seo-article-pipeline」, or hands over a brand/article material packet.

Seventh stage of the SEO pipeline: for one selected topic, find the value proposition and winning angle, and produce a complete SEO writing Brief. Corresponds to the v2 flowchart step 「選擇主題：設計 Brief」. Triggers when the user hands over a Topics handoff packet, provides reference articles/forums/expert opinions, or says 「寫 Brief」. Only writes the Brief — does not design the outline and does not write the article.

Stage 8 of the SEO pipeline: turn the SEO Brief into an article outline and FAQ section, outputting a handoff summary compatible with content-draft. Corresponds to the v2 flow diagram's 'Structure article: outline design' and 'Build FAQ'. Triggers when the user hands over a Brief handoff packet and says '設計大綱' or '做 FAQ'. Only handles the outline and FAQ; the actual writing is handed off to content-draft.

Post-process a livestream transcript into four parallel workstreams: an event recap Google Doc, a Q&A knowledge base diff, course lecture note proposals, and marketing content idea seeds.

Manages the full external guest-lecturer collaboration lifecycle for Zynkr events — lecturer intake and screening, contract preparation, the per-event D-30→D+3 operations timeline, and monthly fee settlement with statutory tax withholding. Use when the user says '外部講師', '講師合作', '講師結算', '講師合約', 'guest lecturer', or asks to run any stage of the lecturer program (接洽新講師 / 上架講師活動 / 月末結算). Commercial terms (revenue split, thresholds, penalty caps) come from a local program-config.md — they are never hardcoded in this skill.

Guides the operator through preparing a complete Accupass event listing — one field at a time — then outputs a single copy-paste-ready template covering event content, ticketing, marketing emails, and a post-event follow-up checklist. Use when the user says '我要上架活動', '上架活動通', '填活動通', '活動上架', 'accupass', '幫我填模板', or '活動資訊填寫'. Does not publish to Accupass directly (the platform has no API) — it produces the filled template for manual entry.

Weekly transcript curation. Sweeps the 直播筆記 livestream-note Google Docs across N upstream Drive folders, extracts each doc's 逐字稿 (verbatim transcript) tab, and writes one structured zh-TW summary Doc per source into the destination SOT folder. Fully idempotent — skips any source whose target already exists. Trigger on /curate-livestream-transcripts, '整理直播逐字稿', 'curate the livestream transcripts', 'process this week's 直播筆記', or the weekly Monday routine.

Read, draft, edit, and lint Lucid charts using Peter's FE/BE/DB three-layer architecture convention. Triggers whenever the user shares a `lucid.app` URL with no further direction, asks to diagram/chart/visualize a process or workflow, asks to 'read' or 'summarize' an existing Lucid diagram, asks to add/modify nodes on a Lucid chart, or asks whether a chart follows the Zynkr convention. Should fire eagerly on phrases like '幫我畫流程圖', 'draw this workflow', 'diagram this', 'visualize this process', 'turn this into a Lucid chart', '/product-flow-design', or any pasted Lucid URL. Bridges the human-facing Shape × Color principles (`5.0 product/architecture_principles_guidebook.md`, `5.0 product/color-shape-principles.md`) to the Lucid MCP tools (`mcp__lucid__fetch`, `mcp__lucid__lucid_create_diagram_from_specification`, `mcp__lucid__lucid_add_block`, `mcp__lucid__lucid_add_line`, `mcp__lucid__lucid_edit_item`). Use even when the user does not name 'Lucid' explicitly — if they want a process flow drawn or interpreted,

Weekly hygiene ritual for Zynkr's local↔cloud knowledge governance. Lists Google Drive Docs modified in the last N days across the 8 LOB folders (and Drive root), diffs against local `_INDEX.md` entries in `~/Desktop/Claude/zynkr/`, and proposes specific index edits: new entries to add, broken/renamed links to fix, deleted Docs to remove. Triggers on phrases like 'drift check', 'weekly hygiene', 'sync indexes', 'check cloud changes', 'what changed in cloud this week', '/admin-governance', or when the user pastes nothing but asks to reconcile local/cloud state. Should fire eagerly when the user references the weekly hygiene ritual from the Zynkr knowledge-governance model.

Files loose meeting recordings sitting in a Google Drive recording inbox into the right category sub-folder, with an approval gate. For each loose video it groups the same-prefix siblings (the ` - Notes by Gemini` Doc, ` - Chat` .txt, any .srt) into one unit, reads the Gemini Notes to classify which sub-folder it belongs in, shows the user a filing plan to approve, then moves the whole group and logs the move to a `Video Index` sheet. If nothing fits it proposes a new sub-folder. Trigger on /admin-video-document, '整理錄影檔', '歸檔錄影', '歸檔影片到資料夾', '整理錄影資料夾', 'file my recordings', 'sort the recording folder', 'organise the recordings folder', or when the user points at the recording inbox and wants the videos filed.

Turn raw meeting notes, transcripts, voice memos, or messy unstructured updates into a clean structured Weekly Project Update (Summary · Progress · Blockers · What's Next). Trigger whenever the user pastes meeting notes/transcripts and asks to 'organize my notes', 'tidy up these notes', 'turn this into a weekly update', '整理會議筆記', '整理一下筆記', '幫我寫週報摘要', or shares messy meeting/voice-memo text wanting it cleaned into an internal-stakeholder update. Source: admin-meeting-prep agent (sheetId 3.04).

Article fission — extract outline + summary from any popular article, then run 3 rounds of reflective dialogue to surface the writer's own refined take, ending with a new actionable outline ready for style + writing handoff.

Translate English (or any source language) into natural, conversational Traditional Chinese using Taiwanese expressions and tone. Removes the 'translation smell' that comes from word-for-word renderings. Also supports a reverse zh-TW → English mode for producing English 'flagship' versions of SEO articles (used by seo-article-pipeline for AEO reach in English-dominant AI engines).

The second leg of the slide-assistant three-leg relay: take the storyline approved by the previous leg (SLIDE_PACKET ▸ Storyline) and, following paging principles, slice it into a page-by-page slide list — deciding which beat each page maps to, what title it carries, how many bullet points it holds, and how dense its information should be. Trigger me immediately when the user hands over a ▸ Storyline handoff packet, or says 「幫我分頁」, 「把故事線切成投影片」, 「每頁放什麼」, 「規劃投影片頁數」, 「slide 分頁設定」. I only handle paging and per-page content allocation, handing off once ▸ Pages is produced; I do not design layout or visuals, nor render .pptx (that's slide-visual-selector and the slide-pptx skill), and I do not go back and rewrite the storyline (that's slide-storyline-designer).

The 'rendering engine' that comes after the three-stage slide relay (the fourth stage, maintained by Anthropic): it takes the SLIDE_PACKET ▸ Visuals handed off by slide-visual-selector and renders it page by page into a real .pptx file, and can also read, parse, and edit existing decks in reverse. This is Anthropic's official slide-pptx skill; Zynkr does not redistribute its code — this card is only a reference and a hand-off pointer, so install it from the Anthropic source.

Leg 1 of the three-leg slide relay: take the raw slide material / topic + the message you want to land, and shape it into a logically smooth storyline — confirm the presentation's goal and audience, fix the core claim that runs through the whole talk, lay out an ordered narrative arc (beats), and check each transition one by one for leaps or gaps, producing the SLIDE_PACKET ▸ Storyline narrative skeleton that gets handed to slide-page-splitter for paging. Trigger me proactively when the user says '幫我設計簡報故事線', '順一下這份簡報的邏輯', '這個 deck 的敘事怎麼排', '我要做提案／募資／培訓簡報，先把骨架抓出來', '檢查我的簡報流暢度', or hands you a pile of scattered slide material wanting to clarify the structure first. Scope boundary: I only handle the storyline and logical skeleton — I don't split slide pages, don't write per-page copy, and don't pick layouts or visuals. Paging is leg 2 slide-page-splitter's job, visual specs are leg 3 slide-visual-selector's job, and rendering the .pptx is the slide-pptx skill's job.

Two-stage consulting discovery — pain-point intake then company vision exploration — to produce a needs definition and strategic discovery summary before any solution work.