// Attach relevant Copilot session lessons, mistakes, decisions, model details, token usage, MCP servers, and skills to a GitHub issue comment. Use when the user asks to add session notes, lessons learned, Copilot notes, mistakes, or implementation details to an issue.
| name | issue-session-notes |
| description | Attach relevant Copilot session lessons, mistakes, decisions, model details, token usage, MCP servers, and skills to a GitHub issue comment. Use when the user asks to add session notes, lessons learned, Copilot notes, mistakes, or implementation details to an issue. |
Use this skill to create or update a GitHub issue comment with the useful parts of a Copilot session. The goal is to leave behind context that helps the next person continue the issue without reading the full chat transcript.
Prefer one living comment per issue. Update that comment instead of creating many new comments, because GitHub issue comments notify subscribers and rapid comment creation can hit secondary rate limits.
Gather only what is available. If a field is unavailable, write Not available
rather than guessing.
Useful Copilot CLI commands from the help menu:
/usage for session usage metrics and token information/env for loaded MCP servers, skills, agents, plugins, and instructions/search to find important moments in the conversation timeline/diff to review code changes before summarizing them/tasks to review subagents and shell commands used during the session/share only when a longer, scrubbed artifact is worth linkingIf slash command output is not directly available to the agent, summarize from the
visible conversation and tool history, and mark unknown fields as Not available.
Use this markdown template. Keep the note short and concrete.
<!-- copilot-session-notes:v1 issue=<issue-number> -->
## Copilot session notes
**Session date:** <YYYY-MM-DD>
**Related work:** <branch, PR, commit, or Not available>
**Model used:** <model name and model ID, or Not available>
**Token usage:** <input/output/total if available, or Not available>
**MCP/tool servers used:** <comma-separated list, or None observed>
**Skills used:** <comma-separated list, or None observed>
**Available but not used:** <optional short list, or omit>
### What we learned
- <Relevant discovery or lesson. Explain why it matters for this issue.>
### Mistakes or false starts
- <What was tried, what went wrong, and how to avoid repeating it.>
### Important implementation details
- <Decision, constraint, edge case, file, command, or validation detail.>
### Next action
- <One concrete next step, or "None.">
Include information that would help someone continue the issue later:
| Include | Skip |
|---|---|
| Root cause of a bug | Full raw chat transcript |
| Failed approach and why it failed | Routine command output |
| Important repo convention discovered | Token values, secrets, or credentials |
| Validation commands that matter | Every command that happened to run |
| Files, functions, or workflows involved | Unrelated exploration |
| Tradeoff or decision made | Vague notes like "Copilot fixed it" |
| Open question or blocker | Unverified guesses |
Prefer GitHub CLI for issue comments:
gh issue comment <issue-number-or-url> \
--body-file <notes-file> \
--edit-last \
--create-if-none
Use standard issue comments for general session notes. For pull request timeline comments, use:
gh pr comment <pr-number-or-url> \
--body-file <notes-file> \
--edit-last \
--create-if-none
Only use pull request review comments when the note belongs on a specific changed line.
If GitHub CLI cannot be used, create an issue comment with the REST API:
POST /repos/{owner}/{repo}/issues/{issue_number}/comments
Request body:
{
"body": "comment markdown"
}
Use Accept: application/vnd.github+json when making API requests.
Not available.Run ruff lint, ruff format, ty type-check, shared/API tests, start the API, smoke test endpoints, then kill the API. Use after editing Python files to catch errors before commit.
Run prek, run tests, resolve issues, commit, push, then monitor the deploy workflow and resolve any deploy failures. Use when user says "ship it", "commit and deploy", "push and deploy", or "land this".
Map concepts, issues, and code changes in this repo to specific chapters and pages of Fluent Python, 2nd edition (Luciano Ramalho). Use when the user wants to ground a task in the underlying Python concept, e.g. "where is this in fluent python?", "what should I read for
Undo local submissions for DevOps and Verify Journal API Implementation so you can re-test verification flows. Also supports custom requirement IDs and user scoping.
Reset verification submissions for a user in production. Use when user says "reset prod submissions", "reset phase X in prod", "undo prod verification", or "reset prod for <username>".
Debug GitHub Actions workflow failures and Terraform errors. Use when deployment failed, Terraform state lock, CI/CD pipeline errors, or troubleshooting deploy.yml.