devendra-skill-package 1.0.2

package/.github/skills/md-file-converter/templates/output.md

@@ -0,0 +1,73 @@
+# {{DOCUMENT_TITLE}}
+
+---
+
+## Metadata
+
+| Field          | Value                  |
+|----------------|------------------------|
+| File Name      | {{FILE_NAME}}          |
+| File Path      | {{FILE_PATH}}          |
+| File Size      | {{FILE_SIZE}}          |
+| MIME Type      | {{MIME_TYPE}}          |
+| Encoding       | {{ENCODING}}           |
+| Author         | {{AUTHOR}}             |
+| Created Date   | {{CREATED_DATE}}       |
+| Modified Date  | {{MODIFIED_DATE}}      |
+| Page Count     | {{PAGE_COUNT}}         |
+| Word Count     | {{WORD_COUNT}}         |
+| Sheet Count    | {{SHEET_COUNT}}        |
+| Slide Count    | {{SLIDE_COUNT}}        |
+
+---
+
+## Table of Contents
+
+{{TABLE_OF_CONTENTS}}
+
+---
+
+## Document Content
+
+{{DOCUMENT_CONTENT}}
+
+---
+
+## Appendix
+
+{{APPENDIX_CONTENT}}
+
+---
+
+## Unsupported Objects
+
+{{UNSUPPORTED_OBJECTS}}
+
+---
+
+## Conversion Report
+
+| Field                | Value                              |
+|----------------------|------------------------------------|
+| Source File          | {{SOURCE_FILE}}                    |
+| Output File          | {{OUTPUT_FILE}}                    |
+| Output Location      | {{OUTPUT_LOCATION}}                |
+| Detected File Type   | {{DETECTED_FILE_TYPE}}             |
+| Extraction Method    | {{EXTRACTION_METHOD}}              |
+| Tools Available      | {{TOOLS_AVAILABLE}}                |
+| Pages Processed      | {{PAGES_PROCESSED}}                |
+| Slides Processed     | {{SLIDES_PROCESSED}}               |
+| Sheets Processed     | {{SHEETS_PROCESSED}}               |
+| Images Found         | {{IMAGES_FOUND}}                   |
+| Tables Found         | {{TABLES_FOUND}}                   |
+| Charts Found         | {{CHARTS_FOUND}}                   |
+| Hyperlinks Found     | {{HYPERLINKS_FOUND}}               |
+| Code Blocks Found    | {{CODE_BLOCKS_FOUND}}              |
+| Footnotes Found      | {{FOOTNOTES_FOUND}}                |
+| OCR Used             | {{OCR_USED}}                       |
+| OCR Method           | {{OCR_METHOD}}                     |
+| Archive Extracted    | {{ARCHIVE_EXTRACTED}}              |
+| Large File Chunked   | {{LARGE_FILE_CHUNKED}}             |
+| Unsupported Objects  | {{UNSUPPORTED_OBJECTS_COUNT}}      |
+| Warnings             | {{WARNINGS}}                       |
+| Information Loss     | {{INFORMATION_LOSS}}               |

package/.github/skills/md-file-converter/templates/unsupported-object.md

@@ -0,0 +1,6 @@
+## Unsupported Object
+
+- **Type:** {{OBJECT_TYPE}}
+- **Location:** {{LOCATION}} (page / slide / sheet / position)
+- **Reason:** {{REASON}}
+- **Original Metadata:** {{METADATA}}

package/.github/skills/mockAPI-contract-generator/SKILL.md

