memory-journal-mcp 8.0.1 → 9.1.0

package/skills/github-commander/workflows/milestone-sprint.md

@@ -1,89 +0,0 @@
----
-description: Work through open issues in a GitHub milestone sequentially, applying the issue-triage workflow to each
----
-
-# Milestone Sprint
-
-Work through open issues in a GitHub milestone sequentially, applying the
-issue-triage workflow to each.
-
-## Phase 1 — Load Milestone
-
-1. Read `memory://briefing` for session context
-2. Fetch milestone details:
-   ```
-   get_github_milestone({ milestone_number: <N> })
-   ```
-3. Read priority ordering directly from the centralized Project Control Board:
-   ```
-   read_resource("memory://kanban/{project_number}")
-   ```
-   Cross-reference this prioritized sequence with the open milestone issues:
-   ```
-   get_github_issues({ milestone: <N>, state: "open" })
-   ```
-4. Journal sprint start:
-   ```
-   create_entry({
-     content: "Starting milestone sprint: <title>. Open issues: <count>. Completion: <percent>%.",
-     entry_type: "milestone_sprint_start",
-     tags: ["commander", "milestone"],
-   })
-   ```
-
-## Phase 2 — Triage Issues
-
-For each open issue in the milestone (in priority order):
-
-1. **HITL checkpoint**: Present the next issue to the human:
-   - Issue number, title, labels
-   - Estimated complexity (based on description and labels)
-   - Ask: "Proceed with this issue?" / "Skip?" / "Stop sprint?"
-
-2. If human approves: run the full **issue-triage.md** workflow for this issue
-
-3. After each issue is complete, update the sprint progress:
-
-   ```
-   get_github_milestone({ milestone_number: <N> })
-   ```
-
-   Report updated completion percentage.
-
-4. Repeat for next issue until:
-   - All issues are complete
-   - Human chooses to stop
-   - Session time/token limits are approached
-
-## Phase 3 — Sprint Summary
-
-After all issues are processed (or sprint is stopped):
-
-1. Aggregate results across all triaged issues:
-   - Issues attempted vs. completed
-   - Gate results summary (total passes/fails)
-   - Security findings across all issues
-   - PRs submitted
-
-2. Report milestone delta:
-
-   ```
-   get_github_milestone({ milestone_number: <N> })
-   ```
-
-   Show completion percentage before and after sprint.
-
-3. Journal sprint summary:
-
-   ```
-   create_entry({
-     content: "Milestone sprint complete: <title>. Issues fixed: <N>/<total>. Milestone: <before>% → <after>%. PRs: <list>.",
-     entry_type: "milestone_sprint_start",
-     tags: ["commander", "milestone", "summary"],
-   })
-   ```
-
-4. Run `/session-summary` with:
-   - All issues triaged in this sprint
-   - Remaining issues for next session
-   - Any blockers or findings requiring human attention

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

