Hope Coding Common
Use this as the default discipline for coding work. Load a narrower ha-*
coding skill when planning, debugging, testing, review, multi-agent execution,
verification, or Workflow authoring is the real center of the task.
Precedence
- Follow the user's current request.
- Read and follow the nearest
AGENTS.md and repository instructions.
- Preserve existing architecture and local conventions unless the task requires
changing them.
- Treat this skill as methodology only. It never grants permissions, changes a
mode, or overrides a runtime safety gate.
Start From Evidence
- Inspect the worktree, relevant files, nearby tests, and existing docs before
choosing an implementation.
- Search with
rg / rg --files when available; read surrounding code rather
than editing from a single match.
- Assume uncommitted changes may belong to the user. Never revert, overwrite, or
reformat unrelated work.
- Prefer existing helpers, error types, state models, and ownership boundaries.
Size The Work
Small and clear
Act directly when the behavior, owning file, and verification path are obvious.
Do not create a formal plan, new abstraction, or subagent ceremony merely because
the task is coding.
Multi-step or uncertain
Use ha-coding-plan when the change spans ownership boundaries, has ordering
constraints, carries migration risk, or needs explicit completion criteria. In
normal execution mode, continue implementing after the plan when the next action
is clear. Plan Mode remains read-only.
Specialized work
- Bug, regression, crash, or failing test:
ha-debug.
- Test design or regression coverage:
ha-test-strategy.
- Review request:
ha-code-review.
- Independent fan-out with meaningful parallel benefit:
ha-multi-agent-coding.
- Proof of completion:
ha-verify.
- Durable
workflow.js: ha-workflow-script.
Load the smallest useful set. Do not activate every coding skill up front.
Control-Plane Boundaries
- Goal defines the durable outcome and completion criteria.
- Plan describes an implementation approach; it does not create a Goal.
- Task exposes current progress and must reflect actual state.
- Workflow executes one durable, observable orchestration run.
- Loop decides when another turn should be triggered.
- Worktree isolates writes; it is not a planning or completion signal.
Do not silently enable or complete any control plane from skill instructions.
Change Discipline
- Keep edits scoped to the requested behavior and owning subsystem.
- Add an abstraction only when it removes real complexity or matches a local
pattern.
- Use structured parsers and APIs for structured data.
- Avoid unrelated cleanup, metadata churn, generated files, and speculative
compatibility layers.
- For multi-step work, keep user-visible tasks truthful and only one task in
progress unless the runtime is genuinely executing independent work.
- Ask only when the next step is unsafe, irreversible, or cannot be inferred
from available evidence.
Finish The Work
- Inspect the final diff and current worktree state.
- Use
ha-verify to map requirements to the smallest sufficient evidence.
- Report what changed, what was verified, and any real residual risk.
- Do not claim completion from intent, a passing unrelated command, or child
Agent completion alone.
Smoke Prompts
- "Implement this small feature and keep the diff minimal."
- "Finish this refactor without touching unrelated user changes."
- "Continue the current coding task through targeted verification."
1---2name: ha-coding-common3description: 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.4---5
6# Hope Coding Common
7
8Use this as the default discipline for coding work. Load a narrower `ha-*`
9coding skill when planning, debugging, testing, review, multi-agent execution,
10verification, or Workflow authoring is the real center of the task.
11
12## Precedence
13
141. Follow the user's current request.
152. Read and follow the nearest `AGENTS.md` and repository instructions.
163. Preserve existing architecture and local conventions unless the task requires
17 changing them.
184. Treat this skill as methodology only. It never grants permissions, changes a
19 mode, or overrides a runtime safety gate.
20
21## Start From Evidence
22
23- Inspect the worktree, relevant files, nearby tests, and existing docs before
24 choosing an implementation.
25- Search with `rg` / `rg --files` when available; read surrounding code rather
26 than editing from a single match.
27- Assume uncommitted changes may belong to the user. Never revert, overwrite, or
28 reformat unrelated work.
29- Prefer existing helpers, error types, state models, and ownership boundaries.
30
31## Size The Work
32
33### Small and clear
34
35Act directly when the behavior, owning file, and verification path are obvious.
36Do not create a formal plan, new abstraction, or subagent ceremony merely because
37the task is coding.
38
39### Multi-step or uncertain
40
41Use `ha-coding-plan` when the change spans ownership boundaries, has ordering
42constraints, carries migration risk, or needs explicit completion criteria. In
43normal execution mode, continue implementing after the plan when the next action
44is clear. Plan Mode remains read-only.
45
46### Specialized work
47
48- Bug, regression, crash, or failing test: `ha-debug`.
49- Test design or regression coverage: `ha-test-strategy`.
50- Review request: `ha-code-review`.
51- Independent fan-out with meaningful parallel benefit: `ha-multi-agent-coding`.
52- Proof of completion: `ha-verify`.
53- Durable `workflow.js`: `ha-workflow-script`.
54
55Load the smallest useful set. Do not activate every coding skill up front.
56
57## Control-Plane Boundaries
58
59- Goal defines the durable outcome and completion criteria.
60- Plan describes an implementation approach; it does not create a Goal.
61- Task exposes current progress and must reflect actual state.
62- Workflow executes one durable, observable orchestration run.
63- Loop decides when another turn should be triggered.
64- Worktree isolates writes; it is not a planning or completion signal.
65
66Do not silently enable or complete any control plane from skill instructions.
67
68## Change Discipline
69
70- Keep edits scoped to the requested behavior and owning subsystem.
71- Add an abstraction only when it removes real complexity or matches a local
72 pattern.
73- Use structured parsers and APIs for structured data.
74- Avoid unrelated cleanup, metadata churn, generated files, and speculative
75 compatibility layers.
76- For multi-step work, keep user-visible tasks truthful and only one task in
77 progress unless the runtime is genuinely executing independent work.
78- Ask only when the next step is unsafe, irreversible, or cannot be inferred
79 from available evidence.
80
81## Finish The Work
82
831. Inspect the final diff and current worktree state.
842. Use `ha-verify` to map requirements to the smallest sufficient evidence.
853. Report what changed, what was verified, and any real residual risk.
864. Do not claim completion from intent, a passing unrelated command, or child
87 Agent completion alone.
88
89## Smoke Prompts
90
91- "Implement this small feature and keep the diff minimal."
92- "Finish this refactor without touching unrelated user changes."
93- "Continue the current coding task through targeted verification."
shiwenwen