claude-skills/.tasks/project-discipline-skill.md

project-discipline — implementation plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Ship a new policy skill project-discipline (four cross-project rules: conventions-over-skill-defaults, master-only, semver-bumping, ask-before-push) and wire it into the canonical project-bootstrap template, with the claude-skills repo dogfooding the trigger.

Architecture: Single-file policy skill (skills/project-discipline/SKILL.md) following the pulling-before-work shape — frontmatter trigger description + body with four numbered rule sections. project-bootstrap v1.4.0 → v1.5.0 adds the canonical trigger line follow project discipline to assets/CLAUDE.md.template after pull remote before work; the existing v1.3.0 idempotent merge propagates it into existing projects on upgrade. The claude-skills repo's own CLAUDE.md gets the line as dogfood. The bootstrap manifest table gains a row for the new skill. The existing .wiki/concepts/skill-versioning.md is extended with a note that Rule 3 expands the versioning requirement from the infra subset to all skills.

Tech Stack: Markdown skills (no build for the skill body itself). Build pipeline: scripts/build.ps1 produces dist/<name>.skill archives. Install: scripts/install.sh (portable across git-bash on Windows + native Linux/macOS). Spec lives at .wiki/concepts/project-discipline-design.md.

---

File Structure

New:

• skills/project-discipline/SKILL.md — frontmatter + body, ~250–300 lines
• skills/project-discipline/README.md — short user-facing intro mirroring skills/pulling-before-work/README.md shape

Modified:

• skills/project-bootstrap/SKILL.md — version: 1.4.0 → 1.5.0; Step 5 inline template gains the new line; new commentary paragraph after the existing pull remote before work paragraph; Step 5.5 manifest table gains a row for project-discipline
• skills/project-bootstrap/assets/CLAUDE.md.template — + follow project discipline after pull remote before work and before we're on Windows
• CLAUDE.md (repo root) — + follow project discipline in the same position (dogfood)
• .wiki/concepts/skill-versioning.md — append a section noting Rule 3 of project-discipline extends version: requirement to ALL skills (not just infra subset)
• .wiki/log.md — append decision entry
• .wiki/index.md — concept page link (added when spec was committed; verify still listed; add project-discipline-design.md if not)
• .tasks/STATUS.md — add [project-discipline-skill] 🔴 Active block, then update to 🟢 Done at the end

Built:

• dist/project-discipline.skill — new
• dist/project-bootstrap.skill — rebuilt

---

Task 1: New skill — frontmatter only

Files:

• Create: skills/project-discipline/SKILL.md

• Step 1: Write the frontmatter

---
name: project-discipline
version: 0.1.0
description: >
  Codifies four cross-project discipline rules: (1) project CLAUDE.md /
  .wiki/CLAUDE.md / .tasks/ override defaults from any other skill (specs
  go to .wiki/concepts/, not docs/superpowers/specs/; tasks to .tasks/,
  not docs/superpowers/plans/); (2) all work on master/main, no feature
  branches without explicit user approval; (3) bump semver on every edit
  of versioned artifacts (SKILL.md frontmatter, package.json,
  pyproject.toml) per MAJOR/MINOR/PATCH rules, recorded in commit message;
  (4) commit freely, never push without explicit per-session user approval
  — grant via "разреши автопуш" / "allow auto-push", revoke via "отзови"
  / "revoke", session end resets to ask-mode; force/delete/non-ff push
  always asks. Activated by "follow project discipline" trigger in
  CLAUDE.md (added by project-bootstrap v1.5.0+).
---

# project-discipline

• Step 2: Verify description length is under 900 chars

$c = Get-Content skills/project-discipline/SKILL.md -Raw
$start = $c.IndexOf('description: >') + 'description: >'.Length
$end = $c.IndexOf('---', $start)
$desc = $c.Substring($start, $end - $start).Trim()
"description chars: $($desc.Length)"

Expected: a number ≤ 900. (Per feedback_skill_description_length_limit memory: harness silently drops descriptions >~1024 and falls back to the H1.)

• Step 3: Commit

git add skills/project-discipline/SKILL.md
git commit -m "feat(project-discipline): scaffold skill frontmatter [v0.1.0]"