@@ -1,144 +0,0 @@
-# Performance Audit
-
-Run a comprehensive performance audit covering build times, bundle size, runtime
-patterns, test suite speed, and database/IO efficiency.
-
-## 1. Build Performance
-
-Measure compilation speed and identify bottlenecks.
-
-For TypeScript projects:
-
-```bash
-npx tsc --noEmit --diagnostics
-```
-
-If a bundler is configured, also run `PROJECT_BUILD_CMD` and report build time.
-
-Report:
-
-- Total compilation time
-- Files compiled, lines of code
-- Memory usage
-- Any abnormally slow type-resolution (deep generics, circular types)
-
-## 2. Bundle & Output Analysis
-
-Analyze the compiled output for size and optimization opportunities:
-
-- Count total output files and aggregate size
-- Identify the largest output files (top 5 by size)
-- Check for accidental bundling of dev dependencies or test fixtures
-- Flag output files that include source maps in production builds
-
-For frontend projects, additionally check:
-
-- Code-splitting effectiveness
-- Asset optimization (images, fonts, CSS)
-- Tree-shaking gaps
-
-## 3. Dependency Weight
-
-Audit dependency footprint:
-
-```bash
-# npm
-npm ls --all --prod 2>/dev/null | tail -1
-
-# yarn
-yarn list --prod
-
-# pnpm
-pnpm list --prod
-```
-
-Report:
-
-- Total production dependency count (direct + transitive)
-- Top 5 heaviest dependencies
-- Duplicate packages (different versions of same dep)
-- Dependencies replaceable with lighter alternatives
-- devDependencies accidentally listed in dependencies
-
-## 4. Runtime Performance
-
-Static analysis pass for runtime performance issues:
-
-- **Hot-path allocations** — object/array creation inside tight loops, repeated
-  `JSON.parse`/`JSON.stringify`, unnecessary spread in iteration
-- **Missing early returns** — expensive work before guard conditions
-- **Redundant computation** — values computed multiple times when cacheable
-- **Blocking operations** — synchronous I/O, CPU-intensive loops without
-  yielding, serial `await` where parallel is safe
-- **Memory leaks** — event listeners not cleaned up, growing collections
-  without eviction, closures capturing large scopes
-- **Startup cost** — heavy top-level initialization, eager loading of
-  rarely-used modules
-
-## 5. Test Suite Performance
-
-Run tests with verbose output:
-
-```bash
-<PROJECT_TEST_CMD> -- --reporter=verbose
-```
-
-_(Agent Note: Ensure OutputCharacterCount >= 10000 on test command execution to fully capture the summary line.)_
-
-Report:
-
-- Total suite duration
-- Top 5 slowest test files
-- Top 5 slowest individual tests
-- Tests doing real I/O without mocking
-- Parallelization opportunities
-
-## 6. Database & I/O Performance
-
-If the project interacts with databases or performs significant I/O:
-
-- **Query patterns** — N+1 queries, missing indexes, unbounded queries,
-  sequential queries that could be batched
-- **Connection management** — pool sizing, connection leak risks, missing
-  timeouts
-- **Caching** — repeated identical queries without caching, stale TTLs
-- **Serialization** — excessive object transformation between layers
-
-## Findings Report
-
-Journal each finding:
-
-```
-create_entry({
-  content: "Performance finding: <severity> — <description>. File: <path>:<lines>. Expected improvement: <estimate>.",
-  entry_type: "audit_finding",
-  tags: ["commander", "performance", "<category>"],
-})
-```
-
-Produce a structured summary:
-
-| Category            | Score (A–F) | Findings | Critical |
-| ------------------- | ----------- | -------- | -------- |
-| Build Performance   |             |          |          |
-| Bundle & Output     |             |          |          |
-| Dependency Weight   |             |          |          |
-| Runtime Performance |             |          |          |
-| Test Suite Speed    |             |          |          |
-| Database & I/O      |             |          |          |
-
-Assign an **overall performance score (A–F)** and list the top 3 highest-impact
-improvements.
-
-## HITL Checkpoint
-
-Present findings to the human. Wait for approval before applying any fixes.
-
-## Apply Fixes
-
-After approval:
-
-1. Apply fixes in impact order (highest improvement first)
-2. Run validation gates
-3. Update changelog
-4. Commit

package/skills/github-commander/workflows/pr-review.md

