agent-workflow-kit-cli 1.3.3 → 1.3.5

package/templates/golang/AGENTS.md.hbs

@@ -1,14 +1,12 @@
 ## 🗺️ Golang Development Guide (Go Backend)
 
 ### 🔄 Agent Development Lifecycle
-The AI Agent must execute all Golang tasks following this 4-step workflow:
-1. **Design & Implementation:** Implement business logic adhering to the Standard Go Project Layout. Keep entrypoints in `cmd/`, core business logic in `internal/`, and standalone shared libraries in `pkg/`.
-2. **Comprehensive Testing:** Write unit tests using the table-driven testing pattern and Go's built-in `testing` library. Run tests with: `go test ./...`.
-3. **Code Quality & Formatting:** Ensure code compiles and meets formatting/linting rules:
-   - Formatting: `gofmt -w .`
-   - Linting: `golangci-lint run`
-   - Build Validation: `go build ./...`
-4. **Dependency Management:** Add new external libraries using `go get [library_name]`. Never manually edit the `go.sum` file.
+The AI Agent must execute all Golang tasks following this structured 5-stage lifecycle:
+1. **Design & Code:** Implement business logic adhering to the Standard Go Project Layout. Keep entrypoints in `cmd/`, core business logic in `internal/`, and standalone shared libraries in `pkg/`.
+2. **Comprehensive Testing:** Write unit tests using the table-driven testing pattern and Go's built-in `testing` library. Mock database layers or third-party connections.
+3. **Troubleshooting & Debugging:** When debugging goroutines or database locks, use context cancellation and trace log output.
+4. **Code Quality & Review:** Verify code quality against `@golang-style.md` to check interface boundaries, error wrapping, and naming.
+5. **Acyclic Design:** Ensure there are no circular imports. Encapsulate domain packages cleanly under `@project-layout.md` and manage concurrent access via `@concurrency.md`.
 
 ---
 
@@ -18,6 +16,8 @@ Refer to the detailed rules below:
 - Directory organization and manual dependency injection: `@project-layout.md`
 - Explicit error handling, wrapping, and custom API errors: `@error-handling.md`
 - Concurrency, goroutine/channel lifecycle, and escape analysis: `@concurrency.md`
+- Scaffolding a business feature (Handler, Service interface, tests): `@golang-feature`
+- Scaffolding repository database operations and models: `@golang-db`
 
 ---
 
@@ -29,8 +29,14 @@ Refer to the detailed rules below:
 
 #### 2. Explicit Error Handling
 - **Check Every Error:** Never ignore returned errors. Write `if err != nil` checks immediately after calling fallible functions.
-- **Wrap Errors:** Use `fmt.Errorf("failed to...: %w", err)` when propagating errors to preserve runtime context.
+- **Wrap Errors:** Use `fmt.Errorf("failed to...: %w", err)` when propagating errors to preserve runtime context. Review details in `@error-handling.md`.
 
 #### 3. Safe Concurrency
 - **Context Propagation:** Pass `ctx context.Context` as the first argument to all functions executing I/O.
 - **Prevent Race Conditions:** Protect shared memory access across goroutines using `sync.Mutex` or `sync/atomic`.
+
+### 🧪 Verification & Testing
+Before completing a task, run the following verification pipeline locally:
+- **Build Validation:** `go build ./...`
+- **Testing:** `go test ./...`
+- **Formatting:** `gofmt -w .`

package/templates/golang/skills/golang-db/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: golang-db
+description: Scaffold a Go database repository layer using SQLx, GORM, or raw SQL queries
+---
+
+Follow this process to add or extend database entities and repository queries.
+
+Inputs:
+- structName: Model entity struct name (e.g., `User`)
+- tableName: Database table name (e.g., `users`)
+- repositoryName: Interface name (e.g., `UserRepository`)
+
+Steps:
+1. Declare the entity model struct with json and db (or gorm) tags:
+   ```go
+   type User struct {
+       ID        int64     `json:"id" db:"id" gorm:"primaryKey"`
+       Email     string    `json:"email" db:"email"`
+       CreatedAt time.Time `json:"created_at" db:"created_at"`
+   }
+   ```
+2. Define the repository interface (e.g., `UserRepository`) containing standard SQL actions (`FindByID`, `Save`).
+3. Implement the interface concrete struct wrapping the database handle (e.g., `*sql.DB`, `*sqlx.DB`, or `*gorm.DB`).
+4. Wire the repository implementation to the service layer using constructor injection.
+5. Create SQL schema files under the `/migrations` or `/db` directories if schema changes are required.
+6. Verify code correctness using:
+   - `go build ./...`