---

Task 2: New skill — body

Files:

• Modify: skills/project-discipline/SKILL.md (append body)

• Step 1: Append the skill body after the H1

> 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 (superpowers, 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`, **not** `docs/superpowers/specs/`.
- **Task tracking / implementation plans** go to `.tasks/<slug>.md` plus a board entry in `.tasks/STATUS.md` (the `using-tasks` format), **not** `docs/superpowers/plans/` or any inline-in-chat plan 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 — Commit yes, push no (session-scoped)

**Every session starts in ask-before-push mode.** On every `git push`, ask:

> Готов push'нуть в `<remote>/<branch>` (N коммитов: <subjects>). Ок?

(or its English equivalent if the user is communicating in English) and wait for explicit `yes` / `да` / `push` / equivalent. Without confirmation — do not push.

**Granting auto-push within a session.** When the user says:

- "разреши автопуш" / "allow auto-push" / "автопуш ок" / equivalent

— push without further confirmation until the end of the session or until revoked.

**Revoking auto-push within a session.** When the user says:

- "отзови автопуш" / "revoke auto-push" / "снова спрашивай" / equivalent

— return to ask-before-push mode.

**Session end resets to ask-mode.** The next session starts asking again, regardless of what was granted in the previous one. This is intentional: a grant is given for the current context (user nearby, consciously decided pushes are safe), and should not survive a context switch.

**Always ask, even with active grant:**

- `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).

A grant covers ordinary fast-forward push to the configured upstream. Anything else is a separate class of operation and needs its own decision.

**What counts as "push":** only `git push` family commands. Local commits, `git stash push`, etc. are not push; the grant does not apply.

## 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 (`claude-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 uses `superpowers`' default `docs/superpowers/specs/`, 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 `claude-skills`).

• Step 2: Sanity-check the file rendered

Get-Content skills/project-discipline/SKILL.md | Measure-Object -Line
Select-String -Path skills/project-discipline/SKILL.md -Pattern '^## Rule [1-4]'

Expected:

• Line count ~250–320

• Four ## Rule N matches in order

• Step 3: Commit

git add skills/project-discipline/SKILL.md
git commit -m "feat(project-discipline): skill body — four rules + activation + out-of-scope [v0.1.0]"

---

Task 3: New skill — README.md

Files:

• Create: skills/project-discipline/README.md

• Step 1: Write README

# project-discipline

Policy skill that codifies four cross-project discipline rules so the same
guarantees that hold in a tightly-maintained repo apply everywhere.

## When it triggers

- **Session start** — when `CLAUDE.md` contains the line `follow project discipline` (added by `project-bootstrap` v1.5.0+).
- **In-chat** — when the user says "use project discipline", "соблюди дисциплину", "проектные правила", or close variants.

## The four rules

1. **Project conventions over skill defaults.** `CLAUDE.md` / `.wiki/CLAUDE.md` / `.tasks/` override any other skill's defaults. Specs go to `.wiki/concepts/`, not `docs/superpowers/specs/`. Tasks to `.tasks/`, not `docs/superpowers/plans/`.
2. **Master-only.** All work on `master` (or `main`). No feature branches without explicit user approval.
3. **Semver discipline.** Bump `version:` in `SKILL.md` / `package.json` / `pyproject.toml` on every edit per MAJOR / MINOR / PATCH; record in commit message; rebuild `dist/` artifacts after.
4. **Commit yes, push no.** Every session starts asking before push. User can grant auto-push within session ("разреши автопуш"); session end resets to ask-mode. Force / delete / non-ff push always asks.

## Prerequisites

None. The skill is a textual policy document; it takes no actions and has no
external dependencies. Activate it by adding `follow project discipline` to
`CLAUDE.md` (or use `project-bootstrap` v1.5.0+ which adds it automatically).

## Related

- `project-bootstrap` (v1.5.0+) — adds the trigger line to new and existing projects' `CLAUDE.md`.
- `pulling-before-work` — companion skill activated by the canonical template; pulls origin once at session start (`git pull --ff-only`).
- `using-tasks` / `using-wiki` — the format conventions Rule 1 routes work into.
- `.wiki/concepts/project-discipline-design.md` (in `claude-skills`) — full design rationale.