@@ -1,129 +0,0 @@
----
-description: Review an open pull request with validation pipeline and structured findings
----
-
-# PR Review
-
-Review an open pull request with optional validation pipeline and structured
-findings.
-
-## Phase 1 — Gather Context
-
-1. Read `memory://briefing` for session context
-2. Fetch the PR details:
-   ```
-   get_github_pr({ pr_number: <N> })
-   ```
-3. If available, fetch Copilot review findings:
-   ```
-   get_copilot_reviews({ pr_number: <N> })
-   ```
-4. Search journal for related entries:
-   ```
-   semantic_search({ query: "<PR title/description>" })
-   ```
-5. Check linked issues and milestone context
-6. Journal review start:
-   ```
-   create_entry({
-     content: "Starting review of PR #<N>: <title>. Author: <author>. Files changed: <count>.",
-     entry_type: "review_start",
-     tags: ["commander", "review"],
-     pr_number: <N>
-   })
-   ```
-
-## Phase 2 — Code Review
-
-1. Check out the PR branch locally:
-
-   ```bash
-   gh pr checkout <N>
-   ```
-
-2. Review changes for:
-   - **Correctness** — does the code do what the PR claims?
-   - **Style** — does it follow project conventions?
-   - **Security** — any injection, validation, or auth issues?
-   - **Performance** — any hot-path allocations, missing early returns?
-   - **Test coverage** — are new/changed paths tested?
-
-3. Run validation gates (same as issue-triage Phase 3):
-   - Gate 1: Lint + Typecheck
-   - Gate 2: Build
-   - Gate 3: Unit/Integration Tests _(Agent Note: Ensure OutputCharacterCount >= 10000 on test execution)_
-   - Gate 4: E2E Tests _(Agent Note: Ensure OutputCharacterCount >= 10000)_
-   - Gate 5: Security Scans (auto-detected)
-
-   Journal each gate result as in issue-triage.
-
-## Phase 3 — Findings Report
-
-Compile all findings into a structured report:
-
-1. **Code review findings** — issues found during manual review
-2. **Gate results** — pass/fail for each validation gate
-3. **Security findings** — from auto-detected security scans
-4. **Copilot findings** — any issues flagged by Copilot reviews
-
-Journal each significant finding:
-
-```
-create_entry({
-  content: "PR #<N> finding: <severity> - <description>. File: <path>:<lines>.",
-  entry_type: "audit_finding",
-  tags: ["commander", "review", "<category>"],
-  pr_number: <N>
-})
-```
-
-**HITL checkpoint**: Present the full findings report to the human. Ask for
-review decision:
-
-- **Approve** — no blocking issues found
-- **Request changes** — blocking issues identified
-- **Comment** — non-blocking suggestions
-
-## Phase 4 — Submit Review
-
-Based on human's decision:
-
-### Approve
-
-```bash
-gh pr review <N> --approve --body "LGTM. All validation gates passed. <summary>"
-```
-
-### Request Changes
-
-```bash
-gh pr review <N> --request-changes --body "<findings summary with specific file/line references>"
-```
-
-### Comment
-
-```bash
-gh pr review <N> --comment --body "<non-blocking suggestions>"
-```
-
-Journal review completion:
-
-```
-create_entry({
-  content: "Completed review of PR #<N>: <decision>. Findings: <count>. Gates: <summary>.",
-  entry_type: "review_complete",
-  tags: ["commander", "review", "<decision>"],
-  pr_number: <N>
-})
-```
-
-_Kanban Sync:_ If the review decision was **Approved**, prompt the user (or execute if explicitly permitted) to merge the PR. Merging the PR securely merges the code and triggers GitHub automation to move the linked Kanban Issue card to the "Done" state, safely completing the execution chain initiated by `roadmap-kickoff`.
-
-## Phase 5 — Session Summary
-
-Run `/session-summary` to capture:
-
-- PR reviewed with decision
-- All findings by category
-- Gate results
-- Any follow-up items

package/skills/github-commander/workflows/roadmap-kickoff.md

