create-yss-spec 2.2.10 → 3.0.1

package/template/.hermes/skills/dispatching-parallel-agents/SKILL.md

@@ -1,185 +0,0 @@
----
-name: dispatching-parallel-agents
-description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
----
-
-# Dispatching Parallel Agents
-
-## Overview
-
-You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
-
-When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
-
-**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
-
-## When to Use
-
-```dot
-digraph when_to_use {
-    "Multiple failures?" [shape=diamond];
-    "Are they independent?" [shape=diamond];
-    "Single agent investigates all" [shape=box];
-    "One agent per problem domain" [shape=box];
-    "Can they work in parallel?" [shape=diamond];
-    "Sequential agents" [shape=box];
-    "Parallel dispatch" [shape=box];
-
-    "Multiple failures?" -> "Are they independent?" [label="yes"];
-    "Are they independent?" -> "Single agent investigates all" [label="no - related"];
-    "Are they independent?" -> "Can they work in parallel?" [label="yes"];
-    "Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
-    "Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
-}
-```
-
-**Use when:**
-- 3+ test files failing with different root causes
-- Multiple subsystems broken independently
-- Each problem can be understood without context from others
-- No shared state between investigations
-
-**Don't use when:**
-- Failures are related (fix one might fix others)
-- Need to understand full system state
-- Agents would interfere with each other
-
-## The Pattern
-
-### 1. Identify Independent Domains
-
-Group failures by what's broken:
-- File A tests: Tool approval flow
-- File B tests: Batch completion behavior
-- File C tests: Abort functionality
-
-Each domain is independent - fixing tool approval doesn't affect abort tests.
-
-### 2. Create Focused Agent Tasks
-
-Each agent gets:
-- **Specific scope:** One test file or subsystem
-- **Clear goal:** Make these tests pass
-- **Constraints:** Don't change other code
-- **Expected output:** Summary of what you found and fixed
-
-### 3. Dispatch in Parallel
-
-Issue all three subagent dispatches in the same response — they run in parallel:
-
-```text
-Subagent (general-purpose): "Fix agent-tool-abort.test.ts failures"
-Subagent (general-purpose): "Fix batch-completion-behavior.test.ts failures"
-Subagent (general-purpose): "Fix tool-approval-race-conditions.test.ts failures"
-# All three run concurrently.
-```
-
-Multiple dispatch calls in one response = parallel execution. One per response = sequential.
-
-### 4. Review and Integrate
-
-When agents return:
-- Read each summary
-- Verify fixes don't conflict
-- Run full test suite
-- Integrate all changes
-
-## Agent Prompt Structure
-
-Good agent prompts are:
-1. **Focused** - One clear problem domain
-2. **Self-contained** - All context needed to understand the problem
-3. **Specific about output** - What should the agent return?
-
-```markdown
-Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
-
-1. "should abort tool with partial output capture" - expects 'interrupted at' in message
-2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
-3. "should properly track pendingToolCount" - expects 3 results but gets 0
-
-These are timing/race condition issues. Your task:
-
-1. Read the test file and understand what each test verifies
-2. Identify root cause - timing issues or actual bugs?
-3. Fix by:
-   - Replacing arbitrary timeouts with event-based waiting
-   - Fixing bugs in abort implementation if found
-   - Adjusting test expectations if testing changed behavior
-
-Do NOT just increase timeouts - find the real issue.
-
-Return: Summary of what you found and what you fixed.
-```
-
-## Common Mistakes
-
-**❌ Too broad:** "Fix all the tests" - agent gets lost
-**✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
-
-**❌ No context:** "Fix the race condition" - agent doesn't know where
-**✅ Context:** Paste the error messages and test names
-
-**❌ No constraints:** Agent might refactor everything
-**✅ Constraints:** "Do NOT change production code" or "Fix tests only"
-
-**❌ Vague output:** "Fix it" - you don't know what changed
-**✅ Specific:** "Return summary of root cause and changes"
-
-## When NOT to Use
-
-**Related failures:** Fixing one might fix others - investigate together first
-**Need full context:** Understanding requires seeing entire system
-**Exploratory debugging:** You don't know what's broken yet
-**Shared state:** Agents would interfere (editing same files, using same resources)
-
-## Real Example from Session
-
-**Scenario:** 6 test failures across 3 files after major refactoring
-
-**Failures:**
-- agent-tool-abort.test.ts: 3 failures (timing issues)
-- batch-completion-behavior.test.ts: 2 failures (tools not executing)
-- tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
-
-**Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
-
-**Dispatch:**
-```
-Agent 1 → Fix agent-tool-abort.test.ts
-Agent 2 → Fix batch-completion-behavior.test.ts
-Agent 3 → Fix tool-approval-race-conditions.test.ts
-```
-
-**Results:**
-- Agent 1: Replaced timeouts with event-based waiting
-- Agent 2: Fixed event structure bug (threadId in wrong place)
-- Agent 3: Added wait for async tool execution to complete
-
-**Integration:** All fixes independent, no conflicts, full suite green
-
-**Time saved:** 3 problems solved in parallel vs sequentially
-
-## Key Benefits
-
-1. **Parallelization** - Multiple investigations happen simultaneously
-2. **Focus** - Each agent has narrow scope, less context to track
-3. **Independence** - Agents don't interfere with each other
-4. **Speed** - 3 problems solved in time of 1
-
-## Verification
-
-After agents return:
-1. **Review each summary** - Understand what changed
-2. **Check for conflicts** - Did agents edit same code?
-3. **Run full suite** - Verify all fixes work together
-4. **Spot check** - Agents can make systematic errors
-
-## Real-World Impact
-
-From debugging session (2025-10-03):
-- 6 failures across 3 files
-- 3 agents dispatched in parallel
-- All investigations completed concurrently
-- All fixes integrated successfully
-- Zero conflicts between agent changes

