setup

스타2

포크0

업데이트2026년 4월 29일 19:07

One-time setup for functional-emotions in the current project — idempotently adds `.claude/.functional-emotions/` to the project's `.gitignore` so the plugin's per-session state files (TSV logs, markdown writeups, eval DB) don't get committed. Safe to re-run. Use after installing the plugin in a new project, or when the user mentions accidentally committing functional-emotions state, or when troubleshooting "why are my session files showing in git status?".

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

jondwillis

jondwillis/functional-emotions

GitHub 저장소 열기 Creator 저장소 보기

다운로드

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

SKILL.md

readonly

name	setup
description	One-time setup for functional-emotions in the current project — idempotently adds `.claude/.functional-emotions/` to the project's `.gitignore` so the plugin's per-session state files (TSV logs, markdown writeups, eval DB) don't get committed. Safe to re-run. Use after installing the plugin in a new project, or when the user mentions accidentally committing functional-emotions state, or when troubleshooting "why are my session files showing in git status?".
disable-model-invocation	false
allowed-tools	Bash

Run a one-time, idempotent setup pass that gitignores the plugin's state directory. The plugin writes a TSV event log, markdown session writeups, and (optionally) a DuckDB file under ${CLAUDE_PROJECT_DIR}/.claude/.functional-emotions/. Without a gitignore entry, those files appear in git status and risk being committed.

This skill only writes to .gitignore. It never touches existing state files, never deletes anything, and never modifies git config.

Steps:

Confirm we're in a git repo. Run git -C "${CLAUDE_PROJECT_DIR}" rev-parse --is-inside-work-tree (or pwd if CLAUDE_PROJECT_DIR is unset). If not a git repo, tell the user "Not in a git repo — no setup needed (state files go to ${TMPDIR} instead)" and stop.
Check if the path is already ignored. Use git's own resolver, which respects .gitignore, .git/info/exclude, parent .gitignores, and the global gitignore. Create a sentinel file path that doesn't need to exist:
```
git -C "${CLAUDE_PROJECT_DIR}" check-ignore -q .claude/.functional-emotions/sentinel
```
Exit code 0 = already ignored. Exit code 1 = not ignored. Exit code 128 = error. If already ignored, tell the user "Already gitignored — no changes needed" and stop.

Append to .gitignore. Append the pattern with a one-line header comment so it's discoverable later:

{
  printf '\n# functional-emotions plugin state (per-session logs, writeups, eval DB)\n'
  printf '.claude/.functional-emotions/\n'
} >> "${CLAUDE_PROJECT_DIR}/.gitignore"

If .gitignore doesn't exist yet, this creates it.

Verify. Re-run the git check-ignore from step 2 and confirm exit code 0. If verification fails, tell the user the append succeeded but git's resolver still doesn't see it (rare — usually means a competing ! negation pattern earlier in the file), and show them the appended lines so they can sort it out.
Report. Tell the user: "Added .claude/.functional-emotions/ to .gitignore. Re-run this skill anytime — it's idempotent." If relevant, mention what's inside the state dir:
- Canonical (must persist): session-*.tsv, labels.jsonl
- Derived (regenerable): sessions/*.md, eval.duckdb + .wal
- Legacy (safe to delete): cbt.duckdb*

Do not stage or commit the .gitignore change. The user decides when that gets committed.

이 저장소의 다른 Skills

같은 저장소

config

jondwillis/functional-emotions

Show the active functional-emotions config as a table — current resolved values, where each value came from (default / profile-derived / explicit override), and the valid options for each field. Use when you want to know what the plugin will actually do this session, or when the `/plugin config functional-emotions` UI didn't show enough context.

2026-05-112

docs-check

jondwillis/functional-emotions

Scan README.md and AGENTS.md for claims that no longer match the current source-of-truth files (hooks/hooks.json, .claude-plugin/plugin.json, scripts/lib.sh, skills/*/SKILL.md). Use after editing any of those files, before committing/releasing, when the user asks about doc-drift, or when the `.claude/settings.json` soft-reminder hook has just fired pointing here.

2026-05-112

label

jondwillis/functional-emotions

