memory-journal-mcp 8.0.1 → 9.1.0

package/skills/adversarial-performance/references/multi-pass-performance-protocol.md

@@ -1,398 +0,0 @@
-# Multi-Pass Performance Protocol
-
-Detailed reference for the 4-phase adversarial performance audit workflow.
-Read this when executing the protocol for the full review dimensions, scoring
-system, and output templates.
-
-## Phase 1 — Profiling (Agent A: Profiler)
-
-### Inputs
-
-Before starting the profiling pass, gather context from these sources:
-
-1. **Repository structure** — build tooling (tsc, tsup, esbuild, webpack,
-   vite), test framework, output directory, entry points
-2. **Existing performance documentation** — READMEs, benchmarks, prior audit
-   results
-3. **Prior audits** — search the journal for related performance entries:
-   ```
-   search_entries({
-     query: "<repository name> performance",
-     entry_type: "perf_profile",
-     tags: ["adversarial-performance"]
-   })
-   ```
-4. **Dependency manifest** — `package.json` (dependency count, scripts),
-   `package-lock.json` (transitive depth)
-5. **Project profile** — auto-detect or use the explicit `PROJECT_PROFILE`
-   setting (see SKILL.md § Auto-Detection)
-
-### Measurement Methods
-
-If `RUN_COMMANDS` is `true`, execute these measurement commands. Otherwise,
-perform static analysis only and note measurements as "estimated" rather than
-"measured."
-
-| Category     | Command                                   | What It Measures                   |
-| ------------ | ----------------------------------------- | ---------------------------------- |
-| Build        | `npx tsc --noEmit --diagnostics`          | Compile time, file count, memory   |
-| Build        | `npm run build`                           | Bundle time, output size, warnings |
-| Bundle       | `du -sh dist/` (or PowerShell equivalent) | Total output size                  |
-| Dependencies | `npm ls --all --prod 2>$null`             | Dependency tree depth              |
-| Tests        | `npm test -- --reporter=verbose`          | Suite duration, slow tests         |
-
-### Profiling Structure
-
-Produce a Markdown document with these sections:
-
-```markdown
-# Performance Profile — [Repository Name]
-
-## Project Profile
-
-- **Type**: [auto-detected: mcp-server, web-app, cli-tool, library]
-- **Profiles**: [stacked: mcp-server + cli-tool + tested + containerized]
-- **Language/Runtime**: [e.g., TypeScript/Node.js 24]
-- **Build Tool**: [e.g., tsup, tsc, esbuild]
-- **Test Framework**: [e.g., Vitest, Playwright]
-- **Source Files**: [count]
-- **Dependencies**: [direct count / transitive count]
-
-## Baseline Measurements
-
-| Metric                  | Value                   | Method            |
-| ----------------------- | ----------------------- | ----------------- |
-| TypeScript compile time | Xs                      | tsc --diagnostics |
-| Bundle build time       | Xs                      | npm run build     |
-| Output size (dist/)     | X KB/MB                 | file system       |
-| Production dependencies | N direct / M transitive | npm ls            |
-| Test suite duration     | Xs                      | npm test          |
-| [etc.]                  |                         |                   |
-
-## Category Assessment (per Category)
-
-For each of the 7 audit categories (see audit-categories.md):
-
-- Current state and measurements
-- Existing optimizations in place
-- Initial efficiency rating: excellent / good / acceptable / poor
-
-## Hot Path Map
-
-Identify the performance-critical code paths:
-
-- Request handling pipeline (for servers)
-- Database query paths (for data-layer projects)
-- Build/compile pipeline
-- Test execution pipeline
-- Startup sequence
-
-## Optimization Opportunities (Preliminary)
-
-Initial hypotheses about where the biggest gains are. These are
-preliminary — Agent B will validate or refute them with stress scenarios.
-```
-
-### Journal
-
-```
-create_entry({
-  content: "<full profiling output>",
-  entry_type: "perf_profile",
-  tags: ["adversarial-performance", "profile"],
-  project_number: <project number>
-})
-```
-
----
-
-## Phase 2 — Stress Test Review (Agent B: Stress Tester)
-
-Switch mental models. You are now a performance skeptic whose job is to find
-every bottleneck the Profiler missed or underestimated. Don't trust the
-baselines — probe their limits.
-
-### Review Dimensions
-
-Score each dimension on a 1–5 scale. Dimensions have different weights
-reflecting their relative importance for performance:
-
-| Dimension           | Weight | Focus Areas                                                                                                    |
-| ------------------- | ------ | -------------------------------------------------------------------------------------------------------------- |
-| **Impact**          | 4      | User-facing latency, throughput degradation, memory pressure, token waste. How much does this actually matter? |
-| **Frequency**       | 3      | How often does this hot path execute? Every request? Once at startup? Rare edge case?                          |
-| **Effort**          | 2      | How hard is the fix? Quick config change vs. architectural refactor?                                           |
-| **Regression Risk** | 1      | Could the optimization break existing behavior or introduce bugs?                                              |
-
-### Severity Mapping
-
-| Weighted Score | Severity | Meaning                                                 |
-| -------------- | -------- | ------------------------------------------------------- |
-| 4.0–5.0        | Critical | High-frequency bottleneck with major user-facing impact |
-| 3.0–3.9        | High     | Significant performance cost, noticeable in production  |
-| 2.0–2.9        | Moderate | Measurable inefficiency but limited blast radius        |
-| 1.0–1.9        | Low      | Optimization opportunity, defense-in-depth improvement  |
-
-### Depth Profiles
-
-The `AUDIT_DEPTH` configuration controls scrutiny level:
-
-- **Scan**: Categories 1 (Build), 3 (Dependencies), 4 (Runtime) only. Quick
-  bottleneck triage.
-- **Standard**: All 7 categories at stated weights. Default.
-- **Intensive**: All 7 categories + extended analysis:
-  - Big-O complexity analysis on identified hot paths
-  - Memory allocation pattern review (object churn in loops)
-  - Cold start vs. warm execution divergence
-  - Event loop blocking analysis (sync I/O, heavy computation)
-  - Concurrency ceiling estimation (worker pools, connection pools)
-  - Comparison against prior audit baselines (regression detection)
-
-### Critique Output Format
-
-```markdown
-## Stress Test Review — [Repository Name]
-
-**Overall Performance Score:** [weighted average] / 5.0
-**Performance Grade:** [A–F]
-
-### Grading Scale
-
-| Grade | Score Range | Meaning                                                  |
-| ----- | ----------- | -------------------------------------------------------- |
-| A     | 4.5–5.0     | Excellent — well-optimized, minimal waste                |
-| B     | 3.5–4.4     | Good — no critical bottlenecks, room for tuning          |
-| C     | 2.5–3.4     | Acceptable — measurable inefficiencies, worth addressing |
-| D     | 1.5–2.4     | Poor — significant bottlenecks impacting UX or cost      |
-| F     | 1.0–1.4     | Failing — severe performance issues, unusable at scale   |
-
-### Findings
-
-| #   | Category     | Severity | Finding                   | File:Line         | Impact             | Optimization                   |
-| --- | ------------ | -------- | ------------------------- | ----------------- | ------------------ | ------------------------------ |
-| 1   | Runtime      | Critical | N+1 query in list handler | src/foo.ts:42     | +200ms per request | Batch query with single SELECT |
-| 2   | Build        | High     | Dev deps in prod bundle   | tsup.config.ts:8  | +2MB output        | Add external[] config          |
-| 3   | Dependencies | Moderate | Duplicate lodash versions | package-lock.json | +400KB install     | npm dedupe                     |
-| ... |              |          |                           |                   |                    |                                |
-
-### Dimension Scores
-
-| Dimension       | Score | Weight | Weighted             |
-| --------------- | ----- | ------ | -------------------- |
-| Impact          | [1–5] | 4      | [score × 4]          |
-| Frequency       | [1–5] | 3      | [score × 3]          |
-| Effort          | [1–5] | 2      | [score × 2]          |
-| Regression Risk | [1–5] | 1      | [score × 1]          |
-| **Total**       |       | **10** | **[sum]/50 = [avg]** |
-
-### Category Breakdown
-
-| Category             | Findings | Worst Severity | Rating        |
-| -------------------- | -------- | -------------- | ------------- |
-| 1. Build Performance | 1        | High           | ⚠️ Needs work |
-| 2. Bundle & Output   | 0        | —              | ✅ Good       |
-| 3. Dependency Weight | 2        | Moderate       | ⚠️ Needs work |
-| ...                  |          |                |               |
-
-### Stress Scenarios
-
-For each critical/high finding, describe the stress scenario that reveals it:
-
-#### Scenario: [Finding Title]
-
-- **Trigger condition**: [What causes worst-case behavior]
-- **Scale factor**: [How performance degrades as N grows]
-- **Measured/estimated impact**: [Quantified: +Xms, +XMB, +X tokens]
-- **Breaking point**: [At what scale does this become unacceptable]
-```
-
-### Journal
-
-```
-create_entry({
-  content: "<full stress test critique>",
-  entry_type: "perf_stress_test",
-  tags: ["adversarial-performance", "stress-test"],
-  project_number: <project number>
-})
-```
-
----
-
-## Phase 3 — Optimization Plan (Agent A: Profiler)
-
-Switch back to the Profiler role. Address every finding from the stress test
-review with an explicit disposition.
-
-### Disposition Table
-
-For each finding, record one of:
-
-| Disposition | Meaning                                                                                                   |
-| ----------- | --------------------------------------------------------------------------------------------------------- |
-| **Accept**  | Implement the suggested optimization                                                                      |
-| **Reject**  | Explain why the finding doesn't warrant optimization (acceptable cost, premature optimization, trade-off) |
-| **Modify**  | Accept the finding but implement a different optimization                                                 |
-| **Defer**   | Acknowledge the inefficiency but defer to a future milestone                                              |
-
-### Optimization Plan Output
-
-Produce the plan prioritized by impact × frequency (highest ROI first):
-
-```markdown
-## Optimization Plan — [Repository Name]
-
-### Disposition Summary
-
-| #   | Finding            | Severity | Disposition | Rationale                               |
-| --- | ------------------ | -------- | ----------- | --------------------------------------- |
-| 1   | N+1 query          | Critical | Accept      | Will batch into single SELECT           |
-| 2   | Dev deps in bundle | High     | Modify      | Using externals instead of tree-shaking |
-| 3   | Duplicate lodash   | Moderate | Defer       | Awaiting lodash-es migration in Q3      |
-
-### Quick Wins (< 1 hour, high impact)
-
-| #   | Finding | Optimization | Expected Improvement       |
-| --- | ------- | ------------ | -------------------------- |
-| ... | ...     | ...          | -Xms latency / -XMB bundle |
-
-### Targeted Improvements (1–4 hours)
-
-| #   | Finding | Optimization | Files Affected | Expected Improvement |
-| --- | ------- | ------------ | -------------- | -------------------- |
-| ... | ...     | ...          | ...            | ...                  |
-
-### Architectural Changes (requires design work)
-
-| #   | Finding | Approach | Effort | Expected Improvement |
-| --- | ------- | -------- | ------ | -------------------- |
-| ... | ...     | ...      | ...    | ...                  |
-
-### Accepted Trade-offs
-
-Findings explicitly rejected or deferred with justification:
-
-| #   | Finding | Disposition | Justification |
-| --- | ------- | ----------- | ------------- |
-| ... | ...     | ...         | ...           |
-
-### Projected Improvement
-
-| Metric                | Before | After (projected) | Improvement |
-| --------------------- | ------ | ----------------- | ----------- |
-| Build time            | Xs     | Xs                | -X%         |
-| Bundle size           | XMB    | XMB               | -X%         |
-| Request latency (p95) | Xms    | Xms               | -X%         |
-| Test suite duration   | Xs     | Xs                | -X%         |
-
-**Score**: Before [X]/5.0 (Grade [Y]) → After (projected) [X]/5.0 (Grade [Y])
-```
-
-### Iteration Control
-
-After optimization planning, check: has `MAX_AUDIT_PASSES` been reached?
-
-- **No** → return to Phase 2 for another stress test of the optimization
-  plan (do the fixes introduce new bottlenecks? Are there second-order
-  performance effects?)
-- **Yes** → proceed to Phase 4
-
-### Journal
-
-```
-create_entry({
-  content: "<optimization plan with dispositions>",
-  entry_type: "perf_optimization",
-  tags: ["adversarial-performance", "optimization"],
-  project_number: <project number>
-})
-```
-
----
-
-## Phase 4 — Copilot Validation (External)
-
-If `COPILOT_VALIDATION` is enabled and the Copilot CLI is available, invoke
-it for an independent review.
-
-See [copilot-performance-prompts.md](copilot-performance-prompts.md) for
-prompt templates.
-
-After the Copilot pass, any new findings follow the same disposition process
-from Phase 3. The final audit report is then presented to the user.
-
-If Copilot CLI is not available, skip this phase gracefully:
-
-```markdown
-> **Phase 4 skipped**: Copilot CLI not available. The audit completed with
-> internal adversarial review only (Phases 1–3).
-```
-
-### Journal
-
-```
-create_entry({
-  content: "<copilot findings + final dispositions>",
-  entry_type: "perf_copilot",
-  tags: ["adversarial-performance", "copilot"],
-  project_number: <project number>
-})
-```
-
----
-
-## Final Report Assembly
-
-After all phases complete, produce a consolidated report artifact:
-
-```markdown
-# Adversarial Performance Audit — [Repository Name]
-
-**Date**: [ISO date]
-**Audit Depth**: [scan | standard | intensive]
-**Project Profile**: [auto-detected profiles]
-**Passes Completed**: [N]
-**Copilot Validation**: [yes | skipped]
-**Commands Executed**: [yes | static analysis only]
-
-## Executive Summary
-
-[2–3 sentence summary: overall performance posture, critical bottleneck
-count, and top recommended optimization]
-
-**Performance Score**: [X] / 5.0 — Grade [A–F]
-
-## Baseline Measurements
-
-[Key metrics from Phase 1]
-
-## Findings Summary
-
-| Category             | Critical | High | Moderate | Low | Total |
-| -------------------- | -------- | ---- | -------- | --- | ----- |
-| 1. Build Performance | ...      |      |          |     |       |
-| ...                  |          |      |          |     |       |
-| **Total**            |          |      |          |     |       |
-
-## Top 3 Highest-Impact Optimizations
-
-1. [Most impactful finding + optimization + expected improvement]
-2. [Second most impactful]
-3. [Third most impactful]
-
-## Full Findings (by impact)
-
-[All findings from Phase 2, grouped by severity descending]
-
-## Optimization Plan
-
-[From Phase 3 — disposition table + quick wins + targeted + architectural]
-
-## Projected Improvement
-
-[Before/after metrics table]
-
-## Appendix: Profiling Data
-
-[Condensed Phase 1 output — measurements, hot path map]
-```

