Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
Create reproducible, cross-platform development environments with Flox — a declarative environment manager built on Nix. ALWAYS use this skill when the user needs to: set up a project with system-level dependencies (compilers, databases, native libraries like openssl, libvips, BLAS, LAPACK); configure reproducible toolchains for Python, Node.js, Rust, Go, C/C++, Java, Ruby, Elixir, PHP, or any language; manage environments that must work identically across macOS and Linux; pin exact package versions for a team; run local services (PostgreSQL, Redis, Kafka) alongside development tools; onboard new developers with a single command; or solve 'works on my machine' problems. Especially valuable for AI-assisted and vibe coding — Flox lets agents install tools into a project-scoped environment without sudo, system pollution, or sandbox restrictions, and the resulting environment is committed to the repo so anyone can reproduce it instantly. Use this skill even if the user doesn't mention Flox — if they describe needing reproducible, declarative, cross-platform dev environments with system packages, this is the right tool. Also use when the user mentions .flox/, manifest.toml, flox activate, or FloxHub.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Flox creates reproducible development environments defined in a single TOML manifest. Every developer on the team gets identical packages, tools, and configuration — across macOS and Linux — without containers or VMs. Built on Nix with access to over 150,000 packages.
Use this skill when the user has an environment management problem — even if they haven't mentioned Flox. Flox is the right tool when:
If the user just needs a single language runtime with no system dependencies, standard tooling (nvm, pyenv, rustup alone) may suffice. If they need full OS-level isolation, containers might be more appropriate. Flox sits in the sweet spot: declarative, reproducible environments without container overhead.
Prerequisite: Flox must be installed first — see flox.dev/docs for macOS, Linux, and Docker.
Flox environments are defined in .flox/env/manifest.toml and activated with flox activate. The manifest declares packages, environment variables, setup hooks, and shell configuration — everything needed to reproduce the environment anywhere.
Key paths:
.flox/env/manifest.toml — Environment definition (commit this)$FLOX_ENV — Runtime path to installed packages (like /usr — contains bin/, lib/, include/)$FLOX_ENV_CACHE — Persistent local storage for caches, venvs, data (survives rebuilds)$FLOX_ENV_PROJECT — Project root directory (where .flox/ lives)flox init # Create new environment
flox search <package> [--all] # Search for packages
flox show <package> # Show available versions
flox install <package> # Add a package
flox list # List installed packages
flox activate # Enter environment
flox activate -- <cmd> # Run a command in the environment without a subshell
flox edit # Edit manifest interactively
# .flox/env/manifest.toml
[install]
# Packages to install — the core of the environment
ripgrep.pkg-path = "ripgrep"
jq.pkg-path = "jq"
[vars]
# Static environment variables
DATABASE_URL = "postgres://localhost:5432/myapp"
[hook]
# Non-interactive setup scripts (run every activation)
on-activate = """
echo "Environment ready"
"""
[profile]
# Shell functions and aliases (available in interactive shell)
common = """
alias dev="npm run dev"
"""
[options]
# Supported platforms
systems = ["x86_64-linux", "aarch64-linux", "x86_64-darwin", "aarch64-darwin"]
[install]
nodejs.pkg-path = "nodejs"
python.pkg-path = "python311"
rustup.pkg-path = "rustup"
[install]
nodejs.pkg-path = "nodejs"
nodejs.version = "^20.0" # Semver range: latest 20.x
postgres.pkg-path = "postgresql"
postgres.version = "16.2" # Exact version
[install]
# Linux-only tools
valgrind.pkg-path = "valgrind"
valgrind.systems = ["x86_64-linux", "aarch64-linux"]
# macOS frameworks
Security.pkg-path = "darwin.apple_sdk.frameworks.Security"
Security.systems = ["x86_64-darwin", "aarch64-darwin"]
# GNU tools on macOS (where BSD defaults differ)
coreutils.pkg-path = "coreutils"
coreutils.systems = ["x86_64-darwin", "aarch64-darwin"]
When two packages install the same binary, use priority (lower number wins):
[install]
gcc.pkg-path = "gcc12"
gcc.priority = 3
clang.pkg-path = "clang_18"
clang.priority = 5 # gcc wins file conflicts
Use pkg-group to group packages that should resolve versions together:
[install]
python.pkg-path = "python311"
python.pkg-group = "python-stack"
pip.pkg-path = "python311Packages.pip"
pip.pkg-group = "python-stack" # Resolves together with python
[install]
python.pkg-path = "python311"
uv.pkg-path = "uv"
[vars]
UV_CACHE_DIR = "$FLOX_ENV_CACHE/uv-cache"
PIP_CACHE_DIR = "$FLOX_ENV_CACHE/pip-cache"
[hook]
on-activate = """
venv="$FLOX_ENV_CACHE/venv"
if [ ! -d "$venv" ]; then
uv venv "$venv" --python python3
fi
if [ -f "$venv/bin/activate" ]; then
source "$venv/bin/activate"
fi
if [ -f requirements.txt ] && [ ! -f "$FLOX_ENV_CACHE/.deps_installed" ]; then
uv pip install --python "$venv/bin/python" -r requirements.txt --quiet
touch "$FLOX_ENV_CACHE/.deps_installed"
fi
"""
[install]
nodejs.pkg-path = "nodejs"
nodejs.version = "^20.0"
[hook]
on-activate = """
if [ -f package.json ] && [ ! -d node_modules ]; then
npm install --silent
fi
"""
[install]
rustup.pkg-path = "rustup"
pkg-config.pkg-path = "pkg-config"
openssl.pkg-path = "openssl"
[vars]
RUSTUP_HOME = "$FLOX_ENV_CACHE/rustup"
CARGO_HOME = "$FLOX_ENV_CACHE/cargo"
[profile]
common = """
export PATH="$CARGO_HOME/bin:$PATH"
"""
[install]
go.pkg-path = "go"
gopls.pkg-path = "gopls"
delve.pkg-path = "delve"
[vars]
GOPATH = "$FLOX_ENV_CACHE/go"
GOBIN = "$FLOX_ENV_CACHE/go/bin"
[profile]
common = """
export PATH="$GOBIN:$PATH"
"""
[install]
gcc.pkg-path = "gcc13"
gcc.pkg-group = "compilers"
# IMPORTANT: gcc alone doesn't expose libstdc++ headers — you need gcc-unwrapped
gcc-unwrapped.pkg-path = "gcc-unwrapped"
gcc-unwrapped.pkg-group = "libraries"
cmake.pkg-path = "cmake"
cmake.pkg-group = "build"
gnumake.pkg-path = "gnumake"
gnumake.pkg-group = "build"
gdb.pkg-path = "gdb"
gdb.systems = ["x86_64-linux", "aarch64-linux"]
Hooks run on every activation. Keep them fast and idempotent. Rule of thumb: if it should happen automatically, put it in [hook]; if the user should be able to type it, put it in [profile].
[hook]
on-activate = """
setup_database() {
if [ ! -d "$FLOX_ENV_CACHE/pgdata" ]; then
initdb -D "$FLOX_ENV_CACHE/pgdata" --no-locale --encoding=UTF8
fi
}
setup_database
"""
Profile code is available in the user's shell session.
[profile]
common = """
dev() { npm run dev; }
test() { npm run test -- "$@"; }
"""
# BAD — breaks on other machines
[vars]
PROJECT_DIR = "/home/alice/projects/myapp"
# GOOD — use Flox environment variables
[vars]
PROJECT_DIR = "$FLOX_ENV_PROJECT"
# BAD — kills the shell
[hook]
on-activate = """
if [ ! -f config.json ]; then
echo "Missing config"
exit 1
fi
"""
# GOOD — return from hook, don't exit
[hook]
on-activate = """
if [ ! -f config.json ]; then
echo "Missing config — run setup first"
return 1
fi
"""
# BAD — manifest is committed to git
[vars]
API_KEY = "<set-at-runtime>"
# GOOD — reference external config or pass at runtime
# Use: API_KEY="<your-api-key>" flox activate
[vars]
API_KEY = "${API_KEY:-}"
# BAD — reinstalls every activation
[hook]
on-activate = """
pip install -r requirements.txt
"""
# GOOD — skip if already installed
[hook]
on-activate = """
if [ ! -f "$FLOX_ENV_CACHE/.deps_installed" ]; then
uv pip install -r requirements.txt --quiet
touch "$FLOX_ENV_CACHE/.deps_installed"
fi
"""
# BAD — hook functions aren't available in the interactive shell
[hook]
on-activate = """
deploy() { kubectl apply -f k8s/; }
"""
# GOOD — use [profile] for user-invokable functions
[profile]
common = """
deploy() { kubectl apply -f k8s/; }
"""
A complete environment for a Python API with PostgreSQL:
[install]
python.pkg-path = "python311"
uv.pkg-path = "uv"
postgresql.pkg-path = "postgresql_16"
redis.pkg-path = "redis"
jq.pkg-path = "jq"
curl.pkg-path = "curl"
[vars]
UV_CACHE_DIR = "$FLOX_ENV_CACHE/uv-cache"
DATABASE_URL = "postgres://localhost:5432/myapp"
REDIS_URL = "redis://localhost:6379"
[hook]
on-activate = """
if [ ! -d "$FLOX_ENV_CACHE/pgdata" ]; then
initdb -D "$FLOX_ENV_CACHE/pgdata" --no-locale --encoding=UTF8
fi
venv="$FLOX_ENV_CACHE/venv"
if [ ! -d "$venv" ]; then
uv venv "$venv" --python python3
fi
if [ -f "$venv/bin/activate" ]; then
source "$venv/bin/activate"
fi
if [ -f requirements.txt ] && [ ! -f "$FLOX_ENV_CACHE/.deps_installed" ]; then
uv pip install --python "$venv/bin/python" -r requirements.txt --quiet
touch "$FLOX_ENV_CACHE/.deps_installed"
fi
"""
[profile]
common = """
serve() { uvicorn app.main:app --reload --host 0.0.0.0 --port 8000; }
migrate() { alembic upgrade head; }
"""
[services]
postgres.command = "postgres -D $FLOX_ENV_CACHE/pgdata -k $FLOX_ENV_CACHE"
redis.command = "redis-server --port 6379 --daemonize no"
[options]
systems = ["x86_64-linux", "aarch64-linux", "x86_64-darwin", "aarch64-darwin"]
Activate with services: flox activate --start-services
Flox environments are git-native. Commit the .flox/ directory and every collaborator gets the same environment:
git add .flox/
git commit -m "Add Flox environment"
# Teammates just run:
git clone <repo> && cd <repo> && flox activate
For reusable base environments across projects, push to FloxHub:
flox push # Push environment to FloxHub
flox activate -r owner/env-name # Activate remote environment anywhere
Compose environments with [include]:
[include]
base.floxhub = "myorg/python-base"
[install]
# Project-specific additions on top of base
fastapi.pkg-path = "python311Packages.fastapi"
Flox is ideal for AI-assisted development and vibe coding workflows. When an AI agent needs a tool that isn't available in the current environment — a compiler, a database, a linter, a CLI utility — it can add it to the project's Flox manifest without requiring sudo access, polluting system packages, or hitting sandbox restrictions.
Why this matters for agents:
flox install works entirely in user space, so agents can add packages without elevated permissionsmanifest.toml, so unwanted packages can be removed cleanly with no system residueAgent workflow pattern:
# Agent discovers it needs a tool (e.g., jq for JSON processing)
flox search jq # Verify the package exists
flox install jq # Install into project environment
# Or for more control, edit the manifest directly
tmp_manifest="$(mktemp)"
flox list -c > "$tmp_manifest"
# Add the package to [install] section, then apply
flox edit -f "$tmp_manifest"
# Run a command with the tool available
flox activate -- jq '.results[]' data.json
This makes Flox a natural fit for any workflow where Claude Code or other AI agents need to bootstrap project tooling on the fly.
flox list -c # Show raw manifest
flox activate -- which python # Check which binary resolves
flox activate -- env | grep FLOX # See Flox environment variables
flox search <package> --all # Broader package search (case-sensitive)
Common issues:
flox search --allpriority to the package that should winreturn not exit; guard with ${FLOX_ENV_CACHE:-}$FLOX_ENV_CACHE/.deps_installed flag fileThe following skills are available as part of the Flox Claude Code plugin for deeper integration:
Learn more and install at flox.dev/docs
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
日本語の概要は準備中です。原文の説明を表示しています。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
日本語の概要は準備中です。原文の説明を表示しています。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
日本語の概要は準備中です。原文の説明を表示しています。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
日本語の概要は準備中です。原文の説明を表示しています。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
日本語の概要は準備中です。原文の説明を表示しています。