القائمة
Use when generating or updating API documentation that follows the OpenAPI specification — daily sync that adds new endpoints to the catalog, notes key changes, and bumps the version.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when preparing notes for a 1:1 with a report, drafting written feedback, or summarizing a person's recent work/contributions ahead of a conversation or review cycle.
Use when asked to generate or update architecture diagrams or ER (entity-relationship) diagrams from the codebase — the code is the source of truth, not existing docs.
Use when the user asks how to reduce Claude Code costs, manage token usage, choose the right model for a task, or wants a review of whether a session/workflow is running efficiently.
Use when the user asks for a standup update, daily summary, "what did I work on yesterday", or wants to recap recent commits before a team sync.
Use when investigating a bug, test failure, or unexpected behavior and proposing a fix — always runs investigation in Plan Mode so no code changes happen until the root cause and approach are confirmed.
Use when writing or reviewing code that crosses a trust boundary (user input, external APIs, file/network/DB I/O) — guards against invalid input, injection, unsafe failure modes, and missing validation at the edges without over-defending internal code.
| name | openapi-doc-sync |
| description | Use when generating or updating API documentation that follows the OpenAPI specification — daily sync that adds new endpoints to the catalog, notes key changes, and bumps the version. |
Keeps an OpenAPI-spec-following doc set current with the codebase — the codebase is the source of truth, the spec follows it, not the other way around.
Find the API surface in code (routers/controllers/handlers — search for
route decorators/registrations) and the existing spec file(s)
(openapi.yaml/openapi.json or generated docs directory).
Diff reality vs. spec:
Update the spec following OpenAPI conventions:
paths, parameters, requestBody, responses, components/schemastags aligned with the existing catalog groupingBump info.version (semver: patch for additive/non-breaking, minor for new
endpoints, major for breaking changes) and append to a changelog section:
## v<version> — <date>
- Added: `POST /v2/widgets` (new endpoint)
- Changed: `GET /users/{id}` now returns `roles[]` (was single `role`)
- Deprecated: `GET /v1/legacy-search` (superseded by `/v2/search`)
Show the diff for review — don't merge spec changes silently, especially anything marked "Changed" or "Deprecated" (those affect consumers).
/schedule for a daily run (e.g. after the nightly build/merge).