690603:2041 ADR-034-134 #01
This commit is contained in:
@@ -0,0 +1,86 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Run the full speckit pipeline from specification to analysis in one command.
|
||||
---
|
||||
|
||||
# Workflow: speckit.all
|
||||
|
||||
This meta-workflow orchestrates the **complete development lifecycle**, from specification through implementation and validation. For the preparation-only pipeline (steps 1-5), use `/speckit.prepare` instead.
|
||||
|
||||
## Preparation Phase (Steps 1-5)
|
||||
|
||||
1. **Specify** (`/speckit.specify`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-specify/SKILL.md`
|
||||
- Execute with user's feature description
|
||||
- Creates: `spec.md`
|
||||
|
||||
2. **Clarify** (`/speckit.clarify`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-clarify/SKILL.md`
|
||||
- Execute to resolve ambiguities
|
||||
- Updates: `spec.md`
|
||||
|
||||
3. **Plan** (`/speckit.plan`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-plan/SKILL.md`
|
||||
- Execute to create technical design
|
||||
- Creates: `plan.md`
|
||||
|
||||
4. **Tasks** (`/speckit.tasks`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-tasks/SKILL.md`
|
||||
- Execute to generate task breakdown
|
||||
- Creates: `tasks.md`
|
||||
|
||||
5. **Analyze** (`/speckit.analyze`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-analyze/SKILL.md`
|
||||
- Execute to validate consistency across spec, plan, and tasks
|
||||
- Output: Analysis report
|
||||
- **Gate**: If critical issues found, stop and fix before proceeding
|
||||
|
||||
## Implementation Phase (Steps 6-7)
|
||||
|
||||
6. **Implement** (`/speckit.implement`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-implement/SKILL.md`
|
||||
- Execute all tasks from `tasks.md` with anti-regression protocols
|
||||
- Output: Working implementation
|
||||
|
||||
7. **Check** (`/speckit.checker`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-checker/SKILL.md`
|
||||
- Run static analysis (linters, type checkers, security scanners)
|
||||
- Output: Checker report
|
||||
|
||||
## Verification Phase (Steps 8-10)
|
||||
|
||||
8. **Test** (`/speckit.tester`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-tester/SKILL.md`
|
||||
- Run tests with coverage
|
||||
- Output: Test + coverage report
|
||||
|
||||
9. **Review** (`/speckit.reviewer`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-reviewer/SKILL.md`
|
||||
- Perform code review
|
||||
- Output: Review report with findings
|
||||
|
||||
10. **Validate** (`/speckit.validate`):
|
||||
- Use the `view_file` tool to read: `.agents/skills/speckit-validate/SKILL.md`
|
||||
- Verify implementation matches spec requirements
|
||||
- Output: Validation report (pass/fail)
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/speckit.all "Build a user authentication system with OAuth2 support"
|
||||
```
|
||||
|
||||
## Pipeline Comparison
|
||||
|
||||
| Pipeline | Steps | Use When |
|
||||
| ------------------ | ------------------------- | -------------------------------------- |
|
||||
| `/speckit.prepare` | 1-5 (Specify → Analyze) | Planning only — you'll implement later |
|
||||
| `/speckit.all` | 1-10 (Specify → Validate) | Full lifecycle in one pass |
|
||||
|
||||
## On Error
|
||||
|
||||
If any step fails, stop the pipeline and report:
|
||||
|
||||
- Which step failed
|
||||
- The error message
|
||||
- Suggested remediation (e.g., "Run `/speckit.clarify` to resolve ambiguities before continuing")
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Execute the full preparation pipeline (Specify -> Clarify -> Plan -> Tasks -> Analyze) in sequence.
|
||||
---
|
||||
|
||||
# Workflow: speckit.prepare
|
||||
|
||||
This workflow orchestrates the sequential execution of the Speckit preparation phase skills (02-06).
|
||||
|
||||
1. **Step 1: Specify (Skill 02)**
|
||||
- Goal: Create or update the `spec.md` based on user input.
|
||||
- Action: Read and execute `.agents/skills/speckit-specify/SKILL.md`.
|
||||
|
||||
2. **Step 2: Clarify (Skill 03)**
|
||||
- Goal: Refine the `spec.md` by identifying and resolving ambiguities.
|
||||
- Action: Read and execute `.agents/skills/speckit-clarify/SKILL.md`.
|
||||
|
||||
3. **Step 3: Plan (Skill 04)**
|
||||
- Goal: Generate `plan.md` from the finalized spec.
|
||||
- Action: Read and execute `.agents/skills/speckit-plan/SKILL.md`.
|
||||
|
||||
4. **Step 4: Tasks (Skill 05)**
|
||||
- Goal: Generate actionable `tasks.md` from the plan.
|
||||
- Action: Read and execute `.agents/skills/speckit-tasks/SKILL.md`.
|
||||
|
||||
5. **Step 5: Analyze (Skill 06)**
|
||||
- Goal: Validate consistency across all design artifacts (spec, plan, tasks).
|
||||
- Action: Read and execute `.agents/skills/speckit-analyze/SKILL.md`.
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
|
||||
---
|
||||
|
||||
# Workflow: speckit.constitution
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-constitution/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `.specify/` directory doesn't exist: Initialize the speckit structure first
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Create or update the feature specification from a natural language feature description.
|
||||
---
|
||||
|
||||
# Workflow: speckit.specify
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
- This is typically the starting point of a new feature.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-specify/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the feature description for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If no feature description provided: Ask the user to describe the feature they want to specify
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
|
||||
---
|
||||
|
||||
# Workflow: speckit.clarify
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-clarify/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `spec.md` is missing: Run `/speckit.specify` first to create the feature specification
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Execute the implementation planning workflow using the plan template to generate design artifacts.
|
||||
---
|
||||
|
||||
# Workflow: speckit.plan
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-plan/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `spec.md` is missing: Run `/speckit.specify` first to create the feature specification
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
|
||||
---
|
||||
|
||||
# Workflow: speckit.tasks
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-tasks/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `plan.md` is missing: Run `/speckit.plan` first
|
||||
- If `spec.md` is missing: Run `/speckit.specify` first
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
|
||||
---
|
||||
|
||||
// turbo-all
|
||||
|
||||
# Workflow: speckit.analyze
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-analyze/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `spec.md` is missing: Run `/speckit.specify` first
|
||||
- If `plan.md` is missing: Run `/speckit.plan` first
|
||||
- If `tasks.md` is missing: Run `/speckit.tasks` first
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
|
||||
---
|
||||
|
||||
# Workflow: speckit.implement
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-implement/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `tasks.md` is missing: Run `/speckit.tasks` first
|
||||
- If `plan.md` is missing: Run `/speckit.plan` first
|
||||
- If `spec.md` is missing: Run `/speckit.specify` first
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Run static analysis tools and aggregate results.
|
||||
---
|
||||
|
||||
// turbo-all
|
||||
|
||||
# Workflow: speckit.checker
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user may specify paths to check or run on entire project.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-checker/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If no linting tools available: Report which tools to install based on project type
|
||||
- If tools fail: Show raw error and suggest config fixes
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Execute tests, measure coverage, and report results.
|
||||
---
|
||||
|
||||
// turbo-all
|
||||
|
||||
# Workflow: speckit.tester
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user may specify test paths, options, or just run all tests.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-tester/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If no test framework detected: Report "No test framework found. Install Jest, Vitest, Pytest, or similar."
|
||||
- If tests fail: Show failure details and suggest fixes
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Perform code review with actionable feedback and suggestions.
|
||||
---
|
||||
|
||||
# Workflow: speckit.reviewer
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user may specify files to review, "staged" for git staged changes, or "branch" for branch diff.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-reviewer/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If no files to review: Ask user to stage changes or specify file paths
|
||||
- If not a git repo: Review current directory files instead
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Validate that implementation matches specification requirements.
|
||||
---
|
||||
|
||||
# Workflow: speckit.validate
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-validate/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `tasks.md` is missing: Run `/speckit.tasks` first
|
||||
- If implementation not started: Run `/speckit.implement` first
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Perform a security-focused audit of the codebase against OWASP Top 10, CASL authorization, and LCBP3-DMS security requirements.
|
||||
---
|
||||
|
||||
# Workflow: speckit.security-audit
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user may pass a scope hint: `backend`, `frontend`, `both`, or specific module paths (defaults to `both`).
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-security-audit/SKILL.md`
|
||||
- Also load `.agents/skills/_LCBP3-CONTEXT.md` for project-specific rules.
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- This is READ-ONLY — never modify code during the audit.
|
||||
- Output a structured report with Critical / High / Medium / Low severity.
|
||||
|
||||
4. **On Error**:
|
||||
- If scope unclear: Default to `both` (backend + frontend)
|
||||
- If `specs/06-Decision-Records/ADR-016-security-authentication.md` missing: Warn and proceed with OWASP Top 10 + CASL checks only
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Quick bugfix workflow with minimal impact. Focused on surgical fixes without unrelated refactoring.
|
||||
---
|
||||
|
||||
# Workflow: bugfix
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has reported a bug. Treat the bug description or logs as the primary input.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/bugfix/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Phases: Analysis → Planning → Execution → Finalization
|
||||
|
||||
4. **Safety Check**:
|
||||
- Always ensure Tier 1 rules (Security, UUID v7, DB Schema) are NOT violated.
|
||||
- Refer to `AGENTS.md` for the full list of forbidden patterns.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Manual real-app verification — ตรวจแอปจริงหลัง build pass เพื่อยืนยันว่าทำงานถูกต้องใน environment จริง (ไม่ใช่แค่ unit test)
|
||||
---
|
||||
|
||||
# Workflow: check-real-app
|
||||
|
||||
ใช้เมื่อ build/lint/test ผ่านแล้ว แต่ต้องการยืนยันว่าแอปจริงทำงานถูกต้อง
|
||||
เน้นการตรวจที่ unit test ตรวจไม่ได้: UI flow, API response จริง, console errors, network requests
|
||||
|
||||
## ขั้นตอน
|
||||
|
||||
### 1. เริ่ม Dev Server (ถ้ายังไม่รัน)
|
||||
|
||||
ตรวจก่อนว่ามี dev server รันอยู่แล้วหรือไม่ เพื่อป้องกันรันซ้ำ:
|
||||
|
||||
```bash
|
||||
# Backend
|
||||
pnpm --filter backend run start:dev
|
||||
|
||||
# Frontend
|
||||
pnpm --filter frontend run dev
|
||||
```
|
||||
|
||||
### 2. ตรวจ Endpoint / หน้าที่เปลี่ยน
|
||||
|
||||
- เปิด URL ที่เกี่ยวข้องกับงานที่เพิ่ง implement
|
||||
- ตรวจ API endpoint ด้วย curl หรือ browser dev tools
|
||||
- ดู network tab ว่า request/response ถูกต้อง
|
||||
|
||||
```bash
|
||||
# ตัวอย่างตรวจ API จริง
|
||||
curl -X GET http://localhost:3001/api/[endpoint] \
|
||||
-H "Authorization: Bearer <token>" | jq .
|
||||
```
|
||||
|
||||
### 3. ตรวจ Console / Log
|
||||
|
||||
- **Frontend**: เปิด browser DevTools → Console tab — ต้องไม่มี error หรือ warning ที่ไม่คาดเดา
|
||||
- **Backend**: ดู terminal log — ตรวจว่าไม่มี unhandled exception หรือ SQL error
|
||||
|
||||
### 4. ตรวจ Happy Path + Edge Case หลัก
|
||||
|
||||
ตรวจ flow ที่เกี่ยวข้องอย่างน้อย:
|
||||
- [ ] Happy path ทำงานถูกต้อง
|
||||
- [ ] Input ผิดรูปแบบ → แสดง error message ที่เหมาะสม
|
||||
- [ ] Unauthorized access → redirect/403 ถูกต้อง
|
||||
- [ ] หน้าที่ไม่ได้แก้ยังทำงานปกติ (regression check)
|
||||
|
||||
### 5. ตรวจ NAP-DMS Specific
|
||||
|
||||
- [ ] UUID ใน URL และ response เป็น string format ถูกต้อง (ไม่ใช่ integer)
|
||||
- [ ] ไม่มี `NaN` หรือ `undefined` ใน form values หรือ API payload
|
||||
- [ ] Thai/English text แสดงผลถูกต้อง (i18n)
|
||||
- [ ] RBAC: role ที่ไม่มีสิทธิ์ไม่เห็น/เข้าถึงไม่ได้
|
||||
|
||||
## 🚫 No Fake Evidence Rule
|
||||
|
||||
> **ห้ามรายงานว่าตรวจแอปจริงแล้ว ถ้าไม่ได้เปิดแอปและตรวจจริง**
|
||||
> ถ้าตรวจไม่ได้ (เช่น ไม่มี DB, ไม่มี token) ให้ระบุเหตุผลชัดเจน
|
||||
|
||||
## ✅ Mandatory Output
|
||||
|
||||
รายงานท้ายงานต้องมีครบ:
|
||||
|
||||
### Commands run
|
||||
```
|
||||
✅ curl GET /api/correspondences → 200 OK, returned 3 records
|
||||
✅ curl POST /api/correspondences → 201 Created, uuid: "019..."
|
||||
❌ ไม่ได้ตรวจ: file upload flow → เหตุผล: ต้องการ ClamAV service ที่ไม่มีใน local
|
||||
```
|
||||
|
||||
### Evidence
|
||||
- URL ที่ตรวจ + HTTP status code
|
||||
- Screenshot หรือ response body (ถ้า sensitive ให้ mask)
|
||||
- Console log ที่พบ (ถ้ามี error ต้องระบุ)
|
||||
|
||||
### Limitations / Risks
|
||||
- flow หรือ endpoint ที่ยังไม่ได้ตรวจ + เหตุผล
|
||||
- ความเสี่ยงที่ควรตรวจใน staging ก่อน deploy
|
||||
|
||||
### Next steps
|
||||
- งานที่ต้องทำต่อ หรือ flag สำหรับ QA
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Create a new NestJS backend feature module following project standards
|
||||
---
|
||||
|
||||
# Create NestJS Backend Module
|
||||
|
||||
Use this workflow when creating a new feature module in `backend/src/modules/`.
|
||||
Follows `specs/05-Engineering-Guidelines/05-02-backend-guidelines.md` and ADR-005.
|
||||
|
||||
## Steps
|
||||
|
||||
// turbo
|
||||
|
||||
1. **Verify requirements exist** — confirm the feature is in `specs/01-Requirements/` before starting
|
||||
|
||||
// turbo 2. **Check schema** — read `specs/03-Data-and-Storage/lcbp3-v1.8.0-schema.sql` for relevant tables
|
||||
|
||||
3. **Scaffold module folder**
|
||||
|
||||
```
|
||||
backend/src/modules/<module-name>/
|
||||
├── <module-name>.module.ts
|
||||
├── <module-name>.controller.ts
|
||||
├── <module-name>.service.ts
|
||||
├── dto/
|
||||
│ ├── create-<module-name>.dto.ts
|
||||
│ └── update-<module-name>.dto.ts
|
||||
├── entities/
|
||||
│ └── <module-name>.entity.ts
|
||||
└── <module-name>.controller.spec.ts
|
||||
```
|
||||
|
||||
// turbo 4. **Create Entity** — map ONLY columns defined in the schema SQL. Use TypeORM decorators. Add `@VersionColumn()` if the entity needs optimistic locking.
|
||||
|
||||
// turbo 5. **Create DTOs** — use `class-validator` decorators. Never use `any`. Validate all inputs.
|
||||
|
||||
// turbo 6. **Create Service** — inject repository via constructor DI. Use transactions for multi-step writes. Add `Idempotency-Key` guard for POST/PUT/PATCH operations.
|
||||
|
||||
// turbo 7. **Create Controller** — apply `@UseGuards(JwtAuthGuard, CaslAbilityGuard)`. Use proper HTTP status codes. Document with `@ApiTags` and `@ApiOperation`.
|
||||
|
||||
// turbo 8. **Register in Module** — add to `imports`, `providers`, `controllers`, `exports` as needed.
|
||||
|
||||
// turbo 9. **Register in AppModule** — import the new module in `app.module.ts`.
|
||||
|
||||
// turbo 10. **Write unit test** — cover service methods with Jest mocks. Run:
|
||||
|
||||
```bash
|
||||
pnpm test:watch
|
||||
```
|
||||
|
||||
// turbo 11. **Citation** — confirm implementation references `specs/01-Requirements/` and `specs/05-Engineering-Guidelines/05-02-backend-guidelines.md`
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Create a new Next.js App Router page following project standards
|
||||
---
|
||||
|
||||
# Create Next.js Frontend Page
|
||||
|
||||
Use this workflow when creating a new page in `frontend/app/`.
|
||||
Follows `specs/05-Engineering-Guidelines/05-03-frontend-guidelines.md`, ADR-011, ADR-012, ADR-013, ADR-014.
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Determine route** — decide the route path, e.g. `app/(dashboard)/documents/page.tsx`
|
||||
|
||||
2. **Classify components** — decide what is Server Component (default) vs Client Component (`'use client'`)
|
||||
- Server Component: initial data load, static content, SEO
|
||||
- Client Component: interactivity, forms, TanStack Query hooks, Zustand
|
||||
|
||||
3. **Create page file** — Server Component by default:
|
||||
|
||||
```typescript
|
||||
// app/(dashboard)/<route>/page.tsx
|
||||
import { Metadata } from 'next';
|
||||
|
||||
export const metadata: Metadata = {
|
||||
title: '<Page Title> | LCBP3-DMS',
|
||||
};
|
||||
|
||||
export default async function <PageName>Page() {
|
||||
return (
|
||||
<div>
|
||||
{/* Page content */}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
4. **Create API hook** (if client-side data needed) — add to `hooks/use-<feature>.ts`:
|
||||
|
||||
```typescript
|
||||
'use client';
|
||||
import { useQuery } from '@tanstack/react-query';
|
||||
import { apiClient } from '@/lib/api-client';
|
||||
|
||||
export function use<Feature>() {
|
||||
return useQuery({
|
||||
queryKey: ['<feature>'],
|
||||
queryFn: () => apiClient.get('<endpoint>'),
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
5. **Build UI components** — use Shadcn/UI primitives. Place reusable components in `components/<feature>/`.
|
||||
|
||||
6. **Handle forms** — use React Hook Form + Zod schema validation. Never access form values without validation.
|
||||
|
||||
7. **Handle errors** — add `error.tsx` alongside `page.tsx` for route-level error boundaries.
|
||||
|
||||
8. **Add loading state** — add `loading.tsx` for Suspense fallback if page does async work.
|
||||
|
||||
9. **Add to navigation** — update sidebar/nav config if the page should appear in the menu.
|
||||
|
||||
10. **Access control** — ensure page checks CASL permissions. Redirect unauthorized users via middleware or `notFound()`.
|
||||
|
||||
11. **Citation** — confirm implementation references `specs/01-Requirements/` and `specs/05-Engineering-Guidelines/05-03-frontend-guidelines.md`
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Deploy the application via Gitea Actions to QNAP Container Station
|
||||
---
|
||||
|
||||
# Deploy to Production
|
||||
|
||||
Use this workflow to deploy updated backend and/or frontend to QNAP via Gitea Actions CI/CD.
|
||||
Follows `specs/04-Infrastructure-OPS/` and ADR-015.
|
||||
|
||||
## Pre-deployment Checklist
|
||||
|
||||
- [ ] All tests pass locally (`pnpm test:watch`)
|
||||
- [ ] No TypeScript errors (`tsc --noEmit`)
|
||||
- [ ] No `any` types introduced
|
||||
- [ ] Schema changes applied to `specs/03-Data-and-Storage/lcbp3-v1.7.0-schema.sql`
|
||||
- [ ] Environment variables documented (NOT in `.env` files)
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Commit and push to Gitea**
|
||||
|
||||
```bash
|
||||
git status
|
||||
git add .
|
||||
git commit -m "feat(<scope>): <description>"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
2. **Monitor Gitea Actions** — open Gitea web UI → Actions tab → verify pipeline starts
|
||||
|
||||
3. **Pipeline stages (automatic)**
|
||||
- `build-backend` → Docker image build + push to registry
|
||||
- `build-frontend` → Docker image build + push to registry
|
||||
- `deploy` → SSH to QNAP → `docker compose pull` + `docker compose up -d`
|
||||
|
||||
4. **Verify backend health**
|
||||
|
||||
```bash
|
||||
curl http://<QNAP_IP>:3000/health
|
||||
# Expected: { "status": "ok" }
|
||||
```
|
||||
|
||||
5. **Verify frontend**
|
||||
|
||||
```bash
|
||||
curl -I http://<QNAP_IP>:3001
|
||||
# Expected: HTTP 200
|
||||
```
|
||||
|
||||
6. **Check logs in Grafana** — navigate to Grafana → Loki → filter by container name
|
||||
- Backend: `container_name="lcbp3-backend"`
|
||||
- Frontend: `container_name="lcbp3-frontend"`
|
||||
|
||||
7. **Verify database** — confirm schema changes are reflected (if any)
|
||||
|
||||
8. **Rollback (if needed)**
|
||||
|
||||
```bash
|
||||
# SSH into QNAP
|
||||
docker compose pull <service>=<previous-image-tag>
|
||||
docker compose up -d <service>
|
||||
```
|
||||
|
||||
## Common Issues
|
||||
|
||||
| Symptom | Cause | Fix |
|
||||
| ----------------- | --------------------- | ----------------------------------- |
|
||||
| Backend unhealthy | DB connection failed | Check MariaDB container + env vars |
|
||||
| Frontend blank | Build error | Check Next.js build logs in Grafana |
|
||||
| 502 Bad Gateway | Container not started | `docker compose ps` to check status |
|
||||
| Pipeline stuck | Gitea runner offline | Restart runner on QNAP |
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test.
|
||||
---
|
||||
|
||||
# Workflow: diagnose
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided a bug report or performance regression. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/diagnose/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Execute phases: Build feedback loop → Reproduce → Hypothesise → Instrument → Fix → Regression test → Cleanup
|
||||
|
||||
4. **On Error**:
|
||||
- If cannot build a feedback loop: Ask user for environment access, captured artifacts, or production instrumentation
|
||||
- If no correct seam for regression test: Flag architectural issues to improve-codebase-architecture
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Playwright E2E testing patterns, Page Object Model, configuration, CI/CD integration, artifact management, and flaky test strategies for LCBP3-DMS
|
||||
---
|
||||
|
||||
This workflow invokes the e2e-testing skill to help with Playwright E2E testing patterns for LCBP3-DMS.
|
||||
|
||||
Invoke the e2e-testing skill when:
|
||||
- Creating new E2E tests for frontend features
|
||||
- Debugging flaky Playwright tests
|
||||
- Setting up CI/CD integration for E2E tests
|
||||
- Optimizing test performance and reliability
|
||||
- Implementing Page Object Model (POM) patterns
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise.
|
||||
---
|
||||
|
||||
# Workflow: grill-with-docs
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided a plan to stress-test. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/grill-with-docs/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Ask questions one at a time, waiting for feedback before continuing.
|
||||
- Update CONTEXT.md and ADRs inline as terms are resolved.
|
||||
|
||||
4. **On Error**:
|
||||
- If CONTEXT.md or docs/adr/ don't exist: Create them lazily when first term is resolved
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Resume pending multi-session work — อ่าน context เดิม, หา last checkpoint, สรุปสถานะปัจจุบัน และวางแผนต่อ โดยไม่ทำงานซ้ำ
|
||||
---
|
||||
|
||||
# Workflow: resume-pending-work
|
||||
|
||||
ใช้เมื่อกลับมาทำงานที่ค้างไว้ข้าม session — เช่น งานใหญ่ที่แบ่งเป็น phase, งาน migration, หรืองานที่หยุดกลางคัน
|
||||
|
||||
## ขั้นตอน
|
||||
|
||||
### 1. อ่าน Context เดิม
|
||||
|
||||
ตรวจแหล่งข้อมูลเหล่านี้ตามลำดับ:
|
||||
|
||||
```
|
||||
1. Memory system — ดู system-retrieved memories ที่เกี่ยวข้อง
|
||||
2. specs/200-fullstacks/<feature>/tasks.md — ดู task status ล่าสุด
|
||||
3. git log --oneline -20 — ดู commits ล่าสุด
|
||||
4. progress.txt หรือ PROGRESS.md (ถ้ามี) — ดู notes ที่ทิ้งไว้
|
||||
```
|
||||
|
||||
### 2. หา Last Checkpoint
|
||||
|
||||
ระบุให้ชัดว่า:
|
||||
- **ทำไปถึงไหนแล้ว** — phase/task/file ที่ complete แล้ว
|
||||
- **ค้างอยู่ที่ไหน** — step ที่กำลังทำอยู่ตอนหยุด
|
||||
- **ยังไม่ได้ทำอะไร** — tasks ที่เหลือ
|
||||
|
||||
### 3. ตรวจสถานะ Build ปัจจุบัน
|
||||
|
||||
ก่อนทำงานต่อ ต้องรู้ว่า codebase ปัจจุบัน clean หรือไม่:
|
||||
|
||||
```bash
|
||||
# ตรวจ TypeScript errors
|
||||
pnpm --filter backend run build 2>&1 | tail -20
|
||||
pnpm --filter frontend run build 2>&1 | tail -20
|
||||
|
||||
# ดู uncommitted changes
|
||||
git status --short
|
||||
git diff --stat HEAD
|
||||
```
|
||||
|
||||
### 4. สรุปสถานะและวางแผนต่อ
|
||||
|
||||
ก่อนลงมือ ให้สรุปให้ผู้ใช้เห็นก่อน:
|
||||
|
||||
```
|
||||
✅ เสร็จแล้ว:
|
||||
- Phase 1: Entity + Migration (commit abc1234)
|
||||
- Phase 2: Service layer (commit def5678)
|
||||
|
||||
🔄 ค้างอยู่:
|
||||
- Phase 3: Controller — เขียนครึ่งนึง, ยังไม่มี tests
|
||||
|
||||
⏳ ยังไม่ได้ทำ:
|
||||
- Phase 4: Frontend integration
|
||||
- Phase 5: E2E tests
|
||||
|
||||
🚩 Issues ที่พบ:
|
||||
- build error ที่ correspondence.service.ts:142
|
||||
```
|
||||
|
||||
จากนั้นถามผู้ใช้ว่าต้องการ:
|
||||
- ทำงานต่อจาก checkpoint เดิม
|
||||
- Skip ขั้นตอนที่ค้าง (พร้อมระบุ risk)
|
||||
- Re-verify งานที่ทำไปแล้วก่อน
|
||||
|
||||
### 5. ตรวจ NAP-DMS Specific
|
||||
|
||||
ก่อน resume ให้ตรวจ:
|
||||
- [ ] ADR ที่เกี่ยวข้องยังไม่เปลี่ยนแปลง (ดู git log ที่ `specs/06-Decision-Records/`)
|
||||
- [ ] Schema ที่ใช้อยู่ตรงกับ `lcbp3-v1.9.0-schema-02-tables.sql`
|
||||
- [ ] ไม่มี merge conflict หรือ stash ค้าง
|
||||
|
||||
## 🚫 No Fake Resume Rule
|
||||
|
||||
> **ห้ามบอกว่า "ทำต่อจากตรงนี้" โดยไม่ได้อ่าน context เดิมจริง**
|
||||
> ต้องระบุหลักฐานที่ชัดเจนว่า checkpoint อยู่ที่ไหน
|
||||
|
||||
## ✅ Mandatory Output
|
||||
|
||||
### Last checkpoint summary
|
||||
```
|
||||
- เสร็จแล้ว: [phase/commit/task]
|
||||
- ค้างอยู่: [file:line หรือ task ที่หยุด]
|
||||
- ยังไม่ได้ทำ: [tasks ที่เหลือ]
|
||||
```
|
||||
|
||||
### Build status
|
||||
```
|
||||
✅ backend build → clean
|
||||
❌ frontend build → 2 errors (ระบุ errors)
|
||||
```
|
||||
|
||||
### Plan ต่อ
|
||||
แผน 3-5 ข้อที่จะทำในส่วนที่เหลือ พร้อม verification method
|
||||
|
||||
### Risks / Blockers
|
||||
สิ่งที่อาจ block งาน หรือต้องระวังก่อนทำต่อ
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Review code changes for bugs, security issues, and improvements
|
||||
---
|
||||
|
||||
You are a senior software engineer performing a thorough code review to identify potential bugs.
|
||||
|
||||
Your task is to find all potential bugs and code improvements in the code changes. Focus on:
|
||||
|
||||
1. Logic errors and incorrect behavior
|
||||
2. Edge cases that aren't handled
|
||||
3. Null/undefined reference issues
|
||||
4. Race conditions or concurrency issues
|
||||
5. Security vulnerabilities
|
||||
6. Improper resource management or resource leaks
|
||||
7. API contract violations
|
||||
8. Incorrect caching behavior, including cache staleness issues, cache key-related bugs, incorrect cache invalidation, and ineffective caching
|
||||
9. Violations of existing code patterns or conventions
|
||||
|
||||
## 🔴 Tier 1 Critical Rules (CI Blockers)
|
||||
|
||||
The following are **CI-blocking issues** that must be caught in code review. These align with project specs in `specs/05-Engineering-Guidelines/` and `specs/06-Decision-Records/`:
|
||||
|
||||
### ADR-019: UUID Handling
|
||||
|
||||
- **❌ NEVER use `parseInt()`, `Number()`, or `+` operator on UUID values**
|
||||
- Example of violation: `parseInt(projectId)` where `projectId` is UUID string
|
||||
- ✅ Correct: Use UUID string directly without conversion
|
||||
- **❌ NEVER expose internal INT PK in API responses**
|
||||
- API must expose only `publicId` (transformed to `id` via `@Expose()`)
|
||||
- Verify DTOs have `@Exclude()` on `id: number` field
|
||||
|
||||
### TypeScript Strict Rules
|
||||
|
||||
- **❌ ZERO `any` types allowed** — use proper types or `unknown` + narrowing
|
||||
- **❌ ZERO `console.log`** — must use NestJS `Logger` (backend) or remove (frontend)
|
||||
- **❌ NO `req: any` in controllers** — use `RequestWithUser` typed interface
|
||||
|
||||
### Database & Architecture
|
||||
|
||||
- **❌ NO SQL Triggers for business logic** — use NestJS Service methods instead
|
||||
- **❌ NO `.env` files in production** — use Docker environment variables
|
||||
- **❌ NO direct table/column name invention** — verify against `specs/03-Data-and-Storage/lcbp3-v1.9.0-schema-02-tables.sql`
|
||||
|
||||
### Security (ADR-016)
|
||||
|
||||
- Idempotency validation for critical `POST`/`PUT`/`PATCH` endpoints
|
||||
- Two-phase file upload pattern (Upload → Temp → Commit → Permanent)
|
||||
- Input validation with class-validator (backend) and Zod (frontend)
|
||||
|
||||
### Test Coverage Requirements
|
||||
|
||||
- **Backend Services:** 80% minimum
|
||||
- **Backend Overall:** 70% minimum
|
||||
- **Business Logic:** 80% minimum
|
||||
|
||||
Make sure to:
|
||||
|
||||
1. If exploring the codebase, call multiple tools in parallel for increased efficiency. Do not spend too much time exploring.
|
||||
2. If you find any pre-existing bugs in the code, you should also report those since it's important for us to maintain general code quality for the user.
|
||||
3. Do NOT report issues that are speculative or low-confidence. All your conclusions should be based on a complete understanding of the codebase.
|
||||
4. Remember that if you were given a specific git commit, it may not be checked out and local code states may be different.
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Manage database schema changes following ADR-009 (no migrations, modify SQL directly)
|
||||
---
|
||||
|
||||
# Schema Change Workflow
|
||||
|
||||
Use this workflow when modifying database schema for LCBP3-DMS.
|
||||
Follows `specs/06-Decision-Records/ADR-009-database-strategy.md` — **NO TypeORM migrations**.
|
||||
|
||||
## Pre-Change Checklist
|
||||
|
||||
- [ ] Change is required by a spec in `specs/01-Requirements/`
|
||||
- [ ] Existing data impact has been assessed
|
||||
- [ ] No SQL triggers are being added (business logic in NestJS only)
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Read current schema** — load the full schema file:
|
||||
|
||||
```
|
||||
specs/03-Data-and-Storage/lcbp3-v1.8.0-schema.sql
|
||||
```
|
||||
|
||||
2. **Read data dictionary** — understand current field definitions:
|
||||
|
||||
```
|
||||
specs/03-Data-and-Storage/03-01-data-dictionary.md
|
||||
```
|
||||
|
||||
// turbo 3. **Identify impact scope** — determine which tables, columns, indexes, or constraints are affected. List:
|
||||
|
||||
- Tables being modified/created
|
||||
- Columns being added/renamed/dropped
|
||||
- Foreign key relationships affected
|
||||
- Indexes being added/modified
|
||||
- Seed data impact (if any)
|
||||
|
||||
4. **Modify schema SQL** — edit `specs/03-Data-and-Storage/lcbp3-v1.8.0-schema.sql`:
|
||||
- Add/modify table definitions
|
||||
- Maintain consistent formatting (uppercase SQL keywords, lowercase identifiers)
|
||||
- Add inline comments for new columns explaining purpose
|
||||
- Ensure `DEFAULT` values and `NOT NULL` constraints are correct
|
||||
- Add `version` column with `@VersionColumn()` marker comment if optimistic locking is needed
|
||||
|
||||
> [!CAUTION]
|
||||
> **NEVER use SQL Triggers.** All business logic must live in NestJS services.
|
||||
|
||||
5. **Update data dictionary** — edit `specs/03-Data-and-Storage/03-01-data-dictionary.md`:
|
||||
- Add new tables/columns with descriptions
|
||||
- Update data types and constraints
|
||||
- Document business rules for new fields
|
||||
- Add enum value definitions if applicable
|
||||
|
||||
6. **Update seed data** (if applicable):
|
||||
- `specs/03-Data-and-Storage/lcbp3-v1.8.0-seed-basic.sql` — for reference/lookup data
|
||||
- `specs/03-Data-and-Storage/lcbp3-v1.8.0-seed-permissions.sql` — for new CASL permissions
|
||||
|
||||
7. **Update TypeORM entity** — modify corresponding `backend/src/modules/<module>/entities/*.entity.ts`:
|
||||
- Map ONLY columns defined in schema SQL
|
||||
- Use correct TypeORM decorators (`@Column`, `@PrimaryGeneratedColumn`, `@ManyToOne`, etc.)
|
||||
- Add `@VersionColumn()` if optimistic locking is needed
|
||||
|
||||
8. **Update DTOs** — if new columns are exposed via API:
|
||||
- Add fields to `create-*.dto.ts` and/or `update-*.dto.ts`
|
||||
- Add `class-validator` decorators for all new fields
|
||||
- Never use `any` type
|
||||
|
||||
// turbo 9. **Run type check** — verify no TypeScript errors:
|
||||
|
||||
```bash
|
||||
cd backend && npx tsc --noEmit
|
||||
```
|
||||
|
||||
10. **Generate SQL diff** — create a summary of changes for the user to apply manually:
|
||||
|
||||
```
|
||||
-- Schema Change Summary
|
||||
-- Date: <current date>
|
||||
-- Feature: <feature name>
|
||||
-- Tables affected: <list>
|
||||
--
|
||||
-- ⚠️ Apply this SQL to the live database manually:
|
||||
|
||||
ALTER TABLE ...;
|
||||
-- or
|
||||
CREATE TABLE ...;
|
||||
```
|
||||
|
||||
11. **Notify user** — present the SQL diff and remind them:
|
||||
- Apply the SQL change to the live database manually
|
||||
- Verify the change doesn't break existing data
|
||||
- Run `pnpm test` after applying to confirm entity mappings work
|
||||
|
||||
## Common Patterns
|
||||
|
||||
| Change Type | Template |
|
||||
| ----------- | -------------------------------------------------------------- |
|
||||
| Add column | `ALTER TABLE \`table\` ADD COLUMN \`col\` TYPE DEFAULT value;` |
|
||||
| Add table | Full `CREATE TABLE` with constraints and indexes |
|
||||
| Add index | `CREATE INDEX \`idx_table_col\` ON \`table\` (\`col\`);` |
|
||||
| Add FK | `ALTER TABLE \`child\` ADD CONSTRAINT ... FOREIGN KEY ...` |
|
||||
| Add enum | Add to data dictionary + `ENUM('val1','val2')` in column def |
|
||||
|
||||
## On Error
|
||||
|
||||
- If schema SQL has syntax errors → fix and re-validate with `tsc --noEmit`
|
||||
- If entity mapping doesn't match schema → compare column-by-column against SQL
|
||||
- If seed data conflicts → check unique constraints and foreign keys
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Comprehensive security review for LCBP3-DMS with OWASP Top 10 checklist, ADR compliance, and automated security testing patterns
|
||||
---
|
||||
|
||||
This workflow invokes the security-review skill to perform comprehensive security review of LCBP3-DMS code changes.
|
||||
|
||||
Invoke the security-review skill when:
|
||||
- Implementing authentication or authorization
|
||||
- Handling user input or file uploads
|
||||
- Creating new API endpoints
|
||||
- Working with secrets or credentials
|
||||
- Integrating AI features (Ollama/Qdrant)
|
||||
- Storing or transmitting sensitive data
|
||||
- Integrating third-party APIs
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions red-green-refactor, wants integration tests, or asks for test-first development.
|
||||
---
|
||||
|
||||
# Workflow: tdd
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user wants to build features or fix bugs using TDD. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/tdd/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Plan → Tracer Bullet → Incremental Loop → Refactor
|
||||
- One test at a time, only enough code to pass current test.
|
||||
|
||||
4. **On Error**:
|
||||
- If interface changes are needed: Confirm with user first
|
||||
- If unsure which behaviors to test: Ask user to prioritize
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
|
||||
---
|
||||
|
||||
# Workflow: to-issues
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user wants to convert a plan into issues. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/to-issues/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Draft vertical slices (HITL or AFK) → Quiz user → Publish to issue tracker.
|
||||
- Each slice delivers a narrow but complete path through every layer.
|
||||
|
||||
4. **On Error**:
|
||||
- If issue tracker not configured: Run `/setup-matt-pocock-skills` first
|
||||
- If user wants different granularity: Iterate on slice sizes
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Turn the current conversation context into a PRD and publish it to the project issue tracker.
|
||||
---
|
||||
|
||||
# Workflow: to-prd
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user wants to create a PRD from the current context. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/to-prd/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Synthesize current conversation and codebase understanding into a PRD.
|
||||
- Do NOT interview the user - use existing knowledge.
|
||||
|
||||
4. **On Error**:
|
||||
- If issue tracker not configured: Run `/setup-matt-pocock-skills` first
|
||||
- If user expectations unclear: Confirm major modules with user
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
|
||||
---
|
||||
|
||||
# Workflow: triage
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user wants to triage issues. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/triage/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Show what needs attention OR Triage specific issue OR Quick state override.
|
||||
- Apply triage roles: bug/enhancement + needs-triage/needs-info/ready-for-agent/ready-for-human/wontfix.
|
||||
|
||||
4. **On Error**:
|
||||
- If issue tracker not configured: Run `/setup-matt-pocock-skills` first
|
||||
- If state roles conflict: Flag and ask maintainer before proceeding
|
||||
- If no reproduction possible: Mark as `needs-info`
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Generate a custom checklist for the current feature based on user requirements.
|
||||
---
|
||||
|
||||
# Workflow: speckit.checklist
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-checklist/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If `spec.md` is missing: Run `/speckit.specify` first to create the feature specification
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Compare two versions of a spec or plan to highlight changes.
|
||||
---
|
||||
|
||||
# Workflow: speckit.diff
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt (optional file paths or version references).
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-diff/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If no files to compare: Use current feature's `spec.md` vs git HEAD
|
||||
- If `spec.md` doesn't exist: Run `/speckit.specify` first
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Migrate existing projects into the speckit structure by generating spec.md, plan.md, and tasks.md from existing code.
|
||||
---
|
||||
|
||||
# Workflow: speckit.migrate
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt (path to analyze, feature name).
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-migrate/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If path doesn't exist: Ask user to provide valid directory path
|
||||
- If no code found: Report that no analyzable code was detected
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Challenge the specification with Socratic questioning to identify logical gaps, unhandled edge cases, and robustness issues.
|
||||
---
|
||||
|
||||
// turbo-all
|
||||
|
||||
# Workflow: speckit.quizme
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user has provided an input prompt. Treat this as the primary input for the skill.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-quizme/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If required files don't exist, inform the user which prerequisite workflow to run first (e.g., `/speckit.specify` to create `spec.md`).
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Display a dashboard showing feature status, completion percentage, and blockers.
|
||||
---
|
||||
|
||||
// turbo-all
|
||||
|
||||
# Workflow: speckit.status
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user may optionally specify a feature to focus on.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-status/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Apply the user's prompt as the input arguments/context for the skill's logic.
|
||||
|
||||
4. **On Error**:
|
||||
- If no features exist: Report "No features found. Run `/speckit.specify` to create your first feature."
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Convert existing tasks into actionable, dependency-ordered issues on Gitea for the current feature.
|
||||
---
|
||||
|
||||
# Workflow: speckit.taskstoissues
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user may pass filters (e.g., phase, priority). Default: convert all pending tasks.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/speckit-taskstoissues/SKILL.md`
|
||||
- Also load `.agents/skills/_LCBP3-CONTEXT.md` for project conventions (labels, commit format).
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Use Gitea API (not GitHub) — target `git.np-dms.work/np-dms/lcbp3`.
|
||||
- Apply LCBP3 labels: `spec`, `adr`, `security`, `ux`, `backend`, `frontend`, `schema`, etc.
|
||||
- Use commit-format-compatible issue titles (per `specs/05-Engineering-Guidelines/05-05-git-conventions.md`).
|
||||
|
||||
4. **On Error**:
|
||||
- If `tasks.md` missing: Run `/05-speckit.tasks` first
|
||||
- If Gitea credentials missing: Report to user and provide manual issue-creation template
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: A comprehensive verification system for LCBP3-DMS development sessions with build, type check, lint, test, security scan, and diff review phases
|
||||
---
|
||||
|
||||
This workflow invokes the verification-loop skill to perform comprehensive verification of LCBP3-DMS code changes.
|
||||
|
||||
Invoke the verification-loop skill when:
|
||||
|
||||
- After completing a feature or significant code change
|
||||
- Before creating a PR
|
||||
- When you want to ensure quality gates pass
|
||||
- After refactoring
|
||||
- Before deploying to staging/production
|
||||
|
||||
## 🚫 No Fake Evidence Rule
|
||||
|
||||
> **ห้ามรายงานว่า test ผ่าน / build สำเร็จ ถ้าไม่ได้รันจริง**
|
||||
> ถ้ารันไม่ได้ ให้ระบุเหตุผลอย่างชัดเจนแทน
|
||||
|
||||
## ✅ Mandatory Output (ทุก verification ต้องมีครบ)
|
||||
|
||||
รายงานท้ายงานต้องมี 5 หัวข้อนี้เสมอ:
|
||||
|
||||
### 1. Pipeline trace
|
||||
|
||||
ลำดับขั้นตอนที่ทำจริง: Understand → Plan → Execute → Verify → Handoff
|
||||
|
||||
### 2. Commands run
|
||||
|
||||
รายการคำสั่งที่รันจริงพร้อมผลสรุป:
|
||||
|
||||
```
|
||||
✅ pnpm run build → Pass (0 errors)
|
||||
✅ pnpm run lint → Pass (0 warnings)
|
||||
✅ pnpm run test → 42 passed, 0 failed
|
||||
❌ ไม่ได้รัน: e2e tests → เหตุผล: ต้องการ DB จริง, ไม่มีใน CI environment
|
||||
```
|
||||
|
||||
### 3. Verification / Evidence
|
||||
|
||||
หลักฐานจริง เช่น build output, test result, diff, screenshot, link
|
||||
|
||||
### 4. Limitations / Risks
|
||||
|
||||
สิ่งที่ยังไม่ได้ตรวจ, ความเสี่ยง, ข้อจำกัดของ environment
|
||||
|
||||
### 5. Next steps
|
||||
|
||||
งานที่ต้องทำต่อหลัง verification
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
auto_execution_mode: 0
|
||||
description: Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.
|
||||
---
|
||||
|
||||
# Workflow: zoom-out
|
||||
|
||||
1. **Context Analysis**:
|
||||
- The user is unfamiliar with a section of code or needs broader context. Treat this as the primary input.
|
||||
|
||||
2. **Load Skill**:
|
||||
- Use the `view_file` tool to read the skill file at: `.agents/skills/zoom-out/SKILL.md`
|
||||
|
||||
3. **Execute**:
|
||||
- Follow the instructions in the `SKILL.md` exactly.
|
||||
- Go up a layer of abstraction and give a map of all relevant modules and callers.
|
||||
- Use the project's domain glossary vocabulary.
|
||||
|
||||
4. **On Error**:
|
||||
- No specific error handling - this is an exploratory skill.
|
||||
Reference in New Issue
Block a user