@torus-engineering/tas-kit 1.9.0 → 1.11.1

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

@@ -1,27 +1,27 @@
-# /ado-create $ARGUMENTS
+# /ado-create $ARGUMENTS
 
-Tạo work item mới trên Azure DevOps từ file .md local.
+Create new work item on Azure DevOps from local .md file.
 
-## Cú pháp
+## Syntax
 /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)
+- temp-id: Temporary ID in local filename (will be renamed after creating on ADO)
+- --parent-id: ADO ID of parent work item (optional)
 
-## Ví dụ
+## Examples
 /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
+## Actions
+1. Read `tas.yaml`, check `ado.enabled`. If `false` or missing: report "ADO integration is disabled (`ado.enabled: false` in tas.yaml)." then stop.
+2. Run: python .tas/tools/tas-ado.py create-<type> <temp-id> [--parent-id <id>]
+3. Script will:
+   - Find file by pattern {type}-{temp-id}-*.md
+   - Extract title and description
+   - Create work item on ADO
+   - Rename file to {type}-{ado_id}-*.md
+   - Add parent relation if --parent-id provided
+   - Update frontmatter: ado_id, last_ado_sync
+4. Update root/project-status.yaml

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

@@ -1,21 +1,21 @@
 # /ado-delete $ARGUMENTS
 
-Xóa work item trên Azure DevOps. KHÔNG xóa file local.
+Delete work item on Azure DevOps. Does NOT delete local file.
 
-## Cú pháp
+## Syntax
 /ado-delete <type> <ado-id>
 
 - type: epic | feature | story | bug
 
-## Ví dụ
+## Examples
 /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
+## Actions
+1. Read `tas.yaml`, check `ado.enabled`. If `false` or missing: report "ADO integration is disabled (`ado.enabled: false` in tas.yaml)." then stop.
+2. MUST ask user confirmation before deleting: "Are you sure you want to delete <type> #<ado-id> on ADO?"
+3. After user confirms, run: python .tas/tools/tas-ado.py delete-<type> <ado-id>
+4. Script will:
+   - Delete work item on ADO
+   - NOT delete local file (keep for reference)
+   - Update frontmatter: ado_state = Removed, last_ado_sync

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

@@ -1,20 +1,20 @@
 # /ado-get $ARGUMENTS
 
-Pull work item từ Azure DevOps về file .md local.
+Pull work item from Azure DevOps to local .md file.
 
-## Cú pháp
+## Syntax
 /ado-get <ado-id>
 
-## Ví dụ
+## Examples
 /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
+## Actions
+1. Read `tas.yaml`, check `ado.enabled`. If `false` or missing: report "ADO integration is disabled (`ado.enabled: false` in tas.yaml)." then stop.
+2. Run: python .tas/tools/tas-ado.py get <ado-id>
+3. Script will:
+   - Fetch work item from ADO
+   - Convert description HTML to Markdown
+   - Create file {type}-{ado_id}-{slug}.md with frontmatter + content
+   - Update last_ado_sync
+4. If file already exists, ask user if they want to overwrite

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

@@ -1,18 +1,18 @@
-# /ado-status $ARGUMENTS
+# /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).
+Update only work item status on Azure DevOps (fast, no content push).
 
-## Cú pháp
+## Syntax
 /ado-status <ado-id> --status <state> [--assign <name/email>]
 
-## Ví dụ
+## Examples
 /ado-status 1234 --status "In Progress"
-/ado-status 5678 --status "Resolved" --assign "nguyenvana@torus.vn"
+/ado-status 5678 --status "Resolved" --assign "user@example.com"
 
-## 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
+## Actions
+1. Read `tas.yaml`, check `ado.enabled`. If `false` or missing: report "ADO integration is disabled (`ado.enabled: false` in tas.yaml)." then stop.
+2. Run: python .tas/tools/tas-ado.py update-status <ado-id> --status <state> [--assign ...]
+3. Script will:
+   - Only update state and/or assigned-to on ADO
+   - Find local file, update frontmatter: ado_state, last_ado_sync
+   - Update root/project-status.yaml

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

@@ -1,26 +1,26 @@
 # /ado-update $ARGUMENTS
 
-Cập nhật work item trên Azure DevOps từ file .md local.
+Update work item on Azure DevOps from local .md file.
 
-## Cú pháp
+## Syntax
 /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)
+- --assign: assign to person (optional)
+- --status: update status (optional)
 
-## Ví dụ
+## Examples
 /ado-update story 1234 --status "In Progress"
-/ado-update bug 5678 --assign "tranvanb@torus.vn" --status "Committed"
+/ado-update bug 5678 --assign "user@example.com" --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
+## Actions
+1. Read `tas.yaml`, check `ado.enabled`. If `false` or missing: report "ADO integration is disabled (`ado.enabled: false` in tas.yaml)." then stop.
+2. Run: python .tas/tools/tas-ado.py update-<type> <ado-id> [--assign ...] [--status ...]
+3. Script will:
+   - Find local file by pattern *-<ado-id>-*.md
+   - Read title and description from file
+   - Update work item on ADO
+   - Update frontmatter: ado_state, ado_assigned_to, last_ado_sync
+4. If no --assign and --status provided, push entire file content to ADO

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

