@vyuhlabs/dxkit 2.5.0 → 2.5.1

package/templates/.claude/skills/gcloud/SKILL.md

@@ -1,66 +0,0 @@
----
-name: gcloud
-description: Google Cloud Platform operations — gcloud CLI, Cloud Run, GKE, BigQuery, IAM, GCS. Use when asked about GCP, Google Cloud, gcloud commands, or cloud infrastructure.
-paths:
-  - '**/cloudbuild.yaml'
-  - '**/cloudbuild.yml'
-  - '**/.gcloudignore'
-  - '**/app.yaml'
----
-
-# Google Cloud (gcloud)
-
-## Setup
-- **Auth:** `gcloud auth login`
-- **Project:** set via `gcloud config set project <id>` or the `GOOGLE_CLOUD_PROJECT` env var
-- **SDK:** install from https://cloud.google.com/sdk (devcontainer users get it via the post-create script)
-
-## Common Commands
-
-### Authentication & Project
-```bash
-gcloud auth list                              # check auth status
-gcloud config get-value project               # current project
-gcloud config set project <PROJECT_ID>        # switch project
-gcloud projects list                          # list accessible projects
-```
-
-### Services & Resources
-```bash
-gcloud services list --enabled                # enabled APIs
-gcloud run services list                      # Cloud Run services
-gcloud container clusters list                # GKE clusters
-gcloud sql instances list                     # Cloud SQL instances
-gcloud storage ls                             # GCS buckets
-```
-
-### Logs & Monitoring
-```bash
-gcloud logging read "resource.type=cloud_run_revision" --limit=50
-gcloud logging read "severity>=ERROR" --limit=20 --format=json
-```
-
-## Integration with Secrets
-
-GCP project ID is typically set as an environment variable:
-```
-GOOGLE_CLOUD_PROJECT=my-project-id
-```
-
-Source it from a secret store (Infisical, Doppler, GitHub Secrets) rather than committing to `.env`.
-
-## Security — CRITICAL
-
-1. **NEVER output `gcloud auth print-access-token`** — it exposes bearer tokens
-2. **NEVER output or log service account JSON keys**
-3. **NEVER embed credentials in code** — use Workload Identity or Application Default Credentials
-4. Use `gcloud auth application-default login` for local development
-5. In production, use Workload Identity Federation (not service account keys)
-
-## Deployment
-
-See the `deploy` skill for GCP deployment patterns (Cloud Run, GKE).
-
-## Gotchas
-
-See [references/gotchas.md](references/gotchas.md) for GCP-specific issues.

package/templates/.claude/skills/gcloud/references/gotchas.md

@@ -1,5 +0,0 @@
-# Google Cloud Gotchas
-
-<!-- This file grows over time. Each entry is added during session-end. -->
-<!-- Format: date, category, description, resolution -->
-<!-- NEVER include secret values, tokens, credentials, or project IDs here -->

package/templates/.claude/skills/learned/SKILL.md

@@ -1,55 +0,0 @@
----
-name: learned
-description: Project-specific learnings, gotchas, and conventions discovered during development. Check this before starting any task for accumulated team knowledge.
----
-
-# Learned Patterns & Gotchas
-
-This skill accumulates project-specific knowledge over time.
-It is updated during session-end checkpoints.
-
-## How This Works
-
-1. During `/session-end` (or anytime via `/learn`), the conversation is reviewed for learnings
-2. Any new gotchas, patterns, or conventions are appended to the reference files
-3. Over time, this becomes the most valuable skill — real failure points and patterns
-
-## Files
-
-- [references/gotchas.md](references/gotchas.md) - Accumulated gotchas and edge cases (append-only)
-- [references/conventions.md](references/conventions.md) - Team conventions discovered during development
-- [references/deny-recommendations.md](references/deny-recommendations.md) - Commands that should be added to `.claude/settings.json` deny list (requires human review)
-
-## When to Update
-
-Update these files when you encounter:
-- Unexpected behaviors or edge cases
-- Workarounds for tool/framework bugs
-- Team conventions or patterns that aren't obvious from the code
-- Configuration pitfalls
-- Deployment or environment-specific issues
-
-## When to Create a New Skill
-
-If a learning is significant enough to warrant its own skill (e.g., a specific API integration, a migration workflow, a caching pattern), create a new directory under `.claude/skills/<name>/` with a `SKILL.md` instead of appending here. This skill (`learned`) is for general cross-cutting knowledge; domain-specific knowledge deserves its own skill.
-
-## Format
-
-### Gotchas
-```markdown
-## YYYY-MM-DD - Category / Short Title
-Description of the issue.
-**Resolution:** How it was resolved.
-```
-
-### Conventions
-```markdown
-## Category - Convention Name
-Description of the convention.
-**Rationale:** Why this convention was adopted.
-```
-
-## Security
-
-**NEVER include secret values, tokens, passwords, or API keys in any file under this skill.**
-If a gotcha involves credentials, describe the issue generically without exposing actual values.

