memory-journal-mcp 8.0.1 → 9.1.0

package/skills/github-commander/SKILL.md

@@ -1,144 +0,0 @@
----
-name: github-commander
-description: |
-  Structured workflows for GitHub issues, PRs, milestones, and code audits with validation gates and HITL checkpoints. 
-  Use when assigned a GitHub issue, reviewing a PR, sprinting through a milestone, updating dependencies, or running code audits. 
-  Also use when asked to "triage an issue", "review a PR", or "update deps". 
-  Do NOT trigger on bare verbs (e.g. "fix this"); require GitHub context. 
-  NOT for pipeline authoring (use github-actions instead).
-  Delegate all code quality, performance, and security audits to the dedicated `adversarial-*` skills instead.
----
-
-# GitHub Commander
-
-Structured, configurable workflows that teach AI agents to triage GitHub issues,
-review PRs, and sprint through milestones. Every action is journaled for full
-audit trails, and human-in-the-loop checkpoints keep you in control.
-
-The reason every step journals its results is that it creates a searchable audit
-trail — future sessions can find exactly what was tried, what passed, and what
-failed, without the human needing to remember or repeat context.
-
-## When to Load
-
-Load this skill when any of these apply:
-
-- You are assigned or asked to fix a GitHub issue
-- You need to review or submit a pull request
-- You need to work through issues in a milestone
-- You want to run dependency updates, security audits, or code quality audits
-- The user mentions an issue number (e.g., "fix #42") or PR number
-- The user says "triage", "audit", "review", "update deps", or similar
-- You are about to push code and want a structured validation pipeline
-
-## Quick Reference
-
-| Workflow                | File                            | Purpose                                     |
-| ----------------------- | ------------------------------- | ------------------------------------------- |
-| **Issue Triage**        | `workflows/issue-triage.md`     | Fix a single GitHub issue end-to-end        |
-| **PR Review**           | `workflows/pr-review.md`        | Review a PR with validation pipeline        |
-| **Milestone Sprint**    | `workflows/milestone-sprint.md` | Work through milestone issues sequentially  |
-| **Roadmap Kickoff**     | `workflows/roadmap-kickoff.md`  | Translate planning epics into Kanban issues |
-| **Update Dependencies** | `workflows/update-deps.md`      | Dependency update with audit trail          |
-
-## Prerequisites
-
-- `gh` CLI authenticated (`gh auth status`)
-- `GITHUB_TOKEN` set for API access
-- `PROJECT_REGISTRY` configured for repo auto-detection
-- Project repo cloned locally
-
-## Configuration
-
-All commands are configurable via environment variables. Defaults assume a
-Node.js project. Override for other ecosystems (Python, Rust, Go, etc.).
-
-| Variable                        | Default             | Description                         |
-| ------------------------------- | ------------------- | ----------------------------------- |
-| `PROJECT_LINT_CMD`              | `npm run lint`      | Lint command                        |
-| `PROJECT_TYPECHECK_CMD`         | `npm run typecheck` | Type-check command (empty = skip)   |
-| `PROJECT_BUILD_CMD`             | `npm run build`     | Build command (empty = skip)        |
-| `PROJECT_TEST_CMD`              | `npm run test`      | Unit/integration test command       |
-| `PROJECT_E2E_CMD`               | _(empty = skip)_    | E2E test command                    |
-| `PROJECT_PACKAGE_MANAGER`       | _(auto-detect)_     | `npm`, `yarn`, `pnpm`, or `bun`     |
-| `PROJECT_HAS_DOCKERFILE`        | _(auto-detect)_     | `true` to enable Docker audit steps |
-| `COMMANDER_HITL_FILE_THRESHOLD` | `10`                | HITL if changes touch > N files     |
-| `COMMANDER_SECURITY_TOOLS`      | _(auto-detect)_     | Comma-separated override list       |
-| `COMMANDER_BRANCH_PREFIX`       | `fix`               | Branch naming prefix                |
-
-### Package Manager Auto-Detection
-
-If `PROJECT_PACKAGE_MANAGER` is not set, detect by lockfile:
-
-1. `bun.lockb` or `bun.lock` → `bun`
-2. `pnpm-lock.yaml` → `pnpm`
-3. `yarn.lock` → `yarn`
-4. `package-lock.json` → `npm`
-5. Fallback → `npm`
-
-### Security Tool Auto-Detection
-
-When `COMMANDER_SECURITY_TOOLS` is not set, each tool is detected independently:
-
-| Tool           | Detection                       | What It Scans                 |
-| -------------- | ------------------------------- | ----------------------------- |
-| `npm-audit`    | Always (Node.js project)        | Dependency vulnerabilities    |
-| `codeql`       | `codeql` CLI or `gh codeql`     | Static analysis (SAST)        |
-| `trivy`        | `trivy --version` succeeds      | Container images, filesystems |
-| `docker-scout` | `docker scout version` succeeds | Docker image CVEs             |
-| `gitleaks`     | `gitleaks version` succeeds     | Secrets in git history        |
-| `trufflehog`   | `trufflehog --version` succeeds | Secrets (verified only)       |
-
-Missing tools are skipped with a journal note — never a failure.
-
-## Core Concepts
-
-### Validation Gates
-
-Every workflow uses sequential validation gates. Each gate must pass before the
-next runs. On failure, the agent attempts to auto-fix (lint/type errors). If
-auto-fix fails after 2 attempts, the agent requests human input.
-
-```
-Gate 1: Lint + Typecheck  →  Gate 2: Build  →  Gate 3: Tests  →  Gate 4: E2E  →  Gate 5: Security
-```
-
-Gates configured with empty commands are skipped automatically.
-
-### Journal Audit Trail
-
-Every significant action creates a journal entry with structured tags:
-
-- **`commander`** — all entries from this skill
-- **`triage`** / **`review`** / **`milestone`** — workflow type
-- **`gate-pass`** / **`gate-fail`** — validation results
-- **`security`** — security scan findings
-
-Entries link to issues/PRs via `issue_number` and `pr_number` fields, connecting
-to the knowledge graph automatically.
-
-### Human-in-the-Loop Checkpoints
-
-The agent pauses and requests human approval when:
-
-1. **Before `git push`** — present diff summary, files changed
-2. **Critical security findings** — any critical/high severity scan result
-3. **Unfixable test failures** — after 2 auto-fix attempts
-4. **Large changesets** — changes touch more files than `COMMANDER_HITL_FILE_THRESHOLD`
-5. **Between milestone issues** — in milestone-sprint workflow
-
-## Shipped Entry Types
-
-These entry types are used by Commander workflows for structured audit trails:
-
-| Type                     | Used By          | Purpose                                     |
-| ------------------------ | ---------------- | ------------------------------------------- |
-| `triage`                 | issue-triage     | Issue context gathered, analysis complete   |
-| `implementation`         | issue-triage     | Fix implemented                             |
-| `gate_pass`              | all              | Validation gate passed                      |
-| `gate_fail`              | all              | Validation gate failed (with error details) |
-| `pr_submitted`           | issue-triage     | PR created and pushed                       |
-| `review_start`           | pr-review        | PR review initiated                         |
-| `review_complete`        | pr-review        | PR review completed                         |
-| `milestone_sprint_start` | milestone-sprint | Sprint started                              |
-| `deps_update`            | update-deps      | Dependency update completed                 |

