菜单
Property-based testing. Use for tests and reviews involving broad structured domains, parsers and codecs, canonicalizers and validators, compact postcondition oracles, differential models, stateful APIs and protocols, or concurrent schedules.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Whamp/deep-swe-bench --skill property-based-testing命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Write a viral-but-honest X/Twitter thread for a benchmark or eval result (e.g. DeepSWE, ProgramBench, ponytail, pi-observational-memory runs). Use when the user asks to write, draft, rewrite, iterate on, or render a tweet thread about benchmark results, eval findings, A/B comparisons, agent evaluations, or model measurements, or says "thread", "tweet", "X post", or references the tweet-craft process. Enforces accuracy, human voice, and the accumulated review lessons. Read FEEDBACK_LOG.md before drafting.
Fetch a full X/Twitter thread — all posts with untruncated text plus images — without auth or the paid API. Use when the user wants to retrieve, extract, scrape, pull, save, or download an X/Twitter thread, tweet text, or tweet images, mentions a status URL or tweet id, or asks to get the content of a thread/post.
Use before preparing or executing a confirmed deep-swe-bench launch, especially when configs use advisor, observational-memory workers, subagents, local-vLLM shims, or any model beyond the main executor; use before claiming a launch is working.
基于 SOC 职业分类
正在显示 SKILL.md
| name | property-based-testing |
| description | Property-based testing. Use for tests and reviews involving broad structured domains, parsers and codecs, canonicalizers and validators, compact postcondition oracles, differential models, stateful APIs and protocols, or concurrent schedules. |
A property test searches a quantified domain for a counterexample and shrinks failures. A green run is evidence over the searched cases, not proof over every value.
Use property-based testing when a broad or structured domain, operation sequence, or schedule can challenge a compact oracle. Prefer example tests when the meaningful cases are a small explicit table, the only oracle would duplicate the implementation, or effects cannot be isolated within the test budget.
Write the candidate in this form:
Generate [domain] to challenge [risk], checked by [oracle].
Complete when: all three blanks are concrete. If the oracle blank remains vague, use examples or first clarify the contract.
Write the property before its test code:
For every
xin domainDsatisfying preconditionP, observing the system produces relationRunder equivalence≈.
Ground D, P, R, and ≈ in specifications, public documentation, types, callers, and established tests. Treat names as search leads. Separate supported inputs from invalid inputs when their contracts differ, including the required error or rejection behavior.
Complete when: every term in the quantified statement has a source, and unresolved product decisions have been surfaced to the user.
Load designing properties. Choose the simplest observation independent enough to catch a plausible faulty implementation. For each proposed property, name the counterfeit implementation or bug class it should reject. Build a portfolio only when distinct risks need distinct observations; property count is not a quality target.
Complete when: every property has a grounded contract, an observable oracle, and at least one named counterfeit it should reject.
Load generators and shrinking and the adapter for the repository's installed framework:
Use the existing dependency and project test conventions. When no property-testing dependency exists, follow the repository's dependency policy; if adding one is not already authorized, present the leverage sentence before changing the manifest.
For state or operation sequences, also load stateful and concurrent testing. When ordinary generation cannot reach the risk-bearing cases, load advanced search.
Complete when: the full supported domain is reachable in principle or each deliberate scope limit is justified by measured cost; dependent inputs are generated jointly; risk-bearing categories are observed; and failures can shrink to replayable cases.
Run the property against the target defect, the pre-fix implementation, or a temporary plausible mutant. A green property against its named counterfeit has not yet earned confidence. Keep mutations local and out of the final change.
Complete when: the property set goes red on the target defect and on every named counterfeit that can be safely simulated; record any unproven counterfeit.
Run the repository's normal test command. Keep the suite's existing settings first, then adjust search effort from measured runtime and observed reach. Preserve exact replay data for failures and use triaging counterexamples before changing production code.
Keep a durable explicit example when a minimized case communicates a named boundary or regression better than replay metadata alone; retain the general property too.
Complete when: the corrected implementation is green, the search fits the intended suite budget, the failure is replayable, and the ordinary example-based tests still pass.