package/templates/golang/skills/golang-feature/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: golang-feature
+description: Scaffold a Go package slice including Handler, Service interfaces, and table-driven unit tests
+---
+
+Follow this process to generate a new Go business feature slice.
+
+Inputs:
+- packageName: Name of the package (e.g., `billing`)
+- structName: Primary model struct name (e.g., `Invoice`)
+- functionality: Summary of the business requirements and API paths
+
+Steps:
+1. Create a directory inside `internal/` named `<packageName>/` (e.g., `internal/billing`).
+2. Declare structs and interfaces in `<packageName>.go` or `types.go` (e.g., `BillingService` interface and `Invoice` struct).
+3. Implement the concrete service class (e.g., `service.go` containing `type service struct { ... }` implementing `BillingService`).
+4. Implement HTTP handlers in `handler.go` wrapping inputs/outputs via JSON bindings.
+5. Register routers/handlers in the application bootloader (e.g., in `cmd/server/main.go`).
+6. Write unit tests in `service_test.go` using table-driven tests:
+   ```go
+   func TestBillingService(t *testing.T) {
+       tests := []struct {
+           name    string
+           input   string
+           wantErr bool
+       }{
+           {
+               name:    "Valid input case",
+               input:   "valid",
+               wantErr: false,
+           },
+       }
+       for _, tt := range tests {
+           t.Run(tt.name, func(t *testing.T) {
+               // Implement test validation
+           })
+       }
+   }
+   ```
+7. Run validation commands:
+   - `go build ./...`
+   - `go test ./...`

package/templates/nestjs/AGENTS.md.hbs

@@ -1,15 +1,12 @@
 ## 🗺️ NestJS Development Guide (Node.js Backend)
 
 ### 🔄 Agent Development Lifecycle
-The AI Agent must execute all NestJS tasks following this 5-step workflow:
-1. **Design & Implementation:** Implement business logic adhering to the Module-driven architecture. Keep Controllers thin; place 100% of business logic within Services.
+The AI Agent must execute all NestJS tasks following this structured 5-stage lifecycle:
+1. **Design & Code:** Implement business logic adhering to the Module-driven architecture. Keep Controllers thin; place 100% of business logic within Services. Encapsulate components cleanly as outlined in `@module-architecture.md`.
 2. **Comprehensive Testing:** Write unit tests for Services using Jest Mocking (`.spec.ts`) and end-to-end (E2E) integration tests using Supertest.
-3. **Code Quality & Type Safety:** Run syntax check and type check commands:
-   - Linting: `{{runCommand}} lint`
-   - Type Checking: `{{runCommand}} typecheck`
-   - Testing: `{{runCommand}} test` (or `{{runCommand}} test -- --run` for CI/CD environments)
-   - Build Validation: `{{runCommand}} build`
-4. **Dependency Management:** Install new libraries using `{{packageManager}} add [library_name]`. Never modify the lockfile `{{lockFile}}` manually.
+3. **Troubleshooting & Debugging:** When debugging request validations or database mappings, inspect class-validator metadata and database query logs.
+4. **Code Quality & Review:** Perform self-review using `@validation-errors.md` to ensure constraints are enforced and exceptions are mapped correctly. Check formatting conventions in `@nestjs-style.md`.
+5. **Production Readiness:** Verify compilation and lint errors are resolved before completion.
 
 ---
 
@@ -18,7 +15,7 @@ Refer to the detailed rules below:
 - TypeScript coding style, indentation, decorator sorting, and clean code conventions: `@nestjs-style.md`
 - Strict module boundaries, encapsulation, and resource sharing rules: `@module-architecture.md`
 - Class Validator setups, ValidationPipe data transformations, and Exception Filters: `@validation-errors.md`
-- Process to scaffold modular components (Module, Controller, Service, DTO, Entity): `@SKILL.md`
+- Process to scaffold modular components (Module, Controller, Service, DTO, Entity): `@nestjs-module`
 
 ---
 
@@ -36,3 +33,10 @@ Refer to the detailed rules below:
 - **No Raw Server Errors:** Never expose raw database or system exceptions (HTTP 500) to clients.
 - **Built-in HttpExceptions:** Handle try/catch flows inside Services and map errors to explicit NestJS HttpExceptions (e.g., `NotFoundException`, `BadRequestException`, `ForbiddenException`).
 - **Global Exception Filter:** Expose a global Exception Filter to format all error responses consistently in JSON format.
+
+### 🧪 Verification & Testing
+Before completing a task, run the following verification pipeline:
+- **Linting:** `{{runCommand}} lint`
+- **Type Checking:** `{{runCommand}} typecheck`
+- **Testing:** `{{runCommand}} test`
+- **Build Validation:** `{{runCommand}} build`

package/templates/next-js/AGENTS.md.hbs

@@ -1,15 +1,12 @@
 ## 🗺️ Next.js Development Guide (App Router)
 
 ### 🔄 Agent Development Lifecycle
