andrew-skills

Mark revisions inline in existing Obsidian markdown files using either Obsidian comments (%%...%%) or footnotes ([^N] reference style preferred, ^[...] inline as alternative), so the user can review every change before accepting. Use whenever revising, restructuring, proofreading, reviewing, or annotating existing Obsidian markdown content — outlines, notes, drafts, articles, talk decks. Triggers on words like 調整, 修訂, 重新檢視, 改一下, 重新組織, 校稿, 校閱, 批注, revise, adjust, restructure, reorganize, proofread, review, annotate. Do NOT use when creating brand-new files from scratch, when the user explicitly says 直接改 不用標記, or when working on non-Obsidian markdown (the %%...%% syntax won't auto-hide there; footnotes still work in standard markdown but rendering varies).

校閱、打磨要發到社群（以 Facebook 為主）的短文貼文（約 1k 字）—— 看主軸是否單一貫穿、開場能否扛住『顯示更多』截斷、與母體（演講 / 長文）是否互補不互搶、可貼性與外連策略、引用是否回源查證。Use when reviewing or polishing a Facebook / social short post drafted in Obsidian, a 暴雷文 / 預告文 that companions a talk or long article, or any ~1k-char 社群貼文 / 短文. Triggers on facebook, FB, 社群貼文, 短文, 貼文, 暴雷文, 預告文, po 文, 短文校閱, 貼文校閱. Do NOT use for talks / keynotes / slides (publish-review:talk-structure), long-form blog articles needing formal multi-round review, or the line-level mechanics of marking changes (obsidian-review:obsidian-revision-marks).

整理、重組、檢視技術演講或簡報的內容結構與敘事。核心做法：用少數中性主軸詞當骨架、標題正面肯定、先講動機與變化、主軸逐一展開、用案例落地證明主軸（以問題開場當 hook）、並把『工作稿（含註記/討論/參考資料）』與『釋出稿（只有每頁標題/內容/講者註記）』分開維護。Use when organizing a talk/keynote/slide outline, restructuring a presentation's narrative, naming the 主軸/pillars of a talk, deciding section order, or splitting a messy working doc into a clean release deck. Triggers on 演講, 簡報, keynote, slide, 投影片, 講稿, 大綱, 主軸, 收斂, take away, 整理結構, 重整大綱, release. Do NOT use for line-level edit mechanics of marking changes (that's obsidian-revision-marks), for non-talk prose (articles/docs that have no slide/speaker-note shape), or for slide visual design / layout.

Design Andrew-style API and distributed-system contracts from domain lifecycle, message flow, and correctness guarantees. Use when Codex needs state-machine-driven API design, contract-first or API-first planning, service-to-service messaging, retry and idempotency design, queue or scheduler workflows, worker isolation choices, or measurable validation of ordering, latency, and duplicate-execution tradeoffs.

Build Andrew-style architecture foundations before domain-specific design: frame the real problem, extract stable abstractions, choose data and storage shapes from dominant constraints, validate ideas with measurable POCs, and turn architecture topics into deliberate-practice loops. Use when the task is cross-domain architecture thinking, abstraction-first modeling, storage tradeoff analysis, executable design validation, or architecture skill-building.

Plan Andrew-style microservice architecture and migration by checking whether microservices truly fit, cutting service boundaries around real business responsibilities, evolving systems incrementally instead of rewriting, and engineering platform, runtime, and delivery capabilities as first-class architecture. Use when deciding whether to adopt microservices, decomposing a monolith, planning migration, choosing shared infrastructure, containerizing services, or defining the CI/CD and operability baseline needed to run many services safely.

Design Andrew-style authentication, authorization, permission, and trust-boundary mechanisms for applications and APIs. Use when Codex needs security-by-design thinking, token or key-based trust models, permission-system architecture, RBAC or policy design, anti-replay and signature choices, multi-tenant authorization boundaries, or operational enforcement and audit considerations.

Design Andrew-style service reliability mechanisms from explicit SLOs, bottleneck analysis, load shaping, queue fairness, and operable metrics. Use when Codex needs to design service-quality guarantees, SLI/SLO decomposition, admission control, throttling, queue or lineup mechanisms, workload separation, observability-by-design, or operational controls that protect user experience under load.