菜单
Save the current development session to a timestamped markdown file in .context/. Captures what was done, decisions made, files changed, test state, and open items for continuity. Use at the end of any session before switching tasks or ending the conversation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Deeply analyze a codebase for architectural improvements, refactoring opportunities, and testability issues. Walks through exploration, candidate presentation, and a collaborative implementation loop with the user. Use when the codebase feels messy, untested, hard to navigate, or when preparing for feature work that touches core structures.
Run systematic technical quality checks on frontend code across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with prioritized fix recommendations. Use for pre-ship checks, codebase health assessments, or before significant redesigns.
UX and visual planning for a frontend feature before any code is written. Produces a structured design brief that guides implementation. Use for any new UI surface, component, page, or significant visual redesign. Does not write code — only plans. Complements plan-then-build (which handles architecture and data flow).
One-time design context setup for a project. Interviews the user to capture strategic design intent, then writes .context/PRODUCT.md and optionally .context/DESIGN.md. Use before any design work (new project, or first time using design skills in an existing project). Not for backend-only projects.
Final shipping readiness pass on a UI surface, component, or page. Checks for completeness, consistency, edge cases, micro-interactions, and copy polish. Use after implementation is functionally complete but before declaring it done. Not for finding bugs — for finding gaps between "it works" and "it ships."
Reads staged git changes, recent commit history, and project context to generate a well-structured conventional commit message. Present it to the user for approval before committing.
| name | save-session |
| description | Save the current development session to a timestamped markdown file in .context/. Captures what was done, decisions made, files changed, test state, and open items for continuity. Use at the end of any session before switching tasks or ending the conversation. |
Persist the current session's work, decisions, and state to a timestamped markdown file in .context/ so future sessions can pick up where this one left off.
Determine the filename
date +%Y-%m-%d
Use .context/session-YYYY-MM-DD.md. If a file with that name already exists, append a suffix like -pm or -2.
Gather session content by reviewing:
Write the file with this structure:
# Project Name — Session Summary (YYYY-MM-DD)
## Agenda
Brief description of what this session set out to do.
## Changes Made
### Change 1 — Short title
**Problem:** What was the issue or goal?
**Files:** Which files were touched?
**Change:** What specifically changed? (plain English, not full diffs)
**Tests:** Impact on test suite (count before/after, pass/fail)
### Change 2 — ...
## Current Test State
- `go test ./...` / `npm test` — results
- Lint / vet results
- Build results
## Decisions & Rationale
Any architectural or design decisions made during the session and why.
## Open Items / Next Session Notes
- Unfinished candidates or TODOs
- Recommended next steps
- Blockers or questions
Be concise but specific. Mention exact file paths, function names, and test names. Do not paste full code diffs — summarize the change in 2-4 sentences.
Cross-reference .context/ files if relevant (e.g., "See also golang-react-islands-spec-2026-04-28.md").
.context/. Create the directory if it does not exist. Never overwrite existing files without checking.