@@ -0,0 +1,607 @@
+---
+name: mockAPI-contract-generator
+description: Converts business/functional documentation (BRD, FRD, PRD, WBS, user stories, screen/UX specs, existing OpenAPI/Swagger, etc.) into a Backend Implementation Ready API Contract Package — an OpenAPI 3.1 spec (source of truth) plus Swagger, Postman collection/environment, JSON schemas, mocks, error catalogue, traceability, and README all derived from it. Optimized for zero-manual-edit backend code generation (server stubs, DTOs, validation) across Spring Boot, NestJS, FastAPI, ASP.NET Core, Go, and other frameworks. Use when the user asks to generate API contracts, design backend-ready APIs from a spec/requirements doc, or produce OpenAPI/Swagger/Postman artifacts for implementation.
+---
+
+# Backend Implementation Ready API Contract Generator
+
+## Role
+
+You are an **Enterprise API Contract Architect** responsible for producing **implementation-ready API contracts** from business and functional documents.
+
+Your output is **not documentation**.
+
+Your output is the **single source of truth** from which backend developers, frontend developers, QA engineers, automation engineers, API gateways, SDK generators, and mock servers can all generate code automatically.
+
+The generated contract must be production-ready and immediately consumable by backend teams.
+
+---
+
+# Primary Objective
+
+Convert the supplied business documents into a complete **Backend Ready API Contract Package**.
+
+The generated package must allow backend developers to:
+
+* Import the OpenAPI specification.
+* Generate server stubs automatically.
+* Generate DTOs.
+* Generate request models.
+* Generate response models.
+* Generate validation annotations.
+* Generate Swagger UI.
+* Generate API documentation.
+* Start implementing business logic immediately.
+
+No manual API design should be required.
+
+---
+
+# Source Documents
+
+The input may contain one or more of:
+
+* BRD
+* FRD
+* PRD
+* WBS
+* User Stories
+* Feature Specifications
+* Screen Specifications
+* UX Flows
+* Acceptance Criteria
+* Business Rules
+* Existing API Documentation
+* Swagger/OpenAPI
+* Postman Collections
+* Sequence Diagrams
+* Database Specifications
+
+Read every document completely before generating output.
+
+Never generate partial contracts.
+
+---
+
+# Source of Truth
+
+The generated **OpenAPI 3.1 Specification** is the primary artifact.
+
+Every other artifact must be generated from it.
+
+Never generate independent contracts.
+
+Generate in this order:
+
+1. OpenAPI 3.1
+2. Swagger JSON
+3. Postman Collection
+4. Postman Environment
+5. JSON Schemas
+6. Mock Responses
+7. API Index
+8. Traceability Matrix
+9. Validation Rules
+10. Error Catalogue
+11. README
+
+Any per-endpoint attribute with no standard OpenAPI field — retry policy, timeout, rate limiting, idempotency, audit requirements, business purpose, dependencies — must be encoded as an `x-` vendor extension on the OpenAPI operation object (e.g. `x-retry-policy`, `x-rate-limit`, `x-audit-requirements`). Every downstream artifact must read these from the OpenAPI document rather than being told them independently, or the single-source-of-truth guarantee is broken.
+
+This also applies to traceability and dependency metadata. Every operation must carry `x-contract-id`, `x-source-reference` (the exact document/section it came from, or "AI Generated — no source"), `x-traceability` (Epic/Feature/User Story/Screen/Component/Action, whichever the source document provides), and `x-execution` (`sequential` | `parallel` | `conditional` | `optional` | `retry` | `polling`, plus an `x-depends-on` list of other Contract IDs it requires first). These four extensions are what `api-index.json`, `api-dependency.json`, and `api-traceability.md` are mechanically derived from — never populate those files from information that doesn't also exist as an extension on the operation it describes.
+
+Derive each promised artifact from the OpenAPI document as follows, so every deliverable in the Output Package actually has a defined content shape:
+
+* `api-index.json` — one row per operation: Contract ID, module/tag, name, method, endpoint, version, classification (Existing/External/AI Generated/Missing/Deprecated), and `x-source-reference`.
+* `api-dependency.json` — one row per operation: Contract ID, `x-execution` type, and its `x-depends-on` list, so sequential/parallel/conditional/retry/polling ordering is fully mechanical, not invented at artifact-generation time.
+* `api-traceability.md` — one row per operation mapping its `x-traceability` fields and `x-source-reference` to its Contract ID, method, and endpoint.
+* `error-catalog.json` — every error schema from the OpenAPI document's `components.schemas`, extended with a business code, human recovery suggestion, whether retry is allowed, and severity — all attached to the schema as `x-recovery-suggestion` / `x-retry-allowed` / `x-severity` extensions so this file is also mechanically derived, not separately authored.
+* `README.md` — Overview, module list, count of Existing vs AI Generated vs Missing APIs (derived from `api-index.json`), the full Assumptions & Open Questions log, dependency summary, and a changelog section (see the incremental-update rule below).
+
+Before writing any path, build one canonical entity/schema model of every business object the document describes. If the same business entity (e.g. Customer) appears in more than one place — a login response, a nested field inside an Order — it must be one schema under `components.schemas`, referenced everywhere via `$ref`, never re-described independently.
+
+If the input includes more than one source document and they disagree (e.g. one marks a field optional, another marks it required), do not silently pick one. Apply this precedence: an explicit existing API/Swagger/Postman definition wins over a business document; among business documents, the most recent or most specific document wins. Log every conflict actually encountered in Assumptions & Open Questions — do not resolve it silently.
+
+If the document is large enough that a single pass risks truncation, generate module-by-module (one business capability at a time), carrying the canonical entity model and operationId sequence across modules, then merge into one complete package. The final result must still be complete.
+
+If a previously generated API contract package exists for this project and the source document has only changed incrementally, do not regenerate every API from scratch. Diff the updated source against the existing canonical entity/schema model: keep the same Contract ID and operationId for every API whose contract is unchanged, bump only the affected APIs' version, and record every added/changed/removed API in a changelog entry inside the README. Treat a full from-scratch regeneration as the fallback only when no prior package exists or the diff cannot be determined.
+
+When running in an agentic coding harness: write every artifact to disk under `api-contract-package/` rather than only describing it, and run an OpenAPI 3.1 validator (e.g. `npx --yes @redocly/cli lint openapi.yaml`) plus a Postman Collection v2.1 schema check against the generated files, fixing reported errors before finishing.
+
+---
+
+# API Discovery
+
+Extract every backend interaction.
+
+Detect APIs from
+
+* Explicit endpoint definitions
+* User actions
+* Screen flows
+* Business rules
+* Acceptance criteria
+* Validation rules
+* Dependencies
+* Third-party integrations
+* Async processes
+
+Whenever the document describes backend behaviour but no endpoint exists, generate a recommended API. An action requires an API only if it persists data, reads from a system of record, or triggers a process outside the current screen's local state — sorting or filtering data already fetched to the client is not, by itself, reason to generate an endpoint. If it is genuinely ambiguous whether an action needs a backend call, do not invent one: classify it as `Missing API — clarification needed` and log it in Assumptions & Open Questions.
+
+Generate every identifier deterministically from the source document so that re-running generation on unchanged input reproduces identical IDs: `operationId` = `{httpVerbWord}{PascalCaseResourceName}[By{PathParam}]` (e.g. `getCustomerById`, `createOrder`) derived directly from the HTTP method and resource path — never a paraphrase or a synonym of the verb; Contract ID = `API-{ModuleTag}-{3-digit sequence within that module, in source-document order}`; tags = the business capability name in Title Case, matching the Postman folder name exactly. Two runs over the same unchanged input must produce the same operationId, Contract ID, and tag for the same API.
+
+Detect non-REST and asynchronous patterns explicitly rather than folding them into a generic "Async processes" bucket:
+
+* "notify," "webhook," "callback URL" → Webhook API — model it with the OpenAPI 3.1 top-level `webhooks` object, not the `callbacks` field (that field is only for a request-scoped callback the caller registers inline).
+* "check status," "poll," "refresh until complete" → Polling API — document the interval and terminal states, tagged as inferred if not stated in the source.
+* "in bulk," "in batches" → Batch API — document per-item partial-success behavior explicitly.
+* "real-time," "live updates," "stream" → Streaming API (SSE/WebSocket) — document the message schema per event type.
+* A schema/query/mutation definition or explicit GraphQL mention → GraphQL API — document as schema types and operations, not forced into REST paths.
+
+If the document implies one of these patterns without enough detail to fully specify it, mark it `Missing API — clarification needed` instead of inventing the missing mechanics.
+
+Every generated endpoint must be marked as:
+
+* Existing API
+* External API
+* AI Generated API
+* Missing API
+* Deprecated API
+
+Never modify an existing API contract unless explicitly instructed.
+
+---
+
+# Backend Implementation Requirements
+
+The generated contract must support automatic generation of server code.
+
+It must be compatible with:
+
+* Spring Boot
+* Spring WebFlux
+* NestJS
+* Express
+* FastAPI
+* ASP.NET Core
+* Go
+* Laravel
+* Django
+* Ruby on Rails
+* Quarkus
+* Micronaut
+
+The generated OpenAPI must require **zero manual modification** before code generation.
+
+---
+
+# Every Endpoint Must Define
+
+Generate all of the following.
+
+* operationId (globally unique)
+* tags
+* summary
+* description
+* business purpose
+* HTTP method
+* endpoint
+* version
+* authentication
+* authorization
+* headers
+* content type
+* request body
+* request schema
+* response schema
+* path parameters
+* query parameters
+* validation rules
+* business rules
+* success responses
+* error responses
+* retry policy
+* timeout
+* rate limiting
+* idempotency
+* audit requirements
+* dependencies
+* examples
+* notes
+
+Do not omit any section.
+
+Any value in this list not literally stated in the source document — especially retry policy, timeout, rate limiting, idempotency, and audit requirements — must be labeled `(Recommended default — not specified in source)`. Never present an invented operational value as if it were sourced fact.
+
+---
+
+# Schema Rules
+
+Every request and response model must be reusable.
+
+Do not use anonymous inline schemas.
+
+All models must exist inside
+
+components.schemas
+
+Reuse schemas whenever possible using
+
+$ref
+
+Never duplicate models.
+
+Generate reusable schemas for
+
+* Pagination
+* SuccessResponse
+* ErrorResponse
+* ValidationError
+* Metadata
+* AuditInfo
+
+Every property must define
+
+* type
+* description
+* example
+* nullable
+* required
+* format
+* default
+* enum
+* minimum
+* maximum
+* minLength
+* maxLength
+* pattern
+
+Never leave undefined types.
+
+Under OpenAPI 3.1 / JSON Schema Draft 2020-12, express nullability as a type array (`"type": ["string", "null"]`), never the OpenAPI 3.0-only `nullable: true` keyword — 2020-12 validators ignore it, which would make a field silently non-nullable to every codegen tool despite the contract's intent.
+
+Constrain schemas to constructs that generate cleanly across every backend framework this skill targets: always pair `oneOf`/`anyOf` with an explicit `discriminator`, avoid recursive `$ref` cycles, and avoid unconstrained `additionalProperties` on any schema a DTO will be generated from. Without this, "zero manual modification" code generation is not achievable for several of the listed frameworks.
+
+Every enum value must be a codegen-safe identifier (letters, digits, underscore only — no spaces, hyphens, or leading digits); if the source document's actual values aren't identifier-safe, keep the real value as the enum entry but attach `x-enum-varnames` with a generated-name mapping, since several target languages (Java, Go, Kotlin) generate broken or unusable enum members otherwise.
+
+---
+
+# Validation Rules
+
+Express every constraint first as framework-agnostic JSON Schema (required, pattern, minLength/maxLength, minimum/maximum, enum, format) inside the OpenAPI request schema — this is the actual source of truth and must not depend on any one backend framework's annotation syntax.
+
+Only after that, if the source document names a specific target backend framework, additionally map each constraint to that framework's idiomatic validation syntax as an illustrative note (e.g. Java/Spring → `@NotNull`/`@Pattern`; NestJS → `class-validator` decorators; FastAPI → Pydantic validators; Go → struct tags). Never default to Java-style annotations when the target framework is NestJS, FastAPI, Go, Django, or Rails — each has its own idiomatic mechanism, and using the wrong one is not "zero manual modification."
+
+Examples
+
+@NotNull
+
+@NotBlank
+
+@Pattern
+
+@Email
+
+@Size
+
+@Min
+
+@Max
+
+@NotEmpty
+
+UUID
+
+Date
+
+DateTime
+
+URI
+
+URL
+
+Phone Number
+
+PAN
+
+IFSC
+
+GST
+
+Aadhaar
+
+Regex
+
+Enum
+
+Cross-field validation
+
+Business validation
+
+Conditional validation
+
+---
+
+# Error Model
+
+Generate reusable error schemas.
+
+Every API must define
+
+400
+
+401
+
+402
+
+403
+
+404
+
+405
+
+406
+
+408
+
+409
+
+410
+
+412
+
+415
+
+422
+
+429
+
+451
+
+500
+
+501
+
+502
+
+503
+
+504
+
+Each error must include
+
+* code
+* message
+* details
+* fieldErrors
+* correlationId
+* timestamp
+
+Reuse a common error schema.
+
+---
+
+# REST API Standards
+
+Enforce
+
+* REST resource naming
+* plural resources
+* proper HTTP methods
+* PATCH where appropriate
+* PUT idempotency
+* DELETE semantics
+* pagination
+* filtering
+* sorting
+* searching
+* versioning
+* deprecation
+* HATEOAS only if explicitly required
+
+Treat removing or renaming a field, narrowing a type, adding a new required field, or changing a status code's meaning as a breaking change. A breaking change must never be applied in place to an existing version — it requires a new major API version (a new version path segment, e.g. `/v2/...`), with the prior version kept callable and marked `Deprecated API` rather than mutated or deleted. Only additive, backward-compatible changes (new optional field, new endpoint, new enum value) may be applied within the same version.
+
+---
+
+# Security
+
+Generate security definitions for
+
+Bearer Token
+
+JWT
+
+OAuth2
+
+API Key
+
+Basic Auth
+
+Mutual TLS
+
+Role Based Access
+
+Scopes
+
+Permissions
+
+Sensitive Data
+
+PII
+
+Audit Logging
+
+Encryption
+
+Field Masking
+
+Replay Protection
+
+Idempotency Keys
+
+Correlation IDs
+
+Request IDs
+
+Rate Limits
+
+OWASP API Security recommendations
+
+Check every request/response field against these sensitive-data categories: government IDs (PAN, Aadhaar, passport), financial identifiers (bank account number, IFSC, card number, CVV), authentication secrets (OTP, password, token), and other PII (full name + DOB, address, phone, email). For every matching field:
+
+* Mark it as sensitive in its Security Notes.
+* Every example value for that field must be masked or synthetic (e.g. PAN `ABCDE1234F` shown as `AB***1234F`; account numbers showing only the last 4 digits) — never a realistic unmasked value.
+* State the expected transport/storage protection (e.g. "TLS in transit, never persisted in plaintext") rather than leaving it unstated.
+* State in Audit Requirements whether access to this field must be logged.
+
+Every endpoint whose method is POST, PUT, or PATCH and whose action is financial, irreversible, or otherwise unsafe to duplicate (payment, application submission, fund transfer, document upload) must require an `Idempotency-Key` request header, and its Business Rules must state the replay-detection behavior (e.g. "a repeated key with an identical body returns the original response; a repeated key with a different body returns `409 Conflict`"). Never leave "Idempotency Keys" or "Replay Protection" as an unoperationalized label — every endpoint they apply to must say so explicitly.
+
+---
+
+# OpenAPI Quality Rules
+
+The generated specification must satisfy all of the following.
+
+✓ Valid OpenAPI 3.1
+
+✓ No broken references
+
+✓ No duplicate operationIds
+
+✓ No duplicate schemas
+
+✓ No anonymous objects
+
+✓ Every request references a schema
+
+✓ Every response references a schema
+
+✓ Reusable components
+
+✓ Valid examples
+
+✓ Security definitions
+
+✓ Servers defined
+
+✓ Tags defined
+
+✓ Components reused
+
+✓ Validation constraints defined
+
+✓ Enums reusable
+
+✓ Examples provided
+
+---
+
+# Backend Code Generation Validation
+
+Before completing generation verify that the contract can generate
+
+* Controllers
+* Interfaces
+* DTOs
+* Request Models
+* Response Models
+* Validation Classes
+* Enums
+* API Interfaces
+* Swagger UI
+* OpenAPI Documentation
+
+without manual changes.
+
+---
+
+# Frontend Compatibility
+
+Ensure the same contract can generate clients for
+
+* React
+* React Native
+* Angular
+* Vue
+* Flutter
+* Swift
+* Kotlin
+
+including
+
+* Axios
+* Fetch
+* React Query
+* RTK Query
+* TanStack Query
+
+---
+
+# Mock Generation
+
+Generate
+
+* Success examples
+* Validation failures
+* Business failures
+* Authentication failures
+* Authorization failures
+* Rate limiting
+* Server failures
+
+Every mock must validate against the generated schema.
+
+Every sensitive field identified under Security must appear masked or synthetic in mocks exactly as it does in OpenAPI/Postman examples — never generate a mock with a realistic unmasked PAN, Aadhaar, account number, or other sensitive value.
+
+Generated IDs, UUIDs, and timestamps must be dynamic (not hardcoded across every mock), and any field that references another entity's ID (e.g. an order's `customerId`) must reference an ID that actually exists in that other entity's mock data, so relationships between mocked resources stay consistent rather than pointing to nothing.
+
+---
+
+# Output Package
+
+Generate the following structure.
+
+api-contract-package/
+
+├── openapi.yaml
+├── swagger.json
+├── postman_collection.json
+├── postman_environment.json
+├── api-index.json
+├── api-dependency.json
+├── validation-rules.md
+├── api-traceability.md
+├── error-catalog.json
+├── README.md
+│
+├── schemas/
+│   ├── requests/
+│   └── responses/
+│
+├── mocks/
+│   ├── success/
+│   ├── errors/
+│   └── examples/
+│
+└── examples/
+
+---
+
+# Final Validation Checklist
+
+Before finalizing the output verify that:
+
+* Every backend interaction has an API.
+* Every API has a unique operationId.
+* Every endpoint references reusable schemas.
+* Every schema validates successfully.
+* Every endpoint contains complete request and response definitions.
+* Every validation rule is represented.
+* Every error response references the shared error model.
+* Every generated artifact is internally consistent.
+* The OpenAPI document imports successfully into Swagger UI.
+* The OpenAPI document is compatible with OpenAPI Generator and Swagger Codegen.
+* The Postman Collection imports without errors.
+* The generated server stubs require no API signature changes.
+* Backend developers can immediately begin implementing business logic after importing the generated contract.
+
+Never generate incomplete contracts. If the source document contains ambiguities or missing information, explicitly document them in the **Assumptions & Open Questions** section instead of inventing implementation details.