update summary instructions - resolves #6

9244ee6: Fixed som settings - #6

97bed3f: updated the symmary instruction and fixed som mad references - #6

Author: lakruzz

.githooks/pre-commit

@@ -21,7 +21,7 @@ echo "🔍 Running pre-commit checks..."
 
 # Ruff check
 if [ "$RUN_RUFF" == "TRUE" ]; then
-    printf "   ⏳ Pytest with coverage\r"
+    printf "   ⏳ Ruff check.git\r"
     RUFF_OUT=$(ruff check --output-format=concise . 2>&1)
 
     if [ $? -eq 0 ]; then

.github/instructions/summary.instructions.md

@@ -1,11 +1,25 @@
 ---
 applyTo: '**'
 ---
-When using the @github agent to create issues and comments to issues, please consider that I'm using zsh and unescaped use of backtick are likely to be mistaken as command substitutions. So for that reason prefer to generate the markdown in intermediate `*.md` files in the `./temp` folder and restrain from using the `--body` flag to `gh issue create` and  `gh issue comment` when you markdown contains backticks. But favor the `--body-file` flag instead. Name the file the same as the branch we're working on, with a `.md` extension, and store it in the `./temp` folder. Open it in the editor for my review and annotations.
+# Annotate summaries to issues
 
-When in @github agent mode and I ask to _annotate a comment on the current changeset to the issue_ you can always read the implied issue number from the current git branch - development branches are prefixed with an integer, and that is a reference to the issue being worked on. The branch name is part of the zsh prompt in the @terminal, and can be directly accessed; The `$PS1` is set up to show the branch name too (e.g. `vscode ➜ /workspaces/gh-tt (321-Update_summary_instructions) $` equals issue 321). Let summary serve as a work log note to future self and current colleagues. It should summarize the changes made in the branch we're working on (including any dirty files) since we left `main` (equivalent to `git diff main...HEAD`).
+## Default behaviour
 
-Only summarize on the accumulated change set in the branch. Do not dive into - or reference - the individual commits on the branch. The branch will be squashed into one commit before it hits main so not BOM (Bill of Material) is need - just a summary in prose. Make it a high-level overview of what was done (describe the changes), why it was done (the rationale behind our decisions), and any relevant context (maybe external links of general architectural or design decisions). The summary should have the header `##Change log summary` and even if I did ask you to create such a summary earlier on this branch, you should create the full summary again (don't just summarize the increment since last).
+If you recieved noting but a reference to this file, the default behaviour is to annotate a summary of the changeset to the issue being worked on.
+
+## Use an itermediate md file
+
+When in agent mode, and you are asked to create issues and comments to issues, please consider that I'm using zsh and unescaped use of backtick are likely to be mistaken as command substitutions. So for that reason prefer to generate the markdown in intermediate `*.md` files in the `./temp` folder and restrain from using the `--body` flag to `gh issue create` and  `gh issue comment`. But favor the `--body-file` flag instead. Name the file the same as the branch we're working on, with a `.md` extension, and store it in the `./temp` folder. Open it in the editor for my review and annotations.
+
+## Read issue number from branch name
+
+When agent mode and I ask to _annotate a comment on the current changeset to the issue_ you can always read the implied issue number from the current git branch - development branches are prefixed with an integer, and that is a reference to the issue being worked on. The branch name is part of the zsh prompt in the @terminal, and can be directly accessed; The `$PS1` is set up to show the branch name too (e.g. `vscode ➜ /workspaces/gh-tt (321-Update_summary_instructions) $` equals issue 321). Let summary serve as a work log note to future self and current colleagues. It should summarize the changes made in the branch we're working on since we left `main`.
+
+Equivalent to `git diff main...HEAD --name-status && git diff main...HEAD`.
+
+## Change set summary
+
+Only summarize on the accumulated change set in the branch. Do not dive into - or reference - the individual commits on the branch. The branch will be squashed into one commit before it hits main so no BOM (Bill of Material) is need - just a summary in prose. Make it a high-level overview of what was done (describe the changes), why it was done (the rationale behind our decisions), and any relevant context (maybe external links of general architectural or design decisions). The summary should have the header `## Change log summary` and even if I did ask you to create such a summary earlier on this branch, you should create the full change set summary again (don't just summarize the increment since last).
 
 The purpose of the summary is to help my future self and current team mates to recall and understand the purpose of - and rationale behind - the changes without needing to read through all the code or commit messages.
 

.github/workflows/wrapup.yml

@@ -95,6 +95,7 @@ jobs:
 
   markdown_linter:
     name: Linting
+    needs: mark-pending
     permissions:
       statuses: write
       contents: read

CONTRIBUTING.md

@@ -6,7 +6,7 @@ Feel free to create a fork and fool around - following your own rules. But if yo
 
 If you are a trusted contributor and already have write access to the repo, consider:
 
-1. No commit can be accepted on _our_ `main`, unless it references a [GitHub issue](../../gh-tt/issues)[^issue] in the commit message.
+1. No commit can be accepted on _our_ `main`, unless it references a [GitHub issue](../../issues)[^issue] in the commit message.
 2. Development branches must be created using `gh tt workon` - so they refer to the issue they belong to.
 3. Development branches with more than one commit must all reference the issue they belong to - `gh tt wrapup` does that for you!
 4. Development branches must be squezeed to branches with just one single commit that can be merged _fast-forward only_. These branches must be prefixed with `ready/` to trigger the right workflow. `gh tt deliver` does that for you.

README.md

@@ -104,7 +104,7 @@ This utility supports an [opinionated flow](docs/workflow.md). If you share our
 
 **More goodies in the discussions**
 
-- [The Discussions on the repo](../../gh-tt/discussions) contains a lot of additional perspective and reflections on how the get the most our of this `gh tt` utility.
+- [The Discussions on the repo](../../discussions) contains a lot of additional perspective and reflections on how the get the most our of this `gh tt` utility.
 
 ## Introduction
 
@@ -134,7 +134,7 @@ Read about it in more detail in [docs/workflow.md](docs/workflow.md).
 
 ## Feedback, discussions, contributing
 
-Issues are open on the repo: [`devx-cafe/gh-tt`](../../gh-tt/issues). If you experience errors, misbehavior, or have feature requests, feel free to join the discussion.
+Issues are open on the repo: [`devx-cafe/gh-tt`](../../issues). If you experience errors, misbehavior, or have feature requests, feel free to join the discussion.
 
 For contributing, see [CONTRIBUTING.md](CONTRIBUTING.md).
 
@@ -287,4 +287,4 @@ gh responsibles  # instead of gh tt responsibles
 gh semver        # instead of gh tt semver
 ```
 
-Your feedback - or request for help - is always welcome: Use [the Issues](../../gh-tt/issues) or [the Discussions](../../gh-tt/discussions) to communicate.
+Your feedback - or request for help - is always welcome: Use [the Issues](../../issues) or [the Discussions](../../discussions) to communicate.

cspell.json

@@ -4,7 +4,6 @@
     "ignorePaths": [
         "**/node_modules/**",
         "**/.git/**",
-        "**/.github/**",
         "**/.vscode/**",
         "**/.cspell/**",
         "**/logs/**",