copilot-session-usage 0.6.4__tar.gz → 0.7.2__tar.gz

copilot_session_usage-0.7.2/.github/guidelines/git-commit-message.guideline.md

@@ -0,0 +1,193 @@
+---
+name: Git Commit Message Guideline 2.0
+description: Guidelines for writing conventional commits that communicate intent and user impact
+metadata:
+  owner: Gaetan Semet <gaetan.semet@ampere.cars>
+  keywords: [git, commit, conventional, message, changelog]
+  guideline-id: 45c42e46-0781-4954-a410-1f380f5553f3
+---
+
+# Git Commit Message Guideline
+
+Write clear, user-impact focused commit messages following Conventional Commits format.
+Commit messages communicate *why* changes were made, enabling automated changelog generation,
+bug investigation, and decision-making during upgrades.
+
+**Important**: Focus on user impact, not implementation details.
+
+## Core Rules
+
+### Rule 1: Use Conventional Commit Format
+
+**Apply:** Format every title as `type(scope): description`
+
+Note: scope is optional.
+
+**Why:** Enables automated changelog generation and consistent pattern parsing.
+
+**Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `ci`, `chore`, `build`, `revert`
+
+Choose the type from the category of change, not merely from whether the change
+improves reliability or is important:
+
+- `feat`: adds a new user-facing capability.
+- `fix`: corrects an existing user-facing behavior or defect.
+- `build`: changes packaging, release automation, build tooling, or distribution.
+- `ci`: changes validation, test, or pipeline execution without changing release
+  or packaging behavior.
+- `docs`: changes documentation only.
+- `refactor`: changes internal structure without changing behavior.
+- `test`: adds or changes tests without changing production behavior.
+- `chore`: maintenance that does not fit the other categories.
+
+Release workflows, package publication, versioning automation, and trusted
+publishing configuration use `build`, even when they improve reliability. Use
+`fix` only when correcting an already-observed user-facing defect.
+
+**Examples:**
+
+```text
+feat(auth): add two-factor authentication support
+fix(api): resolve request timeout in user endpoint
+docs(readme): update installation instructions
+perf(cache): optimize query performance by 40%
+test(validators): add email format validation tests
+```
+
+---
+
+### Rule 2: Keep Title Under 50 Characters, Body Under 72 Characters per Line
+
+**Apply:** Enforce character limits for scannability and terminal compatibility.
+
+**Why:** Short titles force clarity; wrapped body text maintains readability in terminals and email clients.
+
+**Exception**: URLs, hashes, or other unbreakable strings in body may exceed limits. Use discretion.
+
+**Example:**
+
+```text
+feat(cache): implement LRU eviction policy
+
+Reduces memory usage in long-running processes by
+automatically removing least-recently-used items.
+
+Changes:
+- Cache drops oldest accessed items upon limit
+- Configurable cache size (default 1000)
+- < 2% performance overhead on reads
+
+Users can set CACHE_SIZE environment variable.
+```
+
+---
+
+### Rule 3: Focus Body on User Impact, Not Implementation Details
+
+**Apply:** Describe what users gain and must know; exclude refactoring details, internal functions, and test additions.
+
+**Why:** Users deciding whether to upgrade, developers integrating changes, and bug investigators need user-level context—not code structure details.
+
+**Do Not** describe function-level changes, test modifications, or test counts.
+CI provides the authoritative check statistics.
+
+**Explicit check before committing**: Ask yourself — "Does the commit body
+read like a diff summary?" If it lists files changed, methods added, or
+test counts, rewrite it. The body must answer: "What can a user now do
+differently, or what error/limitation is now resolved?"
+
+**Example:**
+
+```text
+fix(api): allow null values in optional response fields
+
+Optional fields now omitted from JSON when empty,
+reducing response payload by ~15% for sparse data.
+
+Migration:
+- Check `field in response` instead of `field != null`
+- Response schema updated in API reference
+```
+
+---
+
+### Rule 4: Include Breaking Changes with Migration Guidance
+
+**Apply:** When a breaking change is introduced, use `!` in title and `BREAKING CHANGE:` section.
+Provide explicit migration steps.
+
+**Why:** Breaking changes require user action; clear guidance reduces upgrade confusion.
+
+**Example:**
+
+```text
+feat(api)!: change pagination to cursor-based tokens
+
+Cursors improve performance with large datasets.
+
+BREAKING CHANGE: Replaced `pagination_offset` and
+`pagination_limit` with `pagination.cursor`.
+
+Migration:
+Old: GET /users?limit=10&offset=20
+New: GET /users?limit=10&cursor=xyz123
+
+Update code to use `response.pagination.cursor`
+in next request instead of offset/limit.
+```
+
+### Rule 5: Keep ownership separate from AI assistance
+
+**Apply:** Do not add a `Signed-off-by` line unless explicitly requested by a human.
+The human may add it to indicate that they take ownership of the change. It is a
+DCO attestation, not an AI attribution.
+
+### Rule 6: Attribute the assisting model for AI-generated commits
+
+**Apply:** When the content of a commit was generated mainly with AI assistance,
+include exactly one `Assisted-by` trailer at the end of the message body:
+
+```text
+Assisted-by: PROVIDER:MODEL [FRAMEWORK]
+```
+
+- **PROVIDER** is the underlying model vendor, not the chat interface or IDE
+  integration. For example, use `OpenAI`, not `GitHub Copilot`.
+- **MODEL** is the exact display name reported by the active model selection or
+  current session metadata, for example `GPT-5.6 Luna`.
+- **FRAMEWORK** is optional and names the SDD orchestration framework that drove
+  the implementation. Omit it when assistance was provided directly.
+
+**Determine the value from the current session only:**
+
+1. Use the provider and model identifier exposed by the active harness or session
+  metadata.
+2. For Craftsman sessions, use the current session's
+  `Craftsman-Session-Model-Main` value or equivalent current usage record.
+3. Never copy an `Assisted-by` value from a previous commit, recent `git log`,
+  an example, or another session; those values describe historical assistance.
+4. If the current model cannot be verified, stop and obtain that information
+  before committing. Never guess a model or substitute the IDE/chat interface.
+
+**Correct examples:**
+
+```text
+# Direct AI assistance (no agentic framework):
+Assisted-by: Anthropic:Claude Sonnet 4.6
+
+# AI assistance via Craftsman Ralph Loop:
+Assisted-by: Anthropic:Claude Sonnet 4.6 Craftsman
+
+# GPT via Cursor, no framework:
+Assisted-by: OpenAI:GPT-4o
+```
+
+**Wrong (do not write these):**
+
+```text
+Assisted-by: GitHub Copilot        # ❌ interface name, not model
+Assisted-by: Cursor                # ❌ IDE name, not model
+Assisted-by: AI                    # ❌ too vague
+```
+
+A human may add a `Signed-off-by` line to indicate they take ownership of the change.

