jpmschweitzer/clide
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

document tooling discipline: make targets, shell hygiene

Browse Source 
Add a "Tooling discipline" note to CLAUDE.md — run gates via the make
targets (e.g. make changelog-gate), not the ci/ scripts they wrap; the
Bash working dir is the repo root (no cd / git -C); one command per
invocation. Point the git-commit skill at make changelog-gate for the
60-word cap instead of naming the raw script.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-06-10 16:35:32 +02:00
co-authored by Claude Opus 4.8
parent 3b3dd71f4a
commit 3a4b758dcb
2 changed files with 10 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/git-commit/SKILL.md
+1 -1
View File
@@ -55,7 +55,7 @@ Entries should be short imperative phrases that describe user-facing impact —
### Be concise — this is the rule, not a suggestion
CHANGELOG entries must be **one or two short sentences**. Hard cap: **60 words per bullet** (enforced by `ci/changelog_gate.sh`). Aim for 30 or under; if you can't say it in one line wrapped at ~75 columns, you're writing the wrong document.
CHANGELOG entries must be **one or two short sentences**. Hard cap: **60 words per bullet**, enforced by the pre-push gate — verify before committing with `make changelog-gate` (run the `make` target, not the script it wraps). Aim for 30 or under; if you can't say it in one line wrapped at ~75 columns, you're writing the wrong document.
The CHANGELOG is read by humans scanning for what changed between two versions. It is **not** the place for the rationale, the probe results, the implementation detail, the behavior-change deep dive, or the "see also" cross-references. Those belong in:
CLAUDE.md
+9
View File
@@ -76,6 +76,15 @@ make clean # remove build artefacts
One-time setup on a fresh clone: `make hooks && flutter pub get` once Flutter is installed.
### Tooling discipline
The `make` targets above are the entry points — run them, not the scripts they wrap. Check the changelog with `make changelog-gate`, never `ci/changelog_gate.sh` directly; same for `analyze`/`format`/`test`/`push-check`. The `make` layer sets up the environment and stays correct if a script moves.
Shell hygiene (keeps commands inside the permission allowlist, so they don't get denied mid-task):
- **Working directory is the repo root already** — don't prepend `cd /…/clide` or pass `git -C`. Just run the command.
- **One command per invocation** — no `&&`/`;` chaining and no multiple greps/echos in one call. The only exception is the `git commit -F` HEREDOC.
- Prefer the Read/Edit/Grep tools over `cat`/`sed`/`grep` for inspecting files.
## Git workflow
Commit and push directly to `main` for routine work — this is a solo-dev repo and does not use a branch-first / feature-branch flow. Do **not** create a working branch just to land a change. (This overrides the generic "branch before committing on the default branch" assistant default.) The usual safety rules still hold: never `--no-verify`, never force-push `main`, and let the pre-push gate run.