package/skills/adversarial-planner/SKILL.md

@@ -1,89 +0,0 @@
----
-name: adversarial-planner
-description: |
-  Multi-pass adversarial planning and review skill that improves agent-generated
-  plans through structured critique stages. Combines an initial planning agent
-  (structure, logic, task sequencing) with an adversarial review agent
-  (performance, security, maintainability) and a final Copilot extension validation
-  pass. Use when creating implementation plans, designing architecture, planning
-  roadmaps or milestones, or when the user says "plan this", "review my plan",
-  "adversarial review", or "multi-pass plan".
----
-
-# Adversarial Planner
-
-A multi-pass planning and review system that produces high-quality plans by
-introducing structured adversarial critique stages. Plans pass through an
-iterative pipeline of drafting, review, refinement, and optional external
-validation — producing output optimized for correctness, performance, security,
-and maintainability.
-
-## When to Load
-
-Load this skill when any of these apply:
-
-- Creating an implementation plan for a new feature or architectural change
-- Designing multi-file refactors or system migrations
-- Planning project roadmaps, milestones, or sprint scopes
-- The user asks for an adversarial or multi-pass review of a plan
-- The user says "plan this", "review my plan", "critique this plan",
-  "multi-pass plan", "architect this", "design this system", or "how should I build"
-- You want to reduce confirmation bias in your own planning output
-
-## Adversarial Protocol
-
-This skill follows the standard dual-agent adversarial pattern (Agent A: The Planner, Agent B: The Adversarial Reviewer).
-For the core pipeline rules, phase definitions, and agent switching protocols, read:
-**[../adversarial-security/references/adversarial-base-protocol.md](../adversarial-security/references/adversarial-base-protocol.md)**
-
-For the planner-specific protocol with review dimensions, scoring weights, and output templates, read:
-**[references/multi-pass-protocol.md](references/multi-pass-protocol.md)**
-
-## External Validation (Phase 4)
-
-Phase 4 triggers an independent validation pass using the GitHub CLI (`gh copilot`).
-The `copilot` subcommand is built into modern `gh` CLI — no separate extension is
-needed. This provides a fundamentally different model's perspective on the plan,
-reducing confirmation bias that persists even after adversarial self-review.
-
-For Copilot-specific prompt templates and integration details, read
-[references/copilot-integration.md](references/copilot-integration.md).
-
-**Prerequisites:** `gh` CLI v2.x+ with `gh auth status` passing. If `gh copilot`
-is not available, skip Phase 4 gracefully and note the skip in the journal entry.
-
-Read [references/copilot-usage.md](references/copilot-usage.md) for critical non-interactive execution requirements.
-
-## Feedback Loop & Documentation
-
-Every phase creates a journal entry with structured tags and entry types. This
-builds a searchable audit trail that informs future planning sessions.
-
-For journal templates, tag conventions, cross-session learning patterns, and
-retrospective templates, read
-[references/feedback-loop.md](references/feedback-loop.md).
-
-## Configuration
-
-| Variable             | Default    | Description                                           |
-| -------------------- | ---------- | ----------------------------------------------------- |
-| `MAX_PLAN_PASSES`    | `2`        | Maximum refinement cycles (phases 2–3 repeat)         |
-| `PLAN_REVIEW_DEPTH`  | `standard` | Review depth: `light`, `standard`, or `deep`          |
-| `COPILOT_VALIDATION` | `true`     | Enable/disable the Copilot extension validation phase |
-
-### Review Depth Profiles
-
-- **Light**: Focus on correctness and security only. Best for small, low-risk
-  changes.
-- **Standard**: Full 5-dimension review. Default for most planning tasks.
-- **Deep**: Extended review with additional focus on long-term maintainability,
-  API surface design, and migration safety. Use for architectural decisions.
-
-## Synergies
-
-| Skill/Workflow                   | Relationship                                                                                                                                          |
-| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `autonomous-dev`                 | The Generator/Evaluator pipeline in `autonomous-dev` applies at the code level; this skill applies the same adversarial pattern at the planning level |
-| GitHub CLI (`gh copilot`)        | Built-in `copilot` subcommand used for Phase 4 external validation                                                                                    |
-| `github-commander/copilot-audit` | Full repo/PR audit; this skill uses Copilot for plan-specific review instead                                                                          |
-| `skill-builder`                  | Use to refine this skill's instructions based on observed agent behavior                                                                              |

