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.
git clone --depth 1 https://github.com/shiwenwen/hope-agent /tmp/ha-coding-common && cp -r /tmp/ha-coding-common/skills/ha-coding-common ~/.claude/skills/ha-coding-commonSKILL.md
# 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 1. Follow the user's current request. 2. Read and follow the nearest `AGENTS.md` and repository instructions. 3. Preserve existing architecture and local conventions unless the task requires changing them. 4. 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 1. Inspect the final diff and current worktree state. 2. Use `ha-verify` to map requirements to the smallest sufficient evidence. 3. Report what changed, what was verified, and any real residual risk. 4. 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."
>
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.
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 + attendees, contact (联系人) user/department lookup, hire (招聘) job/talent/application listing. Trigger on phrases like 'OKR 周报', '把这份文档发到飞书云盘', '给团队拉个评审会议', '查 [姓名] 的联系方式', '撤销那条审批', '/wiki 链接', or any request that mentions a feishu / lark URL / token (doxcn.../bascn.../wikcn.../boxcn.../om_...).
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 agent to open / control / click / scrape / log into / verify something in a web app ('open X and click Y', '打开 X 然后点击 Y', 'log into my Gmail', 'scrape this page', 'fill out the form on X'); user reports a flow that requires real browser context (cookies, JS-rendered content, OAuth).
Discover and install third-party skills from external registries when the user needs a capability that no currently-active skill covers. Trigger when: (1) the user explicitly asks 'find a skill for X', 'is there a skill that does X', 'install a skill to X', (2) the user requests a well-known integration (Slack, Notion, Trello, GitHub, Hue, Sonos, iMessage, weather, TTS, transcription …) that isn't in the active skill catalog, (3) you are about to hand-write ad-hoc shell / API code for a domain that almost certainly has a published skill. Do NOT trigger if an active skill already covers the need — scan the visible skill catalog first.
Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / background jobs) directly via the `exec` tool to investigate problems, analyze usage, and locate root causes. Trigger on: user reports something broken / failing / slow / stuck / not responding ('X 不工作', 'X 报错', 'X 卡住', '为什么 X 失败', 'why did X fail', 'show me the logs', 'check what happened'); ad-hoc data analysis ('this week's token usage', '最近调用最多的工具', 'how many subagent runs failed', 'tool error rate', 'find sessions where X happened'); verifying a fix ('did the error stop after I changed Y'). Use BEFORE asking the user to paste log snippets — the data is on disk, query it directly. Read-only — SELECT only, never UPDATE/DELETE/INSERT/DROP.
Hope Agent native macOS desktop control — the standard `mac_control` status / diagnostics / apps / dock / spaces / snapshot / visual / windows / menu / clipboard / dialog loop, target-first action rules, no-blind-coordinate policy, and recovery for stale AX/window/menu/dialog state. Load whenever using `mac_control`, or when the user asks to control local Mac apps, Dock, Spaces, click/type/menu/window/dialog/clipboard, automate Finder/TextEdit/System Settings, visually locate UI, or says 控制 Mac, macOS 自动化, 点按钮, 打开应用, Dock, Space, 关闭窗口, 菜单点击, 视觉定位.
Self-understanding and issue reporting for Hope Agent itself. Use when the user asks how Hope Agent works internally, asks about its own source code/docs/runtime behavior, reports a bug/failure/slowness/crash, asks to diagnose logs, or asks to create/submit a GitHub issue for a bug, feature request, or improvement (including when there is no bug). Chinese triggers: 自查, 了解自己, 自我诊断, 排查 Hope Agent, 提交 issue, 需求 issue, 功能改进.