/ha-test-strategy
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.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ha-test-strategy
Context 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.
SKILL.md
ha-test-strategy.SKILL.mdname: 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"]
Hope Test Strategy
Choose tests that reduce uncertainty about the requested behavior. Test-first is a valuable technique, not an unconditional law.
Precedence
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.
Select The Strategy
Test-first
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.
Regression-first
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.
Characterization-first
For legacy, poorly documented, or risky refactors, capture current intentional behavior before changing structure. Do not freeze a known bug as desired behavior.
Implementation-first with immediate coverage
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.
No new automated test
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.
Choose The Layer
- Unit: pure logic, state transition, parser, policy, or failure classification.
- Integration: persistence, adapter, protocol, or cross-module contract.
- E2E: a user-critical path that only becomes true across the full stack.
- Manual smoke: visual layout, OS integration, credentials, or external state
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.
Test Quality
- Assert observable behavior, not incidental implementation details.
- Keep fixtures deterministic and failures diagnostic.
- Cover the demonstrated edge, including cancellation, retry, stale state, or
partial failure when relevant.
- Avoid mocks that erase the boundary being tested.
- Do not weaken existing assertions merely to make a change pass.
Execute Efficiently
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.
Smoke Prompts
- "Choose and add the right regression test for this bug."
- "Refactor this legacy parser without freezing the broken behavior."
- "Decide whether this UI change needs unit, E2E, or manual evidence."
Read more
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"]
Hope Test Strategy
Choose tests that reduce uncertainty about the requested behavior. Test-first is a valuable technique, not an unconditional law.
Precedence
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.
Select The Strategy
Test-first
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.
Regression-first
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.
Characterization-first
For legacy, poorly documented, or risky refactors, capture current intentional behavior before changing structure. Do not freeze a known bug as desired behavior.
Implementation-first with immediate coverage
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.
No new automated test
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.
Choose The Layer
- Unit: pure logic, state transition, parser, policy, or failure classification.
- Integration: persistence, adapter, protocol, or cross-module contract.
- E2E: a user-critical path that only becomes true across the full stack.
- Manual smoke: visual layout, OS integration, credentials, or external state
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.
Test Quality
- Assert observable behavior, not incidental implementation details.
- Keep fixtures deterministic and failures diagnostic.
- Cover the demonstrated edge, including cancellation, retry, stale state, or
partial failure when relevant.
- Avoid mocks that erase the boundary being tested.
- Do not weaken existing assertions merely to make a change pass.
Execute Efficiently
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.
Smoke Prompts
- "Choose and add the right regression test for this bug."
- "Refactor this legacy parser without freezing the broken behavior."
- "Decide whether this UI change needs unit, E2E, or manual evidence."
🦭 会记忆、能持续推进目标、会动态编排多 Agent 的跨端桌面 AI 助手,也可服务化常驻 NAS / 云端 | A cross-device desktop AI agent with memory, autonomous goals, dynamic workflows, and headless deployment
Repo: shiwenwen/hope-agent
Other skills on hope-agent.
- /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 pre-send self-check.
Open skill - /feishu
Use when the user mentions 飞书 / Feishu / Lark workspace operations: docx (云文档) read/write, bitable (多维表格) records / views / dashboards, drive (云盘) upload/download, wiki (知识库) link resolution, approval (审批) instance create/cancel/query, calendar (日历) event create/list/update +
Open skill - /ha-browser
Hope Agent browser automation — the standard `status → tabs → snapshot → act` loop, stale-ref recovery rules, and what to do when login / 2FA / captcha / camera-prompt / dialog blocks progress. Load this skill whenever you reach for the `browser` tool. Trigger on: user asks the
Open skill - /ha-code-review
Hope-native review of uncommitted, staged, commit, branch, or PR changes: discover concrete regressions, independently verify candidates, and report actionable findings first without speculative noise.
Open skill - /ha-coding-common
Hope-native baseline for implementing, fixing, refactoring, and maintaining code: inspect the repository first, protect user changes, keep scope narrow, and finish with direct evidence.
Open skill - /ha-coding-plan
Hope-native implementation planning for non-trivial code changes: ground the plan in repository evidence, order dependencies, name critical files and risks, define verification, then continue execution when allowed.
Open skill

