메뉴
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.