package/template/.hermes/skills/domain-modeling/ADR-FORMAT.md

@@ -1,47 +0,0 @@
-# ADR Format
-
-ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
-
-Create the `docs/adr/` directory lazily — only when the first ADR is needed.
-
-## Template
-
-```md
-# {Short title of the decision}
-
-{1-3 sentences: what's the context, what did we decide, and why.}
-```
-
-That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
-
-## Optional sections
-
-Only include these when they add genuine value. Most ADRs won't need them.
-
-- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
-- **Considered Options** — only when the rejected alternatives are worth remembering
-- **Consequences** — only when non-obvious downstream effects need to be called out
-
-## Numbering
-
-Scan `docs/adr/` for the highest existing number and increment by one.
-
-## When to offer an ADR
-
-All three of these must be true:
-
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
-
-If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
-
-### What qualifies
-
-- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
-- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
-- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
-- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
-- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
-- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
-- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.

package/template/.hermes/skills/domain-modeling/CONTEXT-FORMAT.md

@@ -1,60 +0,0 @@
-# CONTEXT.md Format
-
-## Structure
-
-```md
-# {Context Name}
-
-{One or two sentence description of what this context is and why it exists.}
-
-## Language
-
-**Order**:
-{A one or two sentence description of the term}
-_Avoid_: Purchase, transaction
-
-**Invoice**:
-A request for payment sent to a customer after delivery.
-_Avoid_: Bill, payment request
-
-**Customer**:
-A person or organization that places orders.
-_Avoid_: Client, buyer, account
-```
-
-## Rules
-
-- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
-- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
-- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
-- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
-
-## Single vs multi-context repos
-
-**Single context (most repos):** One `CONTEXT.md` at the repo root.
-
-**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
-
-```md
-# Context Map
-
-## Contexts
-
-- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
-- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
-- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
-
-## Relationships
-
-- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
-- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
-- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
-```
-
-The skill infers which structure applies:
-
-- If `CONTEXT-MAP.md` exists, read it to find contexts
-- If only a root `CONTEXT.md` exists, single context
-- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
-
-When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

