feat(skills): add commit workflow, explain and help-skills

comments-clean purges explanatory comments before every operator-requested stage or commit and penalizes own violations into persistent memory; commit-no-verify commits the exact staging index with hooks skipped, the invocation itself being the per-commit authorization; commit-next chains both and stages the next logical bundle with an explain and confidence briefing; explain walks code and its collaborators in execution order and offers a Mermaid schema in the affected README; help-skills lists every project, global and plugin skill with triggers and composition.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

skills/comments-clean/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: comments-clean
+description: >
+  Purge explanatory comments from staged and unstaged changes. Run
+  AUTOMATICALLY, without being asked, every time the operator requests a
+  commit or stage in any wording (commit, commit no-verify, stage next,
+  socon, sobu, socobu, "commite ..."), BEFORE executing that request; also
+  on /comments-clean or when the operator complains about comments.
+  Explanatory comments are bad practice: they narrate code instead of
+  letting it speak. Portable across projects.
+---
+
+When the operator asks to commit or stage, run this audit first and only
+then perform the requested git action; never ask whether to run it.
+
+Audit every staged and unstaged change (`git diff` plus `git diff --cached`,
+added lines only) and delete every explanatory comment:
+
+1. Delete: restated code, step narration, section banners, "Note that",
+   rationale prose, apology comments, and any comment whose information the
+   code, task name, or commit message already carries. When in doubt,
+   delete.
+2. Keep only: parameter/exit-code docs, nocheck/noqa/shellcheck directives,
+   and project-sanctioned exception markers that name a concrete trip-wire.
+   A relabeled narration is not an exception; delete it instead.
+3. Re-run the project's comment lint if one exists and re-stage the files
+   that were already staged.
+4. Penalty: if this audit finds anything you wrote yourself, admit it in
+   the report (file and count, no excuses), lower your confidence numbers
+   for the affected bundle, and write the incident to persistent agent
+   memory (extend the existing minimal-comments feedback entry with the
+   date and the pattern you slipped on) so the calibration survives the
+   session.

skills/commit-next/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: commit-next
+description: >
+  Commit the staged bundle with --no-verify, then stage the next logical
+  bundle and brief the operator on it. Trigger on /commit-next or when the
+  operator asks to commit and stage the next bundle in one step. Portable
+  across projects.
+---
+
+1. Run the commit-no-verify skill on the currently staged changes
+   (comments-clean audit first, then `git commit --no-verify`, exact
+   staging index only).
+2. Group the remaining uncommitted changes into logical bundles (one
+   concern per bundle: same failure class, same mechanism, or same role)
+   and stage the next one; never mix concerns to save a commit.
+3. For the newly staged bundle run the explain skill (what the changes do
+   and how the pieces interact, file:line-anchored) followed by the
+   confidence skill (fix confidence, break risk, evidence, residuals).
+4. Close with what remains unstaged and wait for the operator's commit
+   decision; never auto-commit the newly staged bundle.

skills/commit-no-verify/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: commit-no-verify
+description: >
+  Commit the currently staged changes with --no-verify (skip the pre-commit
+  hooks). Trigger on /commit-no-verify or when the operator asks for a
+  no-verify commit in any wording. Invoking this skill IS the explicit
+  per-commit authorization that --no-verify requires; it never carries over
+  to later commits. Portable across projects.
+---
+
+1. Run the comments-clean audit over the staged and unstaged changes first.
+2. Commit exactly the staging index with `git commit --no-verify` and a
+   Conventional-Commits message derived from the staged diff; never add
+   unstaged files, never push.
+3. Report the created commit hash and what remains uncommitted.

skills/explain/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: explain
+description: >
+  Explain code and its interactions. Trigger when the operator asks what a
+  piece of code does, how a mechanism works, why components interact the way
+  they do, or invokes /explain on a file, function, role, or module.
+  Portable across projects.
+---
+
+Explain the named code so an engineer who has never seen it can follow it:
+
+1. Read the code and every collaborator it touches (callers, callees,
+   templates, configs) before explaining; never explain from the name alone.
+2. Lead with the purpose in one sentence, then walk the flow in execution
+   order: inputs, transformations, side effects, outputs. Name the real
+   files and line references.
+3. Make the interactions explicit: which component induces, triggers, or
+   consumes which, and where the single source of truth lives. Point out
+   trip-wires (non-obvious ordering, escaping, caching, permission edges)
+   as part of the flow, not as an appendix.
+4. Afterwards ask whether to persist a Mermaid diagram of the explained
+   mechanism under a `## Schema` heading in the README.md next to the
+   affected code (create the heading if missing, replace its previous
+   diagram if present). On approval, keep the diagram to the explained
+   scope: components as nodes, induction/data flow as labeled edges.

skills/help-skills/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: help-skills
+description: >
+  List and explain every skill available in the current session. Trigger on
+  /help-skills, "welche skills gibt es", "skill übersicht", or when the
+  operator asks what skills exist or what a skill does. Portable across
+  projects.
+---
+
+Produce a one-shot overview of every skill the session can invoke:
+
+1. Sources, in this order: the session's available-skills listing, the
+   project's own skills (`skills/` and `.claude/skills/` in the repo), the
+   user-global skills (`~/.claude/skills/`), and plugin-provided skills.
+   Deduplicate by name; note when a project skill shadows a global one.
+2. Output one table per origin (project, global, plugin): skill name,
+   trigger (slash command or phrasing), one-line purpose in your own words
+   — compress the description, do not paste it.
+3. When the operator names a specific skill or topic, explain only the
+   matching skills in more depth: what they do, when they fire on their
+   own, and how they compose (e.g. commit-next → commit-no-verify →
+   comments-clean).
+4. End with the activation hint: project installers or `make install` in
+   the skills repository refresh the live copies; a restart loads renamed
+   or new skills.