skills/skills/project-discipline/SKILL.md

name, author, version, description

name	author	version	description
project-discipline	ours	0.2.1	Codifies five cross-project discipline rules: (1) project CLAUDE.md / .wiki/CLAUDE.md / .tasks/ override defaults from other skills (specs → .wiki/concepts/, tasks → .tasks/); (2) master-only, no feature branches without approval; (3) semver bump on every edit of versioned artifacts (SKILL.md, package.json, pyproject.toml), recorded in commit; (4) push freely by default — no confirmation needed; a local push-gate skill (e.g. books — auto-deploy) overrides per project; force/delete/non-ff always ask; (5) transit/brainstorm workspaces — artifacts to .brainstorm/ or global wiki only via explicit user direction. Activated by "follow project discipline" trigger in CLAUDE.md (added by project-bootstrap v1.5.0+).

project-discipline

Four cross-project rules. Read at session start. Apply before any other skill's defaults touch paths, branches, versions, or remote pushes.

When this runs

At session start — when CLAUDE.md contains the line follow project discipline. The skill is a policy document; the agent reads it and applies the four rules to all subsequent work in the session.

On explicit reference — when the user says "use project discipline", "соблюди дисциплину", "проектные правила", "что у меня по правилам?", or close variants asking about/applying the rules.

The skill itself takes no actions and has no external side-effects. It instructs the agent how to behave.

Rule 1 — Project conventions override skill defaults

Before applying defaults from any other skill (frontend-design, mcp-builder, etc.), read in this order:

1. CLAUDE.md in the project root.
2. .wiki/CLAUDE.md (if it exists).
3. .tasks/STATUS.md (if it exists).

Any path, format, or workflow explicitly stated in those files overrides the skill default.

Concrete consequences:

• Specs / design documents go to .wiki/concepts/<topic>-design.md.
• Task tracking / implementation plans go to .tasks/<slug>.md plus a board entry in .tasks/STATUS.md (the using-tasks format).
• Frontmatter, naming conventions, log format — as described in the project's .wiki/CLAUDE.md.

If no convention is stated explicitly — fall back to the skill default.

Rule 2 — Master-only

All work happens on the repo's main integration branch — usually master, but if a project uses main, treat main as equivalent.

• No git checkout -b feature/foo for solo work.
• Sync with remote: git pull --ff-only or git pull --rebase. No merge commits for solo work.
• If a task genuinely requires isolation (large experiment, risky refactor with rollback potential, multi-day work with intermediate WIP commits) — ask the user: "this needs its own branch, ok?" — and wait for explicit approval. Without approval, work continues on master.

If the agent finds itself on a non-main branch (after a manual git checkout) or in detached HEAD — report it and ask whether to return to master before working.

Rule 3 — Versioning discipline

When editing any artifact with a semver field, bump the version before committing per:

• MAJOR (X+1.0.0) — breaks the contract. Renames, removed triggers, layout changes, removed public functions, breaking API change.
• MINOR (X.Y+1.0) — adds capability without breaking. New trigger, new optional step, new public function.
• PATCH (X.Y.Z+1) — wording / clarity / typo fixes with no behavior change.

The bump is recorded in the commit message: feat(<artifact>): … [vX.Y.Z] or whatever convention the project uses (see Rule 1).

Applies to: skills/<name>/SKILL.md (version: in frontmatter), package.json ("version":), pyproject.toml (version =), Cargo.toml (version =), and any other semver field in any other manifest.

If the artifact is packaged as dist/<name>.skill, dist/*.tgz, etc. — rebuild the package in the same or the next commit. Forgotten dist artifacts are a common cause of deploying stale binaries.

First edit of an unversioned artifact that COULD have a semver field (a new skill without version:, a new package.json without "version":) — add version: 0.1.0 (or its equivalent) before committing; do not bump anything.

Does not apply to: artifacts with no semver field and no potential for one (wiki concept pages, README.md, shell scripts without a public interface).

Rule 4 — Push freely, gate only where a local gate exists

Default: push freely. An ordinary fast-forward git push to the configured upstream needs no per-push confirmation. No ask-before-push mode by default.

Per-project push gate. A project whose push triggers side effects carries a LOCAL project-scope skill (convention: push-gate) that replaces this default with ask-before-push for that project. Example: books — push to master runs Gitea Actions auto-deploy. Respect the local gate over this rule: if the project has a push-gate skill, its semantics win for that project; this rule's free-push default does not apply there.

Always ask:

• git push --force / --force-with-lease (history rewrite);
• git push origin --delete <branch> (branch deletion);
• push to a remote/branch other than the current tracked upstream (git push other-remote ..., git push origin other-branch);
• push to the main branch that would require non-fast-forward (i.e. would need force).

Anything else is an ordinary fast-forward push and proceeds without a gate.

What counts as "push": only git push family commands. Local commits, git stash push, etc. are not push.

Rule 5 — Transit-zone / brainstorm workspaces

Some workspaces are transit zones — discussion areas with no .tasks/, where brainstorm artifacts are explicitly NOT auto-promoted to project wikis.

Default destination for brainstorm artifacts:

• In-progress brainstorm outputs → .brainstorm/<topic>.md (or whatever the workspace's README/CLAUDE.md declares)
• Mature, cross-cutting outputs → ~/projects/.wiki/concepts/<topic>-design.md via mcp__projects-meta__knowledge_ingest — only when user explicitly directs this

Agent must NOT auto-promote brainstorm artifacts to global wikis by analogy with Rule 1. Convergence-moment (move from workspace to permanent wiki) is a user decision, not an automatic action.

Example: ~/projects/.meeting-room/ is a transit zone. Its CLAUDE.md explicitly states "no .tasks/, transit zone, artifacts go to .brainstorm/ or global wiki via user command." Rule 1's "project conventions override" applies, but the override is explicit in the workspace contract — auto-promotion by analogy would violate that contract.

When in doubt: ask the user "this goes to .brainstorm/, or should I promote to shared wiki?" rather than assuming.

Out of scope

The skill does not:

• modify CLAUDE.md (that's project-bootstrap's job);
• enforce rules via git hooks / pre-commit / CI (this is agent discipline, not tooling);
• manage settings.json permissions (that's update-config);
• check the existence of .wiki/ / .tasks/ (that's setup-wiki / setup-tasks / project-bootstrap); if a project doesn't have them, Rule 1 simply finds no overrides and falls back to skill defaults.

Why this exists

In a tightly-disciplined repo (skills) the four rules already hold by accident — the agent reads .wiki/CLAUDE.md, knows specs go to .wiki/concepts/, knows to bump version:, knows not to push without confirmation. In other projects of the same user, that discipline does not transfer: the agent falls back to vendor-default paths (docs/specs/, docs/plans/), branches on a whim, forgets version: bumps, and pushes without asking. This skill makes the discipline explicit and portable.

Full design rationale (why one skill instead of four, why a skill instead of inline CLAUDE.md lines, scope of each rule, push-permission mechanism choice) lives in .wiki/concepts/project-discipline-design.md (in this repo; in other projects bootstrapped from this repo, the design lives in skills).