feat: install full skill pack

This commit is contained in:
Andy Dixon
2026-07-06 16:08:36 +01:00
parent f8e3da22cf
commit b3e0d839ed
11 changed files with 1266 additions and 122 deletions
+84
View File
@@ -0,0 +1,84 @@
---
name: summarise
description: Generate or update a repository SUMMARY.md that explains what a software project is, what it does, and how it evolved through Git history. Use when the user asks to summarise a codebase, create project history documentation, produce a v3-style management-readable technical narrative, analyse milestones from Git tags, or document significant commits and their product impact.
---
# Summarise
## Goal
Create a `SUMMARY.md` in the repository root unless the user names another file. The document should feel like a polished project-evolution report: technically accurate, management-readable, British English, friendly, crisp, and lightly ADHD without becoming gimmicky.
## Workflow
1. Inspect the project before writing:
- read high-signal files such as `README*`, package manifests, docs, plugin/app metadata, build files, and the main source tree layout;
- identify the project type, audience, core capabilities, and current state;
- do not rely only on commit messages.
2. Gather Git evidence:
- run `git status --short` and avoid mixing unrelated dirty work into the summary unless it is relevant;
- list tags in chronological order and treat them as milestones;
- compare milestone ranges with `git diff --shortstat <from>..<to>`;
- inspect significant commits with `git show --stat --summary <commit>` and, where useful, `git show --name-only <commit>`;
- consider merge commits, large diffs, new packages, major docs, tests, security work, UX changes, and architecture shifts as candidates for deeper explanation.
3. Use the helper script when useful:
- run `~/.codex/skills/summarise/scripts/git-summary-evidence.sh [repo]`;
- use its output as evidence, not as the final document;
- inspect extra commits manually when the script highlights something important.
4. Write `SUMMARY.md` with this shape unless the project strongly suggests another:
- title and short version;
- executive summary;
- line-count/change-size table;
- timeline from Git commits, with tags as milestone headings;
- what the project does now;
- architecture and main components;
- major feature areas;
- significant commits and why they mattered;
- security, testing, documentation, and operational maturity;
- what it is good at;
- what it is not yet;
- recommended rollout/readout narrative;
- final read.
5. Keep the writing honest:
- distinguish implemented features from foundations, prototypes, and future work;
- never inflate weak evidence into certainty;
- call out uncertainty if commit messages are vague;
- avoid corporate filler, but make it readable for non-specialists.
## Style
- Use British English.
- Prefer concrete product impact over raw technical trivia.
- Explain technical terms briefly when they matter.
- Keep a lively, human tone: direct, warm, occasionally wry.
- Avoid overdoing jokes; one sharp line beats six forced ones.
- Use crisp headings and tables where they help scanning.
- Use exact commit hashes, tag names, dates, and file counts where available.
## Significant Commit Heuristics
Give more detail to commits that:
- introduce or remove a package, service, plugin, app, or major subsystem;
- add a new user-facing workflow;
- change data flow, storage, auth, permissions, or trust boundaries;
- add detector/model/algorithm families;
- introduce a new UI paradigm or configuration system;
- add tests around risky behaviour;
- harden security, input bounds, sanitisation, or error handling;
- create or update major documentation;
- have unusually large line counts or many touched files.
Do not treat every commit equally. A small commit can matter if it changes the product shape; a large commit can be mechanical. Say which is which.
## Output Rules
- Create or update `SUMMARY.md` using normal file-editing tools.
- If a project already has a versioned summary such as `v3.md`, use it as a style reference but do not blindly copy it.
- If the user asks for a specific filename, use that filename instead.
- Include enough detail that a manager can understand the journey without reading the source, while an engineer can still trust the evidence.
- Before finishing, run `git diff --check` if a Git repository is present.
+4
View File
@@ -0,0 +1,4 @@
interface:
display_name: "Summarise"
short_description: "Generate project evolution summaries"
default_prompt: "Use $summarise to create a SUMMARY.md for this repository."
+77
View File
@@ -0,0 +1,77 @@
#!/usr/bin/env bash
set -euo pipefail
repo="${1:-.}"
cd "$repo"
if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
echo "Not inside a Git repository: $repo" >&2
exit 1
fi
echo "# Repository"
printf "Root: %s\n" "$(git rev-parse --show-toplevel)"
printf "HEAD: %s\n" "$(git log -1 --format='%h %ad %s' --date=short)"
echo
echo "# Working Tree"
git status --short || true
echo
echo "# Tags Chronological"
tags=()
while IFS= read -r tag; do
tags+=("$tag")
done < <(git tag --sort=creatordate)
if ((${#tags[@]} == 0)); then
echo "No tags found."
else
for tag in "${tags[@]}"; do
printf "%s | %s | %s\n" \
"$tag" \
"$(git log -1 --format='%ad' --date=short "$tag")" \
"$(git log -1 --format='%h %s' "$tag")"
done
fi
echo
echo "# Milestone Diff Stats"
if ((${#tags[@]} > 0)); then
first_commit="$(git rev-list --max-parents=0 HEAD | tail -n 1)"
prev="$first_commit"
prev_label="first commit ${first_commit:0:7}"
for tag in "${tags[@]}"; do
printf "## %s -> %s\n" "$prev_label" "$tag"
git diff --shortstat "$prev".."$tag" || true
prev="$tag"
prev_label="$tag"
done
printf "## %s -> HEAD\n" "$prev_label"
git diff --shortstat "$prev"..HEAD || true
else
git diff --shortstat "$(git rev-list --max-parents=0 HEAD | tail -n 1)"..HEAD || true
fi
echo
echo "# Recent Commit Timeline"
git log --date=short --pretty=format:'%h | %ad | %s' --reverse --max-count=120
echo
echo
echo "# Largest Commits By Changed Files"
git log --pretty=format:'%h' --max-count=300 |
while read -r commit; do
files="$(git show --shortstat --format= "$commit" | awk '/files? changed/ {print $1 + 0}')"
printf "%06d %s %s\n" "${files:-0}" "$commit" "$(git log -1 --format='%ad | %s' --date=short "$commit")"
done | sort -rn | head -n 30
echo
echo "# Largest Commits By Line Churn"
git log --pretty=format:'%h' --max-count=300 |
while read -r commit; do
stat="$(git show --shortstat --format= "$commit")"
inserted="$(awk '/insertions?\(\+\)/ {for (i=1;i<=NF;i++) if ($i ~ /insertions?\(\+\)/) print $(i-1)}' <<<"$stat")"
deleted="$(awk '/deletions?\(-\)/ {for (i=1;i<=NF;i++) if ($i ~ /deletions?\(-\)/) print $(i-1)}' <<<"$stat")"
churn="$(( ${inserted:-0} + ${deleted:-0} ))"
printf "%08d %s %s\n" "$churn" "$commit" "$(git log -1 --format='%ad | %s' --date=short "$commit")"
done | sort -rn | head -n 30