ワンクリックでManusで任意のスキルを実行

ojhunt-implement

スター5

フォーク1

更新日2026年7月10日 15:10

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 ページを確認してインストールできます。

Manusで実行

ソース

Liu233w

Liu233w/ojhunt-lite

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Implementing a feature

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.

User request

$ARGUMENTS

Workflow

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.

このリポジトリの他の Skills

同じリポジトリ

ojhunt-crawlers

Liu233w/ojhunt-lite

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.

2026-07-105

ojhunt-update-env

Liu233w/ojhunt-lite

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".

2026-07-105

ojhunt-commit

Liu233w/ojhunt-lite

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.

2026-05-055

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.

Implementing a feature

User request

$ARGUMENTS

Workflow

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.