package/templates/.claude/skills/learned/references/conventions.md

@@ -1,11 +0,0 @@
-# Team Conventions
-
-<!-- Discovered conventions are added here during session-end. -->
-<!-- Format: category, convention, rationale -->
-<!-- NEVER include secret values, tokens, or credentials here -->
-
-<!-- Example:
-## Python - Use App Factory Pattern
-All FastAPI applications should use the app factory pattern (create_app function) rather than module-level app instantiation.
-**Rationale:** Enables test isolation and configuration flexibility. Adopted after test pollution issues in the auth service.
--->

package/templates/.claude/skills/learned/references/deny-recommendations.md

@@ -1,18 +0,0 @@
-# Deny Rule Recommendations
-
-<!--
-  This file tracks commands/actions that SHOULD be added to .claude/settings.json deny list.
-  Claude cannot modify settings.json directly (security boundary).
-  A developer should periodically review this file and promote entries to settings.json.
-
-  Format:
-  ## YYYY-MM-DD - Rule
-  `DenyPattern` — reason this should be blocked
-  **Context:** what happened that surfaced this need
--->
-
-<!-- Example:
-## 2025-12-15 - Block database drop
-`Bash(dropdb:*)` — accidentally dropped staging database during cleanup
-**Context:** Claude ran dropdb instead of truncating tables during test cleanup
--->

package/templates/.claude/skills/learned/references/gotchas.md

@@ -1,11 +0,0 @@
-# Project Gotchas
-
-<!-- This file grows over time. Each entry is added during session-end. -->
-<!-- Format: date, category, description, resolution -->
-<!-- NEVER include secret values, tokens, or credentials here -->
-
-<!-- Example:
-## 2025-12-15 - Python / Import Order
-ruff's isort rules conflict with local imports when using relative paths in the src/ directory.
-**Resolution:** Use absolute imports from package root (e.g., `from mypackage.module import X`).
--->

package/templates/.claude/skills/pulumi/SKILL.md

@@ -1,73 +0,0 @@
----
-name: pulumi
-description: Pulumi infrastructure as code — stacks, previews, deployments, config. Use when asked about IaC, Pulumi, cloud resources, infrastructure provisioning, or stack management.
-paths:
-  - 'Pulumi.yaml'
-  - 'Pulumi.yml'
-  - 'Pulumi.*.yaml'
-  - '**/Pulumi.yaml'
-  - '**/Pulumi.*.yaml'
----
-
-# Pulumi (Infrastructure as Code)
-
-## Setup
-- **Auth:** `pulumi login`
-- **SDK:** install from https://www.pulumi.com/docs/install/ (devcontainer users get it via the post-create script)
-- **Path:** `~/.pulumi/bin/pulumi`
-
-## Core Workflow
-
-**ALWAYS preview before applying changes:**
-
-```bash
-# 1. Preview changes (safe, read-only)
-pulumi preview
-
-# 2. Review the diff carefully
-
-# 3. Apply changes (REQUIRES explicit user confirmation)
-pulumi up
-
-# 4. Check outputs
-pulumi stack output
-```
-
-## Common Commands
-
-### Stack Management
-```bash
-pulumi stack ls                    # list stacks
-pulumi stack select <name>         # switch stack
-pulumi stack output                # view outputs
-pulumi stack export                # export state
-```
-
-### Configuration
-```bash
-pulumi config                     # view config
-pulumi config set key value       # set plain config
-pulumi config set --secret key value  # set encrypted secret
-pulumi config get key             # get value
-```
-
-### State & History
-```bash
-pulumi stack history              # deployment history
-pulumi state                      # inspect state
-pulumi refresh                    # sync state with cloud
-```
-
-## Security — CRITICAL
-
-1. **ALWAYS `pulumi preview` before `pulumi up`** — review the diff
-2. **NEVER run `pulumi destroy` without explicit user confirmation** — it deletes all resources
-3. **Use `pulumi config set --secret`** for sensitive values — never plain-text
-4. **NEVER output `pulumi config get --secret`** values in responses
-5. **State files may contain secrets** — ensure backend is secure (encrypted)
-6. Pulumi passphrase (if using local backend) should be in `.env`, never hardcoded
-
-## Integration
-
-- Secrets from Infisical can be used as Pulumi config values
-- GCP project from `.env` (`GOOGLE_CLOUD_PROJECT`) can configure Pulumi GCP provider

