[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6R80JM63SNQET74RDW8BWA9":3,"skill-same:01M6R80JM63SNQET74RDW8BWA9":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6R80JM63SNQET74RDW8BWA9","solution-documentation",null,"Use this skill whenever the user wants to create a solution documentation or technical specification document. Triggers include: 'create solution doc', 'create solution documentation', 'write solution documentation' , 'write technical spec', 'document this feature', 'create implementation plan', 'write solution approach', or any request to document a set of backend\u002Ffrontend changes, API modifications, database changes, or system enhancements. The output follows a structured, numbered-section format with Objective\u002FAction breakdown, API endpoints, DB changes, and job references. Do NOT use for README files, API reference docs, changelogs, or user-facing manuals.","Ahmed2020SE\u002Fdotfiles","Ahmed2020SE","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F36050778?v=4","01M6R5NQQQ2F5VVCQY0GZ22JC0","Ahmed Abdel Gawad","01M6R5NQVJ6T307TJYWZVTBY7X",0,"MIT","https:\u002F\u002Fgithub.com\u002FAhmed2020SE\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_claude\u002Fskills\u002Fsolution-documentation\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"documentation","solution documentation","specification","frontend","request","implementation plan","action","technical specification","db","feature","do","create","references","files","write","plan","api","doc","SET","database","2026-11-10 10:12:30",false,"---\nname: solution-documentation\ndescription: \"Use this skill whenever the user wants to create a solution documentation or technical specification document. Triggers include: 'create solution doc', 'create solution documentation', 'write solution documentation' , 'write technical spec', 'document this feature', 'create implementation plan', 'write solution approach', or any request to document a set of backend\u002Ffrontend changes, API modifications, database changes, or system enhancements. The output follows a structured, numbered-section format with Objective\u002FAction breakdown, API endpoints, DB changes, and job references. Do NOT use for README files, API reference docs, changelogs, or user-facing manuals.\"\nlicense: MIT\n---\n\n# Solution Documentation Generator\n\n## Overview\n\nThis skill generates structured solution documentation in a consistent, engineering-ready format used for sprint planning, feature specs, and technical handoffs. Each section follows a numbered format with **Objective** and **Action** sub-sections, along with relevant technical details (endpoints, DB changes, jobs, flags, etc.).\n\n---\n\n## Document Structure\n\nA solution document consists of:\n\n1. A **title** or context header (e.g., \"Solution Approach\")\n2. **Numbered sections**, each representing one feature, change, or concern\n3. Each section contains:\n   - A **bold section title** (e.g., `### **1. Modification of the Drug Index Table**`)\n   - `*   **Objective**`: One-sentence goal statement\n   - `*   **Action**`: Detailed steps, sub-bullets, DB changes, job names, endpoints\n4. **API endpoints** formatted inline using bold + code style:\n   - `* endpoint => GET: _**api\u002FResource\u002FMethod?param=value**_`\n5. **Database changes** described as column additions, flag changes, foreign key references\n6. **Background Jobs** referenced by name when applicable\n7. **Flags \u002F Booleans** described with their behavior implications\n\n---\n\n## Prompt Template for Generation\n\nWhen the user provides raw requirements (as bullet points, meeting notes, Jira tickets, or conversation), use the following prompt strategy:\n\n```\nYou are a senior software architect. Convert the following requirements into a structured Solution Documentation.\n\nFORMAT RULES:\n- Number each section starting from 1\n- Use markdown bold for section titles: ### **N. Section Title**\n- Each section MUST have:\n    * **Objective**: [single-sentence goal]\n    * **Action**: [detailed implementation steps as sub-bullets]\n- For API changes, list endpoints using this format:\n    * endpoint => METHOD: _**api\u002FController\u002FAction?param=value**_\n- For DB changes, describe: table name, column name, type, constraint (FK\u002Findex)\n- For jobs, reference the exact job class name\n- For flags, describe what true\u002Ffalse means in behavior\n- Keep language technical but concise\n- Do NOT add sections not implied by the requirements\n- Maintain YAGNI — only document what is needed\n\nINPUT:\n[paste raw requirements here]\n```\n\n---\n\n## Section Templates\n\n### Standard Feature Section\n\n```markdown\n### **N. [Short Descriptive Title]**\n\n*   **Objective**: [One sentence describing the goal of this change.]\n*   **Action**: [High-level description of what needs to be done.]\n    *   [Sub-step or detail]\n    *   [Sub-step or detail]\n    *   endpoint => GET: _**api\u002FController\u002FMethod?param=value**_\n    *   endpoint => POST: _**api\u002FController\u002FMethod**_\n```\n\n### Database Changes Summary Table Section\n\nThis section MUST appear at the beginning of any solution document that involves database changes, before the detailed sections. It provides a quick at-a-glance overview of all schema changes across all affected tables.\n\n**Status Legend:**\n- ? New table\n- ✏️ Modified table (columns added or altered)\n- ?️ Deprecated column (to be removed in a future release)\n\n```markdown\n### **N. DB New Tables & Schema Changes**\n\n| **Table** | **Status** | **Changes \u002F New Columns** |\n|---|---|---|\n| `TableName` | ? New | `Id` (int, PK), `ForeignKeyId` (int, FK → ReferencedTable), `ColumnName` (nvarchar, Nullable), `Amount` (decimal), `IsDeleted` (bit), `CreatedOn` (datetime) |\n| `AnotherTable` | ✏️ Modified | Add `NewColumnName` (int, FK → OtherTable), Add `Flag` (bit, default: 0) |\n```\n\n**Rules for this section:**\n- List every table affected across the entire solution in one consolidated table\n- Always specify: column name, data type, PK\u002FFK\u002FNullable\u002Fdefault constraints\n- For FK columns, always reference the target table using `FK → TargetTable`\n- For soft-delete patterns, always include: `IsDeleted` (bit), `DeletedBy`, `DeletedOn`\n- For audit columns, always include: `CreatedBy`, `CreatedOn`, `UpdatedBy`, `UpdatedOn`\n- This section is always followed by a Schema Diagram sub-section (N.1)\n\n### Schema Diagram Section\n\nThis sub-section MUST immediately follow the DB Changes Summary Table. It renders a Mermaid ERD that visualizes the relationships between all new and modified tables.\n\n```markdown\n### **N.1 Schema Diagram**\n\n```mermaid\nerDiagram\n    ParentTable {\n        int Id PK\n        string Name\n        datetime CreatedOn\n    }\n    ChildTable {\n        int Id PK\n        int ParentTableId FK\n        string Name\n        bit IsDeleted\n        datetime CreatedOn\n    }\n    AttachmentTable {\n        int Id PK\n        int ChildTableId FK\n        string FileName\n        string FileUrl\n        bigint FileSize\n        string FileType\n        datetime UploadedOn\n    }\n\n    ParentTable ||--o{ ChildTable : \"has many\"\n    ChildTable ||--o{ AttachmentTable : \"has attachments\"\n```\n```\n\n**Rules for the ERD:**\n- Include ALL tables listed in the DB Changes Summary Table\n- Show only columns that are relevant to understanding structure and relationships (PK, FK, key business columns)\n- Use standard Mermaid ERD cardinality notation:\n  - `||--o{` → one-to-many\n  - `||--||` → one-to-one\n  - `}o--o{` → many-to-many\n- Label each relationship with a meaningful verb phrase (e.g., `\"has attachments\"`, `\"categorizes\"`, `\"typed by\"`)\n- Do NOT include every audit column in the diagram — keep it readable\n\n### Database Change Section\n\n```markdown\n### **N. Modification of [Table\u002FEntity Name]**\n\n*   **Objective**: [Why this DB change is needed.]\n*   **Action**:\n    *   Add column `ColumnName` of type `DataType` to table `TableName`\n    *   This column will be a foreign key referencing `ReferencedTable(Id)`\n    *   Flag all existing records: set `ColumnName = [defaultValue]`\n    *   New records should be set to `[newValue]`\n```\n\n### Background Job Section\n\n```markdown\n### **N. [Job Feature Title]**\n\n*   **Objective**: [What the job does and why it needs updating.]\n*   **Action**:\n    *   Update job: _**JobClassName**_\n    *   Include fields: `FieldOne`, `FieldTwo` in generated output\n    *   Apply condition: only for [CountryId \u002F DoctorType \u002F Flag condition]\n```\n\n### API Modification Section\n\n```markdown\n### **N. Modification of [API Name]**\n\n*   **Objective**: [What the API change achieves.]\n*   **Action**:\n    *   Modify search\u002Ffilter\u002Fresponse logic as described\n    *   Extract [data point] from [token \u002F request \u002F DB]\n    *   endpoints to be updated:\n        *   GET: _**api\u002FController\u002FAction?param=value**_\n        *   POST: _**api\u002FController\u002FAction**_\n```\n\n### Conditional Logic Section\n\n```markdown\n### **N. [Feature] for [Country\u002FRole\u002FCondition]**\n\n*   **Objective**: Apply [behavior] only when [condition is met].\n*   **Action**:\n    *   Add condition check: if `[field] == [value]`\n    *   When true: [behavior A]\n    *   When false \u002F default: [behavior B]\n    *   Affected endpoints:\n        *   GET: _**api\u002FController\u002FMethod**_\n```\n\n---\n\n## Formatting Rules\n\n| Element | Format |\n|---|---|\n| Section header | `### **N. Title**` |\n| Objective | `*   **Objective**: ...` |\n| Action | `*   **Action**: ...` |\n| Sub-bullets | `    *   detail` |\n| API endpoint | `GET\u002FPOST\u002FPUT: _**api\u002FPath?param**_` |\n| Job class name | `_**JobClassName**_` |\n| DB column | backtick inline code: `` `ColumnName` `` |\n| Flag\u002FBoolean | describe both true and false behavior |\n| Country-specific | always mention country name and ID context |\n| DB status icon | ? New \u002F ✏️ Modified \u002F ?️ Deprecated |\n| FK reference | `` `ColumnName` (int, FK → TargetTable) `` |\n| ERD cardinality | `\\|\\|--o{` one-to-many, `\\|\\|--\\|\\|` one-to-one |\n\n---\n\n## Completeness Checklist\n\nBefore finalizing the document, verify each section has:\n\n- [ ] A clear **Objective** (one sentence, starts with a verb)\n- [ ] A detailed **Action** with at least one concrete sub-step\n- [ ] All affected **API endpoints** listed with HTTP method\n- [ ] All **DB schema changes** described (table, column, type, constraint)\n- [ ] **DB Changes Summary Table** present if any table is added or modified\n- [ ] **Schema Diagram (Mermaid ERD)** present immediately after the DB summary table\n- [ ] All FK relationships visualized in the ERD with labeled relationship verbs\n- [ ] Any **background jobs** named explicitly\n- [ ] **Conditional logic** (per country, per role, per flag) noted clearly\n- [ ] No duplicate sections — merge related items into one\n- [ ] No future\u002Fspeculative features — follow YAGNI\n\n---\n\n## Quality Rules\n\n- **One objective per section** — if two goals exist, split into two sections\n- **Endpoints must include HTTP method** (GET, POST, PUT, DELETE)\n- **DB changes must include**: table name, column name, data type, and constraint type\n- **DB Changes Summary Table** must consolidate ALL table changes across the document in one place — do not scatter DB changes only in individual sections\n- **Schema Diagram** is mandatory whenever a DB Changes Summary Table is present — never omit it\n- **ERD must reflect the summary table** — every table in the summary must appear in the ERD\n- **Country-specific logic** must always reference the country ID, not just the name\n- **Job modifications** must reference the exact class\u002Fjob name as it exists in code\n- **Avoid vague language** like \"update the system\" — be specific about what changes\n\n---\n\n## Example Output Excerpt\n\n```markdown\n### **1. DB New Tables & Schema Changes**\n\n| **Table** | **Status** | **Changes \u002F New Columns** |\n|---|---|---|\n| `SiteExpenses` | ? New | `Id` (int, PK), `SiteId` (int, FK → Sites), `ExpenseCategoryId` (int, FK → ExpenseCategories), `ExpenseTypeId` (int, FK → ExpenseTypes), `Name` (nvarchar), `Amount` (decimal), `PaymentGatewayId` (int, FK → PaymentGateways), `PaymentDate` (datetime), `Description` (nvarchar, Nullable), `CreatedBy` (nvarchar), `CreatedOn` (datetime), `UpdatedBy` (nvarchar, Nullable), `UpdatedOn` (datetime, Nullable), `IsDeleted` (bit), `DeletedBy` (nvarchar, Nullable), `DeletedOn` (datetime, Nullable) |\n| `ExpenseCategories` | ? New | `Id` (int, PK), `Name` (nvarchar), `CreatedOn` (datetime) |\n| `ExpenseTypes` | ? New | `Id` (int, PK), `ExpenseCategoryId` (int, FK → ExpenseCategories), `Name` (nvarchar), `SiteHolderId` (int, Nullable, FK → SiteHolders), `IsDeleted` (bit), `CreatedOn` (datetime) |\n| `ExpenseAttachments` | ? New | `Id` (int, PK), `ExpenseId` (int, FK → SiteExpenses), `FileName` (nvarchar), `FileUrl` (nvarchar), `FileSize` (bigint), `FileType` (nvarchar), `UploadedOn` (datetime) |\n\n### **1.1 Schema Diagram**\n\n```mermaid\nerDiagram\n    ExpenseCategories {\n        int Id PK\n        string Name\n        datetime CreatedOn\n    }\n    ExpenseTypes {\n        int Id PK\n        int ExpenseCategoryId FK\n        string Name\n        int SiteHolderId \"Nullable FK\"\n        bit IsDeleted\n        datetime CreatedOn\n    }\n    SiteExpenses {\n        int Id PK\n        int SiteId FK\n        int ExpenseCategoryId FK\n        int ExpenseTypeId FK\n        string Name\n        decimal Amount\n        int PaymentGatewayId FK\n        datetime PaymentDate\n        string Description\n        bit IsDeleted\n        datetime CreatedOn\n    }\n    ExpenseAttachments {\n        int Id PK\n        int ExpenseId FK\n        string FileName\n        string FileUrl\n        bigint FileSize\n        string FileType\n        datetime UploadedOn\n    }\n\n    ExpenseCategories ||--o{ ExpenseTypes : \"categorizes\"\n    ExpenseCategories ||--o{ SiteExpenses : \"classifies\"\n    ExpenseTypes ||--o{ SiteExpenses : \"typed by\"\n    SiteExpenses ||--o{ ExpenseAttachments : \"has attachments\"\n```\n\n### **2. Modification of the Drug Index Table**\n\n*   **Objective**: Add country-specific drug data support to the centralized drug index.\n*   **Action**: Add a `CountryId` column (type: `Int`, FK to `Country` table) to the `DrugIndex` table.\n    *   Map Excel columns to DB schema:\n        *   `TradeName`, `NameAr` ← `Product` column\n        *   `GenericName` ← `Molecule` column (strip \"Combination Of\" prefix)\n        *   `Shape` ← `Pack` column\n        *   `ManufacturingCompany` ← `ParentCompany` column\n        *   `Manufacturer` ← `Manufacturer` column\n        *   `Pharmacology` ← `Therapeutic class` column\n    *   Insert Iraq record into `Country` table\n    *   Set `CountryId` = Egypt ID for all existing records\n    *   Insert new Iraq drug records with `CountryId` = Iraq ID\n    *   Create background sync job: _**SyncIraqDrugIndexJob**_\n\n### **3. Modification of Drug Index API Search**\n\n*   **Objective**: Filter drug index search results by the doctor's country.\n*   **Action**: Extract `CountryId` from the authenticated doctor's JWT token and use it to filter results.\n    *   endpoints to be updated:\n        *   PUT: _**api\u002FPortalDoctors\u002FLogin**_ — return `CountryId` in response\n        *   GET: _**api\u002FDrugIndexes\u002FSearch?key=&isHiv=**_ — apply `CountryId` filter\n```\n\n---\n\n## Notes\n\n- This skill is designed for backend\u002FAPI-heavy systems (ASP.NET, REST APIs, SQL Server)\n- Can be adapted for frontend (Angular) changes by adding component\u002Fservice names in Action bullets\n- The **DB Changes Summary Table** + **Schema Diagram** pair should always open the document when DB changes are present — reviewers and DBAs need this upfront\n- Mermaid ERDs render natively in GitHub, Azure DevOps Wiki, GitLab, and most modern markdown viewers\n- When images\u002Fscreenshots are referenced in requirements, add a placeholder note: `[Screenshot: description]`\n- This skill pairs well with the **docx** skill if the output needs to be exported as a Word document\n","# Solution Documentation Generator\n\n## Overview\n\nThis skill generates structured solution documentation in a consistent, engineering-ready format used for sprint planning, feature specs, and technical handoffs. Each section follows a numbered format with **Objective** and **Action** sub-sections, along with relevant technical details (endpoints, DB changes, jobs, flags, etc.).\n\n---\n\n## Document Structure\n\nA solution document consists of:\n\n1. A **title** or context header (e.g., \"Solution Approach\")\n2. **Numbered sections**, each representing one feature, change, or concern\n3. Each section contains:\n   - A **bold section title** (e.g., `### **1. Modification of the Drug Index Table**`)\n   - `*   **Objective**`: One-sentence goal statement\n   - `*   **Action**`: Detailed steps, sub-bullets, DB changes, job names, endpoints\n4. **API endpoints** formatted inline using bold + code style:\n   - `* endpoint => GET: _**api\u002FResource\u002FMethod?param=value**_`\n5. **Database changes** described as column additions, flag changes, foreign key references\n6. **Background Jobs** referenced by name when applicable\n7. **Flags \u002F Booleans** described with their behavior implications\n\n---\n\n## Prompt Template for Generation\n\nWhen the user provides raw requirements (as bullet points, meeting notes, Jira tickets, or conversation), use the following prompt strategy:\n\n```\nYou are a senior software architect. Convert the following requirements into a structured Solution Documentation.\n\nFORMAT RULES:\n- Number each section starting from 1\n- Use markdown bold for section titles: ### **N. Section Title**\n- Each section MUST have:\n    * **Objective**: [single-sentence goal]\n    * **Action**: [detailed implementation steps as sub-bullets]\n- For API changes, list endpoints using this format:\n    * endpoint => METHOD: _**api\u002FController\u002FAction?param=value**_\n- For DB changes, describe: table name, column name, type, constraint (FK\u002Findex)\n- For jobs, reference the exact job class name\n- For flags, describe what true\u002Ffalse means in behavior\n- Keep language technical but concise\n- Do NOT add sections not implied by the requirements\n- Maintain YAGNI — only document what is needed\n\nINPUT:\n[paste raw requirements here]\n```\n\n---\n\n## Section Templates\n\n### Standard Feature Section\n\n```markdown\n### **N. [Short Descriptive Title]**\n\n*   **Objective**: [One sentence describing the goal of this change.]\n*   **Action**: [High-level description of what needs to be done.]\n    *   [Sub-step or detail]\n    *   [Sub-step or detail]\n    *   endpoint => GET: _**api\u002FController\u002FMethod?param=value**_\n    *   endpoint => POST: _**api\u002FController\u002FMethod**_\n```\n\n### Database Changes Summary Table Section\n\nThis section MUST appear at the beginning of any solution document that involves database changes, before the detailed sections. It provides a quick at-a-glance overview of all schema changes across all affected tables.\n\n**Status Legend:**\n- ? New table\n- ✏️ Modified table (columns added or altered)\n- ?️ Deprecated column (to be removed in a future release)\n\n```markdown\n### **N. DB New Tables & Schema Changes**\n\n| **Table** | **Status** | **Changes \u002F New Columns** |\n|---|---|---|\n| `TableName` | ? New | `Id` (int, PK), `ForeignKeyId` (int, FK → ReferencedTable), `ColumnName` (nvarchar, Nullable), `Amount` (decimal), `IsDeleted` (bit), `CreatedOn` (datetime) |\n| `AnotherTable` | ✏️ Modified | Add `NewColumnName` (int, FK → OtherTable), Add `Flag` (bit, default: 0) |\n```\n\n**Rules for this section:**\n- List every table affected across the entire solution in one consolidated table\n- Always specify: column name, data type, PK\u002FFK\u002FNullable\u002Fdefault constraints\n- For FK columns, always reference the target table using `FK → TargetTable`\n- For soft-delete patterns, always include: `IsDeleted` (bit), `DeletedBy`, `DeletedOn`\n- For audit columns, always include: `CreatedBy`, `CreatedOn`, `UpdatedBy`, `UpdatedOn`\n- This section is always followed by a Schema Diagram sub-section (N.1)\n\n### Schema Diagram Section\n\nThis sub-section MUST immediately follow the DB Changes Summary Table. It renders a Mermaid ERD that visualizes the relationships between all new and modified tables.\n\n```markdown\n### **N.1 Schema Diagram**\n\n```mermaid\nerDiagram\n    ParentTable {\n        int Id PK\n        string Name\n        datetime CreatedOn\n    }\n    ChildTable {\n        int Id PK\n        int ParentTableId FK\n        string Name\n        bit IsDeleted\n        datetime CreatedOn\n    }\n    AttachmentTable {\n        int Id PK\n        int ChildTableId FK\n        string FileName\n        string FileUrl\n        bigint FileSize\n        string FileType\n        datetime UploadedOn\n    }\n\n    ParentTable ||--o{ ChildTable : \"has many\"\n    ChildTable ||--o{ AttachmentTable : \"has attachments\"\n```\n```\n\n**Rules for the ERD:**\n- Include ALL tables listed in the DB Changes Summary Table\n- Show only columns that are relevant to understanding structure and relationships (PK, FK, key business columns)\n- Use standard Mermaid ERD cardinality notation:\n  - `||--o{` → one-to-many\n  - `||--||` → one-to-one\n  - `}o--o{` → many-to-many\n- Label each relationship with a meaningful verb phrase (e.g., `\"has attachments\"`, `\"categorizes\"`, `\"typed by\"`)\n- Do NOT include every audit column in the diagram — keep it readable\n\n### Database Change Section\n\n```markdown\n### **N. Modification of [Table\u002FEntity Name]**\n\n*   **Objective**: [Why this DB change is needed.]\n*   **Action**:\n    *   Add column `ColumnName` of type `DataType` to table `TableName`\n    *   This column will be a foreign key referencing `ReferencedTable(Id)`\n    *   Flag all existing records: set `ColumnName = [defaultValue]`\n    *   New records should be set to `[newValue]`\n```\n\n### Background Job Section\n\n```markdown\n### **N. [Job Feature Title]**\n\n*   **Objective**: [What the job does and why it needs updating.]\n*   **Action**:\n    *   Update job: _**JobClassName**_\n    *   Include fields: `FieldOne`, `FieldTwo` in generated output\n    *   Apply condition: only for [CountryId \u002F DoctorType \u002F Flag condition]\n```\n\n### API Modification Section\n\n```markdown\n### **N. Modification of [API Name]**\n\n*   **Objective**: [What the API change achieves.]\n*   **Action**:\n    *   Modify search\u002Ffilter\u002Fresponse logic as described\n    *   Extract [data point] from [token \u002F request \u002F DB]\n    *   endpoints to be updated:\n        *   GET: _**api\u002FController\u002FAction?param=value**_\n        *   POST: _**api\u002FController\u002FAction**_\n```\n\n### Conditional Logic Section\n\n```markdown\n### **N. [Feature] for [Country\u002FRole\u002FCondition]**\n\n*   **Objective**: Apply [behavior] only when [condition is met].\n*   **Action**:\n    *   Add condition check: if `[field] == [value]`\n    *   When true: [behavior A]\n    *   When false \u002F default: [behavior B]\n    *   Affected endpoints:\n        *   GET: _**api\u002FController\u002FMethod**_\n```\n\n---\n\n## Formatting Rules\n\n| Element | Format |\n|---|---|\n| Section header | `### **N. Title**` |\n| Objective | `*   **Objective**: ...` |\n| Action | `*   **Action**: ...` |\n| Sub-bullets | `    *   detail` |\n| API endpoint | `GET\u002FPOST\u002FPUT: _**api\u002FPath?param**_` |\n| Job class name | `_**JobClassName**_` |\n| DB column | backtick inline code: `` `ColumnName` `` |\n| Flag\u002FBoolean | describe both true and false behavior |\n| Country-specific | always mention country name and ID context |\n| DB status icon | ? New \u002F ✏️ Modified \u002F ?️ Deprecated |\n| FK reference | `` `ColumnName` (int, FK → TargetTable) `` |\n| ERD cardinality | `\\|\\|--o{` one-to-many, `\\|\\|--\\|\\|` one-to-one |\n\n---\n\n## Completeness Checklist\n\nBefore finalizing the document, verify each section has:\n\n- [ ] A clear **Objective** (one sentence, starts with a verb)\n- [ ] A detailed **Action** with at least one concrete sub-step\n- [ ] All affected **API endpoints** listed with HTTP method\n- [ ] All **DB schema changes** described (table, column, type, constraint)\n- [ ] **DB Changes Summary Table** present if any table is added or modified\n- [ ] **Schema Diagram (Mermaid ERD)** present immediately after the DB summary table\n- [ ] All FK relationships visualized in the ERD with labeled relationship verbs\n- [ ] Any **background jobs** named explicitly\n- [ ] **Conditional logic** (per country, per role, per flag) noted clearly\n- [ ] No duplicate sections — merge related items into one\n- [ ] No future\u002Fspeculative features — follow YAGNI\n\n---\n\n## Quality Rules\n\n- **One objective per section** — if two goals exist, split into two sections\n- **Endpoints must include HTTP method** (GET, POST, PUT, DELETE)\n- **DB changes must include**: table name, column name, data type, and constraint type\n- **DB Changes Summary Table** must consolidate ALL table changes across the document in one place — do not scatter DB changes only in individual sections\n- **Schema Diagram** is mandatory whenever a DB Changes Summary Table is present — never omit it\n- **ERD must reflect the summary table** — every table in the summary must appear in the ERD\n- **Country-specific logic** must always reference the country ID, not just the name\n- **Job modifications** must reference the exact class\u002Fjob name as it exists in code\n- **Avoid vague language** like \"update the system\" — be specific about what changes\n\n---\n\n## Example Output Excerpt\n\n```markdown\n### **1. DB New Tables & Schema Changes**\n\n| **Table** | **Status** | **Changes \u002F New Columns** |\n|---|---|---|\n| `SiteExpenses` | ? New | `Id` (int, PK), `SiteId` (int, FK → Sites), `ExpenseCategoryId` (int, FK → ExpenseCategories), `ExpenseTypeId` (int, FK → ExpenseTypes), `Name` (nvarchar), `Amount` (decimal), `PaymentGatewayId` (int, FK → PaymentGateways), `PaymentDate` (datetime), `Description` (nvarchar, Nullable), `CreatedBy` (nvarchar), `CreatedOn` (datetime), `UpdatedBy` (nvarchar, Nullable), `UpdatedOn` (datetime, Nullable), `IsDeleted` (bit), `DeletedBy` (nvarchar, Nullable), `DeletedOn` (datetime, Nullable) |\n| `ExpenseCategories` | ? New | `Id` (int, PK), `Name` (nvarchar), `CreatedOn` (datetime) |\n| `ExpenseTypes` | ? New | `Id` (int, PK), `ExpenseCategoryId` (int, FK → ExpenseCategories), `Name` (nvarchar), `SiteHolderId` (int, Nullable, FK → SiteHolders), `IsDeleted` (bit), `CreatedOn` (datetime) |\n| `ExpenseAttachments` | ? New | `Id` (int, PK), `ExpenseId` (int, FK → SiteExpenses), `FileName` (nvarchar), `FileUrl` (nvarchar), `FileSize` (bigint), `FileType` (nvarchar), `UploadedOn` (datetime) |\n\n### **1.1 Schema Diagram**\n\n```mermaid\nerDiagram\n    ExpenseCategories {\n        int Id PK\n        string Name\n        datetime CreatedOn\n    }\n    ExpenseTypes {\n        int Id PK\n        int ExpenseCategoryId FK\n        string Name\n        int SiteHolderId \"Nullable FK\"\n        bit IsDeleted\n        datetime CreatedOn\n    }\n    SiteExpenses {\n        int Id PK\n        int SiteId FK\n        int ExpenseCategoryId FK\n        int ExpenseTypeId FK\n        string Name\n        decimal Amount\n        int PaymentGatewayId FK\n        datetime PaymentDate\n        string Description\n        bit IsDeleted\n        datetime CreatedOn\n    }\n    ExpenseAttachments {\n        int Id PK\n        int ExpenseId FK\n        string FileName\n        string FileUrl\n        bigint FileSize\n        string FileType\n        datetime UploadedOn\n    }\n\n    ExpenseCategories ||--o{ ExpenseTypes : \"categorizes\"\n    ExpenseCategories ||--o{ SiteExpenses : \"classifies\"\n    ExpenseTypes ||--o{ SiteExpenses : \"typed by\"\n    SiteExpenses ||--o{ ExpenseAttachments : \"has attachments\"\n```\n\n### **2. Modification of the Drug Index Table**\n\n*   **Objective**: Add country-specific drug data support to the centralized drug index.\n*   **Action**: Add a `CountryId` column (type: `Int`, FK to `Country` table) to the `DrugIndex` table.\n    *   Map Excel columns to DB schema:\n        *   `TradeName`, `NameAr` ← `Product` column\n        *   `GenericName` ← `Molecule` column (strip \"Combination Of\" prefix)\n        *   `Shape` ← `Pack` column\n        *   `ManufacturingCompany` ← `ParentCompany` column\n        *   `Manufacturer` ← `Manufacturer` column\n        *   `Pharmacology` ← `Therapeutic class` column\n    *   Insert Iraq record into `Country` table\n    *   Set `CountryId` = Egypt ID for all existing records\n    *   Insert new Iraq drug records with `CountryId` = Iraq ID\n    *   Create background sync job: _**SyncIraqDrugIndexJob**_\n\n### **3. Modification of Drug Index API Search**\n\n*   **Objective**: Filter drug index search results by the doctor's country.\n*   **Action**: Extract `CountryId` from the authenticated doctor's JWT token and use it to filter results.\n    *   endpoints to be updated:\n        *   PUT: _**api\u002FPortalDoctors\u002FLogin**_ — return `CountryId` in response\n        *   GET: _**api\u002FDrugIndexes\u002FSearch?key=&isHiv=**_ — apply `CountryId` filter\n```\n\n---\n\n## Notes\n\n- This skill is designed for backend\u002FAPI-heavy systems (ASP.NET, REST APIs, SQL Server)\n- Can be adapted for frontend (Angular) changes by adding component\u002Fservice names in Action bullets\n- The **DB Changes Summary Table** + **Schema Diagram** pair should always open the document when DB changes are present — reviewers and DBAs need this upfront\n- Mermaid ERDs render natively in GitHub, Azure DevOps Wiki, GitLab, and most modern markdown viewers\n- When images\u002Fscreenshots are referenced in requirements, add a placeholder note: `[Screenshot: description]`\n- This skill pairs well with the **docx** skill if the output needs to be exported as a Word document\n",{"name":5,"license":15,"description":7},"main","b6b0a28b9857746ce09f588bfb5c308a7d4a9395","dot_claude\u002Fskills\u002Fsolution-documentation","https:\u002F\u002Fgithub.com\u002FAhmed2020SE\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002FAhmed2020SE","I'm Senior software engineer seeking to learn and improve, i wish someday i will develop something that will be a good use to the community. ","2026-04-12 07:11:28",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add Ahmed2020SE\u002Fdotfiles --skill solution-documentation",{"tool":65,"command":66},"bunx","bunx skills add Ahmed2020SE\u002Fdotfiles --skill solution-documentation",{"tool":68,"command":69},"pnpm","pnpm dlx skills add Ahmed2020SE\u002Fdotfiles --skill solution-documentation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAhmed2020SE\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_claude\u002Fskills\u002Fsolution-documentation\u002FSKILL.md",true,[],[74],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":47},"01M6R7K6Y6YP2HWTY18Y3MZYHV","supabase-postgres-best-practices","Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.","https:\u002F\u002Fgithub.com\u002FAhmed2020SE\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_claude\u002Fskills\u002Fpostgres-best-practices\u002FSKILL.md",[],[81,82,83,84,85,86,87,46,88,89,90,91,92,93,94],"best practices","supabase postgres best practices","supabase","postgres best practices","postgres","writing","performance","Optimization","performance optimization","use","schema","queries","postgres performance","when"]