{copilot_session_usage-0.6.4 → copilot_session_usage-0.7.2}/.github/guidelines/knowledge-base.guidelines.md

@@ -80,7 +80,9 @@ Pre-commit checklist:
 - [ ] Correct `type` and folder for the information recorded.
 - [ ] Required frontmatter present and valid.
 - [ ] No Finding body was reworded or deleted.
-- [ ] All three commands above pass (also covered by `just preflight`).
+- [ ] Run `just knowledge-lint` when knowledge documents changed, then ensure
+  `just knowledge-lint-check` and `just knowledge-validate` pass. Both checks are
+  covered by `just preflight`.
 
 Add a dated entry to `knowledge/log.md` for significant changes. Use plain
 ISO-8601 date headings; avoid parenthetical annotations (they trigger warnings).

copilot_session_usage-0.7.2/.github/skills/gh-commit-changes/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: gh-commit-changes
+description: 'Commit all changes already staged in the Git index as one new Conventional Commit without staging, amending, or pushing anything. Use when asked to commit staged changes or create a commit from the index.'
+argument-hint: 'Optional intent or user-impact context for the commit message'
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Commit Staged Changes
+
+Create exactly one new commit from the Git index. Do not stage or unstage files,
+include unstaged changes, amend or rewrite history, or push.
+
+## Rules
+
+- Find applicable convention or guidelines applicable for the project first.
+  Follow those project conventions when creating commits.
+- Inspect `git diff --cached` and `git diff --cached --check`. Stop if the index
+  is empty, contains secrets or machine-local artifacts, mixes unrelated work,
+  or fails the check. The caller owns index contents.
+- Derive the commit message from all staged changes.
+  Ensure to strictly follow the project convention, then run `git commit` exactly once.
+  Do not use `--all`, `--amend`, or `--no-verify`.
+- Construct the complete message before invoking Git: subject, body, and trailers.
+  Do not pass each wrapped body line as a separate `-m` argument. Each `-m`
+  argument creates a separate paragraph and introduces an unintended blank line.
+  Pass the complete body as one message or use a complete commit-message file.
+- For AI-assisted commits, use exactly one verified `Assisted-by` trailer as
+  required by the guideline. Never guess the model or use the IDE name.
+- Verify the new commit and report any remaining staged or unstaged changes. Do
+  not claim that anything was pushed or that CI passed.

copilot_session_usage-0.7.2/.github/skills/gh-create-pull-request/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: gh-create-pull-request
+description: 'Publish the current Git branch with gh, create or reuse a pull request, monitor GitHub Actions, and repair pipeline failures with one Conventional Commit per fix. Use when asked to push a branch, open a pull request, watch CI, or fix pipeline failures.'
+argument-hint: 'Optional PR title, body, or target branch'
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Create Pull Request and Repair CI
+
+Use only for an explicit request to publish the current branch, open a GitHub
+pull request, monitor its pipeline, or repair a failed pipeline with `gh`.
+
+## Rules
+
+- Find applicable convention or guidelines applicable for the project first.
+  Follow those project conventions when creating commits.
+- Confirm `gh auth status`, the repository, current branch, default branch, and
+  a clean working tree. Stop for a detached/default branch, empty diff.
+  Use `/gh-commit-changes` for uncommitted or staged changes.
+- Push without rewriting history, create or reuse the branch's PR with `gh pr`,
+  and do not merge it unless separately requested.
+- Watch checks with `gh pr checks --watch`; inspect failures with `gh run list`
+  and `gh run view`. Rerun only clearly transient failures.
+- For a code failure, make the smallest safe fix, run the relevant project
+  checks, stage only that fix, invoke `/gh-commit-changes` once, push, and watch
+  the new run. One independent root cause means one new commit.
+- Never weaken checks, expose secrets, force-push, amend, or rewrite history.
+  Stop for administrative or unclear failures and report what is needed.
+
+## Completion
+
+Report the PR URL, final commit, fix commits, confirmed check results, and any
+remaining external action. Do not claim success without evidence from `gh`.