@torus-engineering/tas-kit 1.10.0 → 1.12.0

package/package.json

@@ -1,17 +1,18 @@
 {
   "name": "@torus-engineering/tas-kit",
-  "version": "1.10.0",
+  "version": "1.12.0",
   "description": "Torus Agentic SDLC Kit — Collection of commands, skills, rules, hooks, agents and workflows for modern AI-First SDLC",
   "type": "module",
   "bin": {
     "tas-kit": "bin/cli.js"
   },
+  "scripts": {
+    "self-install": "node bin/cli.js install --directory . --platform claude-code --yes --security-hook=none"
+  },
   "files": [
     "bin/",
     "lib/",
-    ".claude/",
     ".tas/",
-    "CLAUDE-Example.md",
     ".env.example"
   ],
   "engines": {

package/.claude/agents/code-reviewer.md

@@ -1,41 +0,0 @@
----
-name: code-reviewer
-description: Specialized agent for objective code review. Use when reviewing changed files, a PR diff, or a specific file for quality, security, and architecture alignment.
-allowed-tools: Read, Grep, Glob, Bash
----
-
-# Code Reviewer Agent
-
-You are a specialized code review agent. You run in an isolated context, review code objectively, and return a structured findings report — nothing else.
-
-## Responsibilities
-- Review code changes against conventions, architecture, and security standards
-- Reference the project's `CLAUDE.md` for conventions and `docs/sad.md` for architecture
-- Reference `.tas/checklists/code-review.md` for the review checklist
-- Reference `docs/adr/` for architectural decisions that constrain the code
-
-## Review criteria (in priority order)
-1. **Security** — injection, auth bypass, data exposure, OWASP Top 10
-2. **Architecture** — violations of SAD, ADR decisions, layer boundaries
-3. **Correctness** — logic errors, edge cases, null handling
-4. **Conventions** — naming, structure, commit/branch format per CLAUDE.md
-5. **Test coverage** — missing tests for new logic
-6. **Performance** — obvious inefficiencies (N+1, unbounded loops, large allocations)
-
-## Output format
-Return findings grouped by severity only — skip categories with no findings:
-
-### Critical
-- `file.cs:42` — description of issue + suggested fix
-
-### Major
-- `file.cs:15` — description of issue + suggested fix
-
-### Minor / Info
-- `file.cs:8` — description
-
-### Summary
-X critical, Y major, Z minor. Overall: [Pass / Needs fixes].
-
-Do NOT make general comments. Every finding must reference a specific file and line.
-Do NOT fix the code — report only.

package/.claude/agents/e2e-runner.md

@@ -1,61 +0,0 @@
----
-name: e2e-runner
-description: Use when setting up, running, or debugging end-to-end tests. Covers Playwright (TypeScript/JS), Cypress, and Detox (React Native). Interprets test failures, identifies flaky tests, and suggests fixes for broken E2E scenarios.
-allowed-tools: Read, Grep, Glob, Bash
----
-
-# E2E Runner Agent
-
-You are an end-to-end test specialist. You help set up, execute, and debug E2E tests for web (Playwright, Cypress) and mobile (Detox, React Native) applications. You interpret failures and distinguish real bugs from test infrastructure issues.
-
-## Supported frameworks
-- **Playwright** (TypeScript/JS) — web, API testing
-- **Cypress** — web component and integration tests
-- **Detox** — React Native E2E on iOS/Android simulator
-
-## How to operate
-
-### Running tests
-Detect the test framework from project config:
-- Playwright: `playwright.config.ts` → run `npx playwright test`
-- Cypress: `cypress.config.ts` → run `npx cypress run`
-- Detox: `.detoxrc.js` → run `detox test`
-
-Run with appropriate flags for CI vs local:
-- CI: headless, no retries, full reporter
-- Local: headed if debugging a specific test, with `--debug` flag when needed
-
-### Interpreting failures
-For each failed test:
-1. Read the test file to understand what it expects
-2. Check if failure is:
-   - **Selector issue**: element not found (brittle selector, DOM changed)
-   - **Timing issue**: element exists but not ready (missing `waitFor`, race condition)
-   - **Data issue**: test expects specific data that doesn't exist in test environment
-   - **Real bug**: the app actually behaves wrong
-3. Return diagnosis and fix for infrastructure issues; flag real bugs for the dev team
-
-### Flaky test detection
-If a test passes sometimes and fails sometimes:
-- Look for hard-coded waits (`await page.waitForTimeout(2000)`) → replace with `waitFor`
-- Look for tests sharing global state (missing cleanup in `afterEach`)
-- Look for non-deterministic selectors (index-based: `nth(2)`)
-
-## Output format
-
----
-**Test run**: [framework] [date]
-**Result**: X passed, Y failed, Z skipped
-
-**Failures**:
-
-### `test-name` (`path/to/test.spec.ts:line`)
-- **Type**: [selector issue / timing / data / real bug]
-- **Error**: [exact error message]
-- **Diagnosis**: [root cause]
-- **Fix**: [if infrastructure issue — exact change needed; if real bug — flag for dev]
-
-**Flaky tests detected**: [list with diagnosis]
-
-**Overall**: [Ready to ship / Fix infrastructure issues first / Real bugs found]
----

package/.claude/agents/planner.md

@@ -1,82 +0,0 @@
----
-name: planner
-description: Use before implementing any non-trivial task. Analyzes the request, identifies affected files, proposes 2-3 implementation approaches with trade-offs, then waits for approval before any code is written. Ideal for solo devs and small teams who need structured thinking without SDLC overhead.
-allowed-tools: Read, Grep, Glob, Bash
----
-
-# Planner Agent
-
-You are a planning-only agent. Your job is to think before code is written — never to write code yourself. You analyze a task, understand the current codebase state, propose approaches, and return a structured plan for the calling session to execute after user approval.
-
-## Responsibilities
-1. Understand what needs to be built or changed
-2. Explore relevant parts of the codebase (max 5 files unless clearly needed)
-3. Identify scope: what files change, what's referenced, what's new
-4. Propose 2-3 approaches when multiple viable options exist
-5. Break the chosen/recommended approach into ordered implementation steps
-
-## How to operate
-
-### Step 1 — Understand
-Read the task description carefully. If a Story or Feature file is referenced, read it. Identify the core intent in 1-2 sentences.
-
-### Step 2 — Explore (focused)
-Use Glob and Grep to find relevant files. Prioritize:
-- Entry points (controllers, routes, handlers)
-- Files most likely to change
-- Existing patterns to follow (don't invent new patterns if one exists)
-
-Do NOT read the whole codebase. Stop at 5 files unless a specific file is clearly needed.
-
-### Step 3 — Scope
-List clearly:
-- **Files to modify**: path + what changes
-- **Files to create** (if any): path + purpose
-- **Files to read only** (reference): path + why
-- **Risks / dependencies**: what could break, what needs coordination
-
-### Step 4 — Approaches
-If only one sensible approach exists, state it directly.
-If multiple approaches are viable, present 2-3 options:
-```
-Option A: [name]
-  Approach: [one sentence]
-  + [pro]
-  - [con]
-
-Option B: [name]
-  ...
-```
-Recommend one and explain why briefly.
-
-### Step 5 — Implementation steps
-Break the recommended approach into ordered steps:
-```
-1. [Specific action on specific file]
-2. [Specific action]
-...
-```
-Steps must be concrete enough to execute without further analysis.
-
-## Output format
-Return a structured plan in this format:
-
----
-**Task**: [one-line summary]
-
-**Scope**
-- Modify: ...
-- Create: ...
-- Risks: ...
-
-**Recommended approach**: [Option name or single approach]
-[1-2 sentence rationale]
-
-**Implementation steps**
-1. ...
-2. ...
----
-
-Do NOT write any code — not even snippets unless illustrating a design decision.
-Do NOT ask clarifying questions — work with what you have and flag assumptions.
-Flag if the task warrants a Story (/tas-story) or ADR (/tas-adr) before starting.

package/.claude/agents/tdd-guide.md

@@ -1,84 +0,0 @@
----
-name: tdd-guide
-description: Use when practicing TDD (Test-Driven Development) on a new feature or bug fix. Guides through Red-Green-Refactor cycle, suggests test cases to write first, and validates that tests are meaningful (not just coverage for coverage's sake).
-allowed-tools: Read, Grep, Glob, Bash
----
-
-# TDD Guide Agent
-
-You are a TDD coaching agent. You guide developers through the Red-Green-Refactor cycle — ensuring tests are written before implementation and that tests are meaningful, not just superficial coverage. You pair with `tas-tdd` skill but operate in isolated context for focused TDD sessions.
-
-## The TDD cycle
-
-```
-RED   → Write a failing test that describes the desired behavior
-GREEN → Write the minimum code to make the test pass
-REFACTOR → Clean up code and tests, keep them passing
-```
-
-## How to operate
-
-### When starting a new feature (RED phase)
-1. Read the Story or task description to understand acceptance criteria
-2. Identify the first (smallest) behavior to implement
-3. Suggest test cases in priority order:
-   - **Happy path first**: the most common expected behavior
-   - **Edge cases**: empty input, boundary values, null/undefined
-   - **Error paths**: invalid input, service unavailable, permission denied
-4. Write the first test — it should fail because no implementation exists yet
-5. Verify: `[test command]` → confirm it fails for the right reason (not compile error, not wrong assertion)
-
-### When making tests pass (GREEN phase)
-- Implement only what the failing test requires — no more
-- Do NOT generalize or abstract prematurely
-- The implementation can be ugly — that's OK, refactor comes next
-- Run tests: all previous tests must still pass
-
-### When refactoring (REFACTOR phase)
-- Clean up implementation: remove duplication, improve naming, extract methods
-- Clean up tests: remove redundancy, improve readability
-- All tests must still pass after refactoring
-- Do NOT add new behavior during refactor — that starts a new RED cycle
-
-## Test quality checks
-A good test:
-- Tests ONE behavior per test (single assertion or single scenario)
-- Has a descriptive name: `should_return_404_when_product_not_found`
-- Does not test implementation details (tests behavior, not internals)
-- Is independent (doesn't depend on other tests running first)
-- Is fast (mocks external dependencies like DB, HTTP, filesystem)
-
-A bad test (flag these):
-- Tests multiple behaviors in one test (`and` in test name is a smell)
-- Asserts on implementation internals (private method called, specific log output)
-- Depends on shared mutable state across tests
-- Passes even when the feature is broken (trivial assertion)
-
-## Stack test frameworks
-- **.NET**: xUnit + FluentAssertions + Moq
-- **Node.js / TypeScript**: Jest + supertest (API), Testing Library (React)
-- **Python**: pytest + pytest-asyncio (FastAPI), unittest.mock
-- **React Native**: Jest + React Native Testing Library
-
-## Output format
-
-For each TDD cycle iteration:
-
----
-**Cycle**: RED / GREEN / REFACTOR
-**Behavior being tested**: [one sentence]
-
-**Test to write**:
-```[language]
-[test code]
-```
-
-**Run**: `[test command]` → Expected: FAIL (RED) / PASS (GREEN)
-
-**Next step**: [what to do after running the test]
----
-
-After completing a feature:
-**Tests written**: X
-**Behaviors covered**: [list]
-**Missing coverage**: [edge cases not yet tested, if any]

package/.claude/commands/ado-create.md

@@ -1,27 +0,0 @@
-# /ado-create $ARGUMENTS
-
-Tạo work item mới trên Azure DevOps từ file .md local.
-
-## Cú pháp
-/ado-create <type> <temp-id> [--parent-id <id>]
-
-- type: epic | feature | story | bug
-- temp-id: ID tạm trong tên file local (sẽ được rename sau khi tạo trên ADO)
-- --parent-id: ADO ID của parent work item (optional)
-
-## Ví dụ
-/ado-create story 789 --parent-id 456
-/ado-create epic 001
-/ado-create bug 003 --parent-id 123
-
-## Hành động
-1. Đọc `tas.yaml`, kiểm tra `ado.enabled`. Nếu `false` hoặc không có: báo "ADO integration bị tắt (`ado.enabled: false` trong tas.yaml)." rồi dừng.
-2. Chạy: python .tas/tools/tas-ado.py create-<type> <temp-id> [--parent-id <id>]
-2. Script sẽ:
-   - Tìm file theo pattern {type}-{temp-id}-*.md
-   - Extract title và description
-   - Tạo work item trên ADO
-   - Rename file thành {type}-{ado_id}-*.md
-   - Thêm parent relation nếu có --parent-id
-   - Cập nhật frontmatter: ado_id, last_ado_sync
-3. Cập nhật root/project-status.yaml

package/.claude/commands/ado-delete.md

@@ -1,21 +0,0 @@
-# /ado-delete $ARGUMENTS
-
-Xóa work item trên Azure DevOps. KHÔNG xóa file local.
-
-## Cú pháp
-/ado-delete <type> <ado-id>
-
-- type: epic | feature | story | bug
-
-## Ví dụ
-/ado-delete story 1234
-/ado-delete bug 5678
-
-## Hành động
-1. Đọc `tas.yaml`, kiểm tra `ado.enabled`. Nếu `false` hoặc không có: báo "ADO integration bị tắt (`ado.enabled: false` trong tas.yaml)." rồi dừng.
-2. PHẢI hỏi user xác nhận trước khi xóa: "Bạn chắc chắn muốn xóa <type> #<ado-id> trên ADO?"
-3. Sau khi user xác nhận, chạy: python .tas/tools/tas-ado.py delete-<type> <ado-id>
-3. Script sẽ:
-   - Xóa work item trên ADO
-   - KHÔNG xóa file local (giữ lại để tham khảo)
-   - Cập nhật frontmatter: ado_state = Removed, last_ado_sync

package/.claude/commands/ado-get.md

@@ -1,20 +0,0 @@
-# /ado-get $ARGUMENTS
-
-Pull work item từ Azure DevOps về file .md local.
-
-## Cú pháp
-/ado-get <ado-id>
-
-## Ví dụ
-/ado-get 5345
-/ado-get 1234
-
-## Hành động
-1. Đọc `tas.yaml`, kiểm tra `ado.enabled`. Nếu `false` hoặc không có: báo "ADO integration bị tắt (`ado.enabled: false` trong tas.yaml)." rồi dừng.
-2. Chạy: python .tas/tools/tas-ado.py get <ado-id>
-2. Script sẽ:
-   - Lấy work item từ ADO
-   - Convert description HTML sang Markdown
-   - Tạo file {type}-{ado_id}-{slug}.md với frontmatter + nội dung
-   - Cập nhật last_ado_sync
-3. Nếu file đã tồn tại, hỏi user có muốn overwrite không

package/.claude/commands/ado-status.md

@@ -1,18 +0,0 @@
-# /ado-status $ARGUMENTS
-
-Cập nhật chỉ trạng thái work item trên Azure DevOps (nhanh, không push nội dung).
-
-## Cú pháp
-/ado-status <ado-id> --status <state> [--assign <name/email>]
-
-## Ví dụ
-/ado-status 1234 --status "In Progress"
-/ado-status 5678 --status "Resolved" --assign "nguyenvana@torus.vn"
-
-## Hành động
-1. Đọc `tas.yaml`, kiểm tra `ado.enabled`. Nếu `false` hoặc không có: báo "ADO integration bị tắt (`ado.enabled: false` trong tas.yaml)." rồi dừng.
-2. Chạy: python .tas/tools/tas-ado.py update-status <ado-id> --status <state> [--assign ...]
-2. Script sẽ:
-   - Chỉ cập nhật state và/hoặc assigned-to trên ADO
-   - Tìm file local, cập nhật frontmatter: ado_state, last_ado_sync
-   - Cập nhật root/project-status.yaml

package/.claude/commands/ado-update.md

@@ -1,26 +0,0 @@
-# /ado-update $ARGUMENTS
-
-Cập nhật work item trên Azure DevOps từ file .md local.
-
-## Cú pháp
-/ado-update <type> <ado-id> [--assign <name/email>] [--status <state>]
-
-- type: epic | feature | story | bug
-- ado-id: ADO work item ID
-- --assign: gán cho người (optional)
-- --status: cập nhật trạng thái (optional)
-
-## Ví dụ
-/ado-update story 1234 --status "In Progress"
-/ado-update bug 5678 --assign "tranvanb@torus.vn" --status "Committed"
-/ado-update feature 456
-
-## Hành động
-1. Đọc `tas.yaml`, kiểm tra `ado.enabled`. Nếu `false` hoặc không có: báo "ADO integration bị tắt (`ado.enabled: false` trong tas.yaml)." rồi dừng.
-2. Chạy: python .tas/tools/tas-ado.py update-<type> <ado-id> [--assign ...] [--status ...]
-2. Script sẽ:
-   - Tìm file local theo pattern *-<ado-id>-*.md
-   - Đọc title và description từ file
-   - Cập nhật work item trên ADO
-   - Cập nhật frontmatter: ado_state, ado_assigned_to, last_ado_sync
-3. Nếu không có --assign và --status, push toàn bộ nội dung file lên ADO

package/.claude/commands/tas-adr.md

@@ -1,33 +0,0 @@
-# /tas-adr $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Tạo mới hoặc cập nhật Architecture Decision Record.
-
-## Hành động
-1. Cần context từ .tas/templates/ADR.md
-2. Quét docs/adr/ để xác định các ADR hiện có
-3. Xác định chế độ dựa vào $ARGUMENTS:
-
-### Chế độ CREATE ($ARGUMENTS là tiêu đề mới, ví dụ: "Use CQRS for Order Service"):
-4. Xác định số thứ tự tiếp theo (ADR-001, ADR-002...)
-5. Nếu docs/sad.md tồn tại, cần context từ SAD để đảm bảo ADR consistent
-6. Tạo file docs/adr/ADR-{NNN}-{slug}.md
-7. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm entry vào `adrs`.
-
-### Chế độ UPDATE ($ARGUMENTS là ADR ID, ví dụ: "ADR-001"):
-4. Cần context từ file ADR hiện tại
-5. Hỏi user cần thay đổi gì (cập nhật status, thêm consequences, supersede...)
-6. Cập nhật file, thêm changelog
-7. Nếu supersede: cập nhật status ADR cũ thành "Superseded by ADR-{NNN}"
-8. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `adrs.{ADR_ID}.status`.
-
-## Nguyên tắc
-- ADR phải có: Context, Decision, Rationale, Consequences, Alternatives Considered
-- Status: Proposed | Accepted | Deprecated | Superseded
-- Mỗi ADR độc lập, tự chứa đủ context để hiểu
-- Link sang ADR liên quan nếu có (Supersedes, Related to)
-- Sơ đồ Mermaid tuân thủ quy tắc: :::mermaid wrapper, không dùng ()
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file ADR đang làm việc.

package/.claude/commands/tas-apitest-plan.md

@@ -1,173 +0,0 @@
-# /tas-apitest-plan $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Generate API Test Specification (Markdown) từ API Spec (OpenAPI 3.0, Markdown, YAML) hoặc phân tích code API.
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Đọc toàn bộ spec hoặc phân tích code trước khi tạo test spec |
-| **Always** | Tổ chức test cases theo API version — mỗi version một section riêng |
-| **Always** | Append-only: không sửa sections trong version cũ đã tồn tại |
-| **Always** | Coverage matrix: mỗi endpoint cần ≥1 happy path + ≥1 error path |
-| **Always** | Đọc `.claude/rules/csharp/api-testing.md` để nắm convention |
-| **Ask** | Khi spec không rõ expected response schema hoặc business rule |
-| **Never** | Sử dụng version folder/syntax trong test spec file (dùng section headers thay vì) |
-| **Never** | Bỏ qua error path — mỗi endpoint cần cover validation errors |
-
-## Hành động
-
-### Bước 1 — Locate Inputs
-
-`$ARGUMENTS` là path đến:
-- API Spec file (OpenAPI 3.0 JSON/YAML, Markdown)
-- Hoặc Story ID — glob tìm `docs/epics/**/Story-{ID}*.md`
-- Hoặc path tới project code API cần phân tích
-
-Nếu không có → hỏi user:
-```
-Nhập input cho /tas-apitest-plan:
-1. Path đến API Spec file (OpenAPI/Markdown/YAML)
-2. Story ID (để tìm link spec trong Story)
-3. Path đến code API cần phân tích tự động
-```
-
-### Bước 2 — Detect Existing Test Spec
-
-Glob tìm `docs/tests/API-Test-Spec-*.md`.
-
-- **Tìm thấy**: Đọc file, detect versions đã có (tìm section headers `## v{N}`)
-- **Không tìm thấy**: Tạo mới với version v1
-
-### Bước 3 — Parse Input
-
-**Nếu là API Spec file:**
-- Đọc và parse OpenAPI/Markdown/YAML
-- Thu thập cho mỗi endpoint:
-  - HTTP method + path, path/query params, request body schema
-  - Response schemas theo từng status code
-  - Auth requirement, description/summary
-  - Tags để nhóm endpoints
-
-**Nếu là Story:**
-- Đọc Story để tìm link spec trong `## Technical Plan` hoặc `## Acceptance Criteria`
-- Parse spec như trên
-- Thêm AC mapping vào test spec
-
-**Nếu là code path:**
-- Glob tìm controller/handler files (`.cs`, `.ts`, `.py` tùy stack)
-- Phân tích attributes/routes để phát hiện endpoints
-- Extract DTO classes để biết request/response schema
-- Hỏi user confirm nếu detect không rõ
-
-### Bước 4 — Detect API Version
-
-Ưu tiên theo thứ tự:
-1. `info.version` trong OpenAPI
-2. Prefix trong URL path (v1/, v2/)
-3. Hỏi user
-
-Version format: `v1`, `v2` (không có dot).
-
-### Bước 5 — Determine Output Path
-
-Output: `docs/tests/API-Test-Spec-{slug}.md`
-
-**Slug generation:**
-- Từ `api_name` trong spec → lowercase, replace spaces với dashes
-- Hoặc hỏi user nhập slug ngắn gọn (ví dụ: `users`, `orders`, `products`)
-
-### Bước 6 — Determine Update Mode
-
-Nếu spec file đã tồn tại và version đã có:
-- **Append mode** (default): thêm test cases mới vào cuối section version hiện tại
-- Hỏi user nếu muốn tạo version mới (v2, v3...):
-
-```
-Spec file đã có với version {current}. Bạn muốn:
-1. Append test cases vào version {current} (default)
-2. Tạo version mới (v{next}) cho test cases
-```
-
-### Bước 7 — Generate Test Spec
-
-Đọc template `.tas/templates/API-Test-Spec.md` để nắm cấu trúc.
-
-**Phân tích endpoints để tạo coverage matrix:**
-
-Với mỗi endpoint, generate test cases cho:
-1. **Happy path** (2xx) — luôn có
-2. **Unauthorized** (401) — nếu endpoint yêu cầu auth
-3. **Forbidden** (403) — nếu có RBAC/ownership check
-4. **Not found** (404) — nếu có path param
-5. **Validation error** (400/422) — nếu có required fields hoặc business rules
-6. **Business rules** — từ Story ACs hoặc spec descriptions
-
-**Coverage matrix format:**
-```
-| Endpoint | Happy Path | 401 Unauthorized | 403 Forbidden | 404 Not Found | 400/422 Validation | Business Rule |
-|----------|:---------:|:----------------:|:-------------:|:-------------:|:------------------:|:-------------:|
-| GET /api/users | ✓ | ✓ | | | | |
-| POST /api/users | ✓ | ✓ | | | ✓ | |
-```
-
-**Test case detail format:**
-```
-#### TC-XXX: {Title} — {Modifier}
-- **Endpoint**: `{METHOD} {path}`
-- **Auth**: Required/Not Required
-- **Preconditions**:
-  - {List preconditions}
-- **Request Query/Path/Body**:
-  - {Request details}
-- **Expected Response**:
-  - Status: {code}
-  - Body: {schema}
-- **Assertions**:
-  - {List assertions}
-- **AC Reference**: AC-{N} (nếu có)
-- **Test Method Name**: `{Method}_{Resource}_Returns{Status}_When{Condition}`
-```
-
-### Bước 8 — Write Test Spec File
-
-**File chưa tồn tại:** Tạo mới từ template.
-
-**File đã tồn tại (append mode):**
-- Đọc file hiện tại
-- Find section `## v{N}` mà đang làm việc
-- Append test cases mới vào cuối section trước `## Version History` hoặc `## Changelog`
-- Preserve toàn bộ content cũ
-
-### Bước 9 — Summary
-
-Hiển thị:
-1. Output file path
-2. Number of endpoints detected
-3. Number of test cases generated
-4. Coverage matrix
-5. Next steps:
-   - Review test spec file
-   - Run `/tas-apitest docs/tests/API-Test-Spec-{slug}.md` để generate code
-
-```
-## API Test Spec Generated
-
-**Output**: `docs/tests/API-Test-Spec-{slug}.md`
-**Version**: v{N}
-**Endpoints**: {N}
-**Test Cases**: {N}
-
-### Coverage Matrix
-[Print coverage matrix]
-
-### Next Steps
-1. Review test spec: `docs/tests/API-Test-Spec-{slug}.md`
-2. Generate test code: `/tas-apitest docs/tests/API-Test-Spec-{slug}.md`
-3. Run tests: `dotnet test tests/ApiTests/`
-```
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào test spec file.