en un clic
SqlBuildingBlocks
SqlBuildingBlocks contient 5 skills collectées depuis Servant-Software-LLC, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
Run the SqlBuildingBlocks five-agent assessment team against the current GitHub issue backlog and generate a unified status + readiness report with a lightweight local findings index. Use at the start of a work session to get the current readiness picture, or after filing new issues to reassess sequencing and risks. The GitHub issues are the single source of truth for finding descriptions and rationale. The local findings index stores only execution metadata: filesExpected, dependsOn, status, wave tracking, route — for use by `/execute-tasks`.
Developer-specific knowledge for working in the SqlBuildingBlocks codebase. Use when implementing features, fixing bugs, adding grammar rules, extending logical entities, writing tests, or navigating the project structure. Covers: solution layout, Irony grammar patterns, NonTerminal hierarchy, logical entity classes, query engine, visitor pattern, grammar-specific dialects, testing patterns, and practical workflows. SELF-UPDATING: When your work changes, advances, or extends SqlBuildingBlocks in ways that affect this knowledge (new NonTerminals, logical entities, grammar rules, query engine features, etc.), you MUST update this skill to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unchanged content.
Architect's lens on SqlBuildingBlocks. Use when reasoning about system shape, layer boundaries, NonTerminal seams, dialect inheritance, query-engine layering, or the evolution of the architecture itself (not day-to-day coding). Load this when: - Proposing a new grammar dialect, NonTerminal seam, or query-engine extension - Evaluating whether a change respects layer boundaries (Core vs Grammars), Create() dispatch, or consumer NuGet contracts - Reviewing designs for grammar ambiguity, dialect parity, or downstream-consumer impact - Planning the PostgreSQL or SQL Server grammar build-out Do NOT load this skill for "where is file X / how do I add a NonTerminal" -- that is `sqlbuildingblocks-dev-knowledge`. Do NOT load this for product/consumer/maturity questions -- that is `sqlbuildingblocks-domain-knowledge`. SELF-UPDATING: When your work changes, advances, or extends the architecture (new layers, new grammar dialects, query-engine layer changes, resolved architectural gaps), update this skill in the same de
QA-specific knowledge for testing the SqlBuildingBlocks library. Use when planning test strategies, evaluating coverage gaps, writing acceptance criteria, investigating regressions, designing test matrices, or assessing release readiness. Covers: test inventory, coverage analysis, risk-based testing priorities, SQL grammar test matrix, parser correctness verification, query engine testing, edge case catalog, known fragile areas, and test environment setup. SELF-UPDATING: When your work changes, advances, or extends testing in SqlBuildingBlocks (new test projects, coverage changes, discovered edge cases, resolved defects, etc.), you MUST update this skill to reflect the new state before completing your task.
SqlBuildingBlocks product knowledge for Servant Software LLC agents. Use when working on anything related to SqlBuildingBlocks: - Product strategy, roadmap, or feature planning - Technical architecture discussions or documentation - SQL grammar design, dialect support, or parser questions - Integration with consuming projects (FileBased.DataProviders, MockDB) - Understanding current maturity, gaps, or productization needs Provides: product purpose, architecture overview, asset inventory, maturity assessment, and productization gaps. SELF-UPDATING: When your work changes, advances, or extends SqlBuildingBlocks in ways that affect this knowledge (new grammars, features, assets, maturity changes, resolved gaps, etc.), you MUST update this skill and its reference files to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unchanged content.