القائمة
Generate a new Architecture Decision Record from a topic, decision description, or rough notes
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 | adr |
| description | Generate a new Architecture Decision Record from a topic, decision description, or rough notes |
User runs /adr followed by a topic, decision description, or rough notes.
/decisions/ for existing ADRs — assign next sequential number/templates/adr/ADR-TEMPLATE.md/decisions/ADR-XXXX-short-title.mdADR-XXXX-title.md? I can also generate a follow-up ADR for any of the alternatives."Every ADR must be actionable. If the context section is vague, say so and ask for the specific driver (business need, technical constraint, or incident) before proceeding. Never produce an ADR that reads like a blog post — it should read like a decision log.