Menu
Capture session learnings as a structured solution doc in docs/solutions/ — the knowledge flywheel
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Audit a Google ADK tool file against the five known gotchas (DI params, thin wrappers, _j helper, async-wrap blocking calls, httpx context manager) before they bite in production
After creating an ADR, run the cross-referencing checklist — update README Artifacts table, add Related Decisions section to source proposal, cross-link sibling ADRs to each other
Mid-task durability — dump current state and a next-step file before context fills, so the next session resumes without re-deriving where you were
Generate and verify a pre-demo checklist for an ADK/agent project — env vars, GCP auth, embedding swap, ngrok/Slack wiring, dry-run, tests, real-vs-synthetic data
Scan a project's docs (README, CLAUDE.md, ADRs, runbooks) for inconsistent project naming, scope, or framing — catches the "README says retail, CLAUDE.md still says Kroger" class of bug
Refresh a project's status — derive current state from code/tests/git, regenerate the project's status memory entry and (if requested) a status section in the README
| name | compound |
| description | Capture session learnings as a structured solution doc in docs/solutions/ — the knowledge flywheel |
Run after completing any meaningful design session, POC, ADR, or implementation work. Extracts what was learned and writes it to docs/solutions/ so future sessions start with context instead of re-deriving it.
User runs /compound after completing a session of work, OR at natural breakpoints in a multi-day effort.
docs/solutions/YYYY-MM-DD-<topic>-solution.mdMEMORY.md should be updated or added based on learnings| Category | Capture when... |
|---|---|
| Why this approach | The chosen pattern wasn't obvious — alternatives were considered and rejected |
| Gotchas | Something didn't work as expected; a constraint emerged mid-session |
| Validated assumptions | Something that was uncertain before this session is now confirmed with evidence |
| Dead ends | Approach tried and abandoned, and why — saves future sessions from retrying |
| Constraints discovered | Platform limits, API behaviors, infra requirements that aren't in docs |
| Open questions | Unanswered questions that the next session should start with |
Date: [today]
Session type: [design / POC / ADR / debug / review]
Related artifacts: [links to ADRs, proposals, brainstorms, PRs]
One paragraph. What exists now that didn't before, or what is resolved now that wasn't.
What alternatives were ruled out and why. What constraint forced this choice.
Bullet list. Each item: what it is, where it bites you, how to avoid it.
What we believed before that we now have evidence for (or against).
What was tried, what failed, why. Short — enough to recognize the trap.
What's still unresolved. What the next session should start by answering.