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).
日本語の概要は準備中です。原文の説明を表示しています。
Persistent cross-session knowledge base. Manages per-project learnings that compound across sessions — patterns, pitfalls, preferences, and project quirks. The agent gets smarter on your codebase over time. At session start, searches relevant learnings. During sessions, logs discoveries. Supports review, search, prune, and export. Use proactively when the agent encounters a durable project quirk, user preference, or pattern that would save 5+ minutes next time. Also use at session start to recover context. Triggers: "remember this", "log this", "what have we learned?", "show learnings".
インストールする前に、エージェントに与えられる指示の中身を確認できます。
You manage the persistent knowledge that makes the agent smarter across sessions.
Each project gets a learnings.jsonl file. Learnings compound — the agent reads
relevant entries at session start and logs new discoveries during work.
This is the memory the agent keeps between conversations.
Session 1 Session 2 Session 3
───────── ───────── ─────────
Works on auth flow Reads auth learnings Reads auth + api learnings
Logs: "JWT stored in (max 3, scored by (max 3, old ones decay)
httpOnly cookie" relevance + decay) Reinforces auth learning
Applies session 1 learning → it lives longer
Logs: "Rate limiting
uses token bucket"
Each session builds on previous knowledge. The agent gets faster without context rot because:
Each entry is a JSONL line:
{
"ts": "2026-04-29T10:30:00Z",
"type": "pattern|pitfall|preference|quirk|operational",
"key": "kebab-case-identifier",
"insight": "Human-readable description of what was learned",
"confidence": 8,
"source": "observed|user-stated|inferred",
"files": ["path/to/relevant/file.ts"],
"skill": "skill-name-if-from-skill",
"branch": "feature/auth",
"tags": ["auth", "security"]
}
| Type | When to use | Example |
|---|---|---|
pattern | Recurring code/arch pattern | "Error responses always use {error, message, code} format" |
pitfall | Thing that broke and will break again | "Environment variables in Next.js need NEXT_PUBLIC_ prefix for client" |
preference | User's stated taste/choice | "Prefers explicit error handling over try/catch wrappers" |
quirk | Project-specific weirdness | "Port 3000 conflicts with AirPlay on macOS — use 3001" |
operational | Command/fix that saves time | "Database reset: npm run db:reset && npm run db:seed" |
At the start of every session, get a tight context snippet — never the full file:
# This is what the agent calls. Returns at most 3 lines, or nothing.
python3 -c "
from distr.core.learnings.keeper import get_context_learnings
ctx = get_context_learnings()
if ctx:
print(ctx)
else:
print('LEARNINGS: 0 relevant')
"
Output: at most 3 lines like [learnings] key: insight. If nothing relevant,
returns None — inject nothing into context. The agent stays lean.
Log a learning when:
Do NOT log:
from distr.core.learnings.keeper import log_learning
log_learning(
entry_type="pitfall",
key="auth-middleware-swallows-errors",
insight="auth.ts middleware returns 200 with empty body on token expiry instead of 401. Check for empty response bodies.",
confidence=9,
source="observed",
files=["distr/core/auth/middleware.py"],
tags=["auth", "security"],
)
After discovering that the auth middleware swallows errors silently:
Logged learning: "auth-middleware-swallows-errors"
Type: pitfall
Insight: "auth.ts middleware returns 200 with empty body on token expiry instead of 401. Check for empty response bodies in auth flow."
Confidence: 9/10
When a learning proves useful — the agent applied it and it worked — reinforce it. This bumps its score so it survives staleness decay longer:
from distr.core.learnings.keeper import reinforce_learning
reinforce_learning("auth-middleware-swallows-errors")
3+ reinforcements make a learning survive pruning indefinitely.
When the user asks "what have we learned about X?":
Search learnings by:
- Key substring: grep "auth" learnings.jsonl
- Tag: grep "security" learnings.jsonl
- Recent: tail -20 learnings.jsonl
- By file: grep "middleware/auth.ts" learnings.jsonl
Output format:
LEARNINGS: "auth" (3 matches)
═══════════════════════════════
[2026-04-15] pitfall | auth-middleware-swallows-errors (confidence: 9/10)
auth.ts middleware returns 200 with empty body on token expiry...
[2026-04-20] pattern | jwt-storage-strategy (confidence: 8/10)
JWTs stored in httpOnly cookies, never localStorage. Refresh tokens...
Periodically (every 10+ sessions), offer to prune:
Ask: "N learnings may be stale. Review and prune?" Options: yes, no, auto-prune low-confidence.
When enabled by user preference, search learnings from OTHER projects on the same machine. This finds patterns that apply across codebases.
# Cross-project search
for dir in ~/.decisions/learnings/*/; do
if [ "$dir" != "~/.decisions/learnings/$SLUG/" ]; then
echo "--- $(basename $dir) ---"
tail -3 "$dir/learnings.jsonl" 2>/dev/null
fi
done
User controls via: "enable cross-project" / "disable cross-project".
Privacy: Cross-project search stays local. No data leaves the machine.
# Export all learnings as readable markdown
echo "# Learnings for $SLUG" > learnings-export.md
echo "" >> learnings-export.md
while IFS= read -r line; do
echo "## $(echo "$line" | jq -r '.key') ($(echo "$line" | jq -r '.type'))"
echo ""
echo "> $(echo "$line" | jq -r '.insight')"
echo ""
echo "Confidence: $(echo "$line" | jq -r '.confidence')/10 | Source: $(echo "$line" | jq -r '.source') | Date: $(echo "$line" | jq -r '.ts')"
echo ""
done < "$LEARN_FILE" >> learnings-export.md
session-retro and ceo-scope-review search learnings for contextsystematic-debugging searches for similar past bugspre-flight-review checks learnings for known pitfallssession-retro logs top 3 patterns as learningsThis makes every skill smarter over time — learnings are the common substrate.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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`.
日本語の概要は準備中です。原文の説明を表示しています。