package/skills/github-commander/config/project-config.example.md

@@ -1,125 +0,0 @@
-# GitHub Commander — Project Configuration
-
-This file documents all environment variables used by the GitHub Commander skill.
-Copy the relevant variables to your MCP server configuration.
-
-## Quick Start (Node.js — defaults work out of the box)
-
-```json
-{
-  "mcpServers": {
-    "memory-journal-mcp": {
-      "command": "memory-journal-mcp",
-      "env": {
-        "GITHUB_TOKEN": "ghp_your_token",
-        "PROJECT_REGISTRY": "{\"my-repo\":{\"path\":\"/path/to/your/repo\",\"project_number\":1}}"
-      }
-    }
-  }
-}
-```
-
-No additional configuration needed — all defaults are Node.js with npm.
-
-## Full Configuration Reference
-
-### Project Commands
-
-These define what commands the agent runs during validation gates.
-Set any of them to an empty string to skip that gate.
-
-```bash
-# Lint command (default: "npm run lint")
-PROJECT_LINT_CMD="npm run lint"
-
-# Type-check command (default: "npm run typecheck")
-# Set empty to skip: PROJECT_TYPECHECK_CMD=""
-PROJECT_TYPECHECK_CMD="npm run typecheck"
-
-# Build command (default: "npm run build")
-# Set empty to skip: PROJECT_BUILD_CMD=""
-PROJECT_BUILD_CMD="npm run build"
-
-# Unit/integration test command (default: "npm run test")
-PROJECT_TEST_CMD="npm run test"
-
-# E2E test command (default: empty = skip)
-PROJECT_E2E_CMD="npm run test:e2e"
-```
-
-### Package Manager
-
-```bash
-# Auto-detected from lockfile if not set
-# Options: npm, yarn, pnpm, bun
-PROJECT_PACKAGE_MANAGER="npm"
-```
-
-### Docker Support
-
-```bash
-# Auto-detected from Dockerfile presence if not set
-# Set explicitly to enable Docker-specific audit steps
-PROJECT_HAS_DOCKERFILE="true"
-```
-
-### Commander Behavior
-
-```bash
-# HITL checkpoint if changes touch more than this many files (default: 10)
-COMMANDER_HITL_FILE_THRESHOLD="10"
-
-# Override auto-detected security tools (comma-separated)
-# Options: npm-audit, codeql, trivy, docker-scout, gitleaks, trufflehog
-# Default: auto-detect all available tools
-COMMANDER_SECURITY_TOOLS="npm-audit,trivy,gitleaks"
-
-# Branch naming prefix (default: "fix")
-# Produces branches like: fix/issue-123
-COMMANDER_BRANCH_PREFIX="fix"
-```
-
-## Example: Python Project
-
-```json
-{
-  "env": {
-    "PROJECT_LINT_CMD": "ruff check .",
-    "PROJECT_TYPECHECK_CMD": "mypy .",
-    "PROJECT_BUILD_CMD": "",
-    "PROJECT_TEST_CMD": "pytest",
-    "PROJECT_E2E_CMD": "",
-    "PROJECT_PACKAGE_MANAGER": "pip"
-  }
-}
-```
-
-## Example: Rust Project
-
-```json
-{
-  "env": {
-    "PROJECT_LINT_CMD": "cargo clippy -- -D warnings",
-    "PROJECT_TYPECHECK_CMD": "",
-    "PROJECT_BUILD_CMD": "cargo build",
-    "PROJECT_TEST_CMD": "cargo test",
-    "PROJECT_E2E_CMD": "",
-    "PROJECT_PACKAGE_MANAGER": "cargo"
-  }
-}
-```
-
-## Example: Go Project
-
-```json
-{
-  "env": {
-    "PROJECT_LINT_CMD": "golangci-lint run",
-    "PROJECT_TYPECHECK_CMD": "",
-    "PROJECT_BUILD_CMD": "go build ./...",
-    "PROJECT_TEST_CMD": "go test ./...",
-    "PROJECT_E2E_CMD": "",
-    "PROJECT_PACKAGE_MANAGER": "go"
-  }
-}
-```

