Claude Skills by HaipingShi

Before coding, make sure the request actually serves the project goal, and turn it into a clear task with goal, scope, and a way to verify it.

Tell apart raw material, working notes, and permanent project files so temporary stuff never gets treated as the real thing.

Keep simple architecture/data/flow diagrams up to date when the project gets structurally complex.

Run the project's available checks (tests, lint, build) before stopping, handing off, or committing finished work.

End a work session cleanly: report what happened, commit safe files, and leave one clear next step for whoever resumes. Use when running `coderail done` or writing the Owner Receipt.

For vague, big, or risky requests, write down the plan (what, which files, how to verify) and get a yes before coding.

Health-check the project's CodeRail setup and state; reports what is missing or inconsistent and how to fix it.

Build and sharpen the project's domain language. Use when discussing project terminology, writing or editing CONTEXT.md, or recording or editing an ADR in docs/DECISIONS.md.

The final verification before marking a task done: evidence exists, changes stayed in the agreed files, docs are synced.

Finish a task the safe way: verify it, keep changes in scope, sync the docs, commit safe files, and state the next step. Run this instead of declaring done from memory.

Detect when the work has drifted away from the project goal, the task list, or the recorded history.

For long-running autonomous work: at each checkpoint, decide deterministically whether to continue, repair, advance, or stop.

Work through the approved tasks continuously, staying inside each task's file scope and stop conditions.

Write or update the handoff file so the next session (or another person/agent) can resume without re-discovering everything. Use when pausing or ending work, or when asked to produce a handoff.

When the test/check setup itself is broken, fix it without weakening what it verifies.

Rebuild a clear picture of project state (active task, gaps, next step) before resuming or when things feel confusing.

Backfill missing connections in the project history so every change can be traced to a task and a reason.

Set up CodeRail in a repository: goal file, task list, and the three everyday commands (start / check / done).

Turn a request into a concrete task: goal, exact files allowed, how to verify, when to stop.

For bugs, parsers, domain logic, APIs, and shared utilities: require a failing test first, then make it pass.

Record a meaningful action (change, decision, verification) in the project history so it can be found later. Use when logging a completed change or appending to TRACE_INDEX, RUNLOG, or DECISIONS.