@@ -1,33 +1,33 @@
-# /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.
+# /tas-adr $ARGUMENTS
+
+Role: SE - Software Engineer
+Create or update Architecture Decision Record.
+
+## Actions
+1. Need context from .tas/templates/ADR.md
+2. Scan docs/adr/ to identify existing ADRs
+3. Determine mode based on $ARGUMENTS:
+
+### CREATE mode ($ARGUMENTS is new title, e.g., "Use CQRS for Order Service"):
+4. Determine next sequence number (ADR-001, ADR-002...)
+5. If docs/sad.md exists, need context from SAD to ensure ADR consistency
+6. Create file docs/adr/ADR-{NNN}-{slug}.md
+7. Update `project-status.yaml` per `.claude/rules/common/project-status.md` — add entry to `adrs`.
+
+### UPDATE mode ($ARGUMENTS is ADR ID, e.g., "ADR-001"):
+4. Need context from current ADR file
+5. Ask user what needs changing (update status, add consequences, supersede...)
+6. Update file, add changelog
+7. If supersede: update old ADR status to "Superseded by ADR-{NNN}"
+8. Update `project-status.yaml` per `.claude/rules/common/project-status.md` — update `adrs.{ADR_ID}.status`.
+
+## Principles
+- ADR must have: Context, Decision, Rationale, Consequences, Alternatives Considered
+- Status: Proposed | Accepted | Deprecated | Superseded
+- Each ADR is independent, self-contained with enough context to understand
+- Link to related ADRs if any (Supersedes, Related to)
+- Mermaid diagram rules: :::mermaid wrapper, no () in node labels
+
+## Final Step — Token Log
+
+Invoke skill `token-logger`: write AI Usage Log to working ADR file.

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

@@ -1,173 +1,173 @@
-# /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.
+# /tas-apitest-plan $ARGUMENTS
+
+Role: SE - Software Engineer
+Generate API Test Specification (Markdown) from API Spec (OpenAPI 3.0, Markdown, YAML) or analyze API code.
+
+## Always / Ask / Never
+
+| | Action |
+|---|---|
+| **Always** | Read entire spec or analyze code before creating test spec |
+| **Always** | Organize test cases by API version — each version separate section |
+| **Always** | Append-only: don't modify sections in existing old version |
+| **Always** | Coverage matrix: each endpoint needs ≥1 happy path + ≥1 error path |
+| **Always** | Read `.claude/rules/csharp/api-testing.md` for conventions |
+| **Ask** | When spec unclear about expected response schema or business rule |
+| **Never** | Use version folder/syntax in test spec file (use section headers instead) |
+| **Never** | Skip error path — each endpoint needs cover validation errors |
+
+## Actions
+
+### Step 1 — Locate Inputs
+
+`$ARGUMENTS` is path to:
+- API Spec file (OpenAPI 3.0 JSON/YAML, Markdown)
+- Or Story ID — glob find `docs/epics/**/Story-{ID}*.md`
+- Or path to API code project to analyze
+
+If not provided → ask user:
+```
+Enter input for /tas-apitest-plan:
+1. Path to API Spec file (OpenAPI/Markdown/YAML)
+2. Story ID (to find spec link in Story)
+3. Path to API code to auto-analyze
+```
+
+### Step 2 — Detect Existing Test Spec
+
+Glob find `docs/tests/API-Test-Spec-*.md`.
+
+- **Found**: Read file, detect existing versions (find section headers `## v{N}`)
+- **Not found**: Create new with version v1
+
+### Step 3 — Parse Input
+
+**If API Spec file:**
+- Read and parse OpenAPI/Markdown/YAML
+- Collect for each endpoint:
+  - HTTP method + path, path/query params, request body schema
+  - Response schemas per status code
+  - Auth requirement, description/summary
+  - Tags to group endpoints
+
+**If Story:**
+- Read Story to find spec link in `## Technical Plan` or `## Acceptance Criteria`
+- Parse spec as above
+- Add AC mapping to test spec
+
+**If code path:**
+- Glob find controller/handler files (`.cs`, `.ts`, `.py` per stack)
+- Analyze attributes/routes to detect endpoints
+- Extract DTO classes to know request/response schema
+- Ask user confirm if detection unclear
+
+### Step 4 — Detect API Version
+
+Prioritize in order:
+1. `info.version` in OpenAPI
+2. Prefix in URL path (v1/, v2/)
+3. Ask user
+
+Version format: `v1`, `v2` (no dot).
+
+### Step 5 — Determine Output Path
+
+Output: `docs/tests/API-Test-Spec-{slug}.md`
+
+**Slug generation:**
+- From `api_name` in spec → lowercase, replace spaces with dashes
+- Or ask user for short slug (e.g., `users`, `orders`, `products`)
+
+### Step 6 — Determine Update Mode
+
+If spec file exists and version already exists:
+- **Append mode** (default): add new test cases to end of current version section
+- Ask user if want new version (v2, v3...):
+
+```
+Spec file already exists with version {current}. You want:
+1. Append test cases to version {current} (default)
+2. Create new version (v{next}) for test cases
+```
+
+### Step 7 — Generate Test Spec
+
+Read template `.tas/templates/API-Test-Spec.md` for structure.
+
+**Analyze endpoints to create coverage matrix:**
+
+For each endpoint, generate test cases for:
+1. **Happy path** (2xx) — always have
+2. **Unauthorized** (401) — if endpoint requires auth
+3. **Forbidden** (403) — if has RBAC/ownership check
+4. **Not found** (404) — if has path param
+5. **Validation error** (400/422) — if has required fields or business rules
+6. **Business rules** — from Story ACs or 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} (if any)
+- **Test Method Name**: `{Method}_{Resource}_Returns{Status}_When{Condition}`
+```
+
+### Step 8 — Write Test Spec File
+
+**File doesn't exist:** Create new from template.
+
+**File exists (append mode):**
+- Read current file
+- Find section `## v{N}` being worked on
+- Append new test cases to end of section before `## Version History` or `## Changelog`
+- Preserve all old content
+
+### Step 9 — Summary
+
+Display:
+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` to 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/`
+```
+
+## Final Step — Token Log
+
+Invoke skill `token-logger`: write AI Usage Log to test spec file.