Jeric SkillsClaude Code 스킬 마켓플레이스
← 전체 스킬

session-to-skill

v1.2.0

진행 중인 대화에서 재사용 가능한 패턴을 찾아 제안하고, 선택된 것을 이 저장소 컨벤션에 맞는 스킬로 등록한 뒤 원하면 PR까지 생성

설치

호출 이름/session-to-skill:session-to-skill

Session to Skill

지금 하고 있는 대화를 돌아보면서, 다시 쓸 만한 절차나 결과물 형식을 찾아 Claude Code 스킬로 등록해주는 스킬.

무엇을 만드나

  • 현재 세션 내용을 근거로 한 스킬 후보 2~4개 (이름 + 재사용 근거 + 트리거 조건)
  • AskUserQuestion으로 사용자가 고른 후보에 대해, my-claude-skills 컨벤션을 그대로 따르는 SKILL.md / (필요시) template.md / README.md
  • 로컬 스킬 저장소에 등록 + ~/.claude/skills/<name> 심볼릭 링크로 실제 호출 가능하게 설치
  • (선택) 공유 마켓플레이스 Jeric1223/my-claude-skills로 PR 자동 생성

왜 이렇게 설계했나

스킬이 될 만한 패턴은 대화가 끝나고 시간이 지나면 놓치기 쉽다. 방금 겪은 반복 작업, 방금 정리한 규칙이 제일 뚜렷하게 보일 때가 대화 도중이라, 그 순간을 놓치지 않고 구조화하는 게 목적이다. 후보를 사용자 승인 없이 바로 스킬로 만들지 않는 이유는 — 이 프로젝트에서만 통하는 특수한 내용이 일반화된 스킬인 것처럼 잘못 포장될 위험이 있어서다.

파일을 두 곳(저장소 + ~/.claude/skills/)에 복제하지 않고 심볼릭 링크로 연결하는 이유는, 나중에 스킬을 고칠 때 두 사본이 어긋나는 걸 막기 위함이다 — 저장소가 유일한 원본(source of truth)이다.

저장소 경로를 하드코딩하지 않고 $CLAUDE_SKILLS_REPO → 기존 심볼릭 링크 역추적 → 사용자에게 질문 순서로 찾는 이유는, 만든 사람의 로컬 경로가 박혀 있으면 다른 사람이 설치했을 때 그냥 깨지기 때문이다.

PR 직전에 민감정보 스캔을 강제하는 이유가 이 스킬의 가장 중요한 설계 결정이다. 이 스킬의 원재료는 실제 업무 세션이고, 목적지는 public 저장소다. 계정 ID, 사내 호스트, 실제 테이블·큐 이름이 예시에 섞여 들어간 채로 PR이 열리면 되돌릴 수 없다. 그래서 검사 대상 org 키워드도 하드코딩하지 않고 현재 프로젝트의 git remote와 CLAUDE.md에서 실행 시점에 뽑아낸다.

사용 흐름

  1. 세션 내용에서 재사용 가능한 패턴 스캔 (일회성/프로젝트 특수 내용은 제외)
  2. 후보 2~4개 초안 작성
  3. AskUserQuestion으로 제안, 사용자가 선택
  4. 선택된 것마다 my-claude-skills 컨벤션대로 스킬 파일 작성
  5. 로컬 저장소에 등록 + ~/.claude/skills/에 심볼릭 링크
  6. marketplace.json 항목 추가 + 저장소 README 스킬 목록 갱신
  7. main에 직접 커밋하지 않고 브랜치에서 커밋 — push는 요청받았을 때만
  8. "공유 마켓플레이스에 PR로 올릴까요?" 질문 — 거절하면 여기서 종료
  9. 민감정보 스캔 (걸리면 PR 중단하고 해당 줄을 보여줌)
  10. gh로 fork → 임시 디렉터리에 clone → 브랜치 → PR 생성
  11. 정식 테스트를 거치지 않은 1차 초안이라는 점을 명시

자세한 절차는 SKILL.md에 있다.

파일 구성

session-to-skill/
  SKILL.md      # 에이전트가 실제로 읽는 절차 정의
  README.md     # 이 파일 — 사람이 읽는 설명

template.md가 없는 이유: 이 스킬의 결과물은 고정된 문서 한 장이 아니라 "다른 스킬의 파일 세트"라서, 템플릿화할 단일 출력 구조가 없다.

에이전트가 읽는 절차 — SKILL.md

설치하면 Claude가 실행 중에 참조하는 실제 문서다. 아래 내용이 그대로 동작을 결정한다.

Session to Skill

Overview

Looks back at the current conversation (already in context — never re-read a transcript file), finds procedures or output formats worth reusing, proposes them to the user, and turns whatever they pick into a properly-structured skill. Registers it locally first, then optionally opens a PR to the shared marketplace at Jeric1223/my-claude-skills.

When to Use

  • User explicitly asks to extract/create a skill from what just happened in this session
  • Right after a multi-step workflow wraps up and it seems like it'll recur (offer it once, don't insist)
  • NOT for a single one-off task with no repeat structure, and NOT for turning project-specific conventions into a skill — those belong in that project's instructions file, not a personal skill

Process

1. Scan the conversation for candidates. Look for: procedures repeated more than once, decisions/rules the user gave that took several messages to pin down, output structures likely to be asked for again. Apply the bar from superpowers:writing-skills's "When to Create a Skill" — not intuitively obvious, reusable across projects, not project-specific.