package/templates/.claude/skills/quality/SKILL.md.template

@@ -1,89 +0,0 @@
----
-name: quality
-description: Run code quality checks, linting, formatting, and auto-fixing. Use when asked to check code quality, fix lint errors, format code, or run pre-commit checks.
----
-
-# Code Quality
-
-Run `/quality` for the full deterministic report (lint + format + slop + duplication metrics).
-
-{{#IF_PYTHON}}
-## Python
-
-**Tools**: ruff (lint + format), mypy (types)
-
-Common fixes:
-```bash
-ruff check --fix .
-ruff format .
-mypy src/
-```
-
-Key ruff rule groups: pycodestyle (E), pyflakes (F), isort (I), mccabe (C90), bugbear (B).
-{{/IF_PYTHON}}
-
-{{#IF_GO}}
-## Go
-
-**Tools**: golangci-lint, gofmt, goimports
-
-Common fixes:
-```bash
-gofmt -w .
-goimports -w .
-golangci-lint run --fix
-```
-{{/IF_GO}}
-
-{{#IF_NODE}}
-## Node.js
-
-**Tools:** ESLint, Prettier
-Common fixes:
-```bash
-npx prettier --write .
-npx eslint --fix .
-```
-{{/IF_NODE}}
-
-{{#IF_NEXTJS}}
-## Next.js
-
-**Directory:** `frontend/`
-```bash
-cd frontend && npm run lint
-cd frontend && npx prettier --write .
-cd frontend && npx tsc --noEmit  # type check
-```
-{{/IF_NEXTJS}}
-
-{{#IF_RUST}}
-## Rust
-
-**Tools:** clippy, rustfmt
-```bash
-cargo fmt
-cargo clippy --fix --allow-dirty
-```
-{{/IF_RUST}}
-
-{{#IF_CSHARP}}
-## C#
-
-**Tools:** dotnet format, Roslyn Analyzers, StyleCop Analyzers
-**Config:** `.editorconfig`, `Directory.Build.props`
-
-Common fixes:
-```bash
-dotnet format                          # auto-fix formatting
-dotnet format --verify-no-changes      # CI check (no modifications)
-```
-{{/IF_CSHARP}}
-
-## Gotchas
-
-See [references/gotchas.md](references/gotchas.md) for known quality issues.
-
-## Security
-
-Never disable security-related lint rules. If a rule seems wrong, investigate before suppressing.

package/templates/.claude/skills/quality/references/gotchas.md

@@ -1,5 +0,0 @@
-# Quality Gotchas
-
-<!-- This file grows over time. Each entry is added during session-end. -->
-<!-- Format: date, category, description, resolution -->
-<!-- NEVER include secret values, tokens, or credentials here -->

package/templates/.claude/skills/review/SKILL.md.template

@@ -1,74 +0,0 @@
----
-name: review
-description: Review code for quality, security, and patterns. Use when asked to review code, a PR, check for problems, or audit for security issues.
----
-
-# Code Review
-
-## Quick check
-
-Run `/quality` and `/test` first — they cover lint, format, slop, duplication, and test results.
-
-## Review Checklist
-
-### 1. Quality
-- [ ] `/quality` passes
-- [ ] Coverage meets threshold ({{COVERAGE_THRESHOLD}}%)
-- [ ] No suppressed lint rules without justification
-
-### 2. Security
-- [ ] No hardcoded secrets, API keys, tokens, or passwords
-- [ ] No secrets in commit messages, comments, or logs
-- [ ] User input is validated/sanitized at system boundaries
-- [ ] No SQL injection, XSS, or command injection vectors
-- [ ] Sensitive files are gitignored (`.env`, credentials)
-
-### 3. Testing
-- [ ] New features have tests
-- [ ] Edge cases and error paths tested
-- [ ] Tests are deterministic (no timing/order dependencies)
-
-### 4. Architecture
-- [ ] Follows existing patterns in the codebase
-- [ ] Dependencies injected (not imported directly in business logic)
-- [ ] Error handling is consistent
-
-{{#IF_PYTHON}}
-### Python-Specific
-- [ ] Type hints on public functions
-- [ ] Pydantic models for data validation
-- [ ] No bare `except:` — catch specific exceptions
-- [ ] Async/await used correctly (no blocking in async context)
-{{/IF_PYTHON}}
-
-{{#IF_GO}}
-### Go-Specific
-- [ ] Errors checked and handled (no `_` for errors)
-- [ ] Context propagated through call chains
-- [ ] Proper resource cleanup (defer for Close/Unlock)
-- [ ] Table-driven tests used where appropriate
-{{/IF_GO}}
-
-{{#IF_NEXTJS}}
-### Next.js-Specific
-- [ ] Server vs client components used correctly
-- [ ] No sensitive data in client components
-- [ ] TypeScript strict mode compliance
-{{/IF_NEXTJS}}
-
-{{#IF_CSHARP}}
-### C#-Specific
-- [ ] Nullable reference types enabled (`#nullable enable`)
-- [ ] Async/await used correctly (no blocking on async with `.Result` or `.Wait()`)
-- [ ] IDisposable resources properly disposed (`using` statements)
-- [ ] LINQ used appropriately (not in hot paths without reason)
-- [ ] Dependency injection used (no `new` for services)
-- [ ] No hardcoded connection strings
-{{/IF_CSHARP}}
-
-## Common Issues
-- Missing error handling
-- Hardcoded configuration (should use `.env` or config)
-- Missing tests for edge cases
-- Inconsistent naming conventions
-- Overly broad error catching

package/templates/.claude/skills/scaffold/SKILL.md.template

@@ -1,113 +0,0 @@
----
-name: scaffold
-description: Scaffold new code — services, packages, modules, components. Use when asked to create new files, modules, project structure, or boilerplate.
----
-
-# Code Scaffolding
-
-Match existing layout and patterns when adding new code. Read a few neighboring files in the same area before creating new ones — naming, error handling, and test placement should look like the rest of the codebase.
-
-{{#IF_PYTHON}}
-## Python Structure
-```
-services/python/<service-name>/
-├── pyproject.toml
-├── src/
-│   ├── __init__.py
-│   ├── app.py          # Entry point / app factory
-│   ├── models.py       # Data models (Pydantic)
-│   └── routes.py       # API endpoints (if web)
-└── tests/
-    ├── __init__.py
-    └── test_app.py
-```
-
-**Patterns:**
-- FastAPI for web APIs (app factory pattern)
-- Pydantic for data validation
-- pytest for testing
-- See `.template/examples/python-api/` and `.template/examples/python-cli/` for reference
-{{/IF_PYTHON}}
-
-{{#IF_GO}}
-## Go Structure
-```
-services/go/<service-name>/
-├── go.mod
-├── main.go             # Entry point
-├── handlers.go         # HTTP handlers
-├── handlers_test.go    # Handler tests
-└── internal/           # Private packages
-```
-
-**Patterns:**
-- Standard library `net/http` for HTTP
-- `httptest` for handler testing
-- See `.template/examples/go-service/` for reference
-{{/IF_GO}}
-
-{{#IF_NEXTJS}}
-## Next.js Structure
-```
-frontend/
-├── src/
-│   ├── app/            # App Router pages
-│   ├── components/     # React components
-│   └── lib/            # Utilities
-├── public/             # Static assets
-├── package.json
-└── tsconfig.json
-```
-{{/IF_NEXTJS}}
-
-{{#IF_NODE}}
-## Node.js Structure
-```
-services/node/<service-name>/
-├── package.json
-├── tsconfig.json
-├── src/
-│   └── index.ts
-└── tests/
-    └── index.test.ts
-```
-{{/IF_NODE}}
-
-{{#IF_RUST}}
-## Rust Structure
-```
-services/rust/<service-name>/
-├── Cargo.toml
-├── src/
-│   ├── main.rs         # Binary entry
-│   └── lib.rs          # Library code
-└── tests/
-    └── integration.rs
-```
-{{/IF_RUST}}
-
-{{#IF_CSHARP}}
-## C# Structure
-```
-src/<ProjectName>/
-├── <ProjectName>.csproj
-├── Program.cs
-├── Controllers/      # API controllers
-├── Models/           # Data models
-├── Services/         # Business logic
-└── appsettings.json  # Configuration
-tests/<ProjectName>.Tests/
-├── <ProjectName>.Tests.csproj
-└── UnitTests/
-```
-
-**Patterns:**
-- ASP.NET Core for web APIs (minimal APIs or controllers)
-- Entity Framework Core for data access
-- xUnit + Moq for testing
-{{/IF_CSHARP}}
-
-## After scaffolding
-
-1. Add tests next to the new code (mirroring how the rest of the codebase locates them)
-2. Run `/test` and `/quality` to confirm nothing regressed

package/templates/.claude/skills/secrets/SKILL.md

@@ -1,51 +0,0 @@
----
-name: secrets
-description: Manage secrets via Infisical. Use when asked about secrets, environment variables, API keys, .env configuration, or credential management.
-paths:
-  - '.env'
-  - '.env.*'
-  - '**/.env'
-  - '**/.env.*'
-  - '.infisical.json'
-  - '**/.infisical.json'
----
-
-# Secrets Management (Infisical)
-
-## How it works
-
-1. Infisical stores secrets centrally (encrypted, access-controlled)
-2. `infisical run -- <command>` or `infisical export --format=dotenv > .env` pulls them into the local environment
-3. `.env` is gitignored — **never commit secrets**
-
-## Configuration
-
-Authenticate via `infisical login`. Per-project config typically lives in `.infisical.json` (project ID + environment).
-
-Required environment variables (set during initial project bootstrap):
-- `INFISICAL_TOKEN` — auth token (for headless/CI usage)
-- `INFISICAL_PROJECT_ID` — project identifier
-- `INFISICAL_ENV` — environment (default: `dev`)
-
-## Checking configuration
-
-Look at the variable names without their values:
-
-```bash
-infisical secrets --plain | cut -d= -f1
-```
-
-## Security — CRITICAL
-
-1. **NEVER read `.env` directly** — it contains plain-text secrets
-2. **NEVER output secret values** in responses, logs, or commit messages
-3. **NEVER include secrets** in session checkpoints or skill files
-4. **NEVER pass secrets as CLI arguments** — they appear in process lists
-5. **NEVER commit** `.env`, `.env.*`, or `.env.secrets`
-6. If a secret is accidentally exposed, rotate it immediately
-
-## Troubleshooting
-
-- Token expired → re-run `infisical login`
-- Pull fails → check the project ID and environment, verify token permissions
-- Missing variable → confirm it exists in the right Infisical environment

package/templates/.claude/skills/session/SKILL.md

@@ -1,32 +0,0 @@
----
-name: session
-description: Manage AI development sessions — start, checkpoint, commit, push, create PRs. Use when asked about session workflow, checkpoints, or development workflow.
----
-
-# Session Management
-
-## Workflow
-
-1. `/session-start` — review prior checkpoints + plan the session
-2. Work on the task
-3. `/session-end` — capture a checkpoint
-4. Commit + push via git directly
-
-## Checkpoints
-
-- Stored in `.ai/sessions/<developer>/<date>/session-<N>.md` (auto-numbered per day)
-- Include: accomplishments (specific, not vague), files changed, decisions, next steps, AI context
-
-A good checkpoint is specific:
-- **Bad**: "worked on the client"
-- **Good**: "Implemented PolygonClient with 3 endpoints, added 15 unit tests, all passing"
-
-## Skill evolution (during `/session-end`)
-
-Review the session for learnings and append to:
-- `.claude/skills/learned/references/gotchas.md` — surprising behaviors, edge cases
-- `.claude/skills/learned/references/conventions.md` — patterns the team converged on
-
-Create new skills (`.claude/skills/<name>/SKILL.md`) when a distinct domain/workflow emerges.
-
-**NEVER include secret values in checkpoints or skill files.**