一键导入
check
Auto-detect project CI configuration, extract and run corresponding check commands locally (generic, no fixed directory structure dependency)
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Auto-detect project CI configuration, extract and run corresponding check commands locally (generic, no fixed directory structure dependency)
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Toggle "learning mode" — a co-coding mode where the user hand-writes the code themselves instead of you writing it. Trigger on /smart:learning, or whenever the user wants to enable or disable hands-on participation in coding: phrases like "learning mode", "let me write the code", "I want to participate in coding", "co-code with me", "参与编码", "hands-on mode", "turn learning mode off". This is a plain on/off switch — no ratios, no config. When on, every piece of code you would write goes to the console instead, labeled New file / New code / Modify / Delete for the user to type in, and you review what they land, one task at a time. Enabling injects the rules into `.claude/CLAUDE.local.md` (which Claude Code auto-loads every session) so they persist; the presence of that block is the entire state — nothing is stored in `.smart/settings.json`. Use this skill for any request about turning the user's own involvement in writing code on or off.
Use when the user wants to capture, review, or close the open loops Claude surfaced during the current conversation — the insights, suggested next steps, and follow-up questions Claude raised while chasing something else, which get buried as the conversation branches. Persists them to `.smart/notebook.md` as a running list of unfollowed leads. Trigger on `/smart:notebook`, or when the user says "notebook", "记录本", "做题本", "open loops", "what did we not follow up on", "别丢", "被掩埋", "未跟进", "现在有哪些没跟进的". A companion `Stop` hook already auto-captures marked blocks (★ Insight, 建议下一步) after every reply; this skill adds the free-form leads the hook cannot parse and manages their open/closed status. This is NOT `todo` (either/or decisions under a pinned mainline) and NOT `distill` (reusable knowledge Q/A archive) — notebook tracks unclosed leads so a question chased into another question never gets lost.
Use when the user asks to distill, summarize, archive, persist, or save the current session/conversation into a knowledge base; mentions /smart:distill, distill, knowledge base, session topics, Q&A archive, current CC output, or "write this chat to disk"; or provides a scope/target directory for session knowledge capture. Applies only to current conversation context, not source files.
This skill should be used when the user wants to capture, anchor, or reconcile the decisions and options Claude surfaced during the current conversation into a persistent `.smart/todo-list.md` — a mainline-plus-branches todo. Trigger on `/smart:todo`, or when the user says "todo", "todolist", "待办", "主线", "pull me back", "拉回主线", "别跑偏", "I'm lost in branches", "现在该做什么", or wants to stop the conversation's ever-branching decisions from burying the original goal. It pins one Mainline (the fundamental goal) that branch churn can never overwrite, parks divergent decisions as reconciled branches (merging duplicates instead of rewriting), and re-surfaces the mainline every run to pull the user back. Reads the current conversation's surfaced decisions — not source-file TODOs or the native task list.
Personal local config for Claude Code sessions. Trigger on /smart:local, or when the user says "create CLAUDE.local.md", "setup local memory", "local preferences", "git-ignore my local claude file", or wants a per-project personal memory file that is never committed. Bootstraps a git-ignored `.claude/CLAUDE.local.md` in the current project, seeded with the personal preferences below, and ensures it is git-ignored. The personal preferences also apply on their own: always reply in Simplified Chinese, store Plan Mode files under `.claude/plans/`.
This skill should be used when the user says "analyze","optimize plugins", "disable unused plugins", "save context", "reduce context usage", "which plugins do I need", "clean up plugins", "focus context", "trim plugins", or wants to detect the project type and disable irrelevant plugins to save context window space. Invoked explicitly via /smart:optimize-tokens.
| name | check |
| description | Auto-detect project CI configuration, extract and run corresponding check commands locally (generic, no fixed directory structure dependency) |
| argument-hint | No arguments needed, automatically infers check method from .github/workflows/*.yml |
| model | haiku |
You are a local check assistant. Goal: infer which checks should be run from the project CI configuration and execute them locally.
Execution steps (must follow in strict order):
Run git status --short, counting files with M, A, and ?? statuses.
Run: ls .github/workflows/*.yml 2>/dev/null || ls .github/workflows/*.yaml 2>/dev/null
Read every workflow file found. For each file, extract two things:
Grep for the following keywords and build a "check tool inventory":
| Detection keyword (appears in CI files) | Corresponding local check |
|---|---|
ruff | Python lint |
pytest | Python test |
mypy or pyright | Python type check |
eslint | JS/TS lint |
tsc or type-check | TS type check |
vitest or jest | JS/TS test |
turbo | Turbo monorepo check |
go test | Go test |
golangci-lint | Go lint |
For each workflow file, check for a working-directory setting (either under defaults.run.working-directory or per-step). Record the mapping: workflow file → working directory.
Example CI pattern:
defaults:
run:
working-directory: apps/backend
If a workflow has a working directory, all tools detected in that workflow inherit it. If no working directory is specified, the tools run from the repository root.
Build the final inventory as a table:
| Tool | Working directory | Source workflow |
|---|
If no known tools are detected: output "No known check tools found in CI workflows, skipping local checks", and stop.
Based on files present in the project root directory, determine the execution prefix and package manager:
uv.lock exists → Python commands use uv run prefixpyproject.toml exists (no uv.lock) → run directly (ruff, pytest, etc.)pnpm-lock.yaml exists → JS/TS uses pnpmpackage-lock.json exists → JS/TS uses npm rungo.mod exists → Go runs directlyCRITICAL: Run ALL tools in the inventory. Do NOT selectively skip tools based on which files were changed. The purpose of local check is to mirror CI — CI runs every workflow, so local check must run every detected tool.
For each tool in the inventory, cd into its working directory (from step 3b) before executing. If no working directory was detected, execute from the repository root.
Python:
ruff → cd <dir> && uv run ruff check . --fix (or ruff check . --fix)pytest → cd <dir> && uv run pytest -v (or pytest -v)mypy / pyright → cd <dir> && uv run mypy . (or uv run pyright .)JS/TS:
eslint → cd <dir> && pnpm lint (or npm run lint)tsc / type-check → cd <dir> && pnpm type-check (or npx tsc --noEmit)vitest / jest → cd <dir> && pnpm test (or npm test)turbo → extract turbo command from CI file, execute as-is (e.g., pnpm turbo lint type-check build)Go:
go test → cd <dir> && go test ./...golangci-lint → cd <dir> && golangci-lint runWhen the inventory spans multiple working directories (e.g., apps/backend and apps/mobile), run each group in its own directory. Never collapse all checks into one directory.
--fix, which is expected behavior).