Русский

Process

The working cycle codeharness enforces on every project that adopts it. This page is a map of the cycle and where each part is defined — not a restatement of the rules themselves. For the normative text, follow the links.

The cycle: plan → consent → issue → work → verification → review

1. Plan. Any meaningful repository change (code/tests/config/CI/specs/ build/VERSION/documentation) requires a short plan (what, why, risk) and explicit consent before work starts. Defined in CLAUDE.md §1. One exception: routine status-file updates (see session-memory.md) don't need a separate plan — they're bookkeeping for the current task, not a new change.
2. Consent. Work does not start on a meaningful change until the user has explicitly agreed to the plan. CLAUDE.md §1 is also explicit that silent agreement isn't required from the user's side either — if there's a better approach, say so before the decision is locked in.
3. Issue. Same scope as the plan gate — any meaningful repository change needs an issue in the tracker. Order matters: plan agreed → issue created or verified → work starts, not the reverse. Full rules, exceptions (single obvious typo, explicit user override) and label discipline: issue-tracker.md.
4. Work. Once inside an approved plan, don't stop and re-ask except for a real blocker (unexpected failure, conflict, missing information): incident-recovery.md. Commit discipline (one logical step = one commit, when to push, batch rules, release mechanics): git-discipline.md. Code edits inside an existing project follow code-style.md (scope discipline, fail-fast, no unrequested dead-code/back-compat layers).
5. Verification. Mandatory after the work, before reporting done — never claim success from a final OK line alone; baseline discipline for pre-existing red checks; what counts as a real pytest run vs. "no tests ran": testing-and-verification.md.
6. Review. Not a separate codeharness file by itself — review happens through the issue/PR mechanics in issue-tracker.md and through the normal close-on-merge convention (closes #N tied to the branch merge target, not the working branch).

Task routing: Маршрут: inline | skill | agent

Before doing any task, codeharness requires declaring a route line and a short justification — this is a visibility gate, not busywork: a skipped skill or agent is treated as a routing failure, not forgetfulness.

• inline — trivial edit, direct factual answer, or local read of one explicitly named file/fragment.
• skill:<name> — a specialized process exists for the task (design, debugging, review); process skills before implementation skills.
• agent:<name> — the task needs to search for the answer, scan multiple modules, gather project-wide context, or process a large volume — offload it, bring back a short verifiable result.

The route applies to the current phase; when the executor changes, declare a new route (a chain like skill → agent → inline is normal, not a one-time choice). Full detail, the Explore/Plan caveat (they don't load CLAUDE.md), and the optional hook template for hard enforcement: task-routing.md. Subagent/model selection specifics (confirmation gates by model cost, context-offload principle): subagents-and-models.md.

Versioning: SemVer

Single source of truth is the VERSION file at the project root; SemVer applies. A release bumps VERSION, updates the changelog, and requires fully green checks (baseline exceptions for pre-existing red do not carry over to a release). Build identifiers between releases, and the full release procedure: versioning.md and git-discipline.md.

Persistent state across the cycle

Chat history is not reliable (context limits, compaction, new sessions). State that must survive a session lives in the repository — status file, decisions file, CLAUDE.md itself — not only in conversation. Triggers for updating it (handoff, model switch, compaction risk, end of a major step) and the format: session-memory.md. Recovery procedure after a dropped/corrupted session: incident-recovery.md.

Priority when rules conflict

Core (CLAUDE.md) outranks any single .ai-workflow/*.md. A conflict between two topic files is not resolved by Claude on its own — it's raised to the user. See CLAUDE.md §0.