feat(hub-guide): language-agnostic auto-trigger across all skills
- Add principle 27: 'Language-Agnostic Auto-Trigger' to engineering-principles - Remove hardcoded English-only keyword lists from all 26 skill descriptions - Replace with concept-based detection: triggers from code context, project files, and file types regardless of spoken language - Update detect-project.sh hook output with language-agnostic message
This commit is contained in:
asepharyana
@@ -74,3 +74,4 @@ if [ -n "$SKILLS" ]; then
|
||||
fi
|
||||
echo "📐 [hub-guide] Apply these best-practice rules throughout this session."
|
||||
echo "📐 [hub-guide] When in doubt about intent or approach — ask instead of assuming."
|
||||
echo "📐 [hub-guide] All skills work regardless of your spoken language — they trigger from code context and project files, not just English keywords."
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: api-design
|
||||
description: Best practices for API design — REST, GraphQL, RPC conventions, versioning, status codes, pagination, error responses, and documentation. Use when designing new endpoints, reviewing API contracts, or whenever the user mentions "API design," "REST," "RESTful," "GraphQL," "endpoint," "status code," "pagination," "API versioning," "OpenAPI," "gRPC," or "API contract."
|
||||
description: Best practices for API design — REST, GraphQL, RPC conventions, versioning, status codes, pagination, error responses, and documentation. Use when designing new endpoints, reviewing API contracts. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# API Design
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: ci-cd
|
||||
description: CI/CD best practices — GitHub Actions, pipeline design, Docker build + push, deployment workflows, testing in CI, and environment management. Use when designing CI/CD pipelines, debugging workflow failures, or whenever the user mentions "CI," "CD," "GitHub Actions," "GitLab CI," "Jenkins," "pipeline," "deploy," "workflow," "Docker build," "environment," or "automation."
|
||||
description: CI/CD best practices — GitHub Actions, pipeline design, Docker build + push, deployment workflows, testing in CI, and environment management. Use when designing CI/CD pipelines, debugging workflow failures. Triggers from project files and configuration, not just keyword matching."
|
||||
---
|
||||
|
||||
# CI/CD Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: clean-architecture
|
||||
description: Apply Clean Architecture, hexagonal architecture, and SOLID principles when designing system boundaries, modules, or microservices. Use when structuring a new service, deciding what a component should own, untangling framework coupling, or whenever the user mentions "clean architecture," "hexagonal architecture," "onion architecture," "ports and adapters," "SOLID," "Dependency Rule," or "architecture boundaries."
|
||||
description: Apply Clean Architecture, hexagonal architecture, and SOLID principles when designing system boundaries, modules, or microservices. Use when structuring a new service, deciding what a component should own, untangling framework coupling. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Clean Architecture
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: clean-code
|
||||
description: Apply Robert C. Martin's (Uncle Bob's) Clean Code, Clean Architecture, and Clean Craftsmanship principles when writing, reviewing, or refactoring code. Use this skill whenever the user asks to write new code of non-trivial size, refactor existing code, review code for quality, design a module or system boundary, write tests, or whenever the user mentions "clean code," "clean architecture," "SOLID," "SRP," "OCP," "LSP," "ISP," "DIP," "TDD," "refactor," "code smells," or "Uncle Bob." Also engage proactively when producing code with poor naming, long functions (>20 lines), deep nesting, unclear abstractions, duplicated logic, switch/if-else chains on type, missing tests, or frameworks bleeding into business logic.
|
||||
description: Apply Robert C. Martin's (Uncle Bob's) Clean Code, Clean Architecture, and Clean Craftsmanship principles when writing, reviewing, or refactoring code. Use this skill whenever the user asks to write new code of non-trivial size, refactor existing code, review code for quality, design a module or system boundary, write tests, or the user mentions clean-code concepts in any language. Also engage proactively from code quality signals — poor naming, long functions, deep nesting, unclear abstractions — regardless of spoken language. Detects from code context and project files — not dependent on specific language keywords.
|
||||
---
|
||||
|
||||
# Clean Code
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: design-patterns
|
||||
description: Guidance on Gang of Four design patterns and modern alternatives — when to use each pattern, how to implement it correctly, and when to avoid it. Use when designing class structures, solving recurring design problems, refactoring switch/if-else chains, or whenever the user mentions "design patterns," "GoF," "Factory," "Strategy," "Observer," "Singleton," "Adapter," "Decorator," or "DI."
|
||||
description: Guidance on Gang of Four design patterns and modern alternatives — when to use each pattern, how to implement it correctly, and when to avoid it. Use when designing class structures, solving recurring design problems, refactoring switch/if-else chains. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Design Patterns
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: docker
|
||||
description: Docker best practices — Dockerfile optimization, multi-stage builds, Docker Compose, networking, security, and image management. Use when writing Dockerfiles, designing container infrastructure, debugging docker issues, or whenever the user mentions "Docker," "Dockerfile," "docker-compose," "compose," "multi-stage," "container," "image," "registry," or "OCI."
|
||||
description: Docker best practices — Dockerfile optimization, multi-stage builds, Docker Compose, networking, security, and image management. Use when writing Dockerfiles, designing container infrastructure, debugging docker issues. Triggers from project files and configuration, not just keyword matching."
|
||||
---
|
||||
|
||||
# Docker Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: documentation
|
||||
description: Best practices for software documentation — README, API docs, ADRs, inline comments, changelogs, and knowledge base organization. Use when writing README files, designing documentation strategy, adding inline comments, or whenever the user mentions "documentation," "README," "ADR," "changelog," "docstring," "wiki," "documentation as code," or "docs."
|
||||
description: Best practices for software documentation — README, API docs, ADRs, inline comments, changelogs, and knowledge base organization. Use when writing README files, designing documentation strategy, adding inline comments. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Documentation Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: drizzle-database
|
||||
description: Drizzle ORM best practices — schema design, queries, migrations, relations, and performance. Use when designing database schemas, writing Drizzle queries, managing migrations, or whenever the user mentions "Drizzle," "Drizzle ORM," "drizzle-orm," "drizzle-kit," "schema," "migration," "PostgreSQL," "SQLite," or "database design."
|
||||
description: Drizzle ORM best practices — schema design, queries, migrations, relations, and performance. Use when designing database schemas, writing Drizzle queries, managing migrations. Triggers when working with this framework's files and patterns, not just explicit mentions."
|
||||
---
|
||||
|
||||
# Drizzle ORM Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: elysiajs
|
||||
description: ElysiaJS (Bun) best practices — Eden Treaty, plugins, type-safe routes, Elysia validation, and middleware. Use when building ElysiaJS backend APIs, or whenever the user mentions "Elysia," "ElysiaJS," "Eden," "Eden Treaty," "Bun," "Elysia plugin," or "Elysia validation."
|
||||
description: ElysiaJS (Bun) best practices — Eden Treaty, plugins, type-safe routes, Elysia validation, and middleware. Use when building ElysiaJS backend APIs. Triggers when working with this framework's files and patterns, not just explicit mentions."
|
||||
---
|
||||
|
||||
# ElysiaJS Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: engineering-principles
|
||||
description: Foundational software engineering principles that apply across all languages, frameworks, and project types — correctness, simplicity, YAGNI, KISS, DRY, root-cause fixes, least astonishment, explicit over implicit, fail fast, professional craftsmanship, and multi-agent orchestration for complex tasks. This skill is a baseline: apply these principles to every code decision, review, and architecture discussion, regardless of language or framework. Engage proactively whenever writing, reviewing, or designing code — especially when the user's request seems to violate one of these fundamentals. Also use when the user asks for "complex," "big," "multi-step," "comprehensive," "thorough," "parallel," "audit," "migrate," "research," or "large-scale" work — these trigger the Workflow orchestration principle (see §26).
|
||||
description: Foundational software engineering principles that apply across all languages, frameworks, and project types — correctness, simplicity, YAGNI, KISS, DRY, root-cause fixes, least astonishment, explicit over implicit, fail fast, professional craftsmanship, and multi-agent orchestration for complex tasks. This skill is a baseline: apply these principles to every code decision, review, and architecture discussion, regardless of language or framework. Engage proactively whenever writing, reviewing, or designing code — especially when the user's request seems to violate one of these fundamentals. Detects from code context, project files, and task complexity — not dependent on specific language keywords. Triggers regardless of spoken language when the task is complex, multi-step, or large in scope (see §26 — Workflow orchestration).
|
||||
---
|
||||
|
||||
# Engineering Principles
|
||||
@@ -233,3 +233,16 @@ When the user's request is complex, multi-step, or large in scope, **use the Wor
|
||||
**Default to pipeline over barrier.** Pipeline lets item A verify while item B is still being reviewed — no wasted wall-clock time. Barriers (parallel() then parallel()) are only justified when the next stage genuinely needs ALL results from the prior stage (e.g., deduplication across all findings before expensive verification).
|
||||
|
||||
**Don't over-engineer.** A workflow for a one-file fix is wasteful. Use Workflow for tasks that genuinely benefit from multiple perspectives or parallel execution. When in doubt, ask the user: "This looks complex — should I use a multi-agent workflow for thorough coverage?"
|
||||
|
||||
## 27. Language-Agnostic Auto-Trigger — Jangan Hardcode Bahasa Inggris
|
||||
|
||||
Skills harus trigger berdasarkan **konsep**, **konteks kode**, dan **file project** — bukan cuma kata kunci Bahasa Inggris. User bisa ngomong pake bahasa apapun.
|
||||
|
||||
**Aturan:**
|
||||
- Detect dari **konteks** bukan keyword literal. User minta "tes" atau "pengujian" → trigger testing skill. User minta "bikin test" atau "add tests" → same thing.
|
||||
- Detect dari **kode yang lagi dikerjain** — file `.test.ts` → testing skill. Class `OrderService` dengan pola tertentu → clean-architecture skill. `routes.ts` → hono-backend/elysiajs.
|
||||
- Detect dari **file project** — `Cargo.toml` → rust skill. `go.mod` → go skill. `Dockerfile` → docker skill.
|
||||
- **Gak perlu nunggu user nyebut keyword.** Kalau user lagi nulis kode TypeScript dan nyebut "buat repository pattern" — itu trigger clean-architecture + typescript. Kalimatnya campur aduk, konsepnya yang ditangkap.
|
||||
- **Behavioral pattern > keyword.** User bilang "kode ini jelek, rapihin" → trigger clean-code. User bilang "tambahin validasi" → trigger error-handling + security.
|
||||
- **Tanya kalau ragu.** Kalau konteks gak cukup buat nentuin skill mana, tanya 1 pertanyaan pendek. Jangan asumsi.
|
||||
- Hook `detect-project.sh` udah otomatis deteksi dari file project — ini jalur utama activation, bukan cuma keyword matching.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: error-handling
|
||||
description: Best practices for error handling across languages — exceptions, Result types, input validation, error boundaries, null safety, and observability. Use when designing error strategies, writing validation logic, handling API errors, or whenever the user mentions "error handling," "exception," "try-catch," "Result," "Option," "Either," "null check," "validation," "panic," or "error boundary."
|
||||
description: Best practices for error handling across languages — exceptions, Result types, input validation, error boundaries, null safety, and observability. Use when designing error strategies, writing validation logic, handling API errors. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Error Handling
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: git-workflow
|
||||
description: Git workflow best practices — commit conventions, branching strategies, PR conventions, rebase vs merge, and code review. Use when writing commit messages, reviewing PRs, planning branching strategy, or whenever the user mentions "commit," "branch," "pull request," "PR," "merge," "rebase," "squash," "git flow," "trunk-based," "conventional commit," or "code review."
|
||||
description: Git workflow best practices — commit conventions, branching strategies, PR conventions, rebase vs merge, and code review. Use when writing commit messages, reviewing PRs, planning branching strategy. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Git Workflow
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: go
|
||||
description: Go best practices — idiomatic Go, project layout, error handling, interfaces, concurrency, testing, and dependency management. Use when writing Go code, reviewing Go projects, or whenever the user mentions "Go," "Golang," "goroutine," "channel," "interface," "defer," "go mod," "gRPC," "net/http," "chi," "echo," "fiber," or "go test."
|
||||
description: Go best practices — idiomatic Go, project layout, error handling, interfaces, concurrency, testing, and dependency management. Use when writing Go code, reviewing Go projects. Triggers when working with this language's files, regardless of spoken language."
|
||||
---
|
||||
|
||||
# Go Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: hono-backend
|
||||
description: Hono best practices — middleware, RPC, validation (Zod), Drizzle integration, and project organization. Use when building Hono backend APIs, or whenever the user mentions "Hono," "Hono.js," "hono RPC," "hono middleware," "hono Zod OpenAPI," "hono validation," or "hono Drizzle."
|
||||
description: Hono best practices — middleware, RPC, validation (Zod), Drizzle integration, and project organization. Use when building Hono backend APIs. Triggers when working with this framework's files and patterns, not just explicit mentions.js," "hono RPC," "hono middleware," "hono Zod OpenAPI," "hono validation," or "hono Drizzle."
|
||||
---
|
||||
|
||||
# Hono Backend Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: hub-guide
|
||||
description: Guide for the Asepharyana Hub monorepo — submodule workflow, infrastructure stack (Traefik, Dapr, NATS, Redis), CI/CD pipelines, adding new services, and debugging tips. Use when working in the asepharyana-hub monorepo, managing submodules, dealing with Docker/infra setup, or whenever the user asks about "hub monorepo," "submodules," "Traefik," "Dapr," "NATS," "infrastructure," or "adding a new service."
|
||||
description: Guide for the Asepharyana Hub monorepo — submodule workflow, infrastructure stack (Traefik, Dapr, NATS, Redis), CI/CD pipelines, adding new services, and debugging tips. Use when working in the asepharyana-hub monorepo, managing submodules, dealing with Docker/infra setup. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Hub Guide — Asepharyana Hub Monorepo
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: logging-observability
|
||||
description: Best practices for logging, metrics, tracing, alerting, and observability — structured logging, correlation IDs, Prometheus metrics, distributed tracing, and dashboard design. Use when adding logging, designing monitoring, setting up dashboards, debugging production issues, or whenever the user mentions "logging," "observability," "metrics," "tracing," "Prometheus," "Grafana," "Jaeger," "OpenTelemetry," "structured logging," or "alerting."
|
||||
description: Best practices for logging, metrics, tracing, alerting, and observability — structured logging, correlation IDs, Prometheus metrics, distributed tracing, and dashboard design. Use when adding logging, designing monitoring, setting up dashboards, debugging production issues. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Logging & Observability
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: monitoring
|
||||
description: Monitoring and observability best practices — Prometheus, Grafana, alerts, dashboards, uptime monitoring, and incident response. Use when setting up monitoring infrastructure, designing dashboards, defining alerts, or whenever the user mentions "monitoring," "Prometheus," "Grafana," "alert," "dashboard," "uptime," "incident," "runbook," "SLA," "SLO," "SLI," or "on-call."
|
||||
description: Monitoring and observability best practices — Prometheus, Grafana, alerts, dashboards, uptime monitoring, and incident response. Use when setting up monitoring infrastructure, designing dashboards, defining alerts. Triggers from project files and configuration, not just keyword matching."
|
||||
---
|
||||
|
||||
# Monitoring Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: monorepo
|
||||
description: Monorepo best practices — tooling, workspace configuration, shared dependencies, CI/CD, and dependency management. Use when working in monorepos (pnpm workspaces, moon, turborepo, Nx), managing shared packages, or whenever the user mentions "monorepo," "workspace," "pnpm workspace," "moon," "turborepo," "nx," "shared package," "dependency management," or "submodule."
|
||||
description: Monorepo best practices — tooling, workspace configuration, shared dependencies, CI/CD, and dependency management. Use when working in monorepos (pnpm workspaces, moon, turborepo, Nx), managing shared packages. Triggers from project files and configuration, not just keyword matching."
|
||||
---
|
||||
|
||||
# Monorepo Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: nextjs
|
||||
description: Next.js App Router best practices — server components, client components, data fetching, routing, middleware, and deployment. Use when building Next.js applications, or whenever the user mentions "Next.js," "App Router," "server component," "client component," "SSR," "SSG," "ISR," "Middleware," "layout," "page," "route handler," "next/navigation," or "server actions."
|
||||
description: Next.js App Router best practices — server components, client components, data fetching, routing, middleware, and deployment. Use when building Next.js applications. Triggers when working with this framework's files and patterns, not just explicit mentions.js," "App Router," "server component," "client component," "SSR," "SSG," "ISR," "Middleware," "layout," "page," "route handler," "next/navigation," or "server actions."
|
||||
---
|
||||
|
||||
# Next.js Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: performance
|
||||
description: Best practices for software performance — caching, query optimization, lazy loading, profiling, CDN, database indexing, and memory management. Use when optimizing slow endpoints, reducing load times, designing caching strategies, or whenever the user mentions "performance," "optimization," "slow," "cache," "lazy loading," "profiling," "bottleneck," "N+1," "latency," "throughput," or "scalability."
|
||||
description: Best practices for software performance — caching, query optimization, lazy loading, profiling, CDN, database indexing, and memory management. Use when optimizing slow endpoints, reducing load times, designing caching strategies. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Performance Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: python
|
||||
description: Python best practices — typing, project structure, packaging, FastAPI patterns, async, testing, and idiomatic Python. Use when writing Python code, structuring a Python project, or whenever the user mentions "Python," "FastAPI," "Django," "pytest," "PEP 8," "type hints," "Pydantic," "asyncio," "pip," "poetry," or "uv."
|
||||
description: Python best practices — typing, project structure, packaging, FastAPI patterns, async, testing, and idiomatic Python. Use when writing Python code, structuring a Python project. Triggers when working with this language's files, regardless of spoken language."
|
||||
---
|
||||
|
||||
# Python Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: react-frontend
|
||||
description: React and frontend best practices — component patterns, hooks, state management, TanStack Query, React Router, performance, and testing. Use when building React components, designing state management, or whenever the user mentions "React," "hooks," "state management," "component," "JSX," "TanStack Query," "React Router," "Zustand," "Vite," "Next.js," or "Frontend."
|
||||
description: React and frontend best practices — component patterns, hooks, state management, TanStack Query, React Router, performance, and testing. Use when building React components, designing state management. Triggers when working with this framework's files and patterns, not just explicit mentions.js," or "Frontend."
|
||||
---
|
||||
|
||||
# React Frontend Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: rust
|
||||
description: Rust best practices — ownership, error handling, async, project structure, clippy rules, testing, and idiomatic Rust. Use when writing Rust code, reviewing Rust projects, or whenever the user mentions "Rust," "cargo," "clippy," "ownership," "borrowing," "lifetimes," "Result," "Option," "async/await," "tokio," "Axum," "SeaORM," or "unsafe."
|
||||
description: Rust best practices — ownership, error handling, async, project structure, clippy rules, testing, and idiomatic Rust. Use when writing Rust code, reviewing Rust projects. Triggers when working with this language's files, regardless of spoken language."
|
||||
---
|
||||
|
||||
# Rust Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: security
|
||||
description: Security best practices for software development — input validation, authentication, authorization, secrets management, OWASP Top 10, and secure coding patterns. Use when handling user input, designing auth flows, storing secrets, configuring CORS/headers, or whenever the user mentions "security," "XSS," "SQL injection," "CSRF," "authentication," "authorization," "JWT," "OAuth," "encryption," "secrets," "CORS," "RBAC," "OWASP," or "security review."
|
||||
description: Security best practices for software development — input validation, authentication, authorization, secrets management, OWASP Top 10, and secure coding patterns. Use when handling user input, designing auth flows, storing secrets, configuring CORS/headers. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Security Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: testing
|
||||
description: Best practices for software testing — TDD, test pyramid, F.I.R.S.T. principles, mocking strategies, and test organization. Use when writing tests, designing test strategy, refactoring under test, or whenever the user mentions "unit test," "integration test," "TDD," "test coverage," "mock," "stub," "e2e test," "Jest," "Vitest," "pytest," "cargo test," or "testing."
|
||||
description: Best practices for software testing — TDD, test pyramid, F.I.R.S.T. principles, mocking strategies, and test organization. Use when writing tests, designing test strategy, refactoring under test. Detects from code context and project files — not dependent on specific language keywords."
|
||||
---
|
||||
|
||||
# Testing Best Practices
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: typescript
|
||||
description: TypeScript best practices — strict mode, type patterns, generics, module system, async patterns, and project organization. Use when writing TypeScript code, configuring tsconfig, or whenever the user mentions "TypeScript," "TS," "ESM," "deno," "bun," "type annotation," "generics," "interface," "type," "strict mode," or "tsconfig."
|
||||
description: TypeScript best practices — strict mode, type patterns, generics, module system, async patterns, and project organization. Use when writing TypeScript code, configuring tsconfig. Triggers when working with this language's files, regardless of spoken language."
|
||||
---
|
||||
|
||||
# TypeScript Best Practices
|
||||
|
||||
Reference in New Issue
Block a user