• Step 2: Commit

git add skills/project-discipline/README.md
git commit -m "docs(project-discipline): README"

---

Task 4: Bootstrap template — add trigger line

Files:

• Modify: skills/project-bootstrap/assets/CLAUDE.md.template

• Step 1: Insert the new line after pull remote before work

Use Edit:

• old_string:

  pull remote before work
  we're on Windows
  

• new_string:

  pull remote before work
  follow project discipline
  we're on Windows
  

• Step 2: Verify

Get-Content skills/project-bootstrap/assets/CLAUDE.md.template

Expected: eight trigger lines in this order:

talk like a caveman
use superpowers
use project wiki
use task management system
check across all projects
pull remote before work
follow project discipline
we're on Windows

• Step 3: Commit

git add skills/project-bootstrap/assets/CLAUDE.md.template
git commit -m "feat(project-bootstrap): template gains 'follow project discipline' trigger"

---

Task 5: Bootstrap SKILL.md — version bump + Step 5 update + manifest row

Files:

• Modify: skills/project-bootstrap/SKILL.md

• Step 1: Bump version in frontmatter

Edit:

• old_string: version: 1.4.0

• new_string: version: 1.5.0

• Step 2: Update the Step 5 inline template (mirror of assets/CLAUDE.md.template)

Find the fenced markdown block in Step 5:

talk like a caveman
use superpowers
use project wiki
use task management system
check across all projects
pull remote before work
we're on Windows

Replace with:

talk like a caveman
use superpowers
use project wiki
use task management system
check across all projects
pull remote before work
follow project discipline
we're on Windows

• Step 3: Add commentary paragraph for the new trigger

After the existing paragraph that explains pull remote before work (ending with "...silently dead like any other absent skill.") and before the paragraph about we're on Windows (starting with "The we're on Windows line activates..."), insert:

The `follow project discipline` line activates the `project-discipline` skill,
which codifies four cross-project rules: (1) project CLAUDE.md / .wiki/CLAUDE.md
/ .tasks/ override defaults from any other skill; (2) all work on master/main,
no feature branches without explicit user approval; (3) version bump on every
edit of versioned artifacts per semver, recorded in commit; (4) commit freely,
push only after explicit per-session approval. Install the skill on the host
if `project-discipline` is not in `~/.claude/skills/`; otherwise the trigger is
silently dead like any other absent skill.

• Step 4: Add project-discipline row to Step 5.5 manifest table

Find the table:

| Skill | Version | Role |
|---|---|---|
| `project-bootstrap` | <version> | orchestrator |
| `setup-wiki` | <version> | wiki canonical layout |
| `setup-tasks` | <version> | tasks canonical layout |

Replace with:

| Skill | Version | Role |
|---|---|---|
| `project-bootstrap` | <version> | orchestrator |
| `setup-wiki` | <version> | wiki canonical layout |
| `setup-tasks` | <version> | tasks canonical layout |
| `project-discipline` | <version> | cross-project policy |

• Step 5: Verify

Select-String -Path skills/project-bootstrap/SKILL.md -Pattern '^version:|follow project discipline|project-discipline' | ForEach-Object { "$($_.LineNumber): $($_.Line)" }

Expected: at least 5 hits — version: 1.5.0, the line in the Step 5 fenced block, the new commentary paragraph, the row in the manifest table.

• Step 6: Commit

git add skills/project-bootstrap/SKILL.md
git commit -m "feat(project-bootstrap): v1.5.0 — add 'follow project discipline' canonical trigger [v1.5.0]"

---

Task 6: Update .wiki/concepts/skill-versioning.md — note Rule 3 scope extension

Files:

• Modify: .wiki/concepts/skill-versioning.md

• Step 1: Read current content

Get-Content .wiki/concepts/skill-versioning.md

Note the existing section "## What skills are versioned" which scopes versioning to the infra subset.

• Step 2: Update the ## What skills are versioned section

Find:

## What skills are versioned