@@ -1,79 +0,0 @@
----
-description: Translate an approved epic implementation plan into an agent-actionable GitHub Kanban structure via Milestones and tracked Issues.
----
-
-# /roadmap-kickoff
-
-**Objective**: Translate an approved architectural or implementation plan into an agent-actionable GitHub Kanban structure. This establishes an **Agent Coordination Center** where large epics are safely chunked into distinct, trackable threads.
-
-## Context & Rationale
-
-When an implementation plan requires multiple agent sessions (e.g., crossing token limits, context constraints, or independent phase checkpoints), we use the GitHub Kanban board + Memory Journal MCP as the synchronization layer.
-
-By anchoring every implementation task to a Milestone and throwing it in the Project Backlog:
-
-1. **Context Integrity**: A fresh agent session can pull down `memory://kanban/{project_number}` or `memory://github/milestones` and immediately know what is up next.
-2. **Parallel Work**: The user can spin up parallel agents operating on distinct project columns/issues.
-3. **Decoupling**: The central plan remains the source of truth, while GitHub acts as the execution layer.
-
----
-
-## Prerequisites
-
-- An agreed-upon **Implementation Plan** or Epic (e.g. `docs/epic-implementation-plan.md`).
-- A `gh` CLI token verified to possess the `project` scope (req. for adding to Projects v2 columns). If missing, the user runs: `gh auth refresh -s project`.
-
----
-
-## Workflow Steps
-
-### 1. Establish the Milestone
-
-Determine the version tag or epic codename from the implementation plan. Create the milestone to anchor the issues.
-
-```bash
-// turbo
-gh api repos/{owner}/{repo}/milestones -F title="Epic Name (vX.X.X)" -F state="open" -F description="Implementation roadmap..."
-```
-
-### 2. Actionable Issue Formulation
-
-Break the implementation plan down into discrete, atomic tracking issues based on the deliverables/phases.
-
-- Each issue body **must** contain enough context (deliverables, acceptance rules, scope) so that an entirely new agent session could pick it up blindly and succeed.
-
-### 3. Generate Tracking Issues
-
-Use the explicit Milestone Title (not the ID) to tie all created issues firmly to the Epic.
-
-```bash
-// turbo
-gh issue create --repo {owner}/{repo} --title "Feat: Phase X - ..." --body "Full context..." --milestone "Epic Name (vX.X.X)"
-```
-
-### 4. Backlog Placement (Crucial)
-
-By default, newly created issues might land unmapped in a Project's "No Status" bucket. You must explicitly move them into the `Backlog`.
-
-**A. Retrieve Node IDs:**
-
-```bash
-// turbo
-gh project view {project_number} --owner {owner} --format json -q .id
-gh project field-list {project_number} --owner {owner} --format json
-gh project item-list {project_number} --owner {owner} --format json
-```
-
-_Identify the: (1) Project ID, (2) Status Field ID, (3) 'Backlog' Option ID, and (4) The newly created Item Node IDs._
-
-**B. Update Item Status:**
-
-```bash
-// turbo
-gh project item-edit --id {ITEM_NODE_ID} --project-id {PROJECT_NODE_ID} --field-id {STATUS_FIELD_ID} --single-select-option-id {BACKLOG_OPTION_ID}
-```
-
-### 5. Orchestration Handoff
-
-- Use the **memory-journal-mcp** server to record a `create_entry` (or `team_create_entry`). Include the milestone link, total breakdown of GitHub issues, and explicitly record the `roadmap_anchored` state, storing the newly registered Project and Board Node IDs.
-- Daisy-chain launch (or notify the human to launch) the Sprint Orchestrator by issuing the command: `"Run /milestone-sprint targeting Milestone <X>"`. The orchestration node will pull directly from the initialized Kanban backlog based on the anchored Project Board metrics.

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