2. Draft 2-4 candidates. For each: a name, one sentence on the reusable pattern, and a rough trigger description. Discard anything that's really just this-project detail wearing a skill's clothes.

3. Propose via AskUserQuestion. Multi-select — the user may want more than one, or none of the above (they can always type something else via "Other").

3.5. Confirm the name before building anything. The user invokes skills by typing /<name> from memory, so names must be easy to recall:

  • Only plain English words a non-native speaker knows (postman-collection, session-to-skill) — no jargon like integration-branch-merge
  • The most important word goes first — the word the user would think of in the moment ("I need to merge and it conflicts… merge-something") → merge-safe, not safe-merge
  • Two words is ideal, three at most
  • Offer 2-3 such names per selected skill via AskUserQuestion and use only the name the user confirms, for the folder, the name: frontmatter, and the marketplace.json entry. Do not create folders under a working name and rename later.

4. Build each selected skill. Follow the repo convention exactly (see the marketplace repo's top-level README.md "스킬 구조" section, and CONTRIBUTING.md): SKILL.md (required), README.md (required, human-facing), template.md (only if output shape must be fixed).

5. Register it locally.

Resolve the local skills repo — never hardcode a path, try in this order and stop at the first hit:

  1. $CLAUDE_SKILLS_REPO
  2. The repo root that an existing ~/.claude/skills/* symlink resolves into (readlink -f, then walk up to the dir containing .claude-plugin/marketplace.json)
  3. Ask the user where their skills repo is. If they don't have one, write the skill straight into ~/.claude/skills/<skill-name>/ and skip the symlink — a local-only skill still works.

Then:

  • Write the canonical folder into <repo>/<skill-name>/
  • Symlink it: ln -s <repo>/<skill-name> ~/.claude/skills/<skill-name>. If a same-named entry already exists there, stop and tell the user instead of overwriting it.
  • Add an entry to <repo>/.claude-plugin/marketplace.json (name, source, description, version: "1.0.0", author) — this file is the only registry; without it the skill isn't installable
  • Add a row to <repo>/README.md's 스킬 목록 table

6. Commit, don't push. Branch off main first (never commit on main/master directly), commit there — then stop. Pushing the user's own repo only happens when they ask.

7. Offer to share it. Ask via AskUserQuestion, once, per skill:

이 스킬을 공유 마켓플레이스(Jeric1223/my-claude-skills)에 PR로 올릴까요?

Options: 올린다 / 로컬에만 둔다. If they decline, stop here — do not ask again.

8. Sanitize before anything leaves the machine. The repo is public and this skill's raw material is a work session, so scan every file about to be published (SKILL.md, README.md, template.md) and abort the PR on any hit, showing the offending lines and asking the user to confirm or edit:

  • Cloud account IDs and keys — \b[0-9]{12}\b, \b(AKIA|ASIA)[0-9A-Z]{16}\b
  • Absolute home paths — /Users/[^/[:space:]]+/, /home/[^/[:space:]]+/
  • Private hosts and networks — \b10\., \b192\.168\., \b172\.(1[6-9]|2[0-9]|3[01])\., \.internal\b, \.local\b
  • Credentials — (password|secret|token|api[_-]?key)\s*[=:]\s*\S
  • Org-specific terms derived at runtime, not hardcoded: pull them from the current project's git remotes (git remote -v), the org/host segments of any non-GitHub remote, and any company or project names in the user's CLAUDE.md. Grep the drafted files for those terms.
  • Real infrastructure names carried over from the session — table names, queue names, bucket names, endpoints, ticket IDs

Anything that survives should read as a generic example. If a pattern genuinely needs a concrete value to make sense, replace it with a placeholder (<account-id>, example.com).

9. Open the PR. Requires gh:

  • gh auth status — if gh is missing or unauthenticated, stop before creating any branch: tell the user to brew install gh && gh auth login and re-run. Do not half-build the PR.
  • OWNER=$(gh api user -q .login). If OWNER is the upstream owner, work on a branch in a clone of the upstream; otherwise gh repo fork Jeric1223/my-claude-skills --clone=false and use the fork.
  • Clone into a temp dir (mktemp -d) — do not reuse the user's local repo for this, and never touch its working tree
  • Branch add-<skill-name>, copy the skill folder in, add the marketplace.json entry and the README table row (steps 3 and 4 of CONTRIBUTING.md)
  • Commit, push to the fork, gh pr create --repo Jeric1223/my-claude-skills filling in .github/PULL_REQUEST_TEMPLATE.md's checklist honestly — leave a box unchecked rather than checking something you didn't verify
  • Report the PR URL back to the user

10. Say what's untested. New skills built this way are a first draft, not verified against RED-GREEN-REFACTOR pressure scenarios. Say so plainly — in the PR body too — rather than implying they've been tested.

Common Mistakes

  • Proposing something so tied to this one project's specifics that it can't actually generalize
  • Skipping the AskUserQuestion step and just picking a candidate yourself
  • Opening a PR without running step 8 — a public repo makes leaked internal names permanent
  • Hardcoding the local skills repo path instead of resolving it
  • Forgetting the marketplace.json entry — the skill looks registered but can't be installed
  • Pushing the user's own repo without being asked, or committing straight on main
  • Overwriting an existing ~/.claude/skills/<name> instead of flagging the collision
  • Starting the fork/branch dance before checking that gh is authenticated
GitHub에서 소스 보기 →