[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CT84MWYRZ9FFFS4FTMVMNH":3,"skill-same:01M7CT84MWYRZ9FFFS4FTMVMNH":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":14,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M7CT84MWYRZ9FFFS4FTMVMNH","test-planner",null,"Author comprehensive Test Plan specifications compliant with ISO\u002FIEC\u002FIEEE 29119-3 standard (superseding IEEE 829) and E2E Testing Patterns, establishing testing pyramid ratios, fixture strategies, boundary edge cases, headless containerized E2E acceptance suites, and triple-gate quality metrics.","roychshao\u002Fhermes-multi-agent-sdlc","roychshao","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F80042326?v=4","01M7CT40S8BYSC0MNGP7XBSHZV","邵靖翔","01M7CT40SVAZD0C7JVDFSDGWJ8",0,"MIT","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fdev-tester\u002Fskills\u002Ftest-planner\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: test-planner\ndescription: \"Author comprehensive Test Plan specifications compliant with ISO\u002FIEC\u002FIEEE 29119-3 standard (superseding IEEE 829) and E2E Testing Patterns, establishing testing pyramid ratios, fixture strategies, boundary edge cases, headless containerized E2E acceptance suites, and triple-gate quality metrics.\"\nversion: 2.1.0\nauthor: Hermes Agent Team\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [testing, test-plan, iso-29119, ieee-829, e2e-testing-patterns, playwright, cypress, qa, sdet, verification]\n    related_skills: [e2e-testing-patterns, testing-patterns, srs-specifier, sdd-architect, delegate-software-engineering-team]\n---\n\n# Test Plan Specification Skill (ISO\u002FIEC\u002FIEEE 29119-3 & E2E Testing Patterns)\n\n## Overview\nProduce an authoritative **Test Plan** document compliant with **ISO\u002FIEC\u002FIEEE 29119-3:2021** (superseding legacy IEEE 829) and incorporating modern **E2E Testing Patterns** (Headless Playwright \u002F Cypress). The Test Plan defines test strategy, fixture architecture, boundary conditions, and full-stack containerized acceptance criteria for automated verification.\n\n## Role & Execution Timing\n- **Author**: **`dev-tester` (SDET)**\n- **When Created**: Early Stage 1 \u002F Phase 3 (immediately after `docs\u002Fsdd.md` is published by `dev-architech`).\n- **Target Output Path**: `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Ftest_plan.md`\n\n---\n\n## 📐 Testing Pyramid & Triple-Gate Quality Standard\n\n### 1. Pyramid Allocation\n- **Unit Tests (70%)**: Pure domain logic, model validations, helper utilities, schema serialization. Executed in milliseconds without external I\u002FO.\n- **Integration Tests (20%)**: API Routers, database transactions, dependency injection overrides, authentication & permission middlewares.\n- **End-to-End (E2E) Container Tests (10%)**: Real browser \u002F HTTP headless workflows executed against the live running Docker Compose stack (`http:\u002F\u002Flocalhost`).\n\n### 2. Triple-Gate Quality Standard (🚦 Triple-Gate Acceptance Iron Law)\n1. **Module Pass Rate Gate**: `failed == 0` and `errors == 0` (100% pass rate for unit and integration tests).\n2. **Code Coverage Gate**: Backend & frontend core logic coverage $\\ge 80\\%$.\n3. **Phase 6 Containerized E2E Gate**: 100% passing E2E acceptance suite executed in headless mode against the live running Docker Compose environment before project release.\n\n---\n\n## 🛠️ Step-by-Step Procedure\n\n### Step 1: Read SRS, SDD, and E2E Testing Patterns\n1. Read `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Fsrs.md` and `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Fsdd.md`.\n2. Extract all Use Cases (`UC-XXX`), API Endpoints, Database Entities, and Constraints.\n3. Consult `e2e-testing-patterns` for Page Object Model (POM), selector strategies (`getByRole`, `data-testid`), and headless test execution.\n\n### Step 2: Define Test Architecture & Fixtures\n- **Unit\u002FIntegration**: `pytest` (Python) or `vitest` \u002F `supertest` (Node.js\u002FTS).\n- **E2E Acceptance**: Headless Playwright (`npx playwright test` \u002F pure CLI automation — zero GUI, zero computer_use required).\n- Database Strategy: In-memory \u002F transactional DB rollback for unit tests; live PostgreSQL container for E2E tests.\n\n### Step 3: Author Test Suite Catalog (Unit, Integration & E2E Scenarios)\nMap each `UC-XXX` to:\n1. Unit test cases (`TC-UNIT-XXX`)\n2. Integration API test cases (`TC-INT-XXX`)\n3. E2E critical user journey test cases (`TC-E2E-XXX`)\n\n### Step 4: Define Boundary & Security Edge Cases\n- Missing mandatory fields (HTTP 422 \u002F 400).\n- Duplicate unique constraints (HTTP 409).\n- Expired \u002F malformed JWT tokens (HTTP 401).\n- Insufficient role permissions (HTTP 403).\n- Non-existent resource lookups (HTTP 404).\n- Boundary inputs (empty strings, maximum string length, negative numbers, special characters).\n\n### Step 5: Write Document to `\u002Fdocs\u002Ftest_plan.md`\nWrite the complete specification to `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Ftest_plan.md`.\n\n---\n\n## 📄 Test Plan Document Template Structure\n\n```markdown\n# Software Test Plan\n## Project: {Project Name}\n**Standard**: ISO\u002FIEC\u002FIEEE 29119-3:2021 (Superseding IEEE 829)  \n**Version**: 1.0.0  \n**Author**: dev-tester (SDET)  \n**Status**: Baseline  \n**References**: `docs\u002Fsrs.md`, `docs\u002Fsdd.md`, `e2e-testing-patterns`  \n\n---\n\n## 1. Test Strategy & Objectives\n### 1.1 Objective\nVerify that the software fulfills all functional requirements in `docs\u002Fsrs.md`, conforms to architecture in `docs\u002Fsdd.md`, and meets all quality and security gates.\n\n### 1.2 Testing Pyramid Distribution\n- **Unit Tests (70%)**: Fast, isolated tests for utility functions, model constraints, and domain logic.\n- **Integration Tests (20%)**: API endpoint testing with database interactions.\n- **E2E Scenario Tests (10%)**: Complete multi-step workflows validating end-to-end user journeys against live Docker stack.\n\n---\n\n## 2. Test Environment & Fixtures Architecture\n- **Unit \u002F Integration Runner**: Vitest \u002F Pytest \u002F Supertest\n- **E2E Runner**: Headless Playwright CLI (executed against `http:\u002F\u002Flocalhost`)\n- **Database Strategy**: Isolated transactional DB for unit tests; live container for E2E.\n- **Auth Fixtures**: Pre-seeded standard and admin credentials.\n\n---\n\n## 3. Test Traceability Matrix (TTM)\n| Test Case ID | Target UC | Test Tier | Target Endpoint \u002F UI Component | Description | Expected Result |\n| :--- | :--- | :--- | :--- | :--- | :--- |\n| `TC-AUTH-001` | `UC-001` | Integration | `POST \u002Fapi\u002Fv1\u002Fauth\u002Fregister` | Successful registration | HTTP 201, User created |\n| `TC-AUTH-002` | `UC-001` | Integration | `POST \u002Fapi\u002Fv1\u002Fauth\u002Fregister` | Duplicate email registration | HTTP 409 Conflict |\n| `TC-AUTH-003` | `UC-002` | Integration | `POST \u002Fapi\u002Fv1\u002Fauth\u002Flogin` | Valid login | HTTP 200, JWT returned |\n| `TC-E2E-001`  | `UC-001, UC-002` | E2E | `\u002Fregister` -> `\u002Flogin` -> `\u002F` | Register new user, login, verify dashboard | Redirect to `\u002F`, Token stored, UI rendered |\n| `TC-E2E-002`  | `UC-003, UC-009` | E2E | `\u002Fmeetings\u002Fcreate` -> `\u002Fmeetings\u002F:id` | Create meeting, add agenda items | Meeting card displayed, items listed |\n\n---\n\n## 4. Boundary & Security Test Matrix\n| Category | Scenario | Test Input | Expected Status |\n| :--- | :--- | :--- | :--- |\n| Input Validation | Empty required field | `{\"email\": \"\"}` | HTTP 422 \u002F 400 |\n| String Length | Overly long input | 300-char string | HTTP 422 \u002F 400 |\n| Security | Missing Bearer token | No `Authorization` header | HTTP 401 |\n| Security | Tampered JWT | Invalid signature | HTTP 401 |\n| Authorization | Standard user accessing Admin API | Role `USER` on `\u002Fadmin` | HTTP 403 |\n\n---\n\n## 5. End-to-End (E2E) Containerized Acceptance Test Suite\n*Executed in Phase 6 against the live Docker Compose environment (`http:\u002F\u002Flocalhost`)*\n\n### 5.1 Page Object Model (POM) Architecture\n- `LoginPage`: Selectors (`getByLabel('Email address')`, `getByRole('button', { name: 'Sign in' })`)\n- `RegisterPage`: Selectors (`getByLabel('Display name')`, `getByLabel('Password')`)\n- `DashboardPage` & `MeetingDetailPage`: Selectors (`getByRole('button', { name: 'Create Meeting' })`, `data-testid`)\n\n### 5.2 Critical User Journeys (E2E Scenarios)\n1. **Journey 1: Account Onboarding & Session Persistence**\n   - Navigate to `http:\u002F\u002Flocalhost\u002Fregister`\n   - Fill form, submit ➔ verify redirect to `\u002F` or `\u002Flogin`\n   - Refresh page ➔ verify session remains authenticated\n2. **Journey 2: Meeting Lifecycle & Real-Time Agenda Tracking**\n   - Create meeting ➔ verify listed on `\u002Fmeetings`\n   - Open detail page ➔ add 2 agenda items ➔ toggle `isDiscussed`\n   - Record decision ➔ create action item ➔ assign to attendee\n3. **Journey 3: Admin Governance & Access Enforcement**\n   - Login as standard user ➔ verify `\u002Fadmin` redirects or 403\n   - Login as admin ➔ inspect user list ➔ toggle status\n\n---\n\n## 6. Quality Acceptance Gates (Triple-Gate Standard)\n1. **Module Pass Rate Gate**: `failed == 0` and `errors == 0` (100% pass rate).\n2. **Code Coverage Gate**: Backend & frontend core logic $\\ge 80\\%$.\n3. **E2E Container Gate**: 100% Pass Rate across all `TC-E2E-XXX` test scenarios in Phase 6.\n```\n","# Test Plan Specification Skill (ISO\u002FIEC\u002FIEEE 29119-3 & E2E Testing Patterns)\n\n## Overview\nProduce an authoritative **Test Plan** document compliant with **ISO\u002FIEC\u002FIEEE 29119-3:2021** (superseding legacy IEEE 829) and incorporating modern **E2E Testing Patterns** (Headless Playwright \u002F Cypress). The Test Plan defines test strategy, fixture architecture, boundary conditions, and full-stack containerized acceptance criteria for automated verification.\n\n## Role & Execution Timing\n- **Author**: **`dev-tester` (SDET)**\n- **When Created**: Early Stage 1 \u002F Phase 3 (immediately after `docs\u002Fsdd.md` is published by `dev-architech`).\n- **Target Output Path**: `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Ftest_plan.md`\n\n---\n\n## 📐 Testing Pyramid & Triple-Gate Quality Standard\n\n### 1. Pyramid Allocation\n- **Unit Tests (70%)**: Pure domain logic, model validations, helper utilities, schema serialization. Executed in milliseconds without external I\u002FO.\n- **Integration Tests (20%)**: API Routers, database transactions, dependency injection overrides, authentication & permission middlewares.\n- **End-to-End (E2E) Container Tests (10%)**: Real browser \u002F HTTP headless workflows executed against the live running Docker Compose stack (`http:\u002F\u002Flocalhost`).\n\n### 2. Triple-Gate Quality Standard (🚦 Triple-Gate Acceptance Iron Law)\n1. **Module Pass Rate Gate**: `failed == 0` and `errors == 0` (100% pass rate for unit and integration tests).\n2. **Code Coverage Gate**: Backend & frontend core logic coverage $\\ge 80\\%$.\n3. **Phase 6 Containerized E2E Gate**: 100% passing E2E acceptance suite executed in headless mode against the live running Docker Compose environment before project release.\n\n---\n\n## 🛠️ Step-by-Step Procedure\n\n### Step 1: Read SRS, SDD, and E2E Testing Patterns\n1. Read `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Fsrs.md` and `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Fsdd.md`.\n2. Extract all Use Cases (`UC-XXX`), API Endpoints, Database Entities, and Constraints.\n3. Consult `e2e-testing-patterns` for Page Object Model (POM), selector strategies (`getByRole`, `data-testid`), and headless test execution.\n\n### Step 2: Define Test Architecture & Fixtures\n- **Unit\u002FIntegration**: `pytest` (Python) or `vitest` \u002F `supertest` (Node.js\u002FTS).\n- **E2E Acceptance**: Headless Playwright (`npx playwright test` \u002F pure CLI automation — zero GUI, zero computer_use required).\n- Database Strategy: In-memory \u002F transactional DB rollback for unit tests; live PostgreSQL container for E2E tests.\n\n### Step 3: Author Test Suite Catalog (Unit, Integration & E2E Scenarios)\nMap each `UC-XXX` to:\n1. Unit test cases (`TC-UNIT-XXX`)\n2. Integration API test cases (`TC-INT-XXX`)\n3. E2E critical user journey test cases (`TC-E2E-XXX`)\n\n### Step 4: Define Boundary & Security Edge Cases\n- Missing mandatory fields (HTTP 422 \u002F 400).\n- Duplicate unique constraints (HTTP 409).\n- Expired \u002F malformed JWT tokens (HTTP 401).\n- Insufficient role permissions (HTTP 403).\n- Non-existent resource lookups (HTTP 404).\n- Boundary inputs (empty strings, maximum string length, negative numbers, special characters).\n\n### Step 5: Write Document to `\u002Fdocs\u002Ftest_plan.md`\nWrite the complete specification to `\u002Fopt\u002Fdata\u002Fworkspace\u002F{project_name}\u002Fdocs\u002Ftest_plan.md`.\n\n---\n\n## 📄 Test Plan Document Template Structure\n\n```markdown\n# Software Test Plan\n## Project: {Project Name}\n**Standard**: ISO\u002FIEC\u002FIEEE 29119-3:2021 (Superseding IEEE 829)  \n**Version**: 1.0.0  \n**Author**: dev-tester (SDET)  \n**Status**: Baseline  \n**References**: `docs\u002Fsrs.md`, `docs\u002Fsdd.md`, `e2e-testing-patterns`  \n\n---\n\n## 1. Test Strategy & Objectives\n### 1.1 Objective\nVerify that the software fulfills all functional requirements in `docs\u002Fsrs.md`, conforms to architecture in `docs\u002Fsdd.md`, and meets all quality and security gates.\n\n### 1.2 Testing Pyramid Distribution\n- **Unit Tests (70%)**: Fast, isolated tests for utility functions, model constraints, and domain logic.\n- **Integration Tests (20%)**: API endpoint testing with database interactions.\n- **E2E Scenario Tests (10%)**: Complete multi-step workflows validating end-to-end user journeys against live Docker stack.\n\n---\n\n## 2. Test Environment & Fixtures Architecture\n- **Unit \u002F Integration Runner**: Vitest \u002F Pytest \u002F Supertest\n- **E2E Runner**: Headless Playwright CLI (executed against `http:\u002F\u002Flocalhost`)\n- **Database Strategy**: Isolated transactional DB for unit tests; live container for E2E.\n- **Auth Fixtures**: Pre-seeded standard and admin credentials.\n\n---\n\n## 3. Test Traceability Matrix (TTM)\n| Test Case ID | Target UC | Test Tier | Target Endpoint \u002F UI Component | Description | Expected Result |\n| :--- | :--- | :--- | :--- | :--- | :--- |\n| `TC-AUTH-001` | `UC-001` | Integration | `POST \u002Fapi\u002Fv1\u002Fauth\u002Fregister` | Successful registration | HTTP 201, User created |\n| `TC-AUTH-002` | `UC-001` | Integration | `POST \u002Fapi\u002Fv1\u002Fauth\u002Fregister` | Duplicate email registration | HTTP 409 Conflict |\n| `TC-AUTH-003` | `UC-002` | Integration | `POST \u002Fapi\u002Fv1\u002Fauth\u002Flogin` | Valid login | HTTP 200, JWT returned |\n| `TC-E2E-001`  | `UC-001, UC-002` | E2E | `\u002Fregister` -> `\u002Flogin` -> `\u002F` | Register new user, login, verify dashboard | Redirect to `\u002F`, Token stored, UI rendered |\n| `TC-E2E-002`  | `UC-003, UC-009` | E2E | `\u002Fmeetings\u002Fcreate` -> `\u002Fmeetings\u002F:id` | Create meeting, add agenda items | Meeting card displayed, items listed |\n\n---\n\n## 4. Boundary & Security Test Matrix\n| Category | Scenario | Test Input | Expected Status |\n| :--- | :--- | :--- | :--- |\n| Input Validation | Empty required field | `{\"email\": \"\"}` | HTTP 422 \u002F 400 |\n| String Length | Overly long input | 300-char string | HTTP 422 \u002F 400 |\n| Security | Missing Bearer token | No `Authorization` header | HTTP 401 |\n| Security | Tampered JWT | Invalid signature | HTTP 401 |\n| Authorization | Standard user accessing Admin API | Role `USER` on `\u002Fadmin` | HTTP 403 |\n\n---\n\n## 5. End-to-End (E2E) Containerized Acceptance Test Suite\n*Executed in Phase 6 against the live Docker Compose environment (`http:\u002F\u002Flocalhost`)*\n\n### 5.1 Page Object Model (POM) Architecture\n- `LoginPage`: Selectors (`getByLabel('Email address')`, `getByRole('button', { name: 'Sign in' })`)\n- `RegisterPage`: Selectors (`getByLabel('Display name')`, `getByLabel('Password')`)\n- `DashboardPage` & `MeetingDetailPage`: Selectors (`getByRole('button', { name: 'Create Meeting' })`, `data-testid`)\n\n### 5.2 Critical User Journeys (E2E Scenarios)\n1. **Journey 1: Account Onboarding & Session Persistence**\n   - Navigate to `http:\u002F\u002Flocalhost\u002Fregister`\n   - Fill form, submit ➔ verify redirect to `\u002F` or `\u002Flogin`\n   - Refresh page ➔ verify session remains authenticated\n2. **Journey 2: Meeting Lifecycle & Real-Time Agenda Tracking**\n   - Create meeting ➔ verify listed on `\u002Fmeetings`\n   - Open detail page ➔ add 2 agenda items ➔ toggle `isDiscussed`\n   - Record decision ➔ create action item ➔ assign to attendee\n3. **Journey 3: Admin Governance & Access Enforcement**\n   - Login as standard user ➔ verify `\u002Fadmin` redirects or 403\n   - Login as admin ➔ inspect user list ➔ toggle status\n\n---\n\n## 6. Quality Acceptance Gates (Triple-Gate Standard)\n1. **Module Pass Rate Gate**: `failed == 0` and `errors == 0` (100% pass rate).\n2. **Code Coverage Gate**: Backend & frontend core logic $\\ge 80\\%$.\n3. **E2E Container Gate**: 100% Pass Rate across all `TC-E2E-XXX` test scenarios in Phase 6.\n```\n",{"name":5,"author":24,"license":15,"version":25,"metadata":26,"platforms":44,"description":7},"Hermes Agent Team","2.1.0",{"hermes":27},{"tags":28,"related_skills":39},[29,30,31,32,33,34,35,36,37,38],"testing","test-plan","iso-29119","ieee-829","e2e-testing-patterns","playwright","cypress","qa","sdet","verification",[33,40,41,42,43],"testing-patterns","srs-specifier","sdd-architect","delegate-software-engineering-team",[45,46,47],"linux","macos","windows","master","89e68a8718471ab849f0bdbce4a3b9c482268777","dev-tester\u002Fskills\u002Ftest-planner","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc","https:\u002F\u002Fgithub.com\u002Froychshao","National Taiwan University CSIE Master\r\nNational Chengchi University CS Bachelor","2026-09-15 03:35:21",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add roychshao\u002Fhermes-multi-agent-sdlc --skill test-planner",{"tool":61,"command":62},"bunx","bunx skills add roychshao\u002Fhermes-multi-agent-sdlc --skill test-planner",{"tool":64,"command":65},"pnpm","pnpm dlx skills add roychshao\u002Fhermes-multi-agent-sdlc --skill test-planner","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fdev-tester\u002Fskills\u002Ftest-planner\u002FSKILL.md",true,[],[70,76,83,90,95,101],{"skillNo":71,"name":41,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7CT8XM3T4AHBARB8ZVVZCH7","Generate professional Software Requirements Specification (SRS) compliant with ISO\u002FIEC\u002FIEEE 29148 and IEEE 830 standards, focusing purely on requirements (WHAT the system does) with granular use-case decomposition, high-level technology constraints, non-functional requirements, and strict exclusion of design details (no API routes, no ERD\u002FDDL, no response envelopes).","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fmain\u002Fskills\u002Fsrs-specifier\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7CT6WM0NNVJ9ZW4MSS4YYDK","writing-plans","Write a markdown plan to .hermes\u002Fplans\u002F; no execution.","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fdev-pm\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7CT6H6BEPFJW4QKH0CXY14F","system-design","Produce a comprehensive system design document for a software project.","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fdev-pm\u002Fskills\u002Fsystem-design\u002FSKILL.md",[],[],{"skillNo":91,"name":41,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M7CT6B27YCX5QVZXE4H9ZZR2","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fdev-pm\u002Fskills\u002Fsrs-specifier\u002FSKILL.md",[],[],{"skillNo":96,"name":42,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":19},"01M7CT65P7PTV5YNVTT3BDZKFR","Author comprehensive Software Design Description (SDD) specifications compliant with IEEE 1016-2009 standard, translating SRS requirements into layered clean architectures, explicit Business Service method signatures, domain exceptions, ERDs, REST APIs, and ADRs.","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fdev-pm\u002Fskills\u002Fsdd-architect\u002FSKILL.md",[],[],{"skillNo":102,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":19},"01M7CT5HZJT6W43CVKJS6GMKJ4","https:\u002F\u002Fgithub.com\u002Froychshao\u002Fhermes-multi-agent-sdlc\u002Fblob\u002Fmaster\u002Fdev-frontend\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[],[]]