@@ -1,170 +0,0 @@
-# Security Audit
-
-Run a comprehensive security audit using auto-detected scanning tools. Each tool
-is independently detected and skipped gracefully if unavailable.
-
-## Phase 1 — Tool Detection
-
-Detect available security scanning tools (see SKILL.md § Security Tool
-Auto-Detection). Journal which tools are available:
-
-```
-create_entry({
-  content: "Security audit: detected tools: <list>. Unavailable: <list>.",
-  entry_type: "audit_finding",
-  tags: ["commander", "security", "detection"]
-})
-```
-
-## Phase 2 — Dependency Vulnerabilities
-
-### npm audit (always available for Node.js)
-
-```bash
-npm audit --json
-```
-
-Report:
-
-- Total vulnerabilities by severity (critical / high / moderate / low)
-- Whether each is fixable via `npm audit fix` or requires manual intervention
-- Any overrides/resolutions in the manifest that may mask unfixed vulnerabilities
-
-For non-Node.js projects, use the equivalent tool:
-
-- Python: `pip audit --format json`
-- Rust: `cargo audit --json`
-- Go: `govulncheck ./...`
-
-## Phase 3 — Static Analysis (SAST)
-
-### CodeQL (if available)
-
-```bash
-codeql database create /tmp/codeql-db --language=<detected> --overwrite
-codeql database analyze /tmp/codeql-db \
-  --format=sarif-latest \
-  --output=/tmp/codeql-results.sarif \
-  security-extended security-and-quality
-```
-
-Parse SARIF output for findings. Journal each finding with severity.
-
-## Phase 4 — Secret Scanning
-
-### Gitleaks (if available)
-
-```bash
-gitleaks detect --source . --report-format json --report-path /tmp/gitleaks.json
-```
-
-### TruffleHog (if available)
-
-```bash
-trufflehog filesystem . --json --only-verified
-```
-
-For each finding: report file, line, secret type, and remediation.
-
-## Phase 5 — Container Security (if applicable)
-
-Skip unless `PROJECT_HAS_DOCKERFILE` is `true` or a Dockerfile is detected.
-
-### Trivy (if available)
-
-Filesystem scan:
-
-```bash
-trivy fs --severity HIGH,CRITICAL --format json .
-```
-
-Image scan (if image is built):
-
-```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
-```
-
-## Phase 6 — Source Code Analysis
-
-Perform static analysis of the source code for common vulnerability patterns:
-
-1. **SQL injection** — string interpolation in SQL queries, missing parameterized
-   queries
-2. **Command injection** — user input passed to `exec()`, `spawn()`, or shell
-   commands without sanitization
-3. **Path traversal** — user-supplied paths used without normalization and
-   boundary checks
-4. **Prototype pollution** — unchecked `Object.assign()`, deep merge without
-   prototype guards
-5. **Input validation gaps** — blind-casting external payloads without validation,
-   overly permissive schemas, missing `.strict()` on API boundaries (ALWAYS use Zod)
-6. **Authentication bypass** — endpoints accessible without auth checks
-7. **Error disclosure** — stack traces, database errors, or internal structure
-   leaked in responses
-
-## Phase 7 — CI/CD Pipeline Review
-
-If GitHub Actions workflows exist (`.github/workflows/`):
-
-1. **Action pinning** — verify `uses:` references use SHA commits, not tags
-2. **Secret handling** — verify secrets use `${{ secrets.* }}`, not inline values
-3. **Security gates** — verify security scans (e.g., Docker Scout, Trivy, CodeQL, npm audit) hard-fail on vulnerabilities (no `continue-on-error: true`)
-4. **Permissions** — verify workflow `permissions` follows least privilege
-
-## Phase 8 — Findings Report
-
-Journal all findings:
-
-```
-create_entry({
-  content: "Security audit finding: <severity> — <description>. Tool: <tool>. File: <path>.",
-  entry_type: "security_finding",
-  tags: ["commander", "security", "<tool-name>"],
-})
-```
-
-Produce a structured summary:
-
-| Category                   | Risk Level | Findings | Critical |
-| -------------------------- | ---------- | -------- | -------- |
-| Dependency Vulnerabilities |            |          |          |
-| Static Analysis (SAST)     |            |          |          |
-| Secret Exposure            |            |          |          |
-| Container Security         |            |          |          |
-| Source Code Patterns       |            |          |          |
-| CI/CD Pipeline             |            |          |          |
-
-**HITL checkpoint**: Present findings report to the human with:
-
-- An overall security posture score (A–F)
-- Top 3 most urgent remediations
-- Whether any findings are auto-fixable
-
-## Phase 9 — Apply Fixes (with approval)
-
-After human approves the fix plan:
-
-1. Apply fixes in severity order (critical → high → moderate → low)
-2. Run validation gates after all fixes:
-   - Gate 1: Lint + Typecheck
-   - Gate 2: Build
-   - Gate 3: Tests
-3. Journal each fix applied
-
-## Phase 10 — Commit
-
-Stage and commit security fixes:
-
-```bash
-git add <fixed files> <changelog>
-git diff --cached --stat
-git commit -m "security: audit fixes"
-```
-
-**Do not push** without human approval.