package/skills/github-commander/workflows/code-quality-audit.md

@@ -1,82 +0,0 @@
-# Code Quality Audit
-
-Run a comprehensive code quality audit as a static analysis pass. No code
-changes are made until the human approves the findings.
-
-## Prompt
-
-Perform a comprehensive code quality audit of the target project. For each
-finding, report the file path, line range, severity (critical / moderate / low),
-and a concrete fix suggestion. Group findings by category:
-
-1. **Dead & unreachable code** — unused exports, unreachable branches, vestigial
-   feature flags
-2. **Duplication** — repeated logic that should be extracted into shared helpers
-3. **Import hygiene** — unused imports, missing imports, circular dependencies
-4. **Type safety** — `any` usage (use `unknown` instead), loose type assertions
-   (`as` — prefer `satisfies`), missing return types on exported functions,
-   and use of `enum`s (prefer literal union types)
-5. **Error handling** — typed error classes with descriptive messages including
-   context. Propagate with stack traces; never silently swallow exceptions
-6. **Logging** — centralized logger with structured payloads. Module-prefixed
-   codes. Severity: error | warning | info
-7. **Complexity** — functions exceeding ~40 lines, files exceeding ~500 lines,
-   high branching depth. Large files should be split into subdirectories with
-   barrel re-exports
-8. **Naming & consistency** — files/folders should follow project conventions.
-   Flag unclear variable names and inconsistent naming
-9. **Magic values** — hardcoded strings, numbers, or timeouts that should be
-   named constants
-10. **Stale markers** — TODO, FIXME, HACK, XXX comments; outdated JSDoc;
-    comments that contradict the code
-11. **Boundary Validation & Security** — ALWAYS use Zod (or equivalent) to
-    validate external boundaries. Flag blind-casting of payloads. Flag
-    unsanitized SQL interpolation, missing validation, overly permissive schemas
-12. **Performance** — unnecessary allocations in hot paths, missing early
-    returns, redundant queries
-13. **Dependency hygiene** — unused dependencies, unlisted peer dependencies
-14. **Accessibility** — if any UI/HTML output exists, verify proper labeling,
-    semantic structure, keyboard operability, contrast, and ARIA attributes
-
-## Execution
-
-1. Scan the project source directory systematically
-2. Journal each finding:
-   ```
-   create_entry({
-     content: "Code quality finding: [<category>] <severity> — <description>. File: <path>:<lines>.",
-     entry_type: "audit_finding",
-     tags: ["commander", "code-quality", "<category>"],
-   })
-   ```
-3. Produce a summary table:
-   | Category | Findings | Critical | Moderate | Low |
-   |---|---|---|---|---|
-4. Assign an overall quality score (A–F)
-
-## HITL Checkpoint
-
-Present findings to the human:
-
-- Summary table with counts per category
-- Overall quality score
-- Top critical findings with fix suggestions
-
-Wait for approval before applying any fixes.
-
-## Apply Fixes
-
-After human approval:
-
-1. Fix critical issues first, then moderate, then low
-2. Run validation gates after all fixes:
-   - Gate 1: Lint + Typecheck
-   - Gate 2: Build
-   - Gate 3: Tests _(Agent Note: Ensure OutputCharacterCount >= 10000 on test command execution to fully capture the summary line.)_
-3. Update changelog with audit fixes
-4. Commit with descriptive message:
-   ```bash
-   git add <fixed files> <changelog>
-   git diff --cached --stat
-   git commit -m "chore: code quality audit fixes"
-   ```