package/template/.hermes/skills/domain-modeling/SKILL.md

@@ -1,74 +0,0 @@
----
-name: domain-modeling
-description: Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.
----
-
-# Domain Modeling
-
-Actively build and sharpen the project's domain model as you design. This is the *active* discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `CONTEXT.md` for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
-
-## File structure
-
-Most repos have a single context:
-
-```
-/
-├── CONTEXT.md
-├── docs/
-│   └── adr/
-│       ├── 0001-event-sourced-orders.md
-│       └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
-
-```
-/
-├── CONTEXT-MAP.md
-├── docs/
-│   └── adr/                          ← system-wide decisions
-├── src/
-│   ├── ordering/
-│   │   ├── CONTEXT.md
-│   │   └── docs/adr/                 ← context-specific decisions
-│   └── billing/
-│       ├── CONTEXT.md
-│       └── docs/adr/
-```
-
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
-
-## During the session
-
-### Challenge against the glossary
-
-When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
-
-### Sharpen fuzzy language
-
-When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
-
-### Discuss concrete scenarios
-
-When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
-
-### Cross-reference with code
-
-When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
-
-### Update CONTEXT.md inline
-
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
-
-`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
-
-### Offer ADRs sparingly
-
-Only offer to create an ADR when all three are true:
-
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
-
-If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).

package/template/.hermes/skills/domain-modeling/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Domain Modeling"
-  short_description: "Build and sharpen a domain model"

package/template/.hermes/skills/file-export-download/SKILL.md

