菜单
Systematically discover edge cases by category with concrete examples. Use when expanding coverage for input domains, state transitions, timing, and failure modes.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/llipe/dev-tasks --skill activity-edge-case-refinement命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | activity-edge-case-refinement |
| description | Systematically discover edge cases by category with concrete examples. Use when expanding coverage for input domains, state transitions, timing, and failure modes. |
Systematic edge-case discovery by category with concrete examples for each. Produces a categorized edge-case catalog mapped to acceptance criteria, ensuring no high-risk boundary goes untested. Invoked by the verifier agent in Design Mode.
RFC 2119 Notice: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
Discover and catalog edge cases across all relevant categories for the feature under test. Every edge case MUST be tied to at least one acceptance criterion and include a concrete, testable example.
This activity assumes:
verifier).verifier.You MUST evaluate every category below against the source artifact. For each category that applies, produce ≥1 concrete edge case. For categories that do not apply, explicitly note N/A — {reason}.
Boundary values, empty/null/missing inputs, maximum-length strings, special characters, Unicode, encoding mismatches.
Example: A name field accepts 1–100 characters. Edge cases: empty string, 1 character, 100 characters, 101 characters, string with only whitespace, string with emoji, string with null bytes.
Invalid state transitions, re-entrant operations, concurrent state changes, transitions from terminal states.
Example: An order can move pending → confirmed → shipped → delivered. Edge cases: attempt pending → shipped (skip confirmed), attempt delivered → pending (reverse), call confirm twice on the same order.
Race conditions, timeouts, out-of-order events, duplicate submissions, slow network responses.
Example: Two users submit the same promo code simultaneously. Edge case: both requests arrive before either is committed — does the system apply the code twice or correctly reject one?
Repeated identical requests, retry storms, duplicate webhook deliveries.
Example: POST /api/payments is called twice with the same idempotency key. Edge case: second call should return the same result without creating a duplicate payment.
Network failures mid-operation, partial writes, downstream service unavailability, disk full, database connection loss.
Example: Payment gateway returns a timeout after charging the card. Edge case: system must not create a second charge on retry — check for charge-before-confirm pattern.
Expired tokens, revoked permissions mid-session, privilege escalation, cross-tenant data access.
Example: User A has read access to project X. Edge case: User A attempts DELETE /api/projects/X — should receive 403, not 404 or 500.
Integer overflow, float precision, date boundaries (leap years, DST transitions, epoch limits), empty collections, maximum record counts.
Example: A date picker allows selecting a delivery date. Edge cases: Feb 29 in a leap year, Feb 29 in a non-leap year, Dec 31 23:59:59 UTC, Jan 1 00:00:00 UTC, dates in year 2038.
Memory pressure, connection pool depletion, rate limiting, disk space, file descriptor limits.
Example: API rate limit is 100 requests/minute. Edge cases: 100th request (should succeed), 101st request (should return 429), requests resume after the window resets.
Backward compatibility, deprecated field handling, schema migration, version header omission.
Example: API v2 renames userName to username. Edge cases: v1 client sends userName to v2 endpoint, v2 client sends username to v1 endpoint, request with no version header.
### EC-{id}: {Edge-Case Title}
| Field | Value |
| ------------------- | --------------------------------------------------------------------------------------- |
| **AC(s)** | AC-{n} |
| **Category** | {category name from list above} |
| **Input / Setup** | {Concrete input or precondition} |
| **Expected Result** | {Observable behavior} |
| **Risk if Missed** | {Consequence of not testing this — data loss, security breach, silent corruption, etc.} |
Given a user story with AC-5: "Discount code can only be used once per user."
Deriving the edge case:
| Field | Value |
|---|---|
| AC(s) | AC-5 |
| Category | Idempotency, Timing & Concurrency |
| Input / Setup | User sends two POST /api/cart/discount requests with the same code in parallel (within 50ms). |
| Expected Result | Exactly one application succeeds. The second returns an error indicating the code was already used. |
| Risk if Missed | User gets double discount — revenue loss, potential abuse vector. |
Validating "requested vs delivered":
This skill returns a categorized list of edge cases in the template format above. The calling agent (verifier) assembles them into the edge-case section of the test plan.
Use this checklist to verify completeness before returning results:
N/A with reason.EC-1, EC-2, …).