briefing-outline

Solid

說明提綱 (briefing outline) writing — distill detailed source material into one high-altitude overview that gives each part its purpose and essence, then points down for the detail. Source count is not the point: it works over several documents or one long report (pointing down to its sections). Use when the user wants to 整理/撰寫一份說明提綱, condense one or more sources into a navigable briefing for a 主管 or 委員會, summarise a long report into a high-altitude overview that points down for detail, or re-sync an existing 提綱 after its sources changed. Do NOT invoke to author a single formal document from scratch — 簽呈/會議紀錄/報告/專案規劃 (use formal-doc-structure), for RFP / 需求規格書 / 招標規格 (use rfp-writing), for lowering one term or passage to a non-technical audience (use plain-speak), or for pure language cleanup (use avoid-ai-writing-zh). This skill sits above the source material and points down into each part.

Data & Documents 0 stars 0 forks Updated 6 days ago MIT

Install

View on GitHub

Quality Score: 78/100

Stars 20%
0
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# 說明提綱 (Briefing Outline) A 說明提綱 sits at a fixed **altitude**: high enough to see the whole body of source material at once, always pointing **down** to each source for the detail — where a source is a separate document, or a section of one long report. Its reader — a 主管 or 委員會 deciding direction — wants to grasp the whole and know where to drill, not re-read the sources. Every section carries enough essence to stand on its own, then hands off with 「(詳《source》)」. The recurring failure is drift below altitude — dragging in 逐項標準、逐條規則、逐步操作、完整明細 that belong in the source. Hold altitude and the 提綱 stays readable and stable when sources churn. ## Output Language Match the language of the user's request, and apply it to *all* user-facing output — option labels, generated-document headings, table column names — not just prose. If the user explicitly asks for another language, that wins. Language follows the request, not the source material. When the sources are in English but the user writes in Chinese, the 提綱 stays Chinese. If the request is in Chinese, use Traditional Chinese (Taiwan business usage) and keep established technical terms in English. The English in this file is structural labelling for you, not literal output. Never mirror this file's language into your response. ## Steps 1. **Inventory the sources.** List every source and one line on what each holds — a source being a separate document, or (for a single long report) one of its sections. Separate any **umbrel...

Details

Author
leoluyi
Repository
leoluyi/skills
Created
3 months ago
Last Updated
6 days ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

API & Backend Solid

formal-doc-structure

Draft, revise, or restructure formal internal business documents in Traditional Chinese (Taiwan corporate / financial-institution usage) — 簽呈, 會議紀錄, 評估報告, 專案規劃, 採購與廠商溝通, 對主管簡報, 驗收與交付, 跨單位協調. Picks a reader-driven structure per document type and produces a usable draft, not just advice. Trigger when the user asks to write or fix an internal business document, memo, report, meeting record, plan, or vendor communication. Do NOT invoke for RFP / 招標規格 / 需求規格書 (use rfp-writing), for pure language cleanup with no structural work (use avoid-ai-writing / clean-ai-writing), or for casual chat, creative writing, marketing copy, or code comments.

0 Updated 6 days ago
leoluyi
Data & Documents Listed

academic-principles-calibration

處理「學術英文原則」——讀使用者從網路蒐集或自行整理的學術英文寫作規則/教材/詞彙表(放 writing-style/academic-principles/sources/ 的 md/docx/pdf,非本人所寫的文章),萃取成一份可操作的規則摘要 writing-style/academic-principles/academic-principles.md,供後續編修與該篇 style-guide.md 參考。當第一次設定學術原則、使用者在 academic-principles/sources/ 新增或更換規則文件、或說「更新學術英文原則/整理我蒐集的寫作規則/重新萃取學術原則」時使用。只處理英文語言層面,不搬運版權原文。個人本人筆法另由 personal-voice-calibration 處理。

0 Updated 5 days ago
billy1125
Data & Documents Listed

report-to-brief

긴 보고서·연구보고서·정책보고서를 짧은 정책브리프·이슈페이퍼·요약본(1~8쪽)으로 압축하는 스킬. 원본(.hwpx/.docx/.md/.pdf)이나 붙여넣은 본문을 입력받아, 두괄식(결론 먼저)·자립성(브리프만 읽어도 이해)·근거 보존(핵심 수치·출처 유지) 원칙으로 재구성하고, 압축 과정에서 핵심 주장 누락·의미 왜곡·출처 유실이 없는지 3축 압축검수로 점검한다. 다음 상황에서 반드시 사용한다: '브리프로 만들어줘', '요약본', '정책브리프', '이슈페이퍼', '한 장으로', '요약해줘(보고서를)', '압축', 'executive summary', '핵심만 뽑아줘', '분량 줄여줘' 등 긴 문서를 짧게 만드는 요청. 단순 몇 줄 요약이 아니라 배포 가능한 브리프 산출물을 만드는 데 적용한다. 백지 집필·양식 변환은 다른 스킬의 몫이다.

0 Updated 6 days ago
parkjui92-tech