email-draft
Use when the user asks to draft, polish, translate, or reply to an email. Produces a clean draft with subject line, greeting, body, and sign-off, plus a…
Hope-native test strategy for features, fixes, and refactors: select test-first, regression-first, characterization, integration, E2E, or manual evidence according to risk and repository rules.
$ npx -y skills add shiwenwen/hope-agent --skill ha-test-strategy --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/ha-test-strategyContext preview
The summary Claude sees to decide when to auto-load this skill.
Hope-native test strategy for features, fixes, and refactors: select test-first, regression-first, characterization, integration, E2E, or manual evidence according to risk and repository rules.
name: ha-test-strategy description: "Hope-native test strategy for features, fixes, and refactors: select test-first, regression-first, characterization, integration, E2E, or manual evidence according to risk and repository rules." paths: ["*.rs", "*.ts", "*.tsx", "*.js", "*.jsx", "*.py", "*.go", "*.java", "*.kt", "*.swift", "*.c", "*.cpp", "*.h", "*.rb", "*.php", "*.sh"]
Choose tests that reduce uncertainty about the requested behavior. Test-first is a valuable technique, not an unconditional law.
Follow the user's request and repository instructions. Do not run broad suites, install dependencies, or rewrite test infrastructure when the project forbids or does not require it.
Prefer a failing test before implementation when the new contract is clear, the test seam is stable, and observing the failure proves the test is meaningful.
For a bug, reproduce the original failure in the narrowest credible automated test before or alongside the fix. Confirm it fails for the right reason, then passes after the root-cause change.
For legacy, poorly documented, or risky refactors, capture current intentional behavior before changing structure. Do not freeze a known bug as desired behavior.
Reasonable for exploratory seams, generated code, mechanical migrations, or UI work where the correct test boundary becomes clear only after a small reversible implementation. Add the relevant proof before claiming completion.
Reasonable for pure docs, trivial metadata, generated outputs, or low-risk mechanical changes when existing checks directly cover the risk. Explain the decision rather than adding a meaningless test.
that cannot be honestly simulated.
Use the lowest layer that proves the contract. Add a higher layer only for a boundary the lower layer cannot cover.
partial failure when relevant.
1. Run the narrowest new or failing test. 2. Run the nearest affected suite when justified. 3. Use `ha-verify` to decide whether broader gates are needed at closeout.
If a test is flaky or environment-blocked, investigate the cause. Do not rerun until green and call that proof.
🦭 会记忆、能持续推进目标、会动态编排多 Agent 的跨端桌面 AI 助手,也可服务化常驻 NAS / 云端 | A cross-device desktop AI agent with memory, autonomous goals, dynamic workflows, and headless deployment
Repo: shiwenwen/hope-agent
Use when the user asks to draft, polish, translate, or reply to an email. Produces a clean draft with subject line, greeting, body, and sign-off, plus a…
Use when the user mentions 飞书 / Feishu / Lark workspace operations: docx (云文档) read/write, bitable (多维表格) records / views / dashboards, drive (云盘)…
Hope Agent browser automation — the standard `status → tabs → snapshot → act` loop, stale-ref recovery rules, and what to do when login / 2FA / captcha /…
Hope-native review of uncommitted, staged, commit, branch, or PR changes: discover concrete regressions, independently verify candidates, and report actionable…
Hope-native baseline for implementing, fixing, refactoring, and maintaining code: inspect the repository first, protect user changes, keep scope narrow, and…
Hope-native implementation planning for non-trivial code changes: ground the plan in repository evidence, order dependencies, name critical files and risks,…