菜单
Use at the start of a workday or when the user says "start my day", "good morning", "/start-day", "morning", "what should I work on today", or wants a catch-up on what happened while they were away. Use when the user wants a short ranked list of what to tackle today.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when asked to rewrite or format text in the user's voice, "make this sound like me", "match my voice", "de-stiffen this", when text "reads too corporate / businessy / stiff", to "strip the em-dashes / agent typography", or to draft a Slack announcement, PR body, or doc in the user's voice. Also /match-voice.
Use when writing or rewriting reader-facing technical text — documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, agent/system prompts — or when asked to "de-slop", "make this readable", "simplify this doc", "write for non-native readers", "apply STE", "Simplified Technical English", or "ASD-STE100", or to prepare text for translation. Also use to CHECK such text for clarity violations. Do NOT use for chat replies, PR/review comments, or commit messages (that is terse-output), nor for marketing, brand, or personal-voice writing (that is match-voice) — this skill deletes persuasion by design.
Use when the user asks for a deep review, full review, comprehensive review, production readiness assessment, full audit, multi-domain audit, "security and reliability and code review", or "review everything". Also use when the user explicitly requests performance review alongside the comprehensive request (e.g. "include perf", "review including performance", "deep review with perf"); without that explicit phrasing, performance is excluded. Do NOT use for narrow single-domain reviews (use the matching review-* skill directly).
Review code architecture (SOLID, design patterns, package design, coupling, testability), Go best practices, and protobuf/API design using manual analysis and static analysis tools (gocyclo, staticcheck, buf). Use when the user asks for a code review, architecture review, Go review, protobuf review, SOLID review, or design pattern review.
Use when the user wants to execute an approved implementation plan and says any of "do it" (with a plan in scope), "lets do it" / "let's do it", "confirmed" (as approval to proceed on a plan), "implement the plan", "implement this", "execute the plan", "start implementing", "work through the plan", "implement the next phase", "build it out", "knock out the plan", or "/implement-plan PATH". Also use when a plan file (`./.plans/PLAN.md`, any `./.plans/*.md`, or legacy `./PLAN.md` / `./docs/plans/*.md`) is present and the user signals readiness to begin coding. Do NOT use when the user is still discussing, refining, or asking questions about the plan, nor when no plan exists — short imperatives like "do it" or "confirmed" alone are ambiguous; verify a plan is in scope before activating.
Use when the user asks to review the plan, sanity-check the plan, vet the plan, evaluate the plan, "is this plan ready", feasibility check on a plan, "review-plan PATH", or when another skill (like implement-plan) requests pre-flight plan evaluation before execution. Do NOT use when no plan file is in scope (the user is likely asking for a summary — use Read instead), nor when the user is asking about source code (use review-code), nor when the user wants documentation review (use review-documentation).
| name | start-day |
| description | Use at the start of a workday or when the user says "start my day", "good morning", "/start-day", "morning", "what should I work on today", or wants a catch-up on what happened while they were away. Use when the user wants a short ranked list of what to tackle today. |
Produce a short morning brief: what happened since the user was last active, and 2–8 ranked things to do today. Discovery-driven — no hardcoded sources. Read-only; never posts, commits, or mutates anything.
A since:<date|weekday> argument overrides everything below.
Two inputs, combined:
~/.claude/projects/*/*.jsonl dated before today, and (b) the user's last Slack message (from:me sort:timestamp).window_start = the earlier of fixed_floor and empirical. Empirical can only push earlier — a low-focus weekend glance cannot shrink the window below fixed_floor, and a vacation gap extends it. window_end = now.
Compute fixed_floor (macOS date):
case $(date +%u) in 1) back=3;; 7) back=2;; *) back=1;; esac # Mon→Fri, Sun→Fri, else yesterday (Sat→Fri via back=1)
floor=$(date -v-${back}d -v15H -v0M -v0S +%s) # last business day @ 15:00 local
Holidays need no special handling: if the last business day was a holiday, the user's empirical last-active day predates it and extends the window automatically.
Scan the available skills. Run every skill whose name matches summarize-* OR whose description declares summary / recap / status intent. Do not hardcode which ones — discover them so newly added ones are picked up. Pass the window when a skill accepts a range. If none exist, skip this step.
Run every available skill whose name matches start-day-* (there may be several). Machine- and context-specific morning setup lives there, outside this portable skill. Fold each extension's output into the brief as bullets.
Slack search reaches DMs and private channels, so ask once before searching: "Scan Slack DMs/private channels for saved items and pings since <window_start>?" On yes:
Slack:slack_search_public_and_private with query is:saved.to:me, after:<window_start unix ts>, sort:timestamp.Slack:slack_read_user_profile — note if the user is currently OOO; deprioritize pings from colleagues whose status shows OOO.Reminders are not reachable through the Slack API — skip them. Never send or post anything (per no-post-without-confirmation).
Open with the window and an override hint:
Caught up since Fri Jun 19, 3:00pm (~3d). Override:
/start-day since:monday.
Then 2–8 ranked items, sampled across size — a couple of quick wins to start the day, 1–2 big-rocks to advance a major project, plus anything time-sensitive from Slack. Tag each [quick] / [project] / [slack]. One terse line each, leading with the action.
Brief only: no auto-actions, no backlog writes, no posting. Stay independent of any tracker — when run inside a tool that supplies project context (system prompt, discovered skills), use it, but never depend on it.