Currently only the **infrastructure** skills (the ones bootstrap touches and that govern project layout). Communication-mode skills (`caveman`, family) and discovery skills (`find-skills`, `active-platform`) aren't versioned — their content is "good copy-paste" and a snapshot mismatch isn't a layout problem.

If we ever start packaging or marketplace-publishing the rest, we'll version them too.

Replace with:

## What skills are versioned

**Originally** only the **infrastructure** skills (the ones bootstrap touches and that govern project layout). Communication-mode skills (`caveman`, family) and discovery skills (`find-skills`, `active-platform`) were left unversioned — their content was "good copy-paste" and a snapshot mismatch wasn't a layout problem.

**As of `project-discipline` v0.1.0** (Rule 3), the requirement extends to **all** skills in this repo, regardless of category. Communication-mode and discovery skills also need `version:` in frontmatter; the migration is a separate one-time task tracked in `.tasks/`. Rationale: discipline-by-default is simpler than maintaining a list of "exempt" skills, and it costs nothing — `version: 0.1.0` is added on the next edit per the Rule 3 first-edit-unversioned clause.

If we ever start packaging or marketplace-publishing skills outside this repo, the same rule still applies.

• Step 3: Update the frontmatter updated: field

Find:

---
title: Skill versioning + bootstrap manifest
type: concept
updated: 2026-04-28
---

Replace with:

---
title: Skill versioning + bootstrap manifest
type: concept
updated: 2026-05-01
---

• Step 4: Commit

git add .wiki/concepts/skill-versioning.md
git commit -m "docs(wiki): skill-versioning — Rule 3 of project-discipline extends scope to all skills"

---

Task 7: Dogfood — add trigger to claude-skills root CLAUDE.md

Files:

• Modify: CLAUDE.md (repo root)

• Step 1: Insert the trigger after pull remote before work

Use Edit:

• old_string:

  pull remote before work
  we're on Windows
  

• new_string:

  pull remote before work
  follow project discipline
  we're on Windows
  

• Step 2: Verify

Get-Content CLAUDE.md

Expected:

# CLAUDE.md
# Agent instructions. Each line is a trigger for an installed skill.

talk like a caveman
use superpowers
use project wiki
use task management system
check across all projects
pull remote before work
follow project discipline
we're on Windows

• Step 3: Commit

git add CLAUDE.md
git commit -m "chore(claude-skills): dogfood 'follow project discipline' trigger"

---

Task 8: Build artifacts

Files:

• Build: dist/project-discipline.skill (new), dist/project-bootstrap.skill (rebuilt)

• Step 1: Run the build script

pwsh scripts/build.ps1 -Names project-discipline,project-bootstrap

Expected output:

built: dist/project-discipline.skill
built: dist/project-bootstrap.skill

• Step 2: Verify the archives

Get-ChildItem dist/project-discipline.skill, dist/project-bootstrap.skill | Format-Table Name, Length, LastWriteTime

Expected: both files exist, LastWriteTime is the current minute, sizes nonzero.

Spot-check the new archive's structure (no Compress-Archive backslash bug — see .wiki/concepts/build-notes.md):

$arch = [System.IO.Compression.ZipFile]::OpenRead((Resolve-Path dist/project-discipline.skill))
$arch.Entries | Select-Object FullName | Format-Table -AutoSize
$arch.Dispose()

Expected: entries like project-discipline/SKILL.md, project-discipline/README.md — forward slashes only.

• Step 3: Commit

git add dist/project-discipline.skill dist/project-bootstrap.skill
git commit -m "build: project-discipline@0.1.0 + project-bootstrap@1.5.0 archives"

---

Task 9: Install on this machine

• Step 1: Run installer

bash scripts/install.sh

(install.sh is portable — works in git-bash on Windows.)

Expected stdout: lines like installed: project-discipline and installed: project-bootstrap (and the rest of the skills, idempotent).

• Step 2: Verify installed skills

