ai-ops-cli 0.1.23 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (62) hide show
  1. package/README.md +107 -45
  2. package/data/presets.yaml +0 -23
  3. package/data/rules/plan-mode.yaml +4 -2
  4. package/data/skills/README.md +157 -0
  5. package/data/skills/reference-skills/ai-llm-python-runtime/SKILL.md +10 -0
  6. package/data/skills/reference-skills/ai-llm-python-runtime/references/reference.md +26 -0
  7. package/data/skills/reference-skills/backend-python-fastapi-runtime/SKILL.md +10 -0
  8. package/data/skills/reference-skills/backend-python-fastapi-runtime/references/reference.md +43 -0
  9. package/data/skills/reference-skills/backend-service-standards/SKILL.md +10 -0
  10. package/data/skills/reference-skills/backend-service-standards/references/reference.md +29 -0
  11. package/data/skills/reference-skills/backend-ts-nestjs-runtime/SKILL.md +10 -0
  12. package/data/skills/reference-skills/backend-ts-nestjs-runtime/references/reference.md +43 -0
  13. package/data/skills/reference-skills/data-pipeline-python-performance/SKILL.md +10 -0
  14. package/data/skills/reference-skills/data-pipeline-python-performance/references/reference.md +24 -0
  15. package/data/skills/reference-skills/db-prisma-postgresql/SKILL.md +10 -0
  16. package/data/skills/reference-skills/db-prisma-postgresql/references/reference.md +25 -0
  17. package/data/skills/reference-skills/db-sqlalchemy-postgresql/SKILL.md +10 -0
  18. package/data/skills/reference-skills/db-sqlalchemy-postgresql/references/reference.md +25 -0
  19. package/data/skills/reference-skills/frontend-app-flutter-runtime/SKILL.md +10 -0
  20. package/data/skills/reference-skills/frontend-app-flutter-runtime/references/reference.md +50 -0
  21. package/data/skills/reference-skills/frontend-web-react-next-runtime/SKILL.md +10 -0
  22. package/data/skills/reference-skills/frontend-web-react-next-runtime/references/reference.md +51 -0
  23. package/data/skills/reference-skills/frontend-web-shadcn-ui/SKILL.md +10 -0
  24. package/data/skills/reference-skills/frontend-web-shadcn-ui/references/reference.md +26 -0
  25. package/data/skills/reference-skills/graphql-client-integration/SKILL.md +10 -0
  26. package/data/skills/reference-skills/graphql-client-integration/references/reference.md +22 -0
  27. package/data/skills/reference-skills/graphql-contract/SKILL.md +10 -0
  28. package/data/skills/reference-skills/graphql-contract/references/reference.md +22 -0
  29. package/data/skills/reference-skills/graphql-server-runtime/SKILL.md +10 -0
  30. package/data/skills/reference-skills/graphql-server-runtime/references/reference.md +40 -0
  31. package/data/skills/reference-skills/python-language/SKILL.md +10 -0
  32. package/data/skills/reference-skills/python-language/references/reference.md +26 -0
  33. package/data/skills/reference-skills/typescript-language/SKILL.md +10 -0
  34. package/data/skills/reference-skills/typescript-language/references/reference.md +23 -0
  35. package/data/skills/skill-registry.json +148 -0
  36. package/data/skills/task-skills/skill-load-check/SKILL.md +8 -0
  37. package/data/skills/task-skills/skill-load-check/scripts/loaded.js +1 -0
  38. package/dist/bin/index.js +1264 -308
  39. package/dist/bin/index.js.map +1 -1
  40. package/package.json +1 -1
  41. package/data/rules/ai-llm-python.yaml +0 -35
  42. package/data/rules/data-pipeline-python.yaml +0 -34
  43. package/data/rules/engineering-standards.yaml +0 -39
  44. package/data/rules/fastapi.yaml +0 -34
  45. package/data/rules/flutter.yaml +0 -40
  46. package/data/rules/graphql-client-app.yaml +0 -29
  47. package/data/rules/graphql-client-web.yaml +0 -30
  48. package/data/rules/graphql-core.yaml +0 -31
  49. package/data/rules/graphql-server.yaml +0 -33
  50. package/data/rules/libs-backend-python.yaml +0 -35
  51. package/data/rules/libs-backend-ts.yaml +0 -36
  52. package/data/rules/libs-frontend-app.yaml +0 -39
  53. package/data/rules/libs-frontend-web.yaml +0 -39
  54. package/data/rules/nestjs-graphql.yaml +0 -31
  55. package/data/rules/nestjs.yaml +0 -26
  56. package/data/rules/nextjs.yaml +0 -34
  57. package/data/rules/prisma-postgresql.yaml +0 -30
  58. package/data/rules/python.yaml +0 -31
  59. package/data/rules/react-typescript.yaml +0 -11
  60. package/data/rules/shadcn-ui.yaml +0 -36
  61. package/data/rules/sqlalchemy.yaml +0 -32
  62. package/data/rules/typescript.yaml +0 -22
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: db-prisma-postgresql
3
+ description: Use when modifying Prisma schemas, transactions, raw queries, indexes, or PostgreSQL migration safety.
4
+ ---
5
+
6
+ # Prisma PostgreSQL
7
+
8
+ Use this skill before changing Prisma schema, raw SQL usage, migration flow, or PostgreSQL transaction settings.
9
+
10
+ Read `references/reference.md` and use it as the detailed persistence guidance.
@@ -0,0 +1,25 @@
1
+ # Prisma PostgreSQL
2
+
3
+ ## Constraints
4
+
5
+ - Do not interpolate strings in unsafe raw SQL APIs.
6
+ - Do not return Prisma models directly from API boundaries.
7
+ - Do not define mutable models without `updatedAt`.
8
+ - Do not use `$use()` middleware in Prisma v7+ patterns.
9
+ - Do not use `prisma db push` in production.
10
+
11
+ ## Guidelines
12
+
13
+ - Use the Prisma client generator/output layout that matches the current repo convention.
14
+ - Use explicit pool and timeout settings.
15
+ - Add indexes for common where/orderBy/join patterns.
16
+ - Set explicit timeout and `maxWait` for interactive transactions.
17
+ - Centralize datasource and migration settings.
18
+ - Implement soft delete consistently.
19
+ - Prefer cursor pagination over deep skip/take on large tables.
20
+ - Use external pooling or explicit connection limits for serverless/container workloads.
21
+
22
+ ## Decision Rules
23
+
24
+ - When Prisma API cannot express PostgreSQL behavior cleanly, use parameterized raw SQL with typed result mapping.
25
+ - When a transaction has dependent steps, use interactive transactions with explicit timeout and wait settings.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: db-sqlalchemy-postgresql
3
+ description: Use when working on SQLAlchemy models, sessions, loading strategy, Alembic migrations, or PostgreSQL persistence rules.
4
+ ---
5
+
6
+ # SQLAlchemy PostgreSQL
7
+
8
+ Use this skill before changing SQLAlchemy models, sessions, raw SQL usage, or Alembic-managed schema changes.
9
+
10
+ Read `references/reference.md` and apply it as the detailed persistence reference.
@@ -0,0 +1,25 @@
1
+ # SQLAlchemy PostgreSQL
2
+
3
+ ## Constraints
4
+
5
+ - Do not use legacy `session.query()` patterns.
6
+ - Do not execute raw SQL strings directly outside migrations.
7
+ - Do not call `session.commit()` from scattered layers.
8
+ - Do not omit `created_at` and `updated_at` on mutable models.
9
+ - Do not change schema without Alembic migrations.
10
+
11
+ ## Guidelines
12
+
13
+ - Use `Mapped[T]` and `mapped_column()` declarative mappings.
14
+ - Define relationships explicitly with `back_populates`.
15
+ - Use `AsyncSession` and `async_sessionmaker` for async stacks.
16
+ - Implement soft delete consistently.
17
+ - Prefer migration-safe string enums.
18
+ - Declare indexes and unique constraints explicitly.
19
+ - Prevent N+1 with explicit loading strategy. Do not rely on lazy loading by default.
20
+
21
+ ## Decision Rules
22
+
23
+ - When routine CRUD is needed, prefer ORM expressions.
24
+ - When complex analytical SQL is needed, use parameterized `text()` or a fit-for-purpose analytical engine.
25
+ - When schema changes are required, generate and review Alembic migrations before applying them.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: frontend-app-flutter-runtime
3
+ description: Use when implementing Flutter app features, Riverpod state, routing, immutable models, Dio networking, or shared app frontend conventions.
4
+ ---
5
+
6
+ # Frontend App Flutter Runtime
7
+
8
+ Use this skill for Flutter app frontend work.
9
+
10
+ Read `references/reference.md` before changing widgets, Riverpod state, routing, networking, or generated model conventions.
@@ -0,0 +1,50 @@
1
+ # Frontend App Flutter Runtime
2
+
3
+ ## Flutter Constraints
4
+
5
+ - Do not use dynamic as a default type.
6
+ - Do not put business logic in `Widget build()`.
7
+ - Do not use StatefulWidget for shared or long-lived state.
8
+ - Do not use GlobalKey to reach into child state for app data flow.
9
+ - Do not keep mutable model fields.
10
+ - Do not run heavy synchronous work on the UI thread.
11
+
12
+ ## Flutter Guidelines
13
+
14
+ - Use Riverpod with code generation and feature-local providers.
15
+ - Use feature-first directories and keep shared code in `lib/core`.
16
+ - Use sealed classes and pattern matching for result and async state handling.
17
+ - Prefer const constructors where possible.
18
+ - Use go_router for declarative routes and deep links.
19
+ - Use freezed for immutable models and generated equality and JSON methods.
20
+ - Write widget tests with `ProviderScope.overrides`.
21
+ - Profile with DevTools before optimizing.
22
+ - Handle async states explicitly.
23
+ - Access external APIs and storage through repositories.
24
+
25
+ ## App Frontend Library Constraints
26
+
27
+ - Do not use the `http` package for API calls.
28
+ - Do not use Provider or Bloc.
29
+ - Do not handwrite data classes.
30
+ - Do not use Navigator 1.0 push/pop APIs for routing.
31
+ - Do not manually implement JSON serialization.
32
+
33
+ ## App Frontend Library Guidelines
34
+
35
+ - Use `@riverpod` with riverpod_generator and build_runner.
36
+ - Use freezed for immutable models and unions.
37
+ - Define routes in a central GoRouter config.
38
+ - Create one shared Dio instance via Riverpod DI.
39
+ - Use shared_preferences or flutter_secure_storage by data sensitivity.
40
+ - Use cached_network_image for network image caching.
41
+ - Use very_good_analysis and treat warnings as CI failures.
42
+ - Use intl or easy_localization with ARB-based translations.
43
+
44
+ ## Decision Rules
45
+
46
+ - When state is local and ephemeral, keep it local.
47
+ - When state is shared or long-lived, use Riverpod Notifier or AsyncNotifier.
48
+ - When HTTP API calls are needed, use one DI-injected Dio client.
49
+ - When network images are rendered, use cached_network_image.
50
+ - When code generation is required, run build_runner instead of editing generated code.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: frontend-web-react-next-runtime
3
+ description: Use when implementing React or Next.js frontend features, App Router structure, client state, fetch patterns, forms, or shared web frontend conventions.
4
+ ---
5
+
6
+ # Frontend Web React Next Runtime
7
+
8
+ Use this skill for React and Next.js web frontend work.
9
+
10
+ Read `references/reference.md` before changing component boundaries, App Router behavior, state handling, fetch strategy, or shared web frontend libraries.
@@ -0,0 +1,51 @@
1
+ # Frontend Web React Next Runtime
2
+
3
+ ## React TypeScript Constraints
4
+
5
+ - Do not use `React.FC` or `FC`.
6
+
7
+ ## React TypeScript Guidelines
8
+
9
+ - Use readonly object and array props.
10
+
11
+ ## Next.js Constraints
12
+
13
+ - Do not import server-only code into client components.
14
+ - Do not expose secrets through `NEXT_PUBLIC_` variables.
15
+ - Do not use `next/router` in App Router projects.
16
+
17
+ ## Next.js Guidelines
18
+
19
+ - Follow App Router file conventions.
20
+ - Keep server actions in dedicated files.
21
+ - Use `next/image` with explicit sizing.
22
+ - Use `next/font` in the root layout.
23
+ - Use `middleware.ts` only for cross-cutting concerns.
24
+ - Export metadata for public pages.
25
+ - Add JSON-LD when SEO or GEO matters.
26
+
27
+ ## Web Frontend Library Constraints
28
+
29
+ - Do not use moment.js or dayjs.
30
+ - Do not use react-icons.
31
+ - Do not use axios in browser code.
32
+ - Do not build conditional className strings manually.
33
+ - Do not install parallel UI kits next to shadcn/ui.
34
+ - Do not use Redux, Recoil, or MobX for local UI state.
35
+
36
+ ## Web Frontend Library Guidelines
37
+
38
+ - Keep styling on Tailwind and design tokens.
39
+ - Use next-intl for i18n and next-themes for theme switching.
40
+ - Render Recharts only inside client components.
41
+ - Mount one Sonner toaster at the app root.
42
+ - Sanitize user HTML before `dangerouslySetInnerHTML`.
43
+ - Use Vitest and Testing Library.
44
+
45
+ ## Decision Rules
46
+
47
+ - When a component needs browser APIs, hooks, or handlers, add `use client` at the smallest leaf.
48
+ - When page data is needed for first render, fetch in server components.
49
+ - When internal form mutation is needed, use server actions.
50
+ - When form validation is needed, use zod with react-hook-form.
51
+ - When client UI state is needed, use a zustand slice.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: frontend-web-shadcn-ui
3
+ description: Use when building or modifying shadcn/ui-based interfaces, component variants, design tokens, or composed Radix primitives.
4
+ ---
5
+
6
+ # Frontend Web shadcn/ui
7
+
8
+ Use this skill for shadcn/ui-specific interface work.
9
+
10
+ Read `references/reference.md` before changing design tokens, component variants, or composed UI primitives.
@@ -0,0 +1,26 @@
1
+ # Frontend Web shadcn/ui
2
+
3
+ ## Constraints
4
+
5
+ - Do not reimplement components already available in shadcn/ui.
6
+ - Do not edit generated shadcn source files directly.
7
+ - Do not overuse arbitrary Tailwind values for stable design tokens.
8
+ - Do not use inline style props for static values.
9
+
10
+ ## Guidelines
11
+
12
+ - Check the shadcn component catalog before building custom primitives.
13
+ - Use `cn()` for conditional class composition.
14
+ - Use shadcn composition patterns for complex components.
15
+ - Use `cva` for variant-heavy components.
16
+ - Keep theme tokens CSS-variable based.
17
+ - Use mobile-first responsive classes.
18
+ - Preserve accessibility for icon-only controls.
19
+ - Use named lucide-react icon imports only.
20
+
21
+ ## Decision Rules
22
+
23
+ - When a needed UI element already exists in shadcn or Radix composition, use that composition first.
24
+ - When no suitable primitive exists and interaction is domain-specific, build a custom component.
25
+ - When a component has variants, model them with `cva`.
26
+ - When styling is needed, use Tailwind utilities by default.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: graphql-client-integration
3
+ description: Use when integrating GraphQL clients in web or app frontends, especially around codegen, caching, and partial-success handling.
4
+ ---
5
+
6
+ # GraphQL Client Integration
7
+
8
+ Use this skill for frontend GraphQL integration in web or app code.
9
+
10
+ Read `references/reference.md` before changing client setup, cache policy, generated operations, or error handling.
@@ -0,0 +1,22 @@
1
+ # GraphQL Client Integration
2
+
3
+ ## Constraints
4
+
5
+ - Do not use ad-hoc fetch wrappers where a shared GraphQL client stack is required.
6
+ - Do not handwrite operation/result types or rely on unchecked casts.
7
+ - Do not treat HTTP 200 as success when `errors[]` exists.
8
+ - Do not create per-feature client instances when shared auth/cache behavior is expected.
9
+
10
+ ## Guidelines
11
+
12
+ - Use generated GraphQL documents and types from codegen artifacts.
13
+ - Keep one configured provider/client at the app root.
14
+ - Set cache and fetch policy explicitly per operation.
15
+ - Co-locate `.graphql` documents and fragments with the consuming feature.
16
+ - Normalize GraphQL errors and extensions into a shared UI error model.
17
+
18
+ ## Decision Rules
19
+
20
+ - When a new query or mutation document is added, regenerate codegen artifacts before committing.
21
+ - When a mutation can return data and business errors together, preserve partial success and surface typed errors.
22
+ - When freshness requirements differ, choose fetch policy deliberately instead of relying on defaults.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: graphql-contract
3
+ description: Use when changing GraphQL schema contracts, field nullability, pagination strategy, or deprecation policy.
4
+ ---
5
+
6
+ # GraphQL Contract
7
+
8
+ Use this skill before editing GraphQL schema contracts or published field behavior.
9
+
10
+ Read `references/reference.md` and follow it as the canonical contract guidance.
@@ -0,0 +1,22 @@
1
+ # GraphQL Contract
2
+
3
+ ## Constraints
4
+
5
+ - Do not rely on implicit nullability. Mark every field intentionally.
6
+ - Do not return unbounded lists. Every collection needs bounded pagination with a stable cursor.
7
+ - Do not expose internal implementation details in enum values.
8
+ - Do not rename or remove published fields or types in the same release. Deprecate first.
9
+
10
+ ## Guidelines
11
+
12
+ - Use PascalCase for types/enums, camelCase for fields/arguments, and SCREAMING_SNAKE_CASE for enum values.
13
+ - Prefer cursor pagination for user-facing lists and reserve offset pagination for bounded admin tables.
14
+ - Use typed `FilterInput` and `OrderByInput` instead of JSON-like free-form arguments.
15
+ - Document scalar contracts such as `DateTime`, `UUID`, and `JSON`, including timezone and format rules.
16
+
17
+ ## Decision Rules
18
+
19
+ - When a field returns a collection, use cursor pagination with deterministic ordering.
20
+ - When a field or type must be renamed or removed, mark it deprecated with a migration reason and keep compatibility for at least one release.
21
+ - When a schema change is high-risk, add usage checks, rollback criteria, and a revert path before shipping.
22
+ - When filtering or sorting is complex, define typed inputs and avoid raw JSON blobs.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: graphql-server-runtime
3
+ description: Use when implementing GraphQL resolvers, NestJS GraphQL modules, subscriptions, or server-side error handling.
4
+ ---
5
+
6
+ # GraphQL Server Runtime
7
+
8
+ Use this skill for resolver design, NestJS GraphQL integration, DataLoader usage, subscription auth, and execution safety.
9
+
10
+ Read `references/reference.md` before changing GraphQL server behavior.
@@ -0,0 +1,40 @@
1
+ # GraphQL Server Runtime
2
+
3
+ ## GraphQL Server Constraints
4
+
5
+ - Do not perform mutations in `Query` resolvers.
6
+ - Do not throw top-level GraphQL errors for expected business failures.
7
+ - Do not issue per-parent DB queries from field resolvers.
8
+ - Do not accept multiple scalar mutation arguments when a typed input object is more stable.
9
+ - Do not expose unauthenticated subscriptions in production.
10
+
11
+ ## GraphQL Server Guidelines
12
+
13
+ - Keep resolvers thin and delegate business logic to services or use cases.
14
+ - Use payload types that can carry both data and typed `userErrors`.
15
+ - Apply depth and complexity limits plus operation timeout guards.
16
+ - Record `operationName` and `requestId` in structured logs.
17
+ - Document idempotency expectations for mutations with irreversible effects.
18
+
19
+ ## NestJS GraphQL Constraints
20
+
21
+ - Do not put business logic in resolvers.
22
+ - Do not access raw GraphQL args/context manually when typed decorators are available.
23
+ - Do not query the DB directly inside `@ResolveField()`.
24
+ - Do not expose unauthenticated `@Subscription()` endpoints.
25
+ - Do not maintain manual SDL in code-first projects.
26
+
27
+ ## NestJS GraphQL Guidelines
28
+
29
+ - Use one resolver per domain entity with clear `@Query()`, `@Mutation()`, and `@ResolveField()` responsibilities.
30
+ - Register DataLoaders as request-scoped providers.
31
+ - Add descriptions for public schema types and fields.
32
+ - Enforce depth and complexity limits in module config.
33
+ - Reuse Guards and Interceptors from REST via `GqlExecutionContext`.
34
+
35
+ ## Decision Rules
36
+
37
+ - When a field resolver loads related entities, batch with DataLoader and avoid N+1.
38
+ - When a mutation can fail due to business validation, return payload data plus typed user errors.
39
+ - When auth is required, apply typed guards and avoid manual JWT parsing in resolver methods.
40
+ - When introducing subscriptions, require auth and choose a production-safe PubSub transport.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: python-language
3
+ description: Use when writing or refactoring Python types, Pydantic models, exception handling, or general language-level design.
4
+ ---
5
+
6
+ # Python Language
7
+
8
+ Use this skill for Python-specific design and implementation work.
9
+
10
+ Read `references/reference.md` before changing type hints, DTO models, exception handling, or filesystem code.
@@ -0,0 +1,26 @@
1
+ # Python Language
2
+
3
+ ## Constraints
4
+
5
+ - Do not use `Any` in type hints by default.
6
+ - Do not use mutable default arguments.
7
+ - Do not use bare `except` or broad `except Exception`.
8
+ - Do not use wildcard imports.
9
+ - Do not use `type(x) == T` checks.
10
+ - Do not use `# type: ignore` without an explicit error code.
11
+
12
+ ## Guidelines
13
+
14
+ - Annotate all function parameters and return types.
15
+ - Use Pydantic v2 models for validated DTO and config boundaries.
16
+ - Use `TypeAlias`, `TypeVar`, `ParamSpec`, `TypedDict`, and `Literal` deliberately.
17
+ - Keep business logic in pure `*_logic.py` modules.
18
+ - Use `@dataclass(frozen=True)` for immutable value objects without validation needs.
19
+ - Use `pathlib.Path` for filesystem paths.
20
+ - Use f-strings for string formatting.
21
+
22
+ ## Decision Rules
23
+
24
+ - When structured input or output needs validation, use Pydantic v2 models.
25
+ - When immutable value objects do not need runtime validation, use frozen dataclasses.
26
+ - When runtime type narrowing is needed, use `isinstance()` or model validation.
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: typescript-language
3
+ description: Use when writing or refactoring TypeScript types, async flows, runtime narrowing, or shared language-level patterns.
4
+ ---
5
+
6
+ # TypeScript Language
7
+
8
+ Use this skill for TypeScript-specific design and implementation work.
9
+
10
+ Read `references/reference.md` before changing type models, async control flow, or runtime narrowing patterns.
@@ -0,0 +1,23 @@
1
+ # TypeScript Language
2
+
3
+ ## Constraints
4
+
5
+ - Do not use `interface`. Use type aliases consistently.
6
+ - Do not use `enum`. Use const objects with inferred literal unions.
7
+ - Do not use `any`. Use `unknown` and narrow it explicitly.
8
+ - Do not use non-null assertion (`!`).
9
+ - Do not use `.then()` chains for normal async flows.
10
+ - Do not throw raw strings.
11
+
12
+ ## Guidelines
13
+
14
+ - Annotate exported function return types.
15
+ - Use `import type` for type-only imports.
16
+ - Use `as const` for static config objects.
17
+ - Keep business logic in `*.logic.ts` and stateless helpers in `*.util.ts`.
18
+
19
+ ## Decision Rules
20
+
21
+ - When a runtime value must be narrowed, prefer explicit guards or schema parsing.
22
+ - When a static config object defines literals, prefer `as const`.
23
+ - When you feel forced to use `as`, prefer schema parse or explicit guards first.
@@ -0,0 +1,148 @@
1
+ {
2
+ "skills": [
3
+ {
4
+ "id": "ai-llm-python-runtime",
5
+ "kind": "reference",
6
+ "supported_tools": ["claude-code", "codex", "gemini"],
7
+ "install_scopes": ["project", "user"],
8
+ "groups": ["backend-python"],
9
+ "included_in_presets": [],
10
+ "source_path": "reference-skills/ai-llm-python-runtime"
11
+ },
12
+ {
13
+ "id": "backend-python-fastapi-runtime",
14
+ "kind": "reference",
15
+ "supported_tools": ["claude-code", "codex", "gemini"],
16
+ "install_scopes": ["project", "user"],
17
+ "groups": ["backend-python"],
18
+ "included_in_presets": ["backend-python"],
19
+ "source_path": "reference-skills/backend-python-fastapi-runtime"
20
+ },
21
+ {
22
+ "id": "backend-service-standards",
23
+ "kind": "reference",
24
+ "supported_tools": ["claude-code", "codex", "gemini"],
25
+ "install_scopes": ["project", "user"],
26
+ "groups": ["backend-ts", "backend-python"],
27
+ "included_in_presets": ["backend-ts", "backend-python"],
28
+ "source_path": "reference-skills/backend-service-standards"
29
+ },
30
+ {
31
+ "id": "backend-ts-nestjs-runtime",
32
+ "kind": "reference",
33
+ "supported_tools": ["claude-code", "codex", "gemini"],
34
+ "install_scopes": ["project", "user"],
35
+ "groups": ["backend-ts"],
36
+ "included_in_presets": ["backend-ts"],
37
+ "source_path": "reference-skills/backend-ts-nestjs-runtime"
38
+ },
39
+ {
40
+ "id": "data-pipeline-python-performance",
41
+ "kind": "reference",
42
+ "supported_tools": ["claude-code", "codex", "gemini"],
43
+ "install_scopes": ["project", "user"],
44
+ "groups": ["backend-python"],
45
+ "included_in_presets": [],
46
+ "source_path": "reference-skills/data-pipeline-python-performance"
47
+ },
48
+ {
49
+ "id": "db-prisma-postgresql",
50
+ "kind": "reference",
51
+ "supported_tools": ["claude-code", "codex", "gemini"],
52
+ "install_scopes": ["project", "user"],
53
+ "groups": ["backend-ts"],
54
+ "included_in_presets": ["backend-ts"],
55
+ "source_path": "reference-skills/db-prisma-postgresql"
56
+ },
57
+ {
58
+ "id": "db-sqlalchemy-postgresql",
59
+ "kind": "reference",
60
+ "supported_tools": ["claude-code", "codex", "gemini"],
61
+ "install_scopes": ["project", "user"],
62
+ "groups": ["backend-python"],
63
+ "included_in_presets": ["backend-python"],
64
+ "source_path": "reference-skills/db-sqlalchemy-postgresql"
65
+ },
66
+ {
67
+ "id": "frontend-app-flutter-runtime",
68
+ "kind": "reference",
69
+ "supported_tools": ["claude-code", "codex", "gemini"],
70
+ "install_scopes": ["project", "user"],
71
+ "groups": ["frontend-app"],
72
+ "included_in_presets": ["frontend-app"],
73
+ "source_path": "reference-skills/frontend-app-flutter-runtime"
74
+ },
75
+ {
76
+ "id": "frontend-web-react-next-runtime",
77
+ "kind": "reference",
78
+ "supported_tools": ["claude-code", "codex", "gemini"],
79
+ "install_scopes": ["project", "user"],
80
+ "groups": ["frontend-web"],
81
+ "included_in_presets": ["frontend-web"],
82
+ "source_path": "reference-skills/frontend-web-react-next-runtime"
83
+ },
84
+ {
85
+ "id": "frontend-web-shadcn-ui",
86
+ "kind": "reference",
87
+ "supported_tools": ["claude-code", "codex", "gemini"],
88
+ "install_scopes": ["project", "user"],
89
+ "groups": ["frontend-web"],
90
+ "included_in_presets": ["frontend-web"],
91
+ "source_path": "reference-skills/frontend-web-shadcn-ui"
92
+ },
93
+ {
94
+ "id": "graphql-client-integration",
95
+ "kind": "reference",
96
+ "supported_tools": ["claude-code", "codex", "gemini"],
97
+ "install_scopes": ["project", "user"],
98
+ "groups": ["frontend-web", "frontend-app"],
99
+ "included_in_presets": ["frontend-web", "frontend-app"],
100
+ "source_path": "reference-skills/graphql-client-integration"
101
+ },
102
+ {
103
+ "id": "graphql-contract",
104
+ "kind": "reference",
105
+ "supported_tools": ["claude-code", "codex", "gemini"],
106
+ "install_scopes": ["project", "user"],
107
+ "groups": ["frontend-web", "frontend-app", "backend-ts"],
108
+ "included_in_presets": ["frontend-web", "frontend-app", "backend-ts"],
109
+ "source_path": "reference-skills/graphql-contract"
110
+ },
111
+ {
112
+ "id": "graphql-server-runtime",
113
+ "kind": "reference",
114
+ "supported_tools": ["claude-code", "codex", "gemini"],
115
+ "install_scopes": ["project", "user"],
116
+ "groups": ["backend-ts"],
117
+ "included_in_presets": ["backend-ts"],
118
+ "source_path": "reference-skills/graphql-server-runtime"
119
+ },
120
+ {
121
+ "id": "python-language",
122
+ "kind": "reference",
123
+ "supported_tools": ["claude-code", "codex", "gemini"],
124
+ "install_scopes": ["project", "user"],
125
+ "groups": ["backend-python"],
126
+ "included_in_presets": ["backend-python"],
127
+ "source_path": "reference-skills/python-language"
128
+ },
129
+ {
130
+ "id": "skill-load-check",
131
+ "kind": "task",
132
+ "supported_tools": ["claude-code", "codex", "gemini"],
133
+ "install_scopes": ["project", "user"],
134
+ "groups": [],
135
+ "included_in_presets": [],
136
+ "source_path": "task-skills/skill-load-check"
137
+ },
138
+ {
139
+ "id": "typescript-language",
140
+ "kind": "reference",
141
+ "supported_tools": ["claude-code", "codex", "gemini"],
142
+ "install_scopes": ["project", "user"],
143
+ "groups": ["frontend-web", "backend-ts"],
144
+ "included_in_presets": ["frontend-web", "backend-ts"],
145
+ "source_path": "reference-skills/typescript-language"
146
+ }
147
+ ]
148
+ }
@@ -0,0 +1,8 @@
1
+ ---
2
+ name: skill-load-check
3
+ description: Use when the user wants to test whether an installed skill can be discovered and loaded.
4
+ ---
5
+
6
+ # Skill Load Check
7
+
8
+ Run the script in `scripts/loaded.js` and return the result.
@@ -0,0 +1 @@
1
+ console.log('A Skill loaded');