package/skills/github-commander/workflows/copilot-audit.md

@@ -1,50 +0,0 @@
-# GitHub Copilot CLI Pre-Push Audit Workflow
-
-This workflow orchestrates an AI-driven adversarial review using the GitHub Copilot CLI (`gh copilot`). It acts as a strict secondary validation layer (a "second opinion") across both localized logic changes (PR reviews) and full repository inspections.
-
-## Phase 1: Environment Readiness & Authentication
-
-1. **Verify Copilot CLI Presence**:
-   Run `gh extension list | grep copilot`.
-   If missing, install it via: `gh extension install github/gh-copilot`.
-
-2. **Verify Authentication**:
-   Ensure the CLI is authenticated via `gh auth status` and test with `gh copilot --version`. If the user has not authenticated, pause the agentic execution and prompt them to authorize (`gh auth login`).
-
-## Phase 2: Execution Targeting (The Audit Context)
-
-Determine whether this is a localized Feature Branch (Pre-Push PR) review or a whole Codebase Audit.
-
-> **Note**: The `gh copilot` extension does not natively support non-interactive file stream piping. The agent must use `gh copilot explain` or instruct the user to use the Copilot Chat window with the generated prompts.
-
-### Path A: Pre-Push PR Review
-
-1. Diff the current working branch against the primary target (e.g., `main` or `master`).
-2. **Execute Evaluation**:
-   Prompt the user to review the diff in their IDE's Copilot Chat using this prompt:
-   "Act as an extremely strict, senior PR reviewer. Review this submitted git diff. Analyze edge cases, logic gaps, unhandled bounds, typescript compliance, and security flaws. Produce a Markdown-formatted table of defects."
-
-### Path B: Comprehensive Codebase Review
-
-1. **Execute Codebase Evaluation**:
-   Prompt the user to perform the review in their IDE using the Workspace chat context (`@workspace`):
-   "Act as an adversarial security and performance auditor. Perform a comprehensive analysis of all files in this repository. Point out bad architectural couplings, injection vectors, unhandled error flows, and data boundaries that are not explicit. Output as a detailed Markdown report."
-
-## Phase 3: Journal Archival (Verification Sync)
-
-1. Capture the exact Markdown payload generated by Copilot.
-2. Persist this via `memory-journal-mcp`:
-   - Tool: `create_entry` (or `team_create_entry` if shared).
-   - Type: `audit_finding` or `triage`.
-   - Title: "Copilot CLI Adversarial Review: [Topic]"
-   - Content: The generated JSON/Markdown from the terminal stdout.
-   - Tags: `copilot`, `review`, `github-commander`.
-
-## Phase 4: Human-in-the-Loop Gateway
-
-1. Analyze and summarize the Copilot payload.
-2. Present the summarized critique directly to the User.
-3. Pause and Wait. Do not commit or push the code.
-4. **Branching Action**:
-   - If User approves changes: Remediate the code directly based on Copilot's findings using local agent tool capabilities (`replace_file_content`, etc).
-   - If User rejects/ignores the findings: Proceed to standard commit and push pipelines.