package/skills/adversarial-planner/references/copilot-integration.md

@@ -1,83 +0,0 @@
-# Copilot Integration
-
-Reference for Phase 4 of the adversarial planning protocol — the independent
-external validation pass using the GitHub CLI (`gh copilot`).
-
-## Why Copilot?
-
-After self-adversarial review (Phases 2–3), confirmation bias can still persist
-because the same model produced both the plan and the critique. The Copilot CLI
-invokes a fundamentally different model with a separate context window, catching
-blind spots that internal review misses.
-
-## Prerequisites
-
-1. **GitHub CLI installed**: `gh --version` (v2.x+)
-2. **Authenticated**: `gh auth status` passing
-3. **Copilot available**: `gh copilot --version` — the `copilot` subcommand is built into modern `gh` CLI (no separate extension needed)
-
-If Copilot CLI is not available, skip Phase 4 gracefully and note the skip in
-the journal entry.
-
-## Plan-Specific Prompt Templates
-
-> **⚠️ CRITICAL — Non-Interactive Mode**: The `gh copilot` CLI must be run in
-> non-interactive mode using the `-p` (or `--prompt`) flag. Interactive mode
-> will hang indefinitely in an automated agent context. Use:
->
-> ```
-> gh copilot -p "<prompt>" --allow-tool "shell(find,cat,head,grep)"
-> ```
->
-> The `--allow-tool` flag grants Copilot read access to the repository files.
-
-- Expect 60–120 seconds per prompt. In environments with hard synchronous timeouts (like Antigravity's 10s `WaitMsBeforeAsync` limit), allow the command to naturally fall into the background. Use the `schedule` tool or wait for the system notification to retrieve the results. Do not skip execution due to timeout constraints.
-
-### Architecture Review
-
-"You are a senior systems architect. Review this implementation plan for a software project. Focus on:
-
-1. Architectural soundness — are the proposed abstractions appropriate?
-2. Security gaps — are there missing auth checks, injection vectors, or data boundary issues?
-3. Performance risks — will this scale? Are there N+1 queries or hot-path allocations?
-4. Missing considerations — what did the planner forget?
-5. Task ordering — are dependencies correctly sequenced?"
-
-### Roadmap/Milestone Review
-
-"You are a technical program manager reviewing a project roadmap. Evaluate:
-
-1. Scope creep — are the milestones focused and achievable?
-2. Risk distribution — are high-risk items front-loaded for early feedback?
-3. Dependency chains — are there single points of failure in the timeline?
-4. Resource assumptions — are the estimates realistic?
-5. Missing milestones — what validation checkpoints are missing?"
-
-### Targeted Security Review
-
-"You are a security engineer. This implementation plan proposes changes to a system. Review it exclusively for security implications:
-
-1. New attack surfaces introduced
-2. Auth/authz gaps
-3. Data validation boundaries
-4. Secret management
-5. Supply chain risks from new dependencies"
-
-## Parsing Copilot Output
-
-Copilot returns unstructured Markdown. To integrate findings into the protocol:
-
-1. **Extract findings** — parse the Markdown for tables or numbered lists
-2. **Map to dimensions** — classify each finding against the 5 review dimensions
-   (Correctness, Security, Performance, Maintainability, Completeness)
-3. **Deduplicate** — compare against Phase 2 findings; skip items already
-   addressed in the refinement
-4. **Disposition** — apply the same Accept/Reject/Modify framework from Phase 3
-
-## Cross-References
-
-- **GitHub CLI (`gh copilot`)** — built-in subcommand for non-interactive
-  reviews; no separate extension or npm package required
-- **`github-commander/workflows/copilot-audit.md`** — Full repo and PR-level
-  audits; use that workflow for post-implementation validation rather than
-  plan review

package/skills/adversarial-planner/references/copilot-usage.md

@@ -1,16 +0,0 @@
-# GitHub Copilot External Validation
-
-> **⚠️ CRITICAL — Non-Interactive Mode**: The `gh copilot` CLI must be run in
-> non-interactive mode using the `-p` (or `--prompt`) flag. Interactive mode
-> will hang indefinitely in an automated agent context. Use:
->
-> ```
-> gh copilot -p "Considering these standards from Phase 0 research: [insert findings]. <prompt>" --allow-tool "shell(find,cat,head,grep)"
-> ```
->
-> The `--allow-tool` flag grants Copilot read access to the repository files.
-> Always `Set-Location` (or `cd`) to the target repository before invoking.
->
-> **⚠️ TIMEOUT GUIDANCE**: Expect 60–120 seconds per prompt. In environments with hard synchronous timeouts, use the `-s` flag or allow the command to naturally fall into the background.
-
-> **⚠️ CRITICAL — No Fabrication**: You MUST actually execute `gh copilot` commands. Do NOT fabricate or predict what Copilot would say.