-The AI Agent must execute all Next.js tasks following this 5-step workflow:
-1. **Design & Implementation:** Build pages and components adhering to the App Router conventions. Default to React Server Components (RSC).
+The AI Agent must execute all Next.js tasks following this structured 5-stage lifecycle:
+1. **Design & Code:** Build pages and components adhering to the App Router conventions. Default to React Server Components (RSC) as described in `@server-client-components.md`.
 2. **Comprehensive Testing:** Write unit tests for business utilities and component behavior using Jest/Vitest.
-3. **Code Quality & Type Safety:** Run syntax check and type check commands:
-   - Linting: `{{runCommand}} lint`
-   - Type Checking: `{{runCommand}} typecheck`
-   - Testing: `{{runCommand}} test` (or `{{runCommand}} test -- --run` for CI/CD environments)
-   - Build Validation: `{{runCommand}} build`
-4. **Dependency Management:** Install new libraries using `{{packageManager}} add [library_name]`. Never modify the lockfile `{{lockFile}}` manually.
+3. **Troubleshooting & Debugging:** When debugging data loading or hydration mismatch issues, isolate Server and Client component scopes.
+4. **Code Quality & Review:** Perform self-review using `@data-fetching-mutations.md` (for Server Actions and query caching parameters) and `@seo-metadata.md`. Check styling rules in `@next-style.md`.
+5. **Production Readiness:** Verify compilation, type checks, and next builds compile warning-free before committing.
 
 ---
 
@@ -19,7 +16,7 @@ Refer to the detailed rules below:
 - Architectural boundaries between React Server Components (RSC) and React Client Components (RCC): `@server-client-components.md`
 - Server-side data fetching, caching, revalidation, and secure Server Actions: `@data-fetching-mutations.md`
 - Semantic HTML5 standards and Dynamic Metadata API configurations: `@seo-metadata.md`
-- Step-by-step process to generate new Pages or Routes cleanly: `@SKILL.md`
+- Step-by-step process to generate new Pages or Routes cleanly: `@next-feature`
 
 ---
 
@@ -39,3 +36,10 @@ Refer to the detailed rules below:
 - **Image Optimization:** Never use raw `<img>` tags. Use `next/image`'s `<Image />` with appropriate `sizes` attributes, and set `priority` for above-the-fold images.
 - **Navigation:** Use `<Link />` from `next/link` to enable background pre-fetching when links enter the viewport.
 - **Dynamic Metadata:** Export a `generateMetadata` function in dynamic routes to optimize search engine crawling.
+
+### 🧪 Verification & Testing
+Before completing a task, run the following verification pipeline:
+- **Linting:** `{{runCommand}} lint`
+- **Type Checking:** `{{runCommand}} typecheck`
+- **Testing:** `{{runCommand}} test`
+- **Build Validation:** `{{runCommand}} build`

package/templates/rust/AGENTS.md.hbs

@@ -1,14 +1,12 @@
 ## 🗺️ Rust Development Guide
 
 ### 🔄 Agent Development Lifecycle
-The AI Agent must execute all Rust tasks following this 4-step workflow:
-1. **Design & Implementation:** Implement business logic adhering to Rust conventions. Enforce structural separation: `main.rs` (for binary application setup) and `lib.rs` (for core business logic that can be reused and tested).
-2. **Comprehensive Testing:** Write unit tests inside internal test modules and integration tests in the `/tests` directory. Run tests with: `cargo test`.
-3. **Code Quality & Linting:** Run check tools regularly to ensure a warning-free state:
-   - Formatting: `cargo fmt`
-   - Linting: `cargo clippy --all-targets -- -D warnings`
-   - Build Validation: `cargo build`
-4. **Dependency Management:** Add external libraries using `cargo add [library_name]`. Never manually edit the `Cargo.lock` file.
+The AI Agent must execute all Rust tasks following this structured 5-stage lifecycle:
+1. **Design & Code:** Implement business logic adhering to Rust conventions. Enforce structural separation: `main.rs` (for binary application setup) and `lib.rs` (for core business logic that can be reused and tested).
+2. **Comprehensive Testing:** Write unit tests inside internal test modules and integration tests in the `/tests` directory. Mocks and double components should be declared under `#[cfg(test)]`.
+3. **Troubleshooting & Debugging:** When debugging lifetimes, memory borrow errors, or asynchronous deadlocks, refer to `@memory-concurrency.md` directives.
+4. **Code Quality & Review:** Verify code conforms strictly to `@rust-style.md` check criteria (preventing warnings, formatting code, avoiding over-cloning).
+5. **Crate Architecture:** Organize workspace dependencies using Cargo Workspaces if building multi-crate projects, maintaining encapsulation guidelines in `@project-layout.md`.
 
 ---
 
