菜单
End-to-end feature workflow — plan (in plan mode) → approval → implement → ./doit.sh full-check → commit → fixups. Load whenever the user invokes /ojhunt-implement or asks to implement/build/add a feature and wants the full plan-implement-test-commit loop rather than a one-off edit.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Workflow for implementing or debugging an OJ crawler — accessibility check, data-source discovery, decision tree, and verification checklist. Load whenever the task is to add a new crawler or fix a broken one. For the crawler reference (metadata schema, login types, templates, HTML parsing, SSL, archived rules) read docs/dev/crawlers.md.
Single source of truth for where each piece of knowledge belongs (docs/dev/, docs/, ADRs, skills, hooks, commands, CLAUDE.md) and what must NOT be documented because it already lives in code or tests. Load BEFORE writing or editing ANY documentation, ADR, or skill — and whenever choosing where a fact should live or whether to document it at all — not only when explicitly asked to "update docs" or "capture learnings".
Git operations, commit conventions, and ADRs. Load when preparing to commit, writing agent/worker prompts that include git steps, planning a change that may warrant an ADR, or evaluating whether a design decision needs documentation.
| name | ojhunt-implement |
| description | End-to-end feature workflow — plan (in plan mode) → approval → implement → ./doit.sh full-check → commit → fixups. Load whenever the user invokes /ojhunt-implement or asks to implement/build/add a feature and wants the full plan-implement-test-commit loop rather than a one-off edit. |
This skill is the procedure for taking a feature from request to committed code.
It only orchestrates — the conventions for each area (Python style, tests, web
layer, crawlers, …) live in docs/dev/*.md, indexed by the routing table in
docs/development.md. Read the matching doc before you write code in that area.
$ARGUMENTS
Work through these in order. Each step exists to keep a fast feedback loop and to make the change reviewable — don't skip ahead.
Plan first, and get approval. If you are not already in plan mode, enter it
(EnterPlanMode) — planning before editing is what lets the user redirect the
approach cheaply, before any code is written. Explore the relevant code, read the
matching docs/dev/*.md, then draft a concrete plan and present it for approval
(ExitPlanMode). Do not implement until the user approves — the request above
is a starting point, not a mandate to build immediately.
Implement the approved plan. Follow the conventions in the docs/dev/ file(s)
for the area you're touching. Keep the change scoped to what was approved.
Verify with ./doit.sh full-check. This starts the dev server, runs lint +
unit + e2e + visual tests, then stops the server — the same gate you'd want green
before committing. When it fails, read .doit/<task>.log (e.g.
grep -nE 'FAILED|error' .doit/test-e2e.log) rather than re-running with
| tail/| grep; the full output is already captured there. Fix and re-run until
green. If a UI change legitimately shifts a visual snapshot, regenerate it with
./doit.sh update-snapshots and commit the updated snapshot alongside the change.
Commit. Invoke the ojhunt-commit skill to create the commit(s) using the
project's conventions (intent-capturing messages, Resolves #N, ADRs when a
decision warrants one).
Handle follow-up suggestions as fixups. When the user has more changes after
the commit, implement them and record each as a git commit --fixup=<sha> commit
— never git commit --amend — so the user can review what changed. Follow the
fixup-first, squash-last workflow in the ojhunt-commit skill: create the
fixup!, wait for approval, then autosquash.
