[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KW8TVVPF6EXZ2E8XTZEKAZ":3,"skill-same:01M6KW8TVVPF6EXZ2E8XTZEKAZ":70},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6KW8TVVPF6EXZ2E8XTZEKAZ","agent-invocation",null,"Authoritative skill for spawning or invoking another agent with proper context. Use PROACTIVELY before any agent calls another agent — covers Claude `Agent(...)` \u002F `SendMessage` and Copilot\u002FVS Code `agent` tool invocation forms, routing rules to triage-agent \u002F agent-manager \u002F research-assistant \u002F product-manager, the SDLC chain and per-stage artifacts, how to brief a cold-started spawned agent with a self-contained handoff, foreground vs background and parallel calls, trust-but-verify after the spawned agent returns, and when NOT to invoke another agent at all.","rafsanulhasan\u002FHypermediaEngine","rafsanulhasan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2341142?v=4","01M6KW2HWPTZWK051N7B0HTBVG","Rafsanul Hasan","01M6KW2J0N3613382MF5DRN79H",0,"GPL-3.0","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fagent-invocation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"agent invocation","agent-manager","for","calls","with","cold","how to","chain","stage","self","copilot","trust","use","Rules","parallel","tool","brief","artifacts","code","routing","2026-11-10 10:12:30",false,"---\nname: agent-invocation\ndescription: \"Authoritative skill for spawning or invoking another agent with proper context. Use PROACTIVELY before any agent calls another agent — covers Claude `Agent(...)` \u002F `SendMessage` and Copilot\u002FVS Code `agent` tool invocation forms, routing rules to triage-agent \u002F agent-manager \u002F research-assistant \u002F product-manager, the SDLC chain and per-stage artifacts, how to brief a cold-started spawned agent with a self-contained handoff, foreground vs background and parallel calls, trust-but-verify after the spawned agent returns, and when NOT to invoke another agent at all.\"\n---\n\n# Agent Invocation\n\nThis skill is the single source of truth for how any agent in the HypermediaEngine multi-agent system spawns or invokes another agent. Every agent (Claude or Copilot\u002FVS Code) must consult this skill before delegating work, handing off across the SDLC, or routing a sub-task to another role. Do not invent invocation conventions — use the forms defined here verbatim.\n\n## When to consult this skill\n\n- You are about to spawn another agent, hand off work, or send a message to a previously spawned agent.\n- The user's request spans more than one agent's responsibility and you are unsure who should own it.\n- You catch yourself reaching for `web` search or library-docs lookup tools directly — that is a signal to delegate to `research-assistant` (see Routing rules).\n- You are about to edit any file under `.claude\u002Fagents\u002F`, `.github\u002Fagents\u002F`, `.github\u002Fskills\u002F`, `.claude\u002Fskills\u002F`, `.claude\u002Fcommands\u002F`, `.github\u002Fprompts\u002F`, `.claude\u002Frules\u002F`, `.github\u002Finstructions\u002F`, or any hook configuration — stop and route to `agent-manager` instead.\n\n## When NOT to invoke another agent\n\n- A simple factual question already answered by the current agent's own context.\n- A follow-up inside an already-triaged workflow where the receiving agent is already running.\n- A task that is fully within the current agent's own responsibilities — do the work, do not subcontract it.\n- Trivial one-shot lookups already resolved inline by `triage-agent` during classification.\n\n## Invocation mechanisms\n\n### Copilot \u002F VS Code (primary platform for this file)\n\n- **Spawn an agent** — use the platform-native `agent` tool, targeting the desired agent by name and passing a self-contained prompt. Example phrasing:\n\n  > Invoke the `agent` tool against `\u003Cagent-name>` with prompt \"\u003Cself-contained brief>\".\n\n- **Continue an already-spawned agent** — send a follow-up message to that named agent rather than re-spawning a cold instance.\n\n- **Parallel independent agents** — issue multiple `agent` tool calls in a single message; the caller synthesizes outputs.\n\n- **Foreground vs background** — default to foreground (you block until the agent returns). Use background only for genuinely independent long-running work where the caller has other useful work to do meanwhile.\n\n### Claude Code\n\n- **Spawn a cold agent** — primary form, used for all new delegations:\n\n  ```\n  Agent(subagent_type: \"\u003Cagent-name>\", description: \"\u003Cone-line task summary>\", prompt: \"\u003Cself-contained brief>\")\n  ```\n\n- **Continue an already-spawned agent** — preserves the agent's working memory; cheaper than a cold respawn:\n\n  ```\n  SendMessage({to: \"\u003Cagent-name>\", message: \"\u003Cfollow-up>\"})\n  ```\n\n- **Parallel independent agents** — issue multiple `runSubagent` mcp calls in a single message. Each runs concurrently and returns to the caller, who synthesizes the combined output. This is the canonical form for orchestration mode 2 (Parallel independent subagents) in the `agent-selection` skill.\n\n- **Foreground vs background** — default to foreground (you block until the agent returns). Use background only for genuinely independent long-running work where the caller has other useful work to do meanwhile.\n\n### Copilot \u002F VS Code\n\n- **Spawn an agent** — use the platform-native `agent` tool, targeting the desired agent by name and passing a self-contained prompt:\n\n  > Invoke the `agent` tool against `\u003Cagent-name>` with prompt \"\u003Cself-contained brief>\".\n\n- **Continue an already-spawned agent** — send a follow-up message to that named agent rather than re-spawning a cold instance.\n\n- **Parallel independent agents** — issue multiple `agent` tool calls in a single message; the caller synthesizes outputs.\n\n- **Foreground vs background** — default to foreground. Background mode is reserved for genuinely independent long-running work.\n\n> Do not invent new invocation syntax on either platform. If a form is not listed here, treat it as unsupported and ask `agent-manager` whether the skill needs updating.\n\n## Routing rules every caller must respect\n\n- **Non-trivial \u002F multi-step \u002F ambiguous user requests → `triage-agent` first.** Triage classifies, decomposes, maps dependencies, and produces a confirmed execution plan before any specialist agent is invoked. Skipping triage to save time costs more than it saves.\n- **Any agent \u002F skill \u002F command \u002F prompt \u002F rules \u002F instructions \u002F hook file lifecycle work → `agent-manager`.** No other agent edits files under `.claude\u002Fagents\u002F`, `.github\u002Fagents\u002F`, `.github\u002Fskills\u002F`, `.claude\u002Fskills\u002F`, `.claude\u002Fcommands\u002F`, `.github\u002Fprompts\u002F`, `.claude\u002Frules\u002F`, `.github\u002Finstructions\u002F`, or any hook configuration. `agent-manager` is the single authority.\n- **External knowledge (library \u002F API \u002F SDK docs, framework conventions, version-specific behavior, current best practices) and non-trivial cross-cutting codebase exploration → `research-assistant`.** Prefer **context7** over web search for library docs. Never run ad-hoc `web` \u002F library-docs tools yourself when a `research-assistant` call would do the job.\n- **Backlog management, prioritization, milestone planning, and release work → `product-manager`.** `triage-agent` consults the PM before invoking `agent-selection` for any Feature or TechDebt batch; feed PM priorities into the routing decision.\n- **SDLC forward chain** — implementation work flows through this order, with each role producing an explicit artifact for the next:\n\n  | Stage | Role | Hands off to next stage |\n  |---|---|---|\n  | 1 | `requirement-analyst` | Finalized spec at `docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md` with numbered acceptance criteria |\n  | 2 | `software-architect` | Architecture Design Document + ADR under `docs\u002Farchitecture\u002Fdecisions\u002F`, plus Implementation Guidance section |\n  | 3 | `system-engineer` | Low-level design notes (class\u002Fmodule structure, design-pattern choices, DI registration plan) |\n  | 4 | `software-engineer` | Implementation diff + `dotnet test` green + `dotnet stryker` survivors triaged |\n  | 5 | `sqa-engineer` (in parallel with `documentation-writer`) | Test plan, implemented tests, mutation report with surviving-mutant rationale, AC-traceability table |\n  | 5 | `documentation-writer` (in parallel with `sqa-engineer`) | New or updated `README.md` files reflecting the change |\n  | 6 | `code-reviewer` | Severity-ranked findings report (Blocker \u002F Warning \u002F Suggestion) with file:line specificity |\n\n  Always cite the artifact path when invoking the next stage. Never hand off without naming the file the next agent should read first.\n\n## How to brief the spawned agent\n\nThe spawned agent starts **cold** — it does not see this conversation, your prior tool calls, or any context that lives only in your head. The prompt must be fully self-contained.\n\nRequired elements in every brief:\n\n- **Goal** — one sentence on the outcome, and one sentence on why it matters.\n- **Required context** — concrete artifact paths (`docs\u002Fspecs\u002F\u003Cslug>.spec.md`, `docs\u002Farchitecture\u002Fdecisions\u002FNNN-*.md`, plan files, failing test names), file paths with **line numbers**, prior findings from earlier agents, and any constraints discovered so far.\n- **Instructions** — the specific question to answer or work to perform, scoped to the receiving agent's role. Do not ask one agent to do another's job.\n- **Acceptance criteria** — numbered ACs the deliverable must satisfy.\n- **Expected deliverable** — its shape and length (e.g., \"findings report ≤ 30 lines\", \"ADR following the project template\", \"code diff + passing tests\", \"test plan with AC-traceability table\").\n- **Write code vs. report only** — say explicitly whether the agent should land code on disk or only return analysis.\n- **Next-hop hint** — which agent (if any) receives this agent's output, so the receiving agent can shape its deliverable appropriately.\n- **Success criteria** — how you (the caller) will verify the handoff is complete.\n\nAnti-patterns to avoid:\n\n- **Do not delegate synthesis.** \"Look into X and fix whatever you find\" outsources the *understanding* — that is your job. Do the diagnostic work first, then hand off a scoped task with a clear acceptance criterion.\n- **Do not assume shared context.** If the spawned agent needs a file path, a line number, or a prior finding, include it explicitly. A cold agent re-reading the entire repo is wasted tokens.\n- **Do not skip the next-hop hint.** Without it, the receiver cannot shape its output for the next stage.\n\n## Parallelism and concurrency\n\n- For **independent sub-tasks** (no collaboration needed between them) — fire multiple `runSubagent` tool calls in a single message on Copilot\u002FVS Code, or multiple `Agent(...)` calls on Claude. The orchestrator synthesizes the combined output.\n- For **research breadth** (e.g., comparing 3–5 options) — spawn 3–5 `research-assistant` subagents in parallel, each with a distinct angle, then synthesize.\n- For **collaborative SDLC work** — do **not** parallelize within the chain; run it sequentially with explicit handoffs (Mode 3 in `agent-selection`).\n- Background mode is for genuinely long-running independent work only — not a default. Most invocations should be foreground.\n\n## Trust but verify\n\nA spawned agent's summary describes **intent**, not necessarily what landed on disk:\n\n- After the agent returns, **verify changed files** with `read` \u002F `search` (Copilot\u002FVS Code) before reporting work complete on the agent's behalf.\n- Mark `TodoWrite` \u002F `todo` items Done only after verification, not on the agent's claim alone.\n- If verification fails, send a `SendMessage` (or Copilot equivalent) follow-up to the same agent rather than respawning a cold instance — the original context is still warm.\n\n## Companion skills\n\n- `agent-selection` — decides *which* agent (or team) to invoke and which of the four orchestration modes applies. Use it alongside this skill: `agent-selection` picks the targets and mode; `agent-invocation` covers the mechanics of actually invoking them with proper context.\n- `triage` — the primary caller of both skills, run at the start of every non-trivial user request.\n\n## Authority\n\nThis skill is authoritative. If an agent's own definition file describes invocation behavior that contradicts this skill, the skill wins, and the agent file should be updated via `agent-manager`. Do not silently diverge.\n","# Agent Invocation\n\nThis skill is the single source of truth for how any agent in the HypermediaEngine multi-agent system spawns or invokes another agent. Every agent (Claude or Copilot\u002FVS Code) must consult this skill before delegating work, handing off across the SDLC, or routing a sub-task to another role. Do not invent invocation conventions — use the forms defined here verbatim.\n\n## When to consult this skill\n\n- You are about to spawn another agent, hand off work, or send a message to a previously spawned agent.\n- The user's request spans more than one agent's responsibility and you are unsure who should own it.\n- You catch yourself reaching for `web` search or library-docs lookup tools directly — that is a signal to delegate to `research-assistant` (see Routing rules).\n- You are about to edit any file under `.claude\u002Fagents\u002F`, `.github\u002Fagents\u002F`, `.github\u002Fskills\u002F`, `.claude\u002Fskills\u002F`, `.claude\u002Fcommands\u002F`, `.github\u002Fprompts\u002F`, `.claude\u002Frules\u002F`, `.github\u002Finstructions\u002F`, or any hook configuration — stop and route to `agent-manager` instead.\n\n## When NOT to invoke another agent\n\n- A simple factual question already answered by the current agent's own context.\n- A follow-up inside an already-triaged workflow where the receiving agent is already running.\n- A task that is fully within the current agent's own responsibilities — do the work, do not subcontract it.\n- Trivial one-shot lookups already resolved inline by `triage-agent` during classification.\n\n## Invocation mechanisms\n\n### Copilot \u002F VS Code (primary platform for this file)\n\n- **Spawn an agent** — use the platform-native `agent` tool, targeting the desired agent by name and passing a self-contained prompt. Example phrasing:\n\n  > Invoke the `agent` tool against `\u003Cagent-name>` with prompt \"\u003Cself-contained brief>\".\n\n- **Continue an already-spawned agent** — send a follow-up message to that named agent rather than re-spawning a cold instance.\n\n- **Parallel independent agents** — issue multiple `agent` tool calls in a single message; the caller synthesizes outputs.\n\n- **Foreground vs background** — default to foreground (you block until the agent returns). Use background only for genuinely independent long-running work where the caller has other useful work to do meanwhile.\n\n### Claude Code\n\n- **Spawn a cold agent** — primary form, used for all new delegations:\n\n  ```\n  Agent(subagent_type: \"\u003Cagent-name>\", description: \"\u003Cone-line task summary>\", prompt: \"\u003Cself-contained brief>\")\n  ```\n\n- **Continue an already-spawned agent** — preserves the agent's working memory; cheaper than a cold respawn:\n\n  ```\n  SendMessage({to: \"\u003Cagent-name>\", message: \"\u003Cfollow-up>\"})\n  ```\n\n- **Parallel independent agents** — issue multiple `runSubagent` mcp calls in a single message. Each runs concurrently and returns to the caller, who synthesizes the combined output. This is the canonical form for orchestration mode 2 (Parallel independent subagents) in the `agent-selection` skill.\n\n- **Foreground vs background** — default to foreground (you block until the agent returns). Use background only for genuinely independent long-running work where the caller has other useful work to do meanwhile.\n\n### Copilot \u002F VS Code\n\n- **Spawn an agent** — use the platform-native `agent` tool, targeting the desired agent by name and passing a self-contained prompt:\n\n  > Invoke the `agent` tool against `\u003Cagent-name>` with prompt \"\u003Cself-contained brief>\".\n\n- **Continue an already-spawned agent** — send a follow-up message to that named agent rather than re-spawning a cold instance.\n\n- **Parallel independent agents** — issue multiple `agent` tool calls in a single message; the caller synthesizes outputs.\n\n- **Foreground vs background** — default to foreground. Background mode is reserved for genuinely independent long-running work.\n\n> Do not invent new invocation syntax on either platform. If a form is not listed here, treat it as unsupported and ask `agent-manager` whether the skill needs updating.\n\n## Routing rules every caller must respect\n\n- **Non-trivial \u002F multi-step \u002F ambiguous user requests → `triage-agent` first.** Triage classifies, decomposes, maps dependencies, and produces a confirmed execution plan before any specialist agent is invoked. Skipping triage to save time costs more than it saves.\n- **Any agent \u002F skill \u002F command \u002F prompt \u002F rules \u002F instructions \u002F hook file lifecycle work → `agent-manager`.** No other agent edits files under `.claude\u002Fagents\u002F`, `.github\u002Fagents\u002F`, `.github\u002Fskills\u002F`, `.claude\u002Fskills\u002F`, `.claude\u002Fcommands\u002F`, `.github\u002Fprompts\u002F`, `.claude\u002Frules\u002F`, `.github\u002Finstructions\u002F`, or any hook configuration. `agent-manager` is the single authority.\n- **External knowledge (library \u002F API \u002F SDK docs, framework conventions, version-specific behavior, current best practices) and non-trivial cross-cutting codebase exploration → `research-assistant`.** Prefer **context7** over web search for library docs. Never run ad-hoc `web` \u002F library-docs tools yourself when a `research-assistant` call would do the job.\n- **Backlog management, prioritization, milestone planning, and release work → `product-manager`.** `triage-agent` consults the PM before invoking `agent-selection` for any Feature or TechDebt batch; feed PM priorities into the routing decision.\n- **SDLC forward chain** — implementation work flows through this order, with each role producing an explicit artifact for the next:\n\n  | Stage | Role | Hands off to next stage |\n  |---|---|---|\n  | 1 | `requirement-analyst` | Finalized spec at `docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md` with numbered acceptance criteria |\n  | 2 | `software-architect` | Architecture Design Document + ADR under `docs\u002Farchitecture\u002Fdecisions\u002F`, plus Implementation Guidance section |\n  | 3 | `system-engineer` | Low-level design notes (class\u002Fmodule structure, design-pattern choices, DI registration plan) |\n  | 4 | `software-engineer` | Implementation diff + `dotnet test` green + `dotnet stryker` survivors triaged |\n  | 5 | `sqa-engineer` (in parallel with `documentation-writer`) | Test plan, implemented tests, mutation report with surviving-mutant rationale, AC-traceability table |\n  | 5 | `documentation-writer` (in parallel with `sqa-engineer`) | New or updated `README.md` files reflecting the change |\n  | 6 | `code-reviewer` | Severity-ranked findings report (Blocker \u002F Warning \u002F Suggestion) with file:line specificity |\n\n  Always cite the artifact path when invoking the next stage. Never hand off without naming the file the next agent should read first.\n\n## How to brief the spawned agent\n\nThe spawned agent starts **cold** — it does not see this conversation, your prior tool calls, or any context that lives only in your head. The prompt must be fully self-contained.\n\nRequired elements in every brief:\n\n- **Goal** — one sentence on the outcome, and one sentence on why it matters.\n- **Required context** — concrete artifact paths (`docs\u002Fspecs\u002F\u003Cslug>.spec.md`, `docs\u002Farchitecture\u002Fdecisions\u002FNNN-*.md`, plan files, failing test names), file paths with **line numbers**, prior findings from earlier agents, and any constraints discovered so far.\n- **Instructions** — the specific question to answer or work to perform, scoped to the receiving agent's role. Do not ask one agent to do another's job.\n- **Acceptance criteria** — numbered ACs the deliverable must satisfy.\n- **Expected deliverable** — its shape and length (e.g., \"findings report ≤ 30 lines\", \"ADR following the project template\", \"code diff + passing tests\", \"test plan with AC-traceability table\").\n- **Write code vs. report only** — say explicitly whether the agent should land code on disk or only return analysis.\n- **Next-hop hint** — which agent (if any) receives this agent's output, so the receiving agent can shape its deliverable appropriately.\n- **Success criteria** — how you (the caller) will verify the handoff is complete.\n\nAnti-patterns to avoid:\n\n- **Do not delegate synthesis.** \"Look into X and fix whatever you find\" outsources the *understanding* — that is your job. Do the diagnostic work first, then hand off a scoped task with a clear acceptance criterion.\n- **Do not assume shared context.** If the spawned agent needs a file path, a line number, or a prior finding, include it explicitly. A cold agent re-reading the entire repo is wasted tokens.\n- **Do not skip the next-hop hint.** Without it, the receiver cannot shape its output for the next stage.\n\n## Parallelism and concurrency\n\n- For **independent sub-tasks** (no collaboration needed between them) — fire multiple `runSubagent` tool calls in a single message on Copilot\u002FVS Code, or multiple `Agent(...)` calls on Claude. The orchestrator synthesizes the combined output.\n- For **research breadth** (e.g., comparing 3–5 options) — spawn 3–5 `research-assistant` subagents in parallel, each with a distinct angle, then synthesize.\n- For **collaborative SDLC work** — do **not** parallelize within the chain; run it sequentially with explicit handoffs (Mode 3 in `agent-selection`).\n- Background mode is for genuinely long-running independent work only — not a default. Most invocations should be foreground.\n\n## Trust but verify\n\nA spawned agent's summary describes **intent**, not necessarily what landed on disk:\n\n- After the agent returns, **verify changed files** with `read` \u002F `search` (Copilot\u002FVS Code) before reporting work complete on the agent's behalf.\n- Mark `TodoWrite` \u002F `todo` items Done only after verification, not on the agent's claim alone.\n- If verification fails, send a `SendMessage` (or Copilot equivalent) follow-up to the same agent rather than respawning a cold instance — the original context is still warm.\n\n## Companion skills\n\n- `agent-selection` — decides *which* agent (or team) to invoke and which of the four orchestration modes applies. Use it alongside this skill: `agent-selection` picks the targets and mode; `agent-invocation` covers the mechanics of actually invoking them with proper context.\n- `triage` — the primary caller of both skills, run at the start of every non-trivial user request.\n\n## Authority\n\nThis skill is authoritative. If an agent's own definition file describes invocation behavior that contradicts this skill, the skill wins, and the agent file should be updated via `agent-manager`. Do not silently diverge.\n",{"name":5,"description":7},"main","00b2c68281930728ee390bb16cec32b88d2caac7",".github\u002Fskills\u002Fagent-invocation","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine","https:\u002F\u002Fgithub.com\u002Frafsanulhasan","\r\n    MCSD || A-CSD || Software Architect\r\n\r\n","2026-06-06 07:47:06",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add rafsanulhasan\u002FHypermediaEngine --skill agent-invocation",{"tool":62,"command":63},"bunx","bunx skills add rafsanulhasan\u002FHypermediaEngine --skill agent-invocation",{"tool":65,"command":66},"pnpm","pnpm dlx skills add rafsanulhasan\u002FHypermediaEngine --skill agent-invocation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fagent-invocation\u002FSKILL.md",true,[],[71,100,120,139,168,187],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":80,"publishedAt":44},"01M6KWEJD606FG3DBBRM0W4DKW","write-tests","Test implementation skill for HypermediaEngine. Takes a confirmed test plan from design-test-cases and produces compilable, runnable xUnit tests following project conventions. Validates coverage quality through mutation testing. Invoked by the sqa-engineer agent after the test plan is approved.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-tests\u002FSKILL.md",[77],{"categoryNo":78,"categoryName":79,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,26],"write tests","write","tests","testing","design","test","project conventions","test plan","Bash","plan","quality","xunit","read","edit","coverage","engineer","mutation testing","project","mutation",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":44},"01M6KWEF2XQ00C1Y6QCK7YHZ1H","write-documentation","Structured documentation writing workflow for HypermediaEngine. Writes or updates README.md files at the repo root and in each project directory (src\u002F, tests\u002F, samples\u002F, etc.) based on current implementation, ADRs, and architecture decisions.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-documentation\u002FSKILL.md",[],[107,82,108,109,110,111,112,89,113,114,115,116,93,94,117,98,83,118,119,26],"documentation","write documentation","writing","directory","workflow","architecture","src","repo","decisions","README","files","updates","at",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":44},"01M6KWEBDXTXAVPQ3BHS3YYYNT","write-adr","Writes a numbered Architecture Decision Record (ADR) for a significant architectural choice in the HypermediaEngine project. Invoked by the software-architect agent whenever a consequential design decision is made or ratified. Saves the ADR to docs\u002Farchitecture\u002Fdecisions\u002F.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-adr\u002FSKILL.md",[],[127,82,128,85,129,112,130,131,132,133,115,93,134,135,98,136,137,26,138],"adr","write adr","docs","architect","decision","choice","grep","architecture decision record","record","software","opus","architecture decision",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":151,"publishedAt":44},"01M6KWE76TM3QHGQ08PEB3KY6D","tunit-playwright-ui-testing","Comprehensive guidance for writing coded end-to-end UI tests in C# using TUnit.Playwright. Tests inherit from PageTest — the base class manages all browser lifecycle. Covers NuGet setup, PageTest inheritance, Page Object Model, browser configuration, parallelism limiting, and CI integration. Based on the official TUnit docs at https:\u002F\u002Ftunit.dev\u002Fdocs\u002Fexamples\u002Fplaywright.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftunit-playwright-ui-testing\u002FSKILL.md",[145,146],{"categoryNo":78,"categoryName":79,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":147,"categoryName":148,"taxonomyType":149,"taxonomyTypeDesc":150},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[84,152,153,154,155,156,157,109,158,159,160,161,162,163,164,165,83,166,167,26],"playwright","ui","playwright ui testing","ui testing","tunit","tunit playwright ui testing","official","dev","examples","ci","lifecycle","model","page","inheritance","end","object",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":175,"publishedAt":44},"01M6KWE44A738GDK65QS02XJBG","triage","Task classification, decomposition, dependency mapping, and routing skill. Invoked by the triage-agent to break any user request into discrete, independently-routable work items with assigned priorities and agent chains.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftriage\u002FSKILL.md",[174],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[170,43,176,177,178,179,180,181,182,183,184,28,185,186],"classification","work","user","dependency","task","priorities","decomposition","user request","mapping","break","request",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":197,"publishedAt":44},"01M6KWDZ3W9ZKPR7FTTTSX8H2K","system-design","Expert system design skill. Use PROACTIVELY to design systems, review architectures, and assist software engineers in learning design principles and implementing them in the code with design patterns.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsystem-design\u002FSKILL.md",[193,196],{"categoryNo":194,"categoryName":195,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":147,"categoryName":148,"taxonomyType":149,"taxonomyTypeDesc":150},[85,198,199,200,201,202,203,133,93,36,204,205,206,207,208,136,209,210,28,211],"system","system design","web","design systems","learning","haiku","design patterns","design principles","expert","patterns","systems","architectures","principles","implementing"]