Test-Path "$env:USERPROFILE\.claude\skills\project-discipline\SKILL.md"
Test-Path "$env:USERPROFILE\.claude\skills\project-bootstrap\SKILL.md"
Select-String -Path "$env:USERPROFILE\.claude\skills\project-bootstrap\SKILL.md" -Pattern '^version:'
Select-String -Path "$env:USERPROFILE\.claude\skills\project-discipline\SKILL.md" -Pattern '^version:'

Expected:

• both Test-Path return True
• version: 1.5.0 for project-bootstrap
• version: 0.1.0 for project-discipline

(No commit — install affects user-level state, not the repo.)

• Step 3: Verify description length post-install

$c = Get-Content "$env:USERPROFILE\.claude\skills\project-discipline\SKILL.md" -Raw
$start = $c.IndexOf('description: >') + 'description: >'.Length
$end = $c.IndexOf('---', $start)
$desc = $c.Substring($start, $end - $start).Trim()
"description chars: $($desc.Length)"

Expected: ≤ 900. (Per feedback_skill_description_length_limit memory.)

---

Task 10: Manual smoke validation

No automated harness — describe what to verify in a fresh session.

• Scenario 1 (skill listing):

In a fresh Claude Code session in claude-skills, ask the agent: "what skills are available?" or list via Skill tool.

Expected: project-discipline appears in the listing with the description from frontmatter (not the H1 fallback). If the description is the H1 ("project-discipline"), the description was silently dropped — check length.

• Scenario 2 (Rule 1 — convention override):

In a fresh session, ask the agent to design a small feature that would normally produce a spec. Expected: agent writes spec to .wiki/concepts/<topic>-design.md, NOT docs/superpowers/specs/. (brainstorming skill default would be docs/superpowers/specs/; Rule 1 should override.)

• Scenario 3 (Rule 2 — master-only):

In a fresh session, ask the agent to "do a small refactor". Expected: agent makes changes on master branch, doesn't git checkout -b. If the task is borderline, agent asks "needs a branch?".

• Scenario 4 (Rule 3 — version bump):

Ask the agent to make any non-trivial edit to a skills/<name>/SKILL.md (e.g., add a sentence to body). Expected: the same commit (or the immediately next commit) bumps version: in frontmatter per PATCH/MINOR/MAJOR rules. The commit message includes [vX.Y.Z].

• Scenario 5 (Rule 4 — push permission default):

After any commit-producing task, expect the agent NOT to push without asking. Expected: agent says something like "готов push'нуть в origin/master, ок?" and waits.

• Scenario 6 (Rule 4 — grant + revoke):

In a session, after the agent commits something, say "разреши автопуш". Then make another change. Expected: agent commits AND pushes without asking. Then say "отзови". Make a third change. Expected: agent commits but asks before pushing again.

• Scenario 7 (Rule 4 — force-push exception):

With auto-push granted, ask the agent to do something requiring git push --force (e.g., simulate by asking: "push --force, ок?"). Expected: agent still asks for confirmation, citing Rule 4 exceptions.

• Scenario 8 (bootstrap upgrade on this very repo):

Re-run project-bootstrap on claude-skills itself in a fresh session: "upgrade project". Expected: bootstrap detects CLAUDE.md exists, runs Step 5 idempotent merge, finds follow project discipline already present (we added it manually in Task 7), reports CLAUDE.md already canon — no changes.

If Task 7 was skipped, the merge would prompt to append the line. Either way the merge logic works.

• Scenario 9 (description length regression check):

Re-run the description length probe (Task 9 Step 3). If the value is > 900, the skill's listing will silently drop the description and substitute H1 — the skill's discoverability collapses. This caught a regression in using-projects-meta once; same check protects here.

• Document results in .tasks/STATUS.md Where I stopped field

After running scenarios, update the task block (Task 12 below) with which scenarios passed.

---

Task 11: Wiki log + index

Files:

• Modify: .wiki/log.md

• Modify: .wiki/index.md (verify)

• Step 1: Append log entry

Append to .wiki/log.md:

## [2026-05-01] decision | project-discipline — new policy skill (v0.1.0): four cross-project rules (conventions-over-defaults, master-only, semver-bumping, ask-before-push); bootstrap template gains canonical trigger; project-bootstrap 1.4.0→1.5.0; skill-versioning concept extended to all skills

