openaidy

Use when writing or reviewing OpenAidy addon UI code (app/index.html, app/index.js) that calls sdk.ui.* — covers component mounting semantics and composed usage patterns beyond the one-line reference in addon_create's tool description.

Use when calling external REST APIs or querying databases on the user's behalf through available tools or MCP servers — read-only by default, parametrized queries, and confirmation before any write.

Use when reading, extracting from, or generating real-world document files — PDFs, spreadsheets (CSV/Excel/Sheets), and slide decks — with available tools; preserve the source and verify the output.

Use when working with calendars — checking availability, finding meeting times, and creating or updating events through an available calendar integration — with careful timezone handling and confirmation before inviting others.

Use when posting to chat or email on the user's behalf — Slack, Discord, Telegram, or mail — through an available integration. Get the recipient and content right, and confirm before anything goes out.

Use when a task needs a real browser — navigating sites, filling and submitting forms, clicking through flows, extracting page data, or taking screenshots — driving whatever browser tool or MCP server is available.

Use when you need current or external facts — searching the web, reading multiple sources, cross-checking claims, and synthesizing an answer with citations instead of guessing from memory.

Use when writing a git commit message or PR title — format it as a Conventional Commit (type(scope): summary) with a body that explains why, matching this repo's history.

Use when reviewing a diff or pull request — find correctness bugs first, then reuse/simplification cleanups, and report each finding with a concrete failure scenario ranked by severity.

Use before implementing anything non-trivial — turn a task into a short, ordered list of small, verifiable steps with concrete file paths, so work is reviewable before code is written.

Use when implementing a new function, endpoint, bug fix, or behavior change — write a failing test first, then the code, following RED-GREEN-REFACTOR.

Use when a bug, failing test, crash, or wrong output needs fixing — a four-phase method to find the root cause before changing code, instead of guessing.

Instructs the agent to keep all responses brief, structured, and direct

Instructs the agent to break down complex tasks into numbered steps