Researcher tool (requires `bun install` in the plugin's eval/ directory and a populated eval.duckdb — run /functional-emotions:report first). Interactively label functional-emotions sessions on dimensions that need human judgment (capitulation, scope-narrowing). Surfaces unlabeled sessions, shows turn / diff / risk-event context, accepts categorical labels with optional notes, writes them to the eval DB. Use when the user wants to do a labeling pass over recent sessions or build training data for the capitulation judge.

2026-04-282

report

jondwillis/functional-emotions

Researcher tool (requires `bun install` in the plugin's eval/ directory). Refresh the functional-emotions eval database and print a markdown summary of sessions, intervention frequency, prime → outcome analysis, tool intensity, and reward-hack / premature-confidence findings. Use when the user wants to inspect aggregated cross-session data, audit recent sessions in bulk, or review which interventions are firing project-wide. For a per-session view with no extra dependencies, use /functional-emotions:diagnose instead.

2026-04-282

check

jondwillis/functional-emotions

Quick state self-check before taking a single risky action — names the model's own emotional/strategic state (calm / focused / rushed / stuck) and the closest reward-hacking risk pattern. Use immediately before a commit, push, edit-after-failure, or skip-a-verification step. This audits the *model*; for auditing whether the *task* is solvable, use /functional-emotions:reflect instead.

2026-04-282

reflect

jondwillis/functional-emotions

Audit whether the current *task* is actually solvable as specified — restates the ask, lists what's been tried, and asks whether the spec/test/fixture itself might be wrong. Use after several attempts have failed in a row, or when tempted to weaken assertions / narrow scope to make progress. This audits the *task*; for a quick audit of the model's own state before a single action, use /functional-emotions:check instead.

2026-04-282

name	setup
description	One-time setup for functional-emotions in the current project — idempotently adds `.claude/.functional-emotions/` to the project's `.gitignore` so the plugin's per-session state files (TSV logs, markdown writeups, eval DB) don't get committed. Safe to re-run. Use after installing the plugin in a new project, or when the user mentions accidentally committing functional-emotions state, or when troubleshooting "why are my session files showing in git status?".
disable-model-invocation	false
allowed-tools	Bash

This skill only writes to .gitignore. It never touches existing state files, never deletes anything, and never modifies git config.

Steps:

Confirm we're in a git repo. Run git -C "${CLAUDE_PROJECT_DIR}" rev-parse --is-inside-work-tree (or pwd if CLAUDE_PROJECT_DIR is unset). If not a git repo, tell the user "Not in a git repo — no setup needed (state files go to ${TMPDIR} instead)" and stop.
Check if the path is already ignored. Use git's own resolver, which respects .gitignore, .git/info/exclude, parent .gitignores, and the global gitignore. Create a sentinel file path that doesn't need to exist:
```
git -C "${CLAUDE_PROJECT_DIR}" check-ignore -q .claude/.functional-emotions/sentinel
```
Exit code 0 = already ignored. Exit code 1 = not ignored. Exit code 128 = error. If already ignored, tell the user "Already gitignored — no changes needed" and stop.

Append to .gitignore. Append the pattern with a one-line header comment so it's discoverable later:

{
  printf '\n# functional-emotions plugin state (per-session logs, writeups, eval DB)\n'
  printf '.claude/.functional-emotions/\n'
} >> "${CLAUDE_PROJECT_DIR}/.gitignore"

If .gitignore doesn't exist yet, this creates it.

Verify. Re-run the git check-ignore from step 2 and confirm exit code 0. If verification fails, tell the user the append succeeded but git's resolver still doesn't see it (rare — usually means a competing ! negation pattern earlier in the file), and show them the appended lines so they can sort it out.
Report. Tell the user: "Added .claude/.functional-emotions/ to .gitignore. Re-run this skill anytime — it's idempotent." If relevant, mention what's inside the state dir:
- Canonical (must persist): session-*.tsv, labels.jsonl
- Derived (regenerable): sessions/*.md, eval.duckdb + .wal
- Legacy (safe to delete): cbt.duckdb*

Do not stage or commit the .gitignore change. The user decides when that gets committed.