docs(project-discipline): design spec + implementation plan + STATUS active block
Spec: .wiki/concepts/project-discipline-design.md — four cross-project rules (conventions-over-defaults, master-only, semver-bumping with first-edit-unversioned clause, session-scoped ask-before-push with grant/revoke and force/delete/non-ff exceptions); architecture: single policy skill activated by 'follow project discipline' line in CLAUDE.md template (added by project-bootstrap v1.5.0); 12-task implementation plan tracked in .tasks/project-discipline-skill.md.
This commit is contained in:
761
.tasks/project-discipline-skill.md
Normal file
761
.tasks/project-discipline-skill.md
Normal file
@@ -0,0 +1,761 @@
|
||||
# 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**
|
||||
|
||||
```markdown
|
||||
---
|
||||
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**
|
||||
|
||||
```powershell
|
||||
$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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```markdown
|
||||
> 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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```markdown
|
||||
# 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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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:
|
||||
|
||||
```markdown
|
||||
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:
|
||||
|
||||
```markdown
|
||||
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:
|
||||
|
||||
```markdown
|
||||
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:
|
||||
|
||||
```markdown
|
||||
| Skill | Version | Role |
|
||||
|---|---|---|
|
||||
| `project-bootstrap` | <version> | orchestrator |
|
||||
| `setup-wiki` | <version> | wiki canonical layout |
|
||||
| `setup-tasks` | <version> | tasks canonical layout |
|
||||
```
|
||||
|
||||
Replace with:
|
||||
|
||||
```markdown
|
||||
| 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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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:
|
||||
|
||||
```markdown
|
||||
## 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:
|
||||
|
||||
```markdown
|
||||
## 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:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: Skill versioning + bootstrap manifest
|
||||
type: concept
|
||||
updated: 2026-04-28
|
||||
---
|
||||
```
|
||||
|
||||
Replace with:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: Skill versioning + bootstrap manifest
|
||||
type: concept
|
||||
updated: 2026-05-01
|
||||
---
|
||||
```
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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`):
|
||||
|
||||
```powershell
|
||||
$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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
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**
|
||||
|
||||
```powershell
|
||||
$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`:
|
||||
|
||||
```markdown
|
||||
## [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**
|
||||
|
||||
```powershell
|
||||
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`):
|
||||
|
||||
```markdown
|
||||
- [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**
|
||||
|
||||
```powershell
|
||||
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):
|
||||
|
||||
```markdown
|
||||
## 🟢 [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:
|
||||
```markdown
|
||||
_Updated: 2026-05-01_
|
||||
```
|
||||
(or whatever current date is there)
|
||||
|
||||
Replace with:
|
||||
```markdown
|
||||
_Updated: 2026-05-01_
|
||||
```
|
||||
|
||||
(Same date — keep current.)
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```powershell
|
||||
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.
|
||||
Reference in New Issue
Block a user