菜单
Use when proving a deployed or built change actually works, verifying a feature locally with no manual step, or deciding how to prove this specific change works. Triggers on "prove it works", "verify the feature", "reproducible locally", "no manual step", "deploy-verify".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/namjul/dotfiles --skill reproducible-locally命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Kurzer faktischer Wochenbericht zur Schwangerschaftswoche. Nutzen bei /ssw, „SSW N“, oder wenn ein Schwangerschafts-Wochenbericht gewünscht ist.
Use when turning a plan, request, or agreed change into working code. Triggers on "implement", "implement the plan", "build this", "code this", "execute the plan". Turns clear intent into working code, tests, and verification.
Test a task for a pocket of reducibility and, if one exists, unfold it into a generative sequence — an ordered list of structure-preserving transformations a fresh agent can execute end to end. Use when the user says "unfold", asks for a generative sequence, or wants a task compressed into a paste-ready build sequence. Do NOT force this on tasks whose core is judgment, taste, or values — declare those irreducible instead, and offer fundamental-sequence discovery mode, capturing any generative sequence found along the way.
| name | reproducible-locally |
| description | Use when proving a deployed or built change actually works, verifying a feature locally with no manual step, or deciding how to prove this specific change works. Triggers on "prove it works", "verify the feature", "reproducible locally", "no manual step", "deploy-verify". |
Source: https://github.com/juanibiapina/dotfiles/tree/672f14c8eb2533ae201cc7e48cf364df224d5a2c/agents/skills/reproducible-locally/SKILL.md Imported from commit:
672f14c8eb2533ae201cc7e48cf364df224d5a2cLicense: MIT, Copyright (c) 2026 Juan Ibiapina
A change is done when its changed behaviour has repeatable, automated evidence. Run the proof from the local workflow when possible; target the environment where the behaviour exists when necessary.
Do not treat tapping through a build, clicking a dashboard, or eyeballing a URL as release evidence for known behaviour. Exercise the changed behaviour and assert an observable postcondition: a response, persisted state, emitted event, metric, or other externally visible effect.
A successful build proves the build succeeded. A successful behavioural check proves the scenario and assertion it exercised.
Report one outcome:
Devise how to prove this specific change each time; there is no standing recipe.