package/skills/github-commander/workflows/issue-triage.md

@@ -1,248 +0,0 @@
----
-description: Fix a single assigned GitHub issue end-to-end — from context gathering through validated PR submission
----
-
-# Issue Triage
-
-Fix a single assigned GitHub issue end-to-end — from context gathering through
-validated PR submission.
-
-## Phase 1 — Gather Context
-
-1. Read `memory://briefing` for session context
-2. Fetch the assigned issue:
-   ```
-   get_github_issue({ issue_number: <N> })
-   ```
-3. Search journal for related prior work:
-   ```
-   semantic_search({ query: "<issue title/description>" })
-   search_entries({ tags: ["commander"] })
-   ```
-4. Check knowledge graph for linked specs/implementations:
-   ```
-   visualize_relationships({ format: "mermaid" })
-   ```
-5. Journal the triage start:
-   ```
-   create_entry({
-     content: "Triaging issue #<N>: <title>. Related entries: <ids>. Prior context: <summary>.",
-     entry_type: "triage",
-     tags: ["commander", "triage"],
-     issue_number: <N>
-   })
-   ```
-
-## Phase 2 — Implement Fix
-
-1. Analyze the issue and implement the fix
-2. Follow existing project conventions (check journal for patterns, rules, etc.)
-3. Journal the implementation:
-   ```
-   create_entry({
-     content: "Implemented fix for #<N>: <description of changes>. Files modified: <list>.",
-     entry_type: "implementation",
-     tags: ["commander", "fix"],
-     issue_number: <N>
-   })
-   ```
-
-## Phase 3 — Validation Gates
-
-Run gates sequentially. Each must pass before the next. Skip gates where the
-command is empty or not configured.
-
-### Gate 1: Lint + Typecheck
-
-Run `PROJECT_LINT_CMD` (default: `npm run lint`).
-Run `PROJECT_TYPECHECK_CMD` (default: `npm run typecheck`).
-
-On failure:
-
-- Attempt auto-fix (run lint with `--fix` if available)
-- Re-run the gate
-- If still failing after 2 attempts → **HITL checkpoint**
-
-Journal result:
-
-```
-create_entry({
-  content: "Gate 1 (Lint + Typecheck): PASSED/FAILED. Details: <output>.",
-  entry_type: "gate_pass" or "gate_fail",
-  tags: ["commander", "validation", "lint"],
-  issue_number: <N>
-})
-```
-
-### Gate 2: Build
-
-Run `PROJECT_BUILD_CMD` (default: `npm run build`).
-Skip if not configured (empty string).
-
-On failure → attempt fix → **HITL checkpoint** after 2 attempts.
-
-### Gate 3: Unit/Integration Tests
-
-Run `PROJECT_TEST_CMD` (default: `npm run test`). _(Agent Note: Ensure OutputCharacterCount >= 10000 on test execution)_
-
-On failure:
-
-- Analyze test output to determine if failure is related to the fix
-- If related: attempt to fix the test or the code
-- If unrelated (pre-existing failure): journal and flag for human
-- After 2 fix attempts → **HITL checkpoint**
-
-### Gate 4: E2E Tests
-
-Run `PROJECT_E2E_CMD` (default: empty = skip). _(Agent Note: Ensure OutputCharacterCount >= 10000)_
-Skip if not configured. Same failure handling as Gate 3.
-
-### Gate 5: Security Scans
-
-Run auto-detected security scanning tools (see SKILL.md § Security Tool
-Auto-Detection). For each available tool:
-
-1. Run the scan
-2. Parse output for findings with severity levels
-3. Journal each finding:
-   ```
-   create_entry({
-     content: "Security finding (<tool>): <severity> - <description>",
-     entry_type: "security_finding",
-     tags: ["commander", "security", "<tool-name>"],
-     issue_number: <N>
-   })
-   ```
-4. **Critical/High findings → HITL checkpoint** (present findings, ask how to proceed)
-5. Missing tools → skip with journal note:
-   ```
-   create_entry({
-     content: "Security scan: <tool> not available — skipped.",
-     entry_type: "gate_pass",
-     tags: ["commander", "validation", "security-skip"],
-     issue_number: <N>
-   })
-   ```
-
-#### npm audit
-
-```bash
-npm audit --json
-```
-
-Parse JSON output. Report vulnerabilities by severity.
-
-#### CodeQL (if available)
-
-```bash
-codeql database create /tmp/codeql-db --language=javascript --overwrite
-codeql database analyze /tmp/codeql-db --format=sarif-latest --output=/tmp/codeql-results.sarif
-```
-
-Or via GitHub Actions (if running in CI context).
-
-#### Trivy (if available)
-
-```bash
-trivy fs --severity HIGH,CRITICAL --format json .
-```
-
-For Docker projects (`PROJECT_HAS_DOCKERFILE=true`):
-
-```bash
-trivy image --severity HIGH,CRITICAL --format json <image-name>
-```
-
-#### Docker Scout (if available)
-
-```bash
-docker scout cves <image-name> --format json --only-severity critical,high
-```
-
-#### Gitleaks (if available)
-
-```bash
-gitleaks detect --source . --report-format json --report-path /tmp/gitleaks.json
-```
-
-#### TruffleHog (if available)
-
-```bash
-trufflehog filesystem . --json --only-verified
-```
-
-## Phase 4 — Human Checkpoint
-
-**Always pause before submitting a PR.** Present to the human:
-
-1. Summary of changes (files modified, lines added/removed)
-2. All gate results (pass/fail with details)
-3. Any security findings
-4. All journal entries created during this workflow
-
-**Additional HITL triggers** (pause earlier if any apply):
-
-- Changes touch more files than `COMMANDER_HITL_FILE_THRESHOLD` (default: 10)
-- Any critical or high security findings
-- Test failures that couldn't be auto-fixed
-
-Wait for human approval before proceeding to Phase 5.
-
-## Phase 5 — Submit PR
-
-1. Create a feature branch:
-
-   ```bash
-   git checkout -b <COMMANDER_BRANCH_PREFIX>/issue-<N>
-   ```
-
-2. Stage changed files selectively (**never `git add -A`**):
-
-   ```bash
-   git add <file1> <file2> ...
-   ```
-
-3. Verify staged files:
-
-   ```bash
-   git diff --cached --stat
-   ```
-
-4. Commit with descriptive message:
-
-   ```bash
-   git commit -m "fix: <description> (closes #<N>)"
-   ```
-
-5. Push and create PR:
-
-   ```bash
-   git push origin <COMMANDER_BRANCH_PREFIX>/issue-<N>
-   gh pr create --base main --title "fix: <description>" --body "Closes #<N>\n\n<summary of changes>"
-   ```
-
-6. Journal the PR and update the Kanban Board:
-   ```
-   create_entry({
-     content: "Submitted PR #<pr_number> for issue #<N>: <description>. Gates: all passed.",
-     entry_type: "pr_submitted",
-     tags: ["commander", "pr", "kanban_sync"],
-     issue_number: <N>,
-     pr_number: <pr_number>
-   })
-   ```
-   _Kanban Sync:_ Using the Project Node IDs anchored in the memory journal during the roadmap kickoff, transition the issue card from "In Progress" to "In Review":
-   ```bash
-   // turbo
-   gh project item-edit --id {ITEM_NODE_ID} --project-id {PROJECT_NODE_ID} --field-id {STATUS_FIELD_ID} --single-select-option-id {IN_REVIEW_OPTION_ID}
-   ```
-
-## Phase 6 — Session Summary
-
-Run `/session-summary` to capture:
-
-- Issue triaged and fixed
-- All gate results
-- Security findings (if any)
-- PR link and status
-- Any pending items for next session