furedea

adr

Architecture Decision Record (ADR) operation skill. Load when a task involves architectural decisions, decision records, ADRs, docs/adr/, library or framework selection, durable project constraints, rejected alternatives, superseding or deprecating previous decisions, or when TSDD says a broad Why belongs in an ADR. This skill turns decision-relevant changes into docs/adr/ entries instead of leaving ADR creation implicit.

bash-style

Bash script coding conventions and bats testing: shebang (#!/bin/bash), set -euxCo pipefail, cd "$(dirname "$0")", usage function with heredoc, readonly constants, SCREAMING_SNAKE_CASE constants, snake_case variables/functions, _snake_case local variables, bats test structure (test-helper/, setup/teardown lifecycle, run/status/output assertions). Load whenever writing, reviewing, or refactoring any Bash script (.sh files, shell scripts) or bats test (.bats files) — new files, bug fixes, function design, project setup, writing tests. Also load when PLANNING or DISCUSSING Bash/shell script implementation or test design, even before any code is written. Without this skill, you will use wrong conventions (missing set flags, wrong naming, no usage function, no readonly, wrong test directory structure) that this user explicitly does not want.

gha-style

GitHub Actions workflow coding conventions: security-critical patterns including permissions, action version pinning, script injection prevention, timeout, shell settings, and concurrency. Load whenever writing or reviewing .github/workflows/*.yml, creating composite actions (.github/actions/), or discussing CI/CD pipeline design. Trigger on: workflow yaml, github actions, CI/CD, .yml in .github/, actions/checkout, ubuntu-latest, workflow_dispatch, on: push, on: pull_request, jobs:, steps:, run:.

git-commit-split

Explicit `/git-commit-split` workflow for organizing an already-dirty working tree into multiple intent-grained commits, optionally pairing each commit with its own branch and PR. Use only when invoked as the custom command or when the user explicitly asks to split pending changes, create one feature per commit, or create one PR per feature. General branch naming, commit granularity, and Conventional Commits rules live in git-workflow; this command owns mode selection, dirty-tree inspection, hunk splitting, plan approval, and execution.

git-workflow

Day-to-day Git workflow for code changes, branches, commits, and delivery safety. Use before code changes or branch/commit work, or when the user says "実装", "修正", "直して", "リファクタ", "追加", "更新", "ブランチ", "branch", "コミット", or "commit". Establishes feature-branch naming, Conventional Commits, one-intent commits, TSDD-friendly commit boundaries, and safe push behavior.

github-ci-init

GitHub Actions CI scaffolding for this user. Installs the curated "default adopted set" — release-please, Claude Code Action (@claude mentions + automated PR review) — by copying bundled workflow templates into a repository's `.github/`. Load whenever the user wants to add CI, GitHub Actions, automated quality checks, release-please, Claude Code Action, automated code review, or retrofit CI onto an existing repository. This skill is DISTINCT from `gha-style` (which covers the coding conventions for writing and editing individual workflow files) — load THIS one for the initial scaffolding (the "which workflows ship and where do they go" decision), then hand off to `gha-style` for any per-file editing afterwards. Also trigger on "/github-ci-init", "set up CI", "add GitHub Actions", "release-please", "claude code action", "claude code review", "@claude workflow", "artifact attestation", "build provenance", "SLSA", ".github/workflows/", or any mention of project-level CI bootstrap.

marp-style

Create Marp presentation slide decks in Markdown. Use this skill whenever the user wants to make slides, a presentation, a deck, or a slideshow — even if they don't say "Marp" explicitly. Also trigger for requests like "研究発表のスライドを作って", "プレゼン資料を作りたい", "勉強会のスライドを作って", "スライドのドラフトを作って", or any context where the output is a slide deck. This skill enforces the user's established Marp format conventions (base theme, 4:3, paginate) so always load it for slide creation tasks.

nix-dev-init

Per-project development environment bootstrap workflow for this user: github/create_repo.sh --template → direnv allow → language sync/build inside the direnv-activated shell. ALWAYS load when starting a new project, initializing a repo, scaffolding dev tooling, or writing project-level flake.nix / .envrc / devShell. Also load when the user asks to use or reference template-python, template-typescript, template-rust, template-tex, template-minimal, or configure an existing project from a template. This skill is DISTINCT from `nix-dotfiles` (global dotfiles system config under ghq); load THIS for project-scoped devShells. Without it, Claude or Codex may run language tools on the host shell and leak host toolchain versions into lockfiles. Supported language templates live under furedea/ and are used via `github/create_repo.sh --template`. Also trigger on "/nix-dev-init", "new project", "set up dev environment", or any mention of creating a flake.nix for a project.

Data & Documents Listed

nix-dotfiles

Nix configuration reference for nix-darwin + home-manager on Apple Silicon macOS. ALWAYS load when the user says "dotfiles" — dotfiles here means nix-managed config. Load for: adding packages, configuring programs, dotfile symlinks, macOS system defaults, activation scripts, unfree packages, darwin-rebuild, home-manager switch, homebrew casks/brews, or any macOS app preference/shortcut change (app prefs like Homerow, Raycast, Ghostty are managed via system.defaults in nix/darwin/default.nix, NOT edited directly). Skip only for standalone non-.nix config files (karabiner.json, starship.toml, nvim/) needing no nix rebuild. Trigger on: "dotfiles", flake.nix, nix/home/default.nix, nix/darwin/default.nix, nixpkgs, home-manager, programs.*, homebrew.casks, homebrew.brews, mkOutOfStoreSymlink, allowUnfree, darwin-rebuild, system.defaults, "nix で管理", "add to nix", app shortcut/preference updates.

python-style

Python coding conventions: uv commands (sync/add/run), pytest, ruff, ty, pytest-mock with autospec, src/ layout, dataclass Value Objects (frozen=True, slots=True), naming, imports, docstrings. Load whenever writing, reviewing, refactoring, linting, typechecking, testing, or PLANNING Python code — even in plan mode, before any code exists. Also load for Python test environment discussions such as pytest, uv run --with pytest, ruff, or ty. Do NOT use for project bootstrap (`uv init`, flake.nix, initial `pyproject.toml` scaffolding) — that is `nix-dev-init`'s job. Without this skill, Claude or Codex falls back to pip, unittest.mock, and wrong class patterns this user rejects.

rust-style

Rust coding conventions: Cargo commands, package layout, tests, rustfmt/clippy, anyhow/thiserror error boundaries, newtypes, enums, ownership, Path/PathBuf filesystem rules, serde config handling, naming, comments, and docs. Load whenever writing, reviewing, refactoring, linting, testing, or discussing Rust code or Rust project style inside an already-bootstrapped project. Do NOT use for initial Nix, direnv, or Cargo project bootstrap; use nix-dev-init first.

skill-auditor

Analyzes Claude Code or Codex session transcripts to evaluate skill portfolio health — routing errors, attention competition between descriptions, and coverage gaps. Generates an interactive HTML report with per-skill health cards, competition matrix, attention budget analysis, and actionable patches. Unlike skill-creator which optimizes individual skills in isolation, skill-auditor optimizes the portfolio as a system, detecting cross-skill attention theft and cascade risks. Use when user says "audit my skills", "skill audit", "run skill-auditor", "analyze skill routing", "check skill competition", "portfolio health", "スキル監査", "スキルの精度を分析", "スキルルーティング分析".

Testing & QA Listed

tsdd

Test-Spec Driven Development (TSDD): tests are the durable specification, TDD is the operating discipline, prose carries only Why, and `CLAUDE.md` stays a navigation map. Load before production code, tests, ADRs, architectural decisions, `CLAUDE.md` edits, or any durable prose artifact that would duplicate tests or code. Also load when the user asks to write tests or define test behavior before implementation, including "test 書いて", "test 書いて", "テスト書いて", "pytest", "テスト環境", "TSDD", "Test-Spec Driven Development", "TDD で実装", "ADR を書いて", "decision record", or "executable specification".