fix(security): 添加VITE_PAYMENT_URL环境变量配置
This commit is contained in:
47
.qoder/skills/understand/languages/cpp.md
Normal file
47
.qoder/skills/understand/languages/cpp.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# C++ Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Templates**: Function, class, and variadic templates for generic compile-time polymorphism
|
||||
- **RAII**: Resource Acquisition Is Initialization — tie resource lifetime to object scope
|
||||
- **Smart Pointers**: `unique_ptr` (exclusive), `shared_ptr` (reference-counted), `weak_ptr` (non-owning)
|
||||
- **Move Semantics**: Rvalue references (`&&`) and `std::move` for efficient resource transfer
|
||||
- **Operator Overloading**: Define custom behavior for operators on user-defined types
|
||||
- **Virtual Functions and Vtable**: Runtime polymorphism through virtual method dispatch tables
|
||||
- **Namespaces**: Organize symbols and prevent name collisions across translation units
|
||||
- **Constexpr**: Compile-time evaluation of functions and variables for zero-runtime-cost computation
|
||||
- **Lambda Expressions**: Anonymous functions with capture lists for closures
|
||||
- **STL Containers and Algorithms**: Standard containers (vector, map, set) and generic algorithms
|
||||
- **Concepts (C++20)**: Named constraints on template parameters replacing SFINAE patterns
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `#include <system_header>` — include standard library or system headers
|
||||
- `#include "local_header.h"` — include project-local header files
|
||||
- `using namespace std` — bring all names from std into scope (avoid in headers)
|
||||
- `using std::vector` — selectively bring specific names into scope
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `.h` / `.hpp` — header files containing declarations, templates, and inline definitions
|
||||
- `.cpp` / `.cc` — implementation files with function definitions and static data
|
||||
- `CMakeLists.txt` — CMake build system configuration
|
||||
- `Makefile` — Make-based build rules and targets
|
||||
- `main.cpp` — program entry point containing `int main()`
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Qt** — Cross-platform application framework with signal/slot mechanism
|
||||
- **Boost** — Extensive collection of peer-reviewed portable libraries
|
||||
- **Catch2** — Header-only testing framework with BDD-style syntax
|
||||
- **Google Test** — Testing framework with fixtures, assertions, and mocking
|
||||
- **gRPC** — High-performance RPC framework for service communication
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses `std::unique_ptr<T>` for RAII-based ownership, ensuring deterministic cleanup
|
||||
> when scope exits. The unique pointer cannot be copied, only moved, making ownership
|
||||
> transfer explicit and preventing accidental double-free errors.
|
||||
>
|
||||
> Header/implementation separation (`.h`/`.cpp`) controls compilation boundaries —
|
||||
> changes to a `.cpp` file only recompile that translation unit, not all includers.
|
||||
46
.qoder/skills/understand/languages/csharp.md
Normal file
46
.qoder/skills/understand/languages/csharp.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# C# Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **LINQ Queries**: Language-integrated queries using method syntax (`.Where().Select()`) or query syntax
|
||||
- **Async/Await with Task**: Asynchronous programming model returning `Task<T>` for non-blocking I/O
|
||||
- **Generics and Constraints**: Type parameters with `where T : class, IDisposable` constraint clauses
|
||||
- **Properties (get/set)**: First-class property syntax with backing fields, auto-properties, and init-only
|
||||
- **Delegates and Events**: Type-safe function pointers; events provide publisher-subscriber pattern
|
||||
- **Attributes**: Metadata annotations (`[HttpGet]`, `[Authorize]`) for declarative configuration
|
||||
- **Nullable Reference Types**: Compiler-enforced null safety with `?` annotations (C# 8+)
|
||||
- **Pattern Matching**: `is`, `switch` expressions with type, property, and relational patterns
|
||||
- **Records and Init-Only Setters**: Immutable reference types with value equality semantics (C# 9+)
|
||||
- **Dependency Injection (Built-in)**: First-class DI container in ASP.NET Core (`IServiceCollection`)
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `using System.Collections.Generic` — import a namespace for unqualified type access
|
||||
- `using static System.Math` — import static members for direct method access
|
||||
- `global using` — file-scoped usings applied to the entire project (C# 10)
|
||||
- `using Alias = Namespace.Type` — type alias for disambiguation
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `*.csproj` — MSBuild project file defining targets, packages, and build properties
|
||||
- `*.sln` — Visual Studio solution file grouping multiple projects
|
||||
- `Program.cs` — application entry point (top-level statements in .NET 6+)
|
||||
- `Startup.cs` — service and middleware configuration (older ASP.NET Core pattern)
|
||||
- `appsettings.json` — hierarchical application configuration
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **ASP.NET Core** — Cross-platform web framework for APIs, MVC, and Razor Pages
|
||||
- **Entity Framework** — ORM with LINQ-to-SQL, migrations, and change tracking
|
||||
- **Blazor** — Component-based UI framework using C# instead of JavaScript
|
||||
- **MAUI** — Cross-platform native UI for mobile and desktop applications
|
||||
- **xUnit** — Modern testing framework with theories, facts, and dependency injection
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses LINQ method syntax `.Where().Select()` to compose a query pipeline over the
|
||||
> collection. LINQ operations are lazily evaluated — the query only executes when
|
||||
> results are enumerated, allowing efficient composition without intermediate allocations.
|
||||
>
|
||||
> The built-in DI container in ASP.NET Core registers services in `Program.cs` and
|
||||
> resolves them via constructor injection, following the composition root pattern.
|
||||
37
.qoder/skills/understand/languages/css.md
Normal file
37
.qoder/skills/understand/languages/css.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# CSS Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Selectors**: Element, class (`.name`), ID (`#name`), attribute (`[attr]`), and pseudo-class (`:hover`) targeting
|
||||
- **Specificity**: Inline > ID > Class > Element cascade priority determining which rules win
|
||||
- **Box Model**: `margin`, `border`, `padding`, `content` dimensions controlling element sizing
|
||||
- **Flexbox**: `display: flex` with `justify-content`, `align-items` for one-dimensional layouts
|
||||
- **Grid**: `display: grid` with `grid-template-columns/rows` for two-dimensional layouts
|
||||
- **Custom Properties (Variables)**: `--name: value` with `var(--name)` for reusable design tokens
|
||||
- **Media Queries**: `@media (max-width: ...)` for responsive design breakpoints
|
||||
- **SCSS/Sass Features**: Nesting, `$variables`, `@mixin`, `@include`, `@extend`, `@use`, `@forward`
|
||||
- **CSS Modules**: Scoped class names (`.module.css`) preventing global style collisions
|
||||
- **Cascade Layers**: `@layer` for explicit control over cascade ordering
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `*.css` — Standard CSS stylesheets
|
||||
- `*.scss` / `*.sass` — Sass/SCSS preprocessor files
|
||||
- `*.less` — Less preprocessor files
|
||||
- `*.module.css` / `*.module.scss` — CSS Modules (scoped styles)
|
||||
- `globals.css` / `reset.css` / `normalize.css` — Global base styles
|
||||
- `tailwind.config.js` — Tailwind CSS configuration (though a JS file)
|
||||
- `variables.scss` / `_variables.scss` — Design token definitions
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- CSS files are `related` to the HTML or component files that import them for styling
|
||||
- SCSS partial files (`_*.scss`) are `depends_on` by the main stylesheet that `@use`s them
|
||||
- CSS variable definition files are `related` to all stylesheets that reference those variables
|
||||
- CSS Modules are `related` to the component files that import them
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Global stylesheet defining CSS custom properties for the design system color palette and typography."
|
||||
> "Responsive layout styles with flexbox and grid for the dashboard page across 3 breakpoints."
|
||||
> "SCSS partial defining shared mixins for spacing, shadows, and media query breakpoints."
|
||||
34
.qoder/skills/understand/languages/dockerfile.md
Normal file
34
.qoder/skills/understand/languages/dockerfile.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Dockerfile Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Multi-Stage Builds**: Multiple `FROM` statements to separate build and runtime stages, reducing image size
|
||||
- **Layer Caching**: Each instruction creates a layer; order instructions from least to most frequently changing for cache efficiency
|
||||
- **Base Images**: `FROM image:tag` selects the starting image; prefer slim/alpine variants for smaller images
|
||||
- **COPY vs ADD**: `COPY` for local files (preferred), `ADD` for URLs and tar extraction
|
||||
- **Build Arguments**: `ARG` for build-time variables, `ENV` for runtime environment variables
|
||||
- **Health Checks**: `HEALTHCHECK` instruction for container orchestrator readiness probes
|
||||
- **Entry Point vs CMD**: `ENTRYPOINT` sets the executable, `CMD` provides default arguments
|
||||
- **User Permissions**: `USER` instruction to run as non-root for security
|
||||
- **Ignore Patterns**: `.dockerignore` excludes files from the build context (like `.gitignore`)
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `Dockerfile` — Primary container image definition (at project root)
|
||||
- `Dockerfile.dev` / `Dockerfile.prod` — Environment-specific Dockerfiles
|
||||
- `docker-compose.yml` — Multi-container application orchestration
|
||||
- `docker-compose.override.yml` — Local development overrides
|
||||
- `.dockerignore` — Build context exclusion patterns
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- Dockerfile `deploys` the application entry point it packages (COPY/CMD target)
|
||||
- docker-compose `depends_on` Dockerfile(s) it references for building
|
||||
- Dockerfile `depends_on` package manifests (package.json, requirements.txt) it copies for dependency installation
|
||||
- docker-compose services create `related` edges between co-deployed components
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Multi-stage Docker build producing a minimal Node.js production image with N build stages."
|
||||
> "Docker Compose configuration orchestrating N services with shared networking and persistent volumes."
|
||||
> "Development Dockerfile with hot-reload support and mounted source volumes."
|
||||
47
.qoder/skills/understand/languages/go.md
Normal file
47
.qoder/skills/understand/languages/go.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# Go Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Goroutines**: Lightweight concurrent functions launched with `go` keyword
|
||||
- **Channels**: Typed conduits for communication and synchronization between goroutines
|
||||
- **Interfaces**: Implicitly satisfied contracts — no `implements` keyword needed
|
||||
- **Struct Embedding**: Composition mechanism providing field and method promotion
|
||||
- **Error Handling**: Explicit error return values (`error` interface) instead of exceptions
|
||||
- **Defer/Panic/Recover**: Deferred cleanup, unrecoverable errors, and recovery mechanism
|
||||
- **Slices vs Arrays**: Arrays are fixed-size values; slices are dynamic views backed by arrays
|
||||
- **Pointers**: Explicit pointer types for pass-by-reference semantics (no pointer arithmetic)
|
||||
- **Context Propagation**: `context.Context` carries deadlines, cancellation, and request-scoped values
|
||||
- **Init Functions**: Package-level `init()` runs automatically before `main()` for setup
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `import "package"` — single package import
|
||||
- `import alias "package"` — aliased import to avoid name conflicts
|
||||
- `import ( ... )` — grouped import block (standard library, then external, then internal)
|
||||
- `import _ "package"` — blank import for side effects only (e.g., driver registration)
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `*_test.go` — test files in the same package (or `_test` package for black-box tests)
|
||||
- `cmd/` — directory containing main packages (binary entry points)
|
||||
- `internal/` — packages only importable by parent module (enforced by compiler)
|
||||
- `pkg/` — public library packages (convention, not enforced)
|
||||
- `go.mod` — module definition with dependency versions
|
||||
- `go.sum` — cryptographic checksums for dependencies
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Gin** — High-performance HTTP framework with middleware support
|
||||
- **Echo** — Minimalist web framework with built-in middleware
|
||||
- **Fiber** — Express-inspired framework built on fasthttp
|
||||
- **Chi** — Lightweight, composable HTTP router
|
||||
- **GORM** — ORM library with associations, hooks, and migrations
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Implements `io.Reader` interface implicitly — no explicit declaration needed, just
|
||||
> matching method signatures. This enables any type with a `Read([]byte) (int, error)`
|
||||
> method to be used wherever `io.Reader` is expected.
|
||||
>
|
||||
> The `internal/` directory enforces encapsulation at the compiler level, preventing
|
||||
> external packages from importing implementation details — stronger than naming convention.
|
||||
35
.qoder/skills/understand/languages/graphql.md
Normal file
35
.qoder/skills/understand/languages/graphql.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# GraphQL Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Type System**: Strongly typed schema defining the API contract with scalar, object, enum, and union types
|
||||
- **Queries**: Read operations fetching data with field-level selection (no over-fetching)
|
||||
- **Mutations**: Write operations for creating, updating, and deleting data
|
||||
- **Subscriptions**: Real-time data push over WebSocket connections
|
||||
- **Resolvers**: Functions mapping schema fields to data sources (database, API, cache)
|
||||
- **Fragments**: Reusable field selections reducing query duplication across operations
|
||||
- **Directives**: `@deprecated`, `@include`, `@skip` for conditional field inclusion and schema metadata
|
||||
- **Input Types**: `input` keyword for complex mutation arguments
|
||||
- **Interfaces and Unions**: Polymorphic types for shared fields across multiple object types
|
||||
- **Schema Stitching / Federation**: Composing multiple GraphQL services into a unified graph
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `schema.graphql` / `*.graphql` — Schema definition files
|
||||
- `*.gql` — Alternative extension for GraphQL files
|
||||
- `schema/*.graphql` — Split schema files by domain (users.graphql, orders.graphql)
|
||||
- `*.resolvers.ts` / `*.resolvers.js` — Resolver implementations (TypeScript/JavaScript convention)
|
||||
- `codegen.yml` — GraphQL Code Generator configuration
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- GraphQL schema files `defines_schema` for the resolver code that implements query/mutation handlers
|
||||
- Type definitions create `related` edges between types connected by field references
|
||||
- Schema files `defines_schema` for client-side query/mutation files that consume the API
|
||||
- Codegen config `configures` the schema-to-code generation pipeline
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "GraphQL schema defining N types, M queries, and K mutations for the user management API."
|
||||
> "API schema with type definitions for products, orders, and payment processing with pagination."
|
||||
> "Subscription schema enabling real-time notifications for order status updates."
|
||||
34
.qoder/skills/understand/languages/html.md
Normal file
34
.qoder/skills/understand/languages/html.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# HTML Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Semantic Elements**: `<main>`, `<nav>`, `<header>`, `<footer>`, `<article>`, `<section>` for meaningful structure
|
||||
- **Document Structure**: `<!DOCTYPE html>`, `<html>`, `<head>`, `<body>` forming the page skeleton
|
||||
- **Forms**: `<form>`, `<input>`, `<select>`, `<textarea>` for user data collection with validation attributes
|
||||
- **Accessibility**: `aria-*` attributes, `role`, `alt` text, and semantic markup for screen readers
|
||||
- **Meta Tags**: `<meta>` for viewport, charset, description, Open Graph, and SEO metadata
|
||||
- **Script and Style Loading**: `<script>`, `<link>`, `<style>` for JavaScript and CSS inclusion
|
||||
- **Data Attributes**: `data-*` custom attributes for storing element-specific data
|
||||
- **Template Syntax**: Framework-specific templating (`{{ }}` for Jinja/Django, `<%= %>` for ERB)
|
||||
- **Web Components**: `<template>`, `<slot>`, Custom Elements for encapsulated reusable components
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `index.html` — Application entry point or SPA shell
|
||||
- `*.html` / `*.htm` — Static HTML pages
|
||||
- `templates/**/*.html` — Server-side template files (Django, Jinja2, Go templates)
|
||||
- `public/index.html` — SPA root document (React, Vue)
|
||||
- `*.ejs` / `*.hbs` / `*.pug` — Templating engine files
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- HTML files `depends_on` JavaScript and CSS files they include via `<script>` and `<link>` tags
|
||||
- Template HTML files `depends_on` the server-side code that renders them
|
||||
- HTML entry points are `deploys` targets for build systems and web servers
|
||||
- HTML files `related` to the components or routes they render
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Single-page application shell with viewport meta, CSS reset, and React root mount point."
|
||||
> "Server-rendered template with navigation, content area, and footer using Django template inheritance."
|
||||
> "Static landing page with responsive layout, form, and third-party script integrations."
|
||||
45
.qoder/skills/understand/languages/java.md
Normal file
45
.qoder/skills/understand/languages/java.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# Java Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Generics (with Erasure)**: Parameterized types erased at runtime; compile-time safety only
|
||||
- **Annotations**: Metadata markers (`@Override`, `@Autowired`) processed at compile or runtime
|
||||
- **Interfaces and Abstract Classes**: Contracts with default methods (Java 8+) and partial implementations
|
||||
- **Streams API**: Functional-style pipeline operations on collections (filter, map, reduce)
|
||||
- **Lambdas**: Concise anonymous function syntax for functional interfaces
|
||||
- **Sealed Classes**: Restricted class hierarchies with explicit permitted subclasses (Java 17+)
|
||||
- **Records**: Immutable data carriers with auto-generated accessors, equals, hashCode (Java 16+)
|
||||
- **Dependency Injection**: IoC pattern central to Spring; constructor, field, or method injection
|
||||
- **Checked vs Unchecked Exceptions**: Checked must be declared or caught; unchecked extend RuntimeException
|
||||
- **Optional**: Container for nullable values encouraging explicit handling over null checks
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `import package.Class` — import a specific class
|
||||
- `import package.*` — wildcard import of all classes in a package
|
||||
- `import static package.Class.method` — static import for direct method/constant access
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `src/main/java/` — source root following Maven/Gradle standard layout
|
||||
- `src/test/java/` — test source root with matching package structure
|
||||
- `pom.xml` — Maven project configuration and dependency management
|
||||
- `build.gradle` — Gradle build script (Groovy or Kotlin DSL)
|
||||
- `Application.java` — Spring Boot entry point with `@SpringBootApplication`
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Spring Boot** — Opinionated framework for production-ready Spring applications
|
||||
- **Jakarta EE** — Enterprise Java standards (formerly Java EE) for server-side development
|
||||
- **Quarkus** — Cloud-native framework optimized for GraalVM and containers
|
||||
- **Micronaut** — Compile-time DI framework for microservices and serverless
|
||||
- **Hibernate** — ORM framework implementing JPA specification
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses `@Autowired` annotation for constructor injection, following Spring IoC container
|
||||
> pattern. Constructor injection is preferred over field injection because it makes
|
||||
> dependencies explicit and enables immutability.
|
||||
>
|
||||
> The Maven standard directory layout (`src/main/java`, `src/test/java`) is a strong
|
||||
> convention — most build tools and IDEs expect this structure by default.
|
||||
46
.qoder/skills/understand/languages/javascript.md
Normal file
46
.qoder/skills/understand/languages/javascript.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# JavaScript Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Closures**: Functions that capture variables from their enclosing lexical scope
|
||||
- **Prototypes**: Prototype chain-based inheritance underlying all JavaScript objects
|
||||
- **Promises**: Asynchronous value containers enabling `.then()` chaining and `async/await`
|
||||
- **Event Loop**: Single-threaded concurrency model with microtask and macrotask queues
|
||||
- **Destructuring**: Extract values from objects and arrays into distinct variables
|
||||
- **Spread/Rest Operators**: `...` for expanding iterables or collecting remaining arguments
|
||||
- **Proxies**: Meta-programming construct to intercept and customize object operations
|
||||
- **Generators**: Functions using `function*` and `yield` for lazy iteration
|
||||
- **Symbol**: Unique, immutable primitive used for non-string property keys
|
||||
- **WeakMap/WeakSet**: Collections with weakly-held keys allowing garbage collection
|
||||
- **Modules (ESM vs CJS)**: ES Modules use `import/export`; CommonJS uses `require/module.exports`
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `import { X } from 'module'` — ESM named import
|
||||
- `const X = require('module')` — CommonJS require
|
||||
- `import('module')` — dynamic import returning a Promise (code splitting)
|
||||
- `export default X` / `export { X }` — ESM export forms
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `index.js` — barrel file or directory entry point
|
||||
- `.mjs` — explicitly ES Module files
|
||||
- `.cjs` — explicitly CommonJS files
|
||||
- `package.json` `"type"` field — sets default module system (`"module"` or `"commonjs"`)
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **React** — Declarative UI with virtual DOM and component model
|
||||
- **Vue** — Progressive framework with reactivity system and single-file components
|
||||
- **Express** — Minimal and flexible Node.js web application framework
|
||||
- **Next.js** — React framework for production with hybrid rendering
|
||||
- **Svelte** — Compile-time framework that shifts work from runtime to build step
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Closure captures outer `config` variable, providing encapsulated state without class
|
||||
> overhead. The returned object's methods share access to the same `config` reference,
|
||||
> forming a module pattern that was standard before ES Modules.
|
||||
>
|
||||
> When encountering `.mjs` vs `.cjs` extensions, the module system is determined by
|
||||
> extension regardless of the `package.json` type field — useful in mixed codebases.
|
||||
34
.qoder/skills/understand/languages/json.md
Normal file
34
.qoder/skills/understand/languages/json.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# JSON Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Strict Syntax**: No trailing commas, no comments (unlike JSONC or JSON5), double-quoted strings only
|
||||
- **Data Types**: Objects, arrays, strings, numbers, booleans, and null — no undefined or date types
|
||||
- **Nested Structure**: Arbitrary nesting depth for hierarchical configuration or data
|
||||
- **Schema Validation**: JSON Schema (`$schema` keyword) for validating structure and types
|
||||
- **JSONC**: JSON with Comments variant used by VS Code, tsconfig.json, and other tooling
|
||||
- **JSON5**: Extended JSON allowing comments, trailing commas, unquoted keys, and more
|
||||
- **JSON Lines** (`.jsonl`): One JSON object per line for streaming data processing
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `package.json` — Node.js project manifest with dependencies, scripts, and metadata
|
||||
- `tsconfig.json` — TypeScript compiler configuration (actually JSONC)
|
||||
- `.eslintrc.json` — ESLint linting rules and configuration
|
||||
- `*.schema.json` — JSON Schema definitions for validation
|
||||
- `composer.json` — PHP Composer project manifest
|
||||
- `appsettings.json` — .NET application configuration
|
||||
- `manifest.json` — Browser extension or PWA manifest
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- `package.json` `configures` the build toolchain and defines project dependencies
|
||||
- `tsconfig.json` `configures` TypeScript compilation for all `.ts` files
|
||||
- JSON Schema files `defines_schema` for API request/response validation
|
||||
- Config JSON files `configures` the runtime behavior of the application
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Node.js project manifest defining N dependencies, build scripts, and project metadata."
|
||||
> "TypeScript compiler configuration enabling strict mode with path aliases for monorepo packages."
|
||||
> "JSON Schema defining the request/response structure for the user API endpoint."
|
||||
45
.qoder/skills/understand/languages/kotlin.md
Normal file
45
.qoder/skills/understand/languages/kotlin.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# Kotlin Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Coroutines and Flow**: Structured concurrency with suspending functions; Flow for reactive streams
|
||||
- **Data Classes**: Auto-generated `equals`, `hashCode`, `toString`, `copy`, and destructuring
|
||||
- **Sealed Classes/Interfaces**: Restricted hierarchies enabling exhaustive `when` expressions
|
||||
- **Extension Functions**: Add methods to existing classes without inheritance or wrappers
|
||||
- **Null Safety**: `?.` safe call, `!!` non-null assertion, `?:` Elvis operator for default values
|
||||
- **Delegation (by keyword)**: Delegate interface implementation or property access to another object
|
||||
- **DSL Builders**: Lambda-with-receiver syntax enabling type-safe builder patterns
|
||||
- **Inline Functions and Reified Types**: Inline for zero-overhead lambdas; reified for runtime type access
|
||||
- **Companion Objects**: Named or anonymous singleton associated with a class (replaces static members)
|
||||
- **Scope Functions**: `let`, `run`, `apply`, `also`, `with` for concise object configuration and transformation
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `import package.ClassName` — import a specific class
|
||||
- `import package.*` — wildcard import of all declarations in a package
|
||||
- `import package.function as alias` — import with alias to resolve naming conflicts
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `build.gradle.kts` — Gradle build script using Kotlin DSL
|
||||
- `Application.kt` — application entry point (Spring Boot or Ktor)
|
||||
- `src/main/kotlin/` — main source root following Gradle conventions
|
||||
- `src/test/kotlin/` — test source root with matching package structure
|
||||
- `settings.gradle.kts` — multi-module project configuration
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Spring Boot (Kotlin)** — Kotlin-first support with coroutines and DSL extensions
|
||||
- **Ktor** — Kotlin-native async web framework from JetBrains
|
||||
- **Jetpack Compose** — Declarative UI toolkit for Android using composable functions
|
||||
- **Exposed** — Lightweight SQL framework with type-safe DSL and DAO patterns
|
||||
- **Koin** — Pragmatic dependency injection framework using Kotlin DSL
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses sealed class hierarchy with `when` exhaustive matching to handle all possible
|
||||
> API response states. The compiler enforces that every variant is covered, eliminating
|
||||
> the need for a fallback `else` branch and catching missing cases at compile time.
|
||||
>
|
||||
> Extension functions allow adding utilities like `String.toSlug()` without modifying
|
||||
> the original class — keeping the extension discoverable through IDE auto-complete.
|
||||
34
.qoder/skills/understand/languages/markdown.md
Normal file
34
.qoder/skills/understand/languages/markdown.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Markdown Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Heading Hierarchy**: `#` through `######` for document structure, with h1 as the title
|
||||
- **Front Matter**: YAML metadata between `---` delimiters at the top of the file
|
||||
- **Fenced Code Blocks**: Triple backticks with optional language identifier for syntax highlighting
|
||||
- **Reference-Style Links**: `[text][ref]` with `[ref]: url` definitions, useful for repeated URLs
|
||||
- **Tables**: Pipe-delimited columns with alignment markers (`:---`, `:---:`, `---:`)
|
||||
- **Admonitions**: Blockquote-based callouts (`> **Note:**`, `> **Warning:**`) for emphasis
|
||||
- **Task Lists**: `- [ ]` and `- [x]` for checklists in issue trackers and READMEs
|
||||
- **HTML Embedding**: Raw HTML allowed inline for features Markdown does not support natively
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `README.md` — Project overview and entry point for new contributors (high-value)
|
||||
- `CONTRIBUTING.md` — Contribution guidelines, code style, PR process
|
||||
- `CHANGELOG.md` — Version history following Keep a Changelog or similar format
|
||||
- `docs/**/*.md` — Documentation directory with guides, API references, tutorials
|
||||
- `*.md` in source directories — Co-located documentation for modules or packages
|
||||
- `ADR-*.md` or `adr/*.md` — Architecture Decision Records
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- Markdown files `documents` the code components they describe or reference
|
||||
- Links to other `.md` files create `related` edges between documentation nodes
|
||||
- Code block references mentioning file paths may imply `documents` edges to those files
|
||||
- README files in subdirectories typically `documents` the module at that path
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Project overview documentation with N sections covering installation, usage, and API reference."
|
||||
> "Architecture Decision Record documenting the choice of [technology] for [purpose]."
|
||||
> "Contributing guide with code style rules, testing requirements, and pull request process."
|
||||
46
.qoder/skills/understand/languages/php.md
Normal file
46
.qoder/skills/understand/languages/php.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# PHP Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Namespaces**: Organize code and prevent naming collisions using backslash-delimited paths
|
||||
- **Traits**: Horizontal code reuse mechanism for sharing methods across unrelated classes
|
||||
- **Type Declarations**: Parameter, return, and property types (scalar, union, intersection types)
|
||||
- **Attributes (PHP 8+)**: Native metadata annotations replacing docblock-based configuration
|
||||
- **Enums (PHP 8.1+)**: First-class enumeration types with methods and interface implementation
|
||||
- **Fibers**: Lightweight cooperative concurrency primitives for non-blocking I/O
|
||||
- **Closures/Anonymous Functions**: First-class functions with explicit `use` for variable capture
|
||||
- **Magic Methods**: Special methods like `__construct`, `__get`, `__set`, `__call` for object behavior
|
||||
- **Dependency Injection**: Constructor injection managed by PSR-11 compatible containers
|
||||
- **Middleware**: Request/response pipeline pattern central to modern PHP frameworks
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `use Namespace\ClassName` — import a class by its fully qualified name
|
||||
- `use Namespace\ClassName as Alias` — import with an alias to avoid conflicts
|
||||
- `namespace App\Http\Controllers` — declare the current file's namespace
|
||||
- `use function Namespace\functionName` — import a namespaced function
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `composer.json` — dependency management and PSR-4 autoloading configuration
|
||||
- `index.php` — web application entry point (front controller)
|
||||
- `artisan` — Laravel CLI entry point for commands and migrations
|
||||
- `routes/` — route definition files (web.php, api.php in Laravel)
|
||||
- PSR-4 autoloading maps namespace prefixes to directory paths
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Laravel** — Full-featured framework with Eloquent ORM, Blade templates, and queues
|
||||
- **Symfony** — Component-based framework powering many PHP projects and libraries
|
||||
- **WordPress** — CMS platform with hook-based plugin architecture
|
||||
- **Slim** — Micro-framework for APIs and small applications
|
||||
- **CodeIgniter** — Lightweight MVC framework with minimal configuration
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses PHP 8 attributes `#[Route('/api/users')]` for declarative route mapping on
|
||||
> controller methods. Attributes replace the older docblock annotation pattern,
|
||||
> providing native language support for metadata that tools can reflect upon.
|
||||
>
|
||||
> PSR-4 autoloading in `composer.json` maps `App\` to `src/`, so the class
|
||||
> `App\Http\Controllers\UserController` loads from `src/Http/Controllers/UserController.php`.
|
||||
34
.qoder/skills/understand/languages/protobuf.md
Normal file
34
.qoder/skills/understand/languages/protobuf.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Protobuf Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Message Types**: `message` blocks defining structured data with typed, numbered fields
|
||||
- **Field Numbers**: Permanent identifiers (1-536870911) — never reuse deleted numbers for backward compatibility
|
||||
- **Scalar Types**: `int32`, `int64`, `string`, `bytes`, `bool`, `float`, `double`, and more
|
||||
- **Enums**: Named integer constants for categorical values
|
||||
- **Services**: `service` blocks defining RPC (Remote Procedure Call) method signatures
|
||||
- **Oneof**: Mutually exclusive field groups — only one field in the group can be set
|
||||
- **Repeated Fields**: `repeated` keyword for list/array fields
|
||||
- **Maps**: `map<key_type, value_type>` for dictionary/hash fields
|
||||
- **Packages and Imports**: Namespace organization and cross-file references
|
||||
- **Proto2 vs Proto3**: Proto3 (current) removes required/optional distinction and defaults all fields
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `*.proto` — Protocol Buffer definition files
|
||||
- `proto/**/*.proto` — Organized proto definitions by service or domain
|
||||
- `buf.yaml` / `buf.gen.yaml` — Buf tool configuration for linting and code generation
|
||||
- `*_pb2.py` / `*.pb.go` / `*_pb.ts` — Generated code (should be excluded from analysis)
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- Protobuf files `defines_schema` for the gRPC service handlers that implement the declared RPCs
|
||||
- Message type references create `related` edges between proto files sharing types
|
||||
- Proto `import` statements create `depends_on` edges between proto files
|
||||
- Generated code files are `depends_on` the proto source that produces them
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Protocol Buffer definitions for N message types and M RPC services in the user authentication domain."
|
||||
> "Shared proto types defining common request/response envelopes and error codes."
|
||||
> "gRPC service definition with N methods for real-time data streaming and batch processing."
|
||||
48
.qoder/skills/understand/languages/python.md
Normal file
48
.qoder/skills/understand/languages/python.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Python Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Decorators**: Functions that wrap other functions or classes using `@decorator` syntax
|
||||
- **List/Dict Comprehensions**: Concise syntax for creating collections from iterables
|
||||
- **Generators and Yield**: Lazy iterators using `yield` for memory-efficient data processing
|
||||
- **Context Managers**: `with` statement for resource management via `__enter__`/`__exit__`
|
||||
- **Type Hints and Typing Module**: Optional static type annotations for tooling and documentation
|
||||
- **Dunder Methods**: Special methods like `__init__`, `__repr__`, `__eq__` defining object behavior
|
||||
- **Metaclasses**: Classes that define how other classes are created (type as default metaclass)
|
||||
- **Dataclasses**: `@dataclass` decorator auto-generating boilerplate from field annotations
|
||||
- **Protocols**: Structural subtyping via `typing.Protocol` for duck-type-safe interfaces
|
||||
- **Descriptors**: Objects defining `__get__`, `__set__`, `__delete__` to customize attribute access
|
||||
- **Async/Await with Asyncio**: Cooperative concurrency using coroutines and an event loop
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `from module import name` — import specific name from module
|
||||
- `import module` — import entire module, access via `module.name`
|
||||
- `from package.module import name` — absolute import from nested package
|
||||
- `from . import relative` — relative import within a package
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `__init__.py` — package initializer (barrel equivalent), can re-export public API
|
||||
- `__main__.py` — package entry point when run with `python -m package`
|
||||
- `conftest.py` — pytest shared fixtures and hooks (auto-discovered)
|
||||
- `setup.py` / `pyproject.toml` — project configuration and build metadata
|
||||
- `requirements.txt` — pinned dependency list
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Django** — Full-stack web framework with ORM, admin, and batteries included
|
||||
- **FastAPI** — Modern async API framework with automatic OpenAPI docs
|
||||
- **Flask** — Lightweight WSGI micro-framework for web applications
|
||||
- **SQLAlchemy** — SQL toolkit and ORM with unit-of-work pattern
|
||||
- **Celery** — Distributed task queue for background job processing
|
||||
- **Pydantic** — Data validation and settings management using type annotations
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses `@dataclass` decorator to auto-generate `__init__`, `__repr__`, and `__eq__` from
|
||||
> field annotations. This eliminates boilerplate while keeping the class definition
|
||||
> readable and the generated methods consistent.
|
||||
>
|
||||
> When `__init__.py` re-exports symbols, it acts as the package's public API surface —
|
||||
> consumers import from the package rather than reaching into internal modules.
|
||||
46
.qoder/skills/understand/languages/ruby.md
Normal file
46
.qoder/skills/understand/languages/ruby.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# Ruby Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Blocks/Procs/Lambdas**: First-class callable objects; blocks are implicit, procs and lambdas are explicit
|
||||
- **Mixins (include/extend)**: Share behavior across classes via modules without inheritance
|
||||
- **Metaprogramming**: Dynamic method definition (`define_method`), interception (`method_missing`)
|
||||
- **Duck Typing**: Objects are defined by what they can do, not what class they are
|
||||
- **DSLs**: Domain-specific languages built using blocks and metaprogramming (e.g., Rails routes)
|
||||
- **Monkey Patching**: Reopening existing classes to add or modify methods at runtime
|
||||
- **Symbols**: Immutable, interned strings (`:name`) used as identifiers and hash keys
|
||||
- **Open Classes**: Any class can be reopened and extended at any point in the program
|
||||
- **Enumerable Module**: Mixin providing collection methods (map, select, reduce) to any class with `each`
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `require 'gem_name'` — load a gem or standard library module
|
||||
- `require_relative './file'` — load a file relative to the current file's directory
|
||||
- `load 'file.rb'` — load and re-execute a file (unlike require, does not cache)
|
||||
- `autoload :ClassName, 'path'` — lazy loading of constants on first reference
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `Gemfile` — dependency declarations managed by Bundler
|
||||
- `Rakefile` — task definitions (Ruby's make equivalent)
|
||||
- `spec/` — RSpec test directory with `*_spec.rb` convention
|
||||
- `test/` — Minitest directory with `test_*.rb` or `*_test.rb` convention
|
||||
- `config.ru` — Rack application entry point for web servers
|
||||
- `lib/` — main source code directory by convention
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Rails** — Full-stack web framework following convention over configuration
|
||||
- **Sinatra** — Minimal DSL for creating web applications quickly
|
||||
- **RSpec** — Behavior-driven testing framework with expressive DSL
|
||||
- **Sidekiq** — Background job processing using Redis-backed queues
|
||||
- **Grape** — REST API micro-framework for Ruby
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses `method_missing` to dynamically delegate attribute access to the wrapped model
|
||||
> object. When a method is not found on the decorator, it falls through to the model,
|
||||
> providing transparent delegation without explicit forwarding methods.
|
||||
>
|
||||
> Rails relies heavily on convention over configuration — file placement in `app/models/`,
|
||||
> `app/controllers/`, etc. determines behavior without explicit registration.
|
||||
47
.qoder/skills/understand/languages/rust.md
Normal file
47
.qoder/skills/understand/languages/rust.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# Rust Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Ownership and Borrowing**: Each value has one owner; references borrow without taking ownership
|
||||
- **Lifetimes**: Annotations (`'a`) ensuring references remain valid for their required duration
|
||||
- **Traits and Trait Objects**: Shared behavior definitions; `dyn Trait` for dynamic dispatch
|
||||
- **Pattern Matching**: Exhaustive `match` expressions deconstructing enums, structs, and tuples
|
||||
- **Enums with Data**: Algebraic data types — each variant can carry different associated data
|
||||
- **Result/Option Error Handling**: `Result<T, E>` for fallible ops; `Option<T>` for nullable values
|
||||
- **Macros**: Declarative (`macro_rules!`) and procedural (derive, attribute, function-like) code generation
|
||||
- **Async/Await with Tokio**: Zero-cost async using `Future` trait and runtime executors
|
||||
- **Unsafe Blocks**: Opt-in blocks for raw pointer dereferencing, FFI, and bypassing borrow checker
|
||||
- **Generics with Trait Bounds**: `<T: Clone + Send>` constraining generic parameters
|
||||
- **Closures and Fn Traits**: `Fn`, `FnMut`, `FnOnce` determine how closures capture environment
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `use crate::module::Item` — import from current crate
|
||||
- `use std::collections::HashMap` — import from standard library
|
||||
- `use super::*` — import everything from parent module
|
||||
- `mod module_name` — declare a submodule (loads from file)
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `mod.rs` — module barrel file (older convention) or `module_name.rs` (2018+ edition)
|
||||
- `lib.rs` — library crate root defining the public API
|
||||
- `main.rs` — binary crate entry point
|
||||
- `Cargo.toml` — project manifest with dependencies and metadata
|
||||
- `build.rs` — build script executed before compilation
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **Actix-web** — Actor-based, high-performance web framework
|
||||
- **Axum** — Ergonomic web framework built on Tower and Hyper
|
||||
- **Rocket** — Type-safe web framework with declarative routing
|
||||
- **Diesel** — Safe, composable ORM and query builder
|
||||
- **Tokio** — Async runtime providing I/O, timers, and task scheduling
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Takes `&self` borrow to read state without transferring ownership; returns
|
||||
> `Result<T, Error>` for explicit error propagation. The `?` operator propagates
|
||||
> errors up the call stack concisely, replacing verbose match blocks.
|
||||
>
|
||||
> The module system maps to the filesystem: `mod handlers;` loads either
|
||||
> `handlers.rs` or `handlers/mod.rs`, establishing the module tree at compile time.
|
||||
35
.qoder/skills/understand/languages/shell.md
Normal file
35
.qoder/skills/understand/languages/shell.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Shell Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Shebang Line**: `#!/bin/bash` or `#!/usr/bin/env bash` specifying the interpreter
|
||||
- **Variables**: `VAR=value` assignment, `$VAR` or `${VAR}` expansion, no spaces around `=`
|
||||
- **Functions**: `function name()` or `name()` for reusable command groups
|
||||
- **Conditionals**: `if [[ condition ]]; then ... fi` with `[[ ]]` for extended tests
|
||||
- **Loops**: `for item in list`, `while condition`, `until condition` iteration patterns
|
||||
- **Pipes and Redirection**: `|` for chaining commands, `>` / `>>` / `2>&1` for output redirection
|
||||
- **Exit Codes**: `$?` captures last command status; `set -e` exits on any failure
|
||||
- **Strict Mode**: `set -euo pipefail` for robust error handling (exit on error, undefined vars, pipe failures)
|
||||
- **Command Substitution**: `$(command)` captures command output as a string
|
||||
- **Here Documents**: `<<EOF ... EOF` for multi-line string input to commands
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `*.sh` / `*.bash` — Shell script files
|
||||
- `scripts/*.sh` — Project automation scripts (build, deploy, setup)
|
||||
- `entrypoint.sh` — Docker container entry point script
|
||||
- `install.sh` / `setup.sh` — Environment setup scripts
|
||||
- `.bashrc` / `.bash_profile` / `.zshrc` — Shell configuration files
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- Shell scripts `triggers` other scripts or build processes they invoke
|
||||
- Entry point scripts `deploys` the application they start
|
||||
- Setup scripts `configures` the development environment
|
||||
- Build scripts `depends_on` the source files they compile or package
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Build automation script compiling TypeScript, running tests, and packaging the release artifact."
|
||||
> "Docker entry point script handling signal forwarding and graceful shutdown."
|
||||
> "Environment setup script installing dependencies and configuring development tools."
|
||||
36
.qoder/skills/understand/languages/sql.md
Normal file
36
.qoder/skills/understand/languages/sql.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# SQL Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **DDL (Data Definition)**: `CREATE TABLE`, `ALTER TABLE`, `DROP TABLE` for schema management
|
||||
- **DML (Data Manipulation)**: `SELECT`, `INSERT`, `UPDATE`, `DELETE` for data operations
|
||||
- **Normalization**: Organizing tables to reduce redundancy through 1NF, 2NF, 3NF relationships
|
||||
- **Foreign Keys**: `REFERENCES` constraints enforcing referential integrity between tables
|
||||
- **Indexes**: `CREATE INDEX` for query performance optimization on frequently queried columns
|
||||
- **Migrations**: Numbered, sequential schema changes applied in order for version control
|
||||
- **Transactions**: `BEGIN`/`COMMIT`/`ROLLBACK` for atomic multi-statement operations
|
||||
- **Views**: Named queries (`CREATE VIEW`) providing virtual tables for complex joins
|
||||
- **Stored Procedures**: Server-side functions for encapsulating business logic in the database
|
||||
- **Constraints**: `NOT NULL`, `UNIQUE`, `CHECK`, `DEFAULT` for data integrity rules
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `migrations/*.sql` — Numbered migration files (e.g., `001_create_users.sql`, `002_add_orders.sql`)
|
||||
- `schema.sql` — Full database schema definition (often generated from migrations)
|
||||
- `seeds/*.sql` — Seed data for development and testing environments
|
||||
- `*.up.sql` / `*.down.sql` — Reversible migration pairs (up applies, down reverts)
|
||||
- `init.sql` — Database initialization script for Docker or fresh setup
|
||||
- `procedures/*.sql` — Stored procedure definitions
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- SQL migration files `migrates` the tables they create or alter
|
||||
- Schema definition files `defines_schema` for the ORM models or data layer code that reads them
|
||||
- Table definitions create implicit `related` edges between tables connected by foreign keys
|
||||
- Seed files `depends_on` the migration files that create the tables they populate
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Database migration creating the users table with email, name, and authentication columns."
|
||||
> "Schema definition with N tables covering user management, orders, and payment processing."
|
||||
> "Seed data populating N tables with development fixtures for testing."
|
||||
46
.qoder/skills/understand/languages/swift.md
Normal file
46
.qoder/skills/understand/languages/swift.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# Swift Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Optionals and Optional Chaining**: `Type?` wraps values that may be nil; `?.` chains safely
|
||||
- **Protocols and Protocol Extensions**: Define contracts with default implementations via extensions
|
||||
- **Value Types vs Reference Types**: Structs and enums are value types; classes are reference types
|
||||
- **Closures**: Self-contained blocks of functionality that capture surrounding context
|
||||
- **Property Wrappers**: `@State`, `@Binding`, `@Published` encapsulate property storage logic
|
||||
- **Result Builders**: `@ViewBuilder`, `@resultBuilder` enable declarative DSL syntax
|
||||
- **Actors and Structured Concurrency**: `actor` types for data isolation; `async let`, `TaskGroup`
|
||||
- **Generics**: Type parameters with `where` clauses and associated type constraints
|
||||
- **Enums with Associated Values**: Each case can carry distinct typed payloads
|
||||
- **Extensions**: Add methods, computed properties, and protocol conformance to existing types
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `import Foundation` — core library with data types, collections, networking
|
||||
- `import UIKit` — iOS UI framework for traditional view controller architecture
|
||||
- `import SwiftUI` — declarative UI framework with reactive state management
|
||||
- `@testable import ModuleName` — import with internal access for unit testing
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `Package.swift` — Swift Package Manager manifest defining targets and dependencies
|
||||
- `*.xcodeproj` / `*.xcworkspace` — Xcode project and workspace configuration
|
||||
- `AppDelegate.swift` — UIKit application lifecycle entry point
|
||||
- `App.swift` — SwiftUI application entry point using `@main`
|
||||
- `Tests/` — test target directory following SPM or Xcode conventions
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **SwiftUI** — Declarative UI framework with reactive data flow
|
||||
- **UIKit** — Imperative UI framework using view controllers and Auto Layout
|
||||
- **Vapor** — Server-side Swift web framework with async support
|
||||
- **Combine** — Reactive framework for processing values over time
|
||||
- **Core Data** — Object graph and persistence framework
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses `@Published` property wrapper to automatically notify SwiftUI views of state
|
||||
> changes. When the wrapped value mutates, the property wrapper triggers `objectWillChange`
|
||||
> on the enclosing `ObservableObject`, causing dependent views to re-render.
|
||||
>
|
||||
> Protocol extensions provide default implementations, allowing types to conform by
|
||||
> simply declaring conformance — no method body needed if defaults suffice.
|
||||
38
.qoder/skills/understand/languages/terraform.md
Normal file
38
.qoder/skills/understand/languages/terraform.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Terraform Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Declarative Infrastructure**: Define desired state; Terraform computes and applies the diff
|
||||
- **Providers**: Plugins connecting to cloud APIs (AWS, GCP, Azure, Kubernetes, etc.)
|
||||
- **Resources**: `resource "type" "name"` blocks declaring infrastructure components
|
||||
- **Data Sources**: `data "type" "name"` blocks reading existing infrastructure state
|
||||
- **Variables**: `variable` blocks for parameterizing configurations with defaults and validation
|
||||
- **Outputs**: `output` blocks exposing values for cross-module references or human consumption
|
||||
- **Modules**: Reusable, composable infrastructure packages with their own variables and outputs
|
||||
- **State Management**: `.tfstate` files tracking real-world resource mapping (never commit to git)
|
||||
- **Workspaces**: Isolated state environments for managing dev/staging/prod from one codebase
|
||||
- **Plan and Apply**: `terraform plan` previews changes, `terraform apply` executes them
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `main.tf` — Primary resource definitions
|
||||
- `variables.tf` — Input variable declarations with types and defaults
|
||||
- `outputs.tf` — Output value definitions
|
||||
- `providers.tf` — Provider configuration and version constraints
|
||||
- `backend.tf` — Remote state backend configuration (S3, GCS, etc.)
|
||||
- `modules/**/*.tf` — Reusable infrastructure modules
|
||||
- `*.tfvars` — Variable value files for different environments
|
||||
- `terraform.lock.hcl` — Provider version lock file
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- Terraform files `provisions` the infrastructure resources they define
|
||||
- Module references create `depends_on` edges between terraform files
|
||||
- Terraform `deploys` application code by referencing container images or deployment targets
|
||||
- Variable files `configures` the terraform modules they parameterize
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Terraform configuration provisioning N AWS resources including VPC, ECS cluster, and RDS instance."
|
||||
> "Infrastructure module defining a reusable Kubernetes namespace with RBAC and network policies."
|
||||
> "Variable definitions for N environment-specific settings (region, instance type, scaling)."
|
||||
46
.qoder/skills/understand/languages/typescript.md
Normal file
46
.qoder/skills/understand/languages/typescript.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# TypeScript Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Generics**: Parameterized types (`<T>`) enabling reusable, type-safe abstractions
|
||||
- **Type Guards**: Runtime checks that narrow types within conditional blocks (`is`, `in`, `typeof`, `instanceof`)
|
||||
- **Discriminated Unions**: Union types with a shared literal field used for exhaustive narrowing
|
||||
- **Utility Types**: Built-in mapped types like `Partial<T>`, `Pick<T, K>`, `Omit<T, K>`, `Record<K, V>`
|
||||
- **Interfaces vs Types**: Interfaces support declaration merging; type aliases support unions and mapped types
|
||||
- **Enums**: Numeric and string enums for named constant sets; prefer `as const` objects when possible
|
||||
- **Mapped Types**: Transform existing types property-by-property using `[K in keyof T]` syntax
|
||||
- **Conditional Types**: `T extends U ? X : Y` for type-level branching logic
|
||||
- **Template Literal Types**: String manipulation at the type level using backtick syntax
|
||||
- **Declaration Merging**: Interfaces with the same name merge their members automatically
|
||||
- **Module Augmentation**: Extending third-party module types via `declare module` blocks
|
||||
|
||||
## Import Patterns
|
||||
|
||||
- `import { X } from 'module'` — named import (most common)
|
||||
- `import type { X } from 'module'` — type-only import (erased at runtime)
|
||||
- `import * as X from 'module'` — namespace import
|
||||
- `import X from 'module'` — default import
|
||||
|
||||
## File Patterns
|
||||
|
||||
- `index.ts` — barrel file re-exporting public API from a directory
|
||||
- `*.d.ts` — type declaration files (ambient declarations, no runtime code)
|
||||
- `tsconfig.json` — TypeScript compiler configuration and project references
|
||||
- `*.tsx` — TypeScript files containing JSX (React components)
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
- **React** — UI component library with hooks and JSX
|
||||
- **Angular** — Full-featured framework with decorators and dependency injection
|
||||
- **Next.js** — React meta-framework with SSR, SSG, and API routes
|
||||
- **NestJS** — Server-side framework inspired by Angular (decorators, modules, DI)
|
||||
- **Express (with TS)** — Minimal HTTP framework with typed request/response handlers
|
||||
|
||||
## Example Language Notes
|
||||
|
||||
> Uses generic type parameter `T extends BaseEntity` to ensure type safety across
|
||||
> repository methods. The constraint guarantees all entities share a common `id` field
|
||||
> while allowing specific entity types to flow through the data layer without casting.
|
||||
>
|
||||
> Barrel files (`index.ts`) re-export symbols so consumers import from the directory
|
||||
> rather than reaching into internal module paths — maintaining encapsulation.
|
||||
35
.qoder/skills/understand/languages/yaml.md
Normal file
35
.qoder/skills/understand/languages/yaml.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# YAML Language Prompt Snippet
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Indentation-Based Nesting**: Whitespace-sensitive structure (spaces only, no tabs) defining hierarchy
|
||||
- **Anchors and Aliases**: `&anchor` defines a reusable block, `*anchor` references it to avoid duplication
|
||||
- **Merge Keys**: `<<: *anchor` merges anchor contents into the current mapping
|
||||
- **Multi-Line Strings**: Literal block (`|`) preserves newlines, folded block (`>`) joins lines
|
||||
- **Document Separators**: `---` starts a new document, `...` ends one (multi-document streams)
|
||||
- **Tags and Types**: `!!str`, `!!int`, `!!bool` for explicit typing; custom tags for application-specific types
|
||||
- **Flow Style**: Inline JSON-like syntax `{key: value}` and `[item1, item2]` for compact notation
|
||||
- **Environment Variable Substitution**: `${VAR}` patterns used in docker-compose and CI configs
|
||||
|
||||
## Notable File Patterns
|
||||
|
||||
- `docker-compose.yml` / `docker-compose.yaml` — Multi-container Docker application definition
|
||||
- `.github/workflows/*.yml` — GitHub Actions CI/CD workflow definitions
|
||||
- `.gitlab-ci.yml` — GitLab CI/CD pipeline configuration
|
||||
- `kubernetes/*.yaml` / `k8s/*.yaml` — Kubernetes resource manifests
|
||||
- `*.config.yaml` — Application configuration files
|
||||
- `mkdocs.yml` — MkDocs documentation site configuration
|
||||
- `serverless.yml` — Serverless Framework configuration
|
||||
|
||||
## Edge Patterns
|
||||
|
||||
- YAML config files `configures` the code modules they control (e.g., database settings affect data layer)
|
||||
- CI/CD YAML files `triggers` build and deployment pipelines
|
||||
- docker-compose YAML `deploys` services and `depends_on` Dockerfiles
|
||||
- Kubernetes YAML `deploys` and `provisions` application services
|
||||
|
||||
## Summary Style
|
||||
|
||||
> "Docker Compose configuration defining N services with networking, volumes, and health checks."
|
||||
> "GitHub Actions workflow running tests on push and deploying to production on merge to main."
|
||||
> "Kubernetes deployment manifest with N replicas, resource limits, and liveness probes."
|
||||
Reference in New Issue
Block a user