• Step 2: Verify .wiki/index.md lists the design page

Select-String -Path .wiki/index.md -Pattern 'project-discipline-design'

If absent, add a line under ## Concepts (alphabetical position — between pulling-before-work-design and repo-layout):

- [project-discipline-design.md](concepts/project-discipline-design.md) — design for project-discipline (four cross-project rules: conventions-over-defaults, master-only, semver-bumping, ask-before-push)

• Step 3: Commit

git add .wiki/log.md .wiki/index.md
git commit -m "docs(wiki): log + index — project-discipline@0.1.0"

---

Task 12: Tasks board entry — close

Files:

• Modify: .tasks/STATUS.md

• Step 1: Insert a Done block at the top (after the header) for this task

Edit .tasks/STATUS.md to add at the very top (immediately after the _Updated:_ line and a blank line):

## 🟢 [project-discipline-skill] — project-discipline skill + project-bootstrap 1.5.0 canonical trigger
**Status:** done
**Where I stopped:** `skills/project-discipline/` shipped at v0.1.0 (four rules: convention-override, master-only, semver-bumping, session-scoped push permission); `assets/CLAUDE.md.template` gains `follow project discipline` after `pull remote before work`; `project-bootstrap` 1.4.0→1.5.0 with new commentary paragraph in Step 5 + manifest table row in Step 5.5; `.wiki/concepts/skill-versioning.md` extended (Rule 3 expands version: requirement to ALL skills, not just infra subset); root `CLAUDE.md` dogfood line added; both archives rebuilt in `dist/`; installed via `install.sh`; description length verified ≤900 chars; smoke scenarios documented (1/8 verifiable inline; 2-7/9 require fresh sessions for full coverage); design rationale at `.wiki/concepts/project-discipline-design.md`
**Next action:** (none — kept until merged)
**Branch:** master

---

• Step 2: Bump the _Updated:_ line in STATUS.md

Find:

_Updated: 2026-05-01_

(or whatever current date is there)

Replace with:

_Updated: 2026-05-01_

(Same date — keep current.)

• Step 3: Commit

git add .tasks/STATUS.md .tasks/project-discipline-skill.md
git commit -m "tasks: close [project-discipline-skill]"

---

Self-Review

Spec coverage:

• ✅ Skill activation rules (CLAUDE.md trigger + in-chat reference) → Task 1, 2
• ✅ Rule 1 (conventions over defaults) → Task 2 body section
• ✅ Rule 2 (master-only) → Task 2 body section
• ✅ Rule 3 (versioning, including unversioned-artifact and dist-rebuild clauses) → Task 2 body + Task 6 cross-link to skill-versioning concept
• ✅ Rule 4 (session-scoped push permission, with exceptions) → Task 2 body section
• ✅ Out-of-scope list → Task 2
• ✅ Template change → Task 4
• ✅ Bootstrap version bump + Step 5 commentary + Step 5.5 manifest row → Task 5
• ✅ skill-versioning concept extension → Task 6
• ✅ Dogfood in repo root → Task 7
• ✅ Build + install + description-length probe → Tasks 8, 9
• ✅ Validation scenarios (covering all four rules + bootstrap merge + length regression) → Task 10
• ✅ Wiki log + index → Task 11
• ✅ Tasks board close → Task 12

Placeholder scan: no TBD / TODO / "implement later". All steps have explicit code or commands. Manifest row and STATUS block have explicit text, not placeholders. The <version> literal in the manifest table is the existing template syntax (filled in by project-bootstrap at runtime), not an unfilled spot in this plan.

Type / wording consistency:

• Trigger line is follow project discipline everywhere (template, dogfood, commentary, README, design doc, plan).
• Skill name project-discipline everywhere (folder, frontmatter, archive, install path, log, README cross-link, manifest row).
• Version 0.1.0 for new skill, 1.5.0 for bootstrap — consistent across frontmatter, log entry, tasks block, build commit, install verification.
• "Master-only" / "master/main" wording consistent between Rule 2 and design doc.
• Push grant phrases ("разреши автопуш" / "allow auto-push") consistent between Rule 4 wording and validation scenarios.