@@ -1,160 +0,0 @@
----
-name: file-export-download
-description: 指导 Vue3 YSS UI 微应用实现文件导出、报表下载、模板下载和附件下载，覆盖 OpenAPI binary 响应、Orval 生成方法检查、responseType blob 兜底、Blob 响应类型、Content-Disposition 文件名、handleBlobResponse、loading 与错误处理；当需求出现导出、下载、Excel、CSV、PDF、ZIP、Blob 或文件流时使用。
----
-
-# YSS 文件导出下载 Skill
-
-## 触发条件
-
-- 页面需要导出 Excel、CSV、PDF、ZIP、报表、密钥文件或其他二进制文件。
-- 页面需要下载导入模板、附件或后端动态生成的文件。
-- Orval 生成接口的返回值是 `Blob`，或业务调用需要配置 `responseType: 'blob'`。
-- 代码正在手写 `URL.createObjectURL`、解析 `Content-Disposition`、拼接文件名或调用 `downloadFileStream`。
-
-## 不适用场景
-
-- 仅上传文件，不包含模板下载或导出流程。
-- 下载公开静态 URL 且无需鉴权、请求参数和响应头文件名时，使用 `downloadFileFromUrl(url, fileName?)`。
-- 浏览器只需要预览远程 PDF/图片，不触发文件保存。
-
-## 必读依据
-
-- 通用接口规则：`../yss-api-integration/SKILL.md`。
-- 当前项目：`openapi/openapi.json`、Orval 配置、生成后的 API 方法和 `packages/src/api/mutator.ts`。
-- YSS Utils 文件下载能力：按下方检索顺序核对 `handleBlobResponse` 和 `downloadBlob`。
-
-## 文档检索
-
-1. MCP 可用时，先用 `search_docs` 查询 `handleBlobResponse 文件下载 Content-Disposition`，并读取命中的 `downloadBlob（/utils/download）` 文档。该能力属于工具函数，不强制调用面向组件别名的 `get_component_docs`。
-2. 搜索无结果时，调整关键词再次调用 `search_docs`；仅在 MCP 不可用、调用失败或仍无结果时，回退读取最新 `llms-full.txt` 的文件下载章节。文档版本与当前依赖不一致时，再核对 `packages/utils` 源码、CodeGraph 和真实导出。
-
-## 决策流程
-
-1. 在 OpenAPI 中定位导出接口，优先把成功响应声明为二进制媒体类型和 `format: binary`。
-2. 重新生成 API 后检查生成方法，而不是凭接口名称判断：
-   - 已包含 `responseType: 'blob'`：业务调用不必重复传第二参数。
-   - 未包含 `responseType: 'blob'`：业务调用必须传第二参数 `{ responseType: 'blob' }`。
-3. 检查 mutator 和全局错误处理器：Blob 成功响应必须保留 `{ data, headers }`；HTTP 4xx/5xx 的 Blob JSON 错误应由全局错误处理器解析并 reject。
-4. 在业务 hook 中设置 loading、防重复点击，调用生成 API，再执行 `handleBlobResponse(res.data, res.headers)`。
-5. 验证文件名、文件内容、错误响应和连续点击，不只验证浏览器出现了下载任务。
-
-> OpenAPI 标准通过响应 `content` 和 `format: binary` 表达二进制，不直接使用 Axios 的 `responseType` 字段。最终以 Orval 生成方法是否含 `responseType: 'blob'` 为判断依据。
-
-## 硬约束（禁止/必须）
-
-- 必须优先导入 `import { handleBlobResponse } from '@yss-ui/utils';` 处理接口文件流。
-- 必须调用 `handleBlobResponse(res.data, res.headers)`；它会自动兼容响应头大小写，并解析 RFC 5987 `filename*` 与普通 `filename`。
-- 第三个 `hasUtf8Encoding` 参数已弃用，禁止继续传递。
-- 生成方法缺少 Blob 配置时，必须在第二参数顶层传 `{ responseType: 'blob' }`；禁止放进 `headers`、请求 body 或查询参数。
-- 生成方法已包含 Blob 配置时，禁止为“保险”重复传相同配置；先保持 OpenAPI 契约和生成产物正确。
-- 禁止修改 Orval 生成文件补写 `responseType`，因为重新生成会覆盖；应修正 OpenAPI，或在业务调用第二参数临时兜底。
-- 禁止依赖 URL 中包含 `download/export` 的请求拦截器猜测响应类型；接口可能不按该名称命名。
-- 禁止在业务层重复实现 `getFileNameFromContentDisposition`、`downloadFileStream`、`URL.createObjectURL` 和 `<a download>` 流程。
-- 必须保留响应头；只取 `res.data` 会丢失服务端文件名。
-- Blob 接口失败时遵循全局 mutator 错误处理，禁止在 catch 中重复 `message.error`；成功下载后可提示 `message.success`。
-- 当前模板 mutator 只能识别“已解析 JSON 对象”的 `success === false`，不会自动检测 HTTP 200 Blob 内的业务错误；发现该契约时必须先修正后端状态码或 mutator，禁止把解析逻辑复制到每个 Hook。
-- 必须用独立 loading 状态防止重复导出，并在 `finally` 中恢复。
-- 不得默认传 `skipBusinessError` 或 `skipErrorHandler`；只有明确需要业务自定义错误体验时才使用。
-
-## OpenAPI 标准代码骨架
-
-```json
-{
-  "responses": {
-    "200": {
-      "description": "导出成功",
-      "headers": {
-        "Content-Disposition": {
-          "schema": { "type": "string" }
-        }
-      },
-      "content": {
-        "application/octet-stream": {
-          "schema": {
-            "type": "string",
-            "format": "binary"
-          }
-        }
-      }
-    }
-  }
-}
-```
-
-根据文件类型可将媒体类型换成 `text/csv`、`application/pdf` 或 Excel 对应类型。跨域请求若读取不到文件名，后端还必须暴露 `Content-Disposition` 响应头。
-
-## 标准代码骨架
-
-### 生成方法已包含 responseType
-
-```typescript
-import { ref } from 'vue';
-import { handleBlobResponse } from '@yss-ui/utils';
-import { downloadAccessSecret } from '@/api/generated/quality';
-
-/** 微应用 mutator 返回的文件下载响应。 */
-type BlobDownloadResponse = {
-  data: Blob;
-  headers: Record<string, string>;
-};
-
-/** 文件下载进行中状态。 */
-const downloading = ref(false);
-
-/** 下载密钥文件。 */
-const downloadFile = async (key: string): Promise<void> => {
-  if (downloading.value) return;
-
-  downloading.value = true;
-  try {
-    const res = (await downloadAccessSecret(key)) as unknown as BlobDownloadResponse;
-    handleBlobResponse(res.data, res.headers);
-  } catch {
-    // mutator 已展示错误；此处只阻止 reject 继续向 UI 事件传播。
-  } finally {
-    downloading.value = false;
-  }
-};
-```
-
-### 生成方法缺少 responseType
-
-只改调用行，其他流程保持一致：
-
-```typescript
-const res = (await downloadAccessSecret(key, {
-  responseType: 'blob',
-})) as unknown as BlobDownloadResponse;
-```
-
-若 mutator 与 Orval 返回类型已经准确声明为 `{ data: Blob; headers: ... }`，直接使用生成类型，删除不必要的类型断言。
-
-## 响应约定
-
-- 后端成功响应应返回真实文件流，并设置 `Content-Disposition: attachment; filename*=UTF-8''...`。
-- mutator 对 Blob 成功响应返回 `{ data, headers }`，以便 `handleBlobResponse` 获取文件名。
-- HTTP 错误的 Blob JSON 由全局错误处理器解析并 reject，业务 Hook 不重复解析或提示。
-- HTTP 200 且 body 是 Blob 包装的业务错误时，当前模板不会自动 reject；必须修复契约或统一拦截器后再交付。
-- `handleBlobResponse` 找不到文件名时会使用 `download`；应优先补齐后端响应头，而不是在每个页面手写解析逻辑。
-
-## 交付检查清单
-
-- [ ] 已检查 OpenAPI 二进制响应声明和 Orval 生成方法。
-- [ ] 仅在生成方法缺少配置时，第二参数传入了 `{ responseType: 'blob' }`。
-- [ ] 已从 `@yss-ui/utils` 导入并调用 `handleBlobResponse(res.data, res.headers)`。
-- [ ] 未修改 Orval 生成文件，未重复实现文件名解析或浏览器下载逻辑。
-- [ ] Blob 成功响应保留了 `data` 与 `headers`，类型断言只位于 API 边界。
-- [ ] 已处理 loading、防重复点击和 `finally` 恢复。
-- [ ] 未在 catch 中重复业务错误 Toast。
-- [ ] 中文文件名、普通文件名和缺失文件名场景均已验证。
-- [ ] HTTP 错误的 Blob JSON 会 reject；如存在 HTTP 200 Blob 业务错误契约，已修正后端状态码或 mutator。
-- [ ] 下载文件可以正常打开，格式和内容与接口预期一致。
-
-## 失败兜底策略
-
-- 生成方法不支持第二参数时，先确认 Orval `options: true`；修正配置并重新生成，禁止手改生成文件。
-- `res.headers` 为空时，检查 mutator 是否错误地只返回 `data`，以及后端/CORS 是否暴露 `Content-Disposition`。
-- 下载到 JSON 错误文件时，先确认 HTTP 状态码：非 2xx 检查全局错误处理器，HTTP 200 检查后端契约并在 mutator 统一补齐；禁止把解析逻辑复制到每个业务 Hook。
-- 文件名始终为 `download` 时，优先修复后端 `Content-Disposition`；无法改后端时再评估统一扩展 YSS 下载工具。
-- 超大文件导致内存压力时，改用后端临时 URL、分片或流式下载方案，不强行把全部内容载入 Blob。

package/template/.hermes/skills/file-export-download/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "YSS 文件导出下载"
-  short_description: "规范 Orval Blob 导出、responseType 配置与文件下载处理"
-  default_prompt: "使用 $file-export-download 实现类型安全的文件导出下载，并正确处理 Blob、响应头和文件名。"