SanHsien
UserAI coding agent 工程技能包：25 個 skill、9 個 slash command，涵蓋 spec→plan→build→verify→review→ship｜Production-grade engineering skills for AI coding agents (Windows-first maintenance fork)
Categories
Indexed Skills (38)
api-and-interface-design
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
browser-testing-with-devtools
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.
ci-cd-and-automation
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
code-review-and-quality
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
code-simplification
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
constraint-driven-development
Establishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.
context-engineering
Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
debugging-and-error-recovery
Guides systematic root-cause debugging. Use when tests fail, builds break, something that worked yesterday broke, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need to figure out what broke and why — a systematic approach to finding and fixing the root cause rather than guessing.
deprecation-and-migration
Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand/contract). Use when deciding whether to maintain or sunset existing code.
documentation-and-adrs
Records decisions and documentation. Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
doubt-driven-development
Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when you want every assumption cross-examined before proceeding, when stress-testing a plan for hidden failure modes, when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production auth, security-sensitive logic, a high-stakes migration, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
frontend-ui-engineering
Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.
idea-refine
Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan".
incremental-implementation
Delivers changes incrementally in thin, verifiable slices. Use when implementing any feature or change that touches more than one file, or when picking up the next task from a plan. Use when rolling a change out behind a feature flag, when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
interview-me
Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
observability-and-instrumentation
Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.
planning-and-task-breakdown
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
security-and-hardening
Hardens code against vulnerabilities. Use when auditing an input handler for vulnerabilities, when handling user input, authentication, data storage, or external integrations, or when checking a login flow is safe against the OWASP Top Ten. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when auditing dependencies for known vulnerabilities, triaging package-manager audit findings, or assessing supply-chain risk in a new package. Use when personal data or privacy compliance (GDPR, CCPA) is involved.
shipping-and-launch
Prepares production launches. Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
source-driven-development
Grounds every implementation decision in official documentation. Use when you want to verify an approach against the official docs before implementing it, or when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.
spec-driven-development
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.
test-driven-development
Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
using-agent-skills
Discovers and invokes agent skills. Use when starting a session, or when you need to decide which skill or workflow applies to the piece of work at hand. This is the meta-skill that governs how all other skills are discovered and invoked.
token-optimizer
多代理編排的 token／配額節流規則。任何要呼叫 Agent tool 或 Workflow 派工之前——不論使用者有沒有提到省 token、單一 subagent 也算——先讀本 skill 再動手。使用者說「省 token」「配額」「別燒爆額度」時也觸發。觸發詞：workflow、多代理、fan-out��subagent、派工、編排、省 token、配額、token optimizer。 English triggers: "save tokens", "quota", "don't burn my limit", "token optimizer".
ai-review
把一份產出送給「另一個模型」做二審，消化意見後才寫最終回報。附單檔 POSIX shell 腳本（預設走 Codex CLI，可用 AI_REVIEW_CMD 換成任何後端）與 code／copy／research 三份 rubric；偵測不到後端時明講「本次僅自審」而不是靜默跳過，也不會中斷你的流程。當使用者說「送二審」「跨模型 review」「找另一個模型看一下」「二審」「ai-review」時觸發。⚠️ 送出去的內容就是給第三方模型看，憑證與個資自己把關。 English triggers: "second opinion", "cross-model review", "have another model review this", "ai review".
ai-search
帶引用的即時網路查證：把問題交給有網路搜尋能力的後端，要求結論先行、每個關鍵事實附來源連結、查不到就說查不到、可能過時的頁面主動標注。附單檔 POSIX shell 腳本（預設走 Codex CLI 的內建網路搜尋，可用 AI_SEARCH_CMD 換成任何會上網的後端）；偵測不到後端時明講「本次略過查證」而不是靜默跳過，也不會中斷你的流程。當使用者說「查證」「上網查一下」「即時查」「fact-check 這個」「這是不是真的」「查最新的」時觸發。⚠️ 問題會送給第三方模型、答案來自公開網路，憑證與個資不要放進問題裡。 English triggers: "fact-check this", "search the web", "look this up", "verify this online", "what is the latest".
blind-review
把剛寫好的改動交給一個「沒看過這段對話」的子代理攻擊（正確性與簡潔性兩軸），主代理再補上假設與設計決策，最後產出一份**給人看的導讀**：先看哪三處、當初為什麼這樣選、哪些沒驗。子代理只審不改，裁決 ship／fix-first／rethink 由人決定。⚠️ 換的是脈絡不是模型家族——要換模型請疊用 ai-review。當使用者說「對抗式審查」「攻擊這個改動」「幫我導讀這個 PR」「派一個沒看過對話的來審」「blind review」時觸發。 English triggers: "adversarially review this", "attack this change", "brief me on this PR", "blind review", "fresh-eyes review".
daily-debrief
產生某一天的工作日報:做了什麼+reflection,存成本地 Markdown。以 mission-log 的零 token 骨架為原料,不重讀原始 transcript。當使用者說「日報」「今天的 daily summary」「幫我補某天的日報」「daily debrief」時觸發。⚠️ 需一併安裝 mission-log(收割器在那支裡);超過 transcript 保留期(預設 30 天)的日期無法補生成。 English triggers: "daily debrief", "daily summary", "write up my day", "backfill the daily for <date>".
damage-report
「開發／優化／修 bug／研究查證」類任務收尾的自檢協定。寫回報之前先跑五問（開發問「改變」、研究問「斷言」,同一骨架兩組對照），把結果附在回報末尾，再加一段「還能怎麼優化」（沒有就寫無）。當使用者說「收尾自檢」「自我 review」「跑五問」「self-review」時觸發；也適合寫進全域指令讓它在每次工具類任務收尾自動執行。 English triggers: "damage report", "self-review", "wrap-up check", "definition of done review".
dropoff
跨專案／跨 session 交接「推球」。把一件事連同完整脈絡交給另一個專案（或同專案的未來 session）的 Claude。當使用者說「交接給 X」「handoff 給某專案」「推球給 X」「把這件事丟給下個 session」時觸發。產出＝目標專案 `.claude/handoffs/` 下的一張交接卡（Markdown 檔），對面 session 用 /pickup 接手；偵測到目標的活躍 session 時加發即時門鈴（使用者說「不用即時通知」則靜默排隊）。 English triggers: "hand this off to X", "drop this off for <project>", "pass this to the next session".
flight-to-calendar
把已訂的航班行程加進使用者的 Google Calendar，一段航班建一個事件、正確處理跨時區、傍晚抵達或清晨起飛的航段標夕陽/日出座位。當使用者提供機票訂位 / e-ticket / PNR / 航班明細（或指向一個訂位檔），並說「把航班加到行事曆」「行程上 calendar」「加這趟飛機到日曆」之類時使用。 English triggers: "add my flights to the calendar", "put the trip on my calendar", "add this flight to my calendar".
new-mission
新任務開工前的簡報流程：只問最必要的幾題（一次一題、能查的先查）→ 產第一版計畫（不實作）→ 送審 → 整合後給使用者確認 → 同時輸出一份優化過的任務 prompt 當這件事的基礎 → 確認後才動手 → 執行結束交一份對照計畫的收尾報告。當使用者說「新任務」「任務簡報」「開工簡報」「先問我再做」「先給計畫」「mission brief」「這個任務怎麼開始」時觸發；接到一個三步以上、或做錯不好回頭的新任務時也該主動提議跑一次。⚠️ 一兩步、可逆、做壞了重來只花幾分鐘的小事不適用，直接做。 English triggers: "new mission", "mission brief", "brief me first", "plan before doing", "ask me first", "kickoff".
recap
多個 session 平行跑時的「現況重述」。先花一兩分鐘把可能過期的東西實際刷新（版本控制狀態、PR／CI、自己啟動過的背景工作、引用過的外部討論串），再用固定四欄回報：目標（用提出者的原話）、現況與證據、卡在人還是卡在技術、下一步（逐項標記由誰做）。⚠️ recap 期間不准開始任何新工作——它是報告，不是續做。當使用者說「recap」「現在到哪了」「這個 session 在幹嘛」「重述現況」「幫我對一下進度」時觸發。 English triggers: "recap", "where are we", "status of this session", "catch me up", "what's the state".
save-all
重開機／關機／收工前的「落地同步」收尾檢查。在每個還開著的對話 session 裡各跑一次，把只活在這個對話裡、還沒寫進磁碟的東西全部外部化並驗證真的落地，然後回報「安全可重開 / 還有 X 沒同步」。當使用者說「要重開機了」「save-all」「/save-all」「準備重開」「關機前收尾」「reboot 前」「今天收工」時觸發。⚠️ 本 skill 只做落地＋回報，不重開機器。 English triggers: "save-all", "about to reboot", "shutting down", "wrapping up for today", "before restart".
mission-log
零 token 的 session 活動收割器。從 Claude Code 本來就在寫的 transcript(~/.claude/projects)抽出指定日期的活動骨架:哪些專案、幾點到幾點、說過什麼、用了哪些工具、花多少 token。當使用者說「今天做了什麼」「昨天的 session 記錄」「收割某天的活動」「mission log」時觸發。⚠️ 只讀不寫、不呼叫模型;日報/週報請用 /daily-debrief、/weekly-debrief(兩者以本 skill 為底層)。 English triggers: "what did I work on today", "harvest my sessions", "mission log", "show session activity".
pickup
跨專案／跨 session 交接「接球」。讓「這個」session 馬上去讀交接給本專案的事項並接手。當使用者說「接手」「pickup」「有沒有交接給我的」「看交接」「接球」時觸發；收到別的 session 傳來的交接門鈴訊息時也觸發。也適合 session 開場主動跑一次，確認沒漏接。讀本專案 `.claude/handoffs/` 下 status: pending 的交接卡。 English triggers: "pickup", "take over", "anything handed off to me?", "check handoffs".
weekly-debrief
產生某一週的工作週報:彙整 7 份日報成趨勢與 reflection,存成本地 Markdown。只讀日報 md,不碰原始 transcript。當使用者說「週報」「這週做了什麼」「weekly summary」「補上週的週報」時觸發。⚠️ 這裡的週報=個人工作回顧;要對外發布的內容型「週報」(電子報/社群貼文)不歸本 skill。需一併安裝 daily-debrief 與 mission-log(缺的日報會先自動補生成)。 English triggers: "weekly debrief", "weekly summary", "wrap up my week", "backfill last week".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.