@@ -18,6 +16,8 @@ Refer to the detailed rules below:
 - Crate modules, Cargo Workspaces, and Trait-based Dependency Injection: `@project-layout.md`
 - Failures management, Result/Option, `thiserror`, and `anyhow`: `@error-handling.md`
 - Lifetimes `'a`, Smart Pointers, and async Tokio safety: `@memory-concurrency.md`
+- Scaffolding a Rust feature (Struct, traits, implementations, unit tests): `@rust-feature`
+- Scaffolding asynchronous database repositories and models: `@rust-db`
 
 ---
 
@@ -28,7 +28,14 @@ Refer to the detailed rules below:
 - **Exclusive Mutable Borrow:** Ensure only one mutable reference `&mut T` exists at a time, and never let it coexist with any read references `&T` in the same scope.
 
 #### 2. Safe Error Handling
-- **No Unwraps:** Never use `.unwrap()` or `.expect()` in production code (except in tests). Propagate errors using `Result<T, E>` or `Option<T>` to ensure system reliability.
+- **No Unwraps:** Never use `.unwrap()` or `.expect()` in production code (except in tests). Propagate errors using `Result<T, E>` or `Option<T>` to ensure system reliability. Manage library errors with `thiserror` and application errors with `anyhow` as outlined in `@error-handling.md`.
 
 #### 3. Async Concurrency (Tokio)
 - **CPU-Bound Tasks:** Never run heavy CPU operations (e.g., encryption, intensive loops) directly inside async contexts. Offload them using `tokio::task::spawn_blocking`.
+- **Mutex Selection:** Prefer standard `std::sync::Mutex` for synchronizing state across threads if the guard is not held across `.await` points. Use `tokio::sync::Mutex` only when needed to prevent scheduling blocking.
+
+### 🧪 Verification & Testing
+Before completing a task, run the following verification pipeline locally:
+- **Lint check:** `cargo clippy --all-targets -- -D warnings`
+- **Testing:** `cargo test`
+- **Formatting:** `cargo fmt -- --check`

package/templates/rust/skills/rust-db/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: rust-db
+description: Scaffold a database repository layer in Rust using SQLx, Diesel, or SeaORM
+---
+
+Follow this process to add database models, tables, and access methods in Rust.
+
+Inputs:
+- modelName: Name of the struct (e.g., `User`)
+- tableName: Database table name (e.g., `users`)
+- databaseLibrary: DB access style: SQLx, Diesel, or SeaORM
+
+Steps:
+1. Declare the database entity struct, applying appropriate serialization/deserialization attributes (e.g., `#[derive(Debug, Serialize, Deserialize, sqlx::FromRow)]`).
+2. Define the repository trait or struct handling asynchronous database connection execution.
+3. If using SQLx, write queries using async query macros to ensure compile-time SQL validation:
+   ```rust
+   let user = sqlx::query_as!<User, _>(
+       "SELECT id, email, created_at FROM users WHERE id = $1", id
+   )
+   .fetch_one(&self.pool)
+   .await?;
+   ```
+4. If using Diesel or SQLx migrations, add a migration script under the `/migrations` directory.
+5. Setup connection pooling parameters and pass database pool references using constructor dependency injection.
+6. Verify query compilation and formatting:
+   - `cargo clippy --all-targets -- -D warnings`

package/templates/rust/skills/rust-feature/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: rust-feature
+description: Scaffold a Rust module, including structs, traits, implementations, and unit/integration tests
+---
+
+Follow this process to generate a new Rust feature or sub-module.
+
+Inputs:
+- moduleName: Name of the module/file (e.g., `billing`)
+- traitName: Name of the trait interface if any (e.g., `BillingService`)
+- functionality: Summary of the business requirements and structs
+
+Steps:
+1. Create a file under `src/` named `<moduleName>.rs` (e.g., `src/billing.rs`), or a subdirectory containing `mod.rs`.
+2. Register the module in `lib.rs` or `main.rs` using `pub mod <moduleName>;`.
+3. Declare traits, structs, and custom error types (using `thiserror` for domain-specific errors) in the new module.
+4. Implement functionality for the structs, mapping options and results safely (no `unwrap` or `expect` allowed in production).
+5. Write inline unit tests inside a nested `tests` module decorated with `#[cfg(test)]`:
+   ```rust
+   #[cfg(test)]
+   mod tests {
+       use super::*;
+
+       #[test]
+       fn test_feature_logic() {
+           // Arrange, Act, Assert
+       }
+   }
+   ```
+6. Add integration tests inside `/tests` if this feature integrates multiple modules or dependencies.
+7. Verify compilation and warnings:
+   - `cargo check`
+   - `cargo test`
+   - `cargo clippy --all-targets -- -D warnings`