القائمة
Write and update documentation: README, API docs, ADRs, inline docs, and runbooks. Use when the user asks to document this, update README, write API docs, write ADR, or add inline documentation.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Complete development workflow from planning to GitHub PR using PARA methodology and RLM for large codebases. Use when implementing a feature, fixing a bug, refactoring, or taking work from plan to GitHub PR.
Analyze and improve performance: profile, find bottlenecks, optimize, and instrument code with observability for diagnosing performance issues (profiling, bottleneck tracing). Use when the user asks about performance, slow code, bottlenecks, profiling, optimization, or adding performance-specific observability.
Design and implement tests (unit, integration, e2e, accessibility, i18n), improve coverage, and run test suites. Use when the user asks to add tests, write tests, improve coverage, run tests, test accessibility, test translations, or implement test strategy.
Configure and fix CI/CD pipelines: build, test, lint, deploy, database migrations, environment config, observability setup (log shipping, metric collection, alert configuration), and releases. Use when the user asks about CI, pipeline, GitHub Actions, deploy, fix the build, environment variables, monitoring setup, or release process.
Debug failures systematically: reproduce, hypothesize, bisect, and fix. Use when the user reports a bug, asks why something fails, or wants to find the root cause.
Write commit messages, changelogs, release notes, and manage versioning following Conventional Commits with required scope. Use when the user asks for a commit message, changelog, release notes, versioning, tagging, or how to format commits.
| name | documentation |
| description | Write and update documentation: README, API docs, ADRs, inline docs, and runbooks. Use when the user asks to document this, update README, write API docs, write ADR, or add inline documentation. |
| triggers | ["/docs","document this","update README","write README","API docs","write ADR","architecture decision","add comments","inline docs","runbook"] |
"Docs that stay in sync with code and intent."
Write documentation that is accurate, scannable, and updated when behavior changes. Prefer living docs over one-off writeups.
| Type | Use for | Location / format |
|---|---|---|
| README | Project overview, setup, usage | Root README.md |
| API docs | Endpoints, params, responses | OpenAPI/Swagger, or docs/api.md |
| ADR | Architecture decisions and rationale | docs/adr/ or context/adr/ |
| Inline | Public APIs, non-obvious logic | Code comments, docstrings |
| Runbook | Operational procedures | docs/runbooks/ or docs/ops/ |
No mandatory commands. Use project structure: if docs/ or CONTRIBUTING.md exists, follow existing layout and style.
When documentation lives in Confluence or the user wants to sync with Confluence, use the Atlassian MCP (after /setup) to fetch pages, search with CQL, and create/update content. Key tools:
confluence_search - Search Confluence content using simple terms or CQLconfluence_get_page - Get content of a specific page by ID or title+spaceconfluence_create_page - Create a new page in a space (supports Markdown)confluence_update_page - Update an existing pageconfluence_get_page_children - Get child pages for navigationconfluence_get_comments - Get comments on a pageconfluence_add_comment - Add a comment to a pageEnsure /setup has been run so Atlassian MCP is configured.
When adding or updating docs, provide the content and say what was created/updated. If the project has a docs style guide, follow it.
When writing ADRs, follow this structure:
# ADR-NNN: [Decision Title]
**Date:** YYYY-MM-DD
**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-NNN
## Context
[What is the issue or situation that motivates this decision?]
## Decision
[What is the decision that was made?]
## Consequences
**Positive:**
- [Benefits of this decision]
**Negative:**
- [Trade-offs and costs]
**Neutral:**
- [Other implications]
Number ADRs sequentially. Store in docs/adr/ or context/adr/. Reference from plans and summaries when relevant.
When documenting APIs with versioning:
/v1/, header Accept-Version, query param).When code is refactored, update affected documentation:
| Situation | Skill to invoke |
|---|---|
| Documenting API changes | architect skill (for tech spec) |
| Writing architectural decisions | Use ADR format above |
| Syncing docs to Confluence | Use Atlassian MCP tools (after /setup) |
| Code needs inline documentation | code-reviewer can flag gaps |