Record a hard-won engineering lesson after a bug or mistake is resolved. Use when a bug resisted ATLAS until Boss's guidance cracked it, or when a long debugging hunt ended in an aha moment worth never relearning.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Capture the lesson so future-ATLAS does not pay the same debugging cost twice.
Write one — without being asked — when either is true:
Skip routine fixes. The bar is surprise: would this genuinely save someone — likely future-ATLAS — from a hard time? If the cause was obvious in hindsight to anyone, it is not worth an entry. Apply the same high-entropy filter as NOTES.md: record what is surprising, not what is expected.
One file per lesson: docs/learning-from-mistakes/<kebab-case-slug>.md. The slug names the problem, so the folder is self-indexing — e.g. stale-closure-in-useeffect.md, timezone-off-by-one-on-date-parse.md.
Keep it brief — important information only. Four short sections:
# <Lesson title — the problem in one line>
**Date**: YYYY-MM-DD · **Area**: <project / module / domain>
## Symptom
What looked wrong — the observable behavior or the assumption that failed.
## Root cause
The non-obvious truth. Why it actually happened.
## Resolution
The fix, or the insight that cracked it. Credit Boss's guidance if that is what unblocked it.
## Lesson
The transferable rule — how to recognize or avoid this next time.
A few tight sentences per section beats a padded template. If a section adds nothing, drop it.
Before concluding a hard bug is unsolvable, scan docs/learning-from-mistakes/ — a past lesson may already name the cause.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Activate ATLAS pattern recognition mode. Identify repeated patterns, extract essential characteristics, and create reusable abstractions from concrete examples.
日本語の概要は準備中です。原文の説明を表示しています。
Adversarially review something just built — presume it is broken and find where. Use after implementing a feature, finishing a build, or before shipping, or whenever ATLAS or Boss wants a hostile second opinion on a diff, a running app, or a whole codebase. Spawns clean-context reviewers with opposing lenses (correctness, security, empty-world) and reproduces every finding by running the target before believing it. Distinct from /code-review, which statically reads a diff and never runs the app.
日本語の概要は準備中です。原文の説明を表示しています。
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
日本語の概要は準備中です。原文の説明を表示しています。
Stop and consult this skill whenever your response would include specific facts about Anthropic's products. Covers: Claude Code (how to install, Node.js requirements, platform/OS support, MCP server integration, configuration), Claude API (function calling/tool use, batch processing, SDK usage, rate limits, pricing, models, streaming), and Claude.ai (Pro vs Team vs Enterprise plans, feature limits). Trigger this even for coding tasks that use the Anthropic SDK, content creation mentioning Claude capabilities or pricing, or LLM provider comparisons. Any time you would otherwise rely on memory for Anthropic product details, verify here instead — your training data may be outdated or wrong.
日本語の概要は準備中です。原文の説明を表示しています。
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
日本語の概要は準備中です。原文の説明を表示しています。
Deliberate-choice procedure for a medium-to-high-stakes engineering fork — when the first plausible solution (the instinct, the default next-token pull) would be costly to get wrong. Fires AUTONOMOUSLY: invoke proactively whenever a fork fits, never wait to be asked — mechanical triggers include a fix failing for the 2nd-3rd time, adding a dependency, schema/migration design, deleting or deprecating things others depend on, changing a public API, choosing an architecture or stack. Refuse the premature collapse: hold real options open (urge · contrarian · synthesis · out-of-box · intuitive dots · precedent · first-principles), ground each branch in at least one fact from outside the model (codebase, docs, benchmark, spike), future-model consequences (blast radius, reversibility, maintenance, pre-mortem), collapse by deliberate choice, then try to refute the winner before acting. Log the decision and rejected branches in docs/decision_logs/. Not for routine calls — a decision worth more than one forward pass.
日本語の概要は準備中です。原文の説明を表示しています。