memory-journal-mcp 7.7.0 → 8.0.0

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

@@ -1,7 +1,7 @@
 # Copilot Integration
 
 Reference for Phase 4 of the adversarial planning protocol — the independent
-external validation pass using the GitHub Copilot CLI.
+external validation pass using the GitHub CLI (`gh copilot`).
 
 ## Why Copilot?
 
@@ -12,71 +12,56 @@ blind spots that internal review misses.
 
 ## Prerequisites
 
-1. **Copilot CLI installed**: `npm list -g @github/copilot`
-2. **Authenticated**: `copilot auth` (requires browser approval)
-3. **Skill dependency**: The `github-copilot-cli` skill documents setup details
+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
 
-These prompts differ from the full codebase/PR audit prompts in
-`github-commander/workflows/copilot-audit.md` — they focus on architectural
-decisions rather than code diffs.
+> **⚠️ 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
 
-```bash
-echo "You are a senior systems architect. Review this implementation plan for a software project. Focus on:
+"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?
-
-Here is the plan:
-
-$(cat plan.md)
-
-Output a Markdown table of findings with columns: #, Category, Severity (Critical/Moderate/Low), Finding, Suggestion." | copilot
-```
+5. Task ordering — are dependencies correctly sequenced?"
 
 ### Roadmap/Milestone Review
 
-```bash
-echo "You are a technical program manager reviewing a project roadmap. Evaluate:
+"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?
-
-Here is the roadmap:
-
-$(cat roadmap.md)
-
-Output a structured assessment with recommendations." | copilot
-```
+5. Missing milestones — what validation checkpoints are missing?"
 
 ### Targeted Security Review
 
-For plans that touch authentication, data access, or external integrations:
+"You are a security engineer. This implementation plan proposes changes to a system. Review it exclusively for security implications:
 
-```bash
-echo "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
-
-Plan:
-
-$(cat plan.md)
-
-List each finding with severity and a concrete mitigation." | copilot
-```
+5. Supply chain risks from new dependencies"
 
 ## Parsing Copilot Output
 
@@ -91,8 +76,8 @@ Copilot returns unstructured Markdown. To integrate findings into the protocol:
 
 ## Cross-References
 
-- **`github-copilot-cli` skill** — CLI installation, authentication, and
-  non-interactive piping patterns
+- **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

@@ -0,0 +1,16 @@
+# 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.

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

@@ -50,6 +50,10 @@ Group by component. For each file:
 Numbered sequence with dependencies noted.
 Which tasks can be parallelized.
 
+## Copilot Security & Performance Scan
+
+Run a non-interactive `gh copilot` scan (`gh copilot -p "..." --allow-tool "shell(find,cat,head,grep)"`) focusing specifically on performance and security risks for the proposed changes, and embed the raw or summarized findings here.
+
 ## Risk Assessment
 
 | Risk | Likelihood | Impact | Mitigation |

package/skills/adversarial-security/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: adversarial-security
+description: |
+  Multi-pass adversarial security audit for entire repositories. Combines
+  structured threat modeling (Agent A) with adversarial attack surface
+  analysis (Agent B) through iterative passes. Merges the security-audit
+  workflow's 10-category checklist with the adversarial-planner's
+  structured critique methodology. Use when running security audits,
+  threat modeling, or when the user says "security audit", "adversarial
+  security", "threat model this repo", "red team this repo", or "find vulnerabilities". NOT for fixing or remediating known security issues (use autonomous-dev instead). NOT for supply chain dependency scanning. NOT for general workflow audits or code quality. If user says 'fix security issues', ask whether they want to audit first or fix known issues.
+---
+
+# Adversarial Security
+
+A multi-pass security auditing system that produces high-confidence
+vulnerability assessments by introducing structured adversarial critique
+stages. Audits pass through an iterative pipeline of reconnaissance,
+red-team attack, remediation planning, and optional external validation —
+producing output optimized for exploitability, impact, and actionable
+remediation.
+
+## When to Load
+
+Load this skill when any of these apply:
+
+- Running a security audit against an entire repository
+- Performing threat modeling for a new or existing codebase
+- The user asks for an adversarial security review or red-team analysis
+- The user says "security audit", "threat model", "find vulnerabilities",
+  "adversarial security", or "red team this repo"
+- Preparing a security posture report for a release or compliance review
+- You want to reduce blind spots in your own security assessment
+
+## Auto-Detection
+
+Before starting, auto-detect the project type by scanning the repository:
+
+| Signal                                                                                         | Project Type | Extra Categories                                 |
+| ---------------------------------------------------------------------------------------------- | ------------ | ------------------------------------------------ |
+| MCP SDK imports (`@modelcontextprotocol/sdk`), `tools/list` handler, tool `description` fields | `mcp-server` | MCP-Specific Security (Category 10) — full depth |
+| Express/Hono/Fastify imports, HTTP route handlers, `listen()` calls                            | `web-app`    | Transport & Network (Category 5) — full depth    |
+| `bin` field in `package.json`, CLI arg parsing (`yargs`, `commander`, `meow`)                  | `cli-tool`   | Input Validation (Category 3) — extra CLI focus  |
+| No server/CLI signals, only exports                                                            | `library`    | Supply Chain (Category 9) — extra consumer focus |
+
+The MCP-Specific Security category (Category 10) is **always evaluated with
+graceful degradation**. If the target is not an MCP server, findings in this
+category are reported as informational rather than skipped entirely. The
+rationale: even non-MCP projects may expose tool-like interfaces, schema
+descriptions, or configuration metadata that could be poisoned.
+
+When signals overlap (e.g., an MCP server that is also a CLI tool), combine
+the extra categories from all matching types.
+
+## Adversarial Protocol
+
+This skill follows the standard dual-agent adversarial pattern (Agent A: The Threat Modeler, Agent B: The Red Team).
+For the core pipeline rules, phase definitions, and agent switching protocols, read:
+**[references/adversarial-base-protocol.md](references/adversarial-base-protocol.md)**
+
+For the security-specific protocol with review dimensions, scoring weights, and output templates, read:
+**[references/multi-pass-security-protocol.md](references/multi-pass-security-protocol.md)**
+
+## Audit Categories
+
+The 10 security categories audited during Phase 1 (Reconnaissance) and
+challenged during Phase 2 (Red Team) are:
+
+1. Dependency Vulnerabilities
+2. Secret & Credential Exposure
+3. Input Validation & Injection
+4. Authentication & Authorization
+5. Transport & Network Security
+6. Docker Security
+7. CI/CD Pipeline Security
+8. Error Handling & Information Disclosure
+9. Supply Chain
+10. MCP-Specific Security (graceful degradation for non-MCP targets)
+
+For the full checklist with CWE IDs, vulnerable patterns, and secure
+patterns, read
+[references/audit-categories.md](references/audit-categories.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 audit,
+reducing confirmation bias that persists even after adversarial self-review.
+
+For prompt templates and integration details, read
+[references/copilot-security-prompts.md](references/copilot-security-prompts.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 security reviews.
+
+For journal templates, tag conventions, cross-session learning patterns, and
+retrospective templates, read
+[references/feedback-loop.md](references/feedback-loop.md).
+
+### Journal Opt-Out
+
+See [references/journal-opt-out.md](references/journal-opt-out.md) for instructions on how to handle explicit opt-outs from journaling.
+
+### Consolidated Report
+
+The final deliverable is a **single consolidated artifact** merging all four
+phases into one document, following the template in
+[references/multi-pass-security-protocol.md § Final Report Assembly](references/multi-pass-security-protocol.md).
+Do NOT produce separate artifacts per phase — the user should receive one
+comprehensive document with all findings, remediations, and external
+validation results. Before sharing output outside the audit context, redact or generalize specific exploit details and avoid including live credentials or internal hostnames.
+
+## Configuration
+
+| Variable             | Default    | Description                                                             |
+| -------------------- | ---------- | ----------------------------------------------------------------------- |
+| `MAX_AUDIT_PASSES`   | `2`        | Maximum red-team cycles (phases 2–3 repeat)                             |
+| `AUDIT_DEPTH`        | `standard` | Depth: `recon`, `standard`, or `paranoid`                               |
+| `COPILOT_VALIDATION` | `true`     | Enable/disable the external validation phase (Phase 4, `gh copilot`)    |
+| `PROJECT_TYPE`       | `auto`     | Auto-detect or explicit: `mcp-server`, `web-app`, `cli-tool`, `library` |
+
+### Audit Depth Profiles
+
+- **Recon**: Scan for critical and high-severity issues only (Categories 2,
+  3, 4). Best for quick triage or low-risk utility repos.
+- **Standard**: Full 10-category audit with all review dimensions. Default
+  for most repositories.
+- **Paranoid**: Extended audit with additional focus on:
+  - Supply chain deep dive (lockfile integrity, install scripts, typosquatting)
+  - Cross-project impact (shared dependencies, ecosystem blast radius)
+  - Advanced attack vectors (prototype pollution chains, ReDoS, timing attacks)
+  - Historical git analysis (secrets that were committed then removed)
+
+## Synergies
+
+| Skill/Workflow             | Relationship                                                                        |
+| -------------------------- | ----------------------------------------------------------------------------------- |
+| `adversarial-planner`      | Applies adversarial pattern to plans; this skill applies it to security posture     |
+| `autonomous-dev`           | Generator/Evaluator pipeline at code level; use after this skill to implement fixes |
+| GitHub CLI (`gh`)          | Built-in `copilot` subcommand used for Phase 4 external validation                  |
+| `/security-audit` workflow | Provides the category checklist; this skill adds adversarial methodology on top     |
+| `skill-builder`            | Use to refine this skill's instructions based on observed agent behavior            |

package/skills/adversarial-security/references/adversarial-base-protocol.md

@@ -0,0 +1,44 @@
+# Adversarial Base Protocol
+
+This document defines the shared structural boilerplate for all adversarial skills in the ecosystem (`adversarial-security`, `adversarial-performance`, `adversarial-planner`, `adversarial-skill-audit`, `adversarial-workflow-audit`).
+
+## Core Architecture: Dual Agent Roles
+
+Adversarial skills operate with two distinct mental models. You are both agents — you must strictly switch perspectives at phase boundaries to counteract confirmation bias.
+
+### Agent A — The Baseline / Recon Agent
+
+**Mandate:** Establish ground truth, map the surface area, and catalog existing properties.
+
+- Think like a defender, planner, or auditor documenting what _is_ or what _should be_.
+- Focus on completeness, accuracy, and baseline measurement.
+- You are NOT looking for flaws in this phase.
+
+### Agent B — The Adversary / Critique Agent
+
+**Mandate:** Break, stress, or invalidate everything Agent A documented.
+
+- Switch to a pessimistic, attacker, or stress-tester mindset.
+- Assume Agent A missed something or that the documented properties are brittle.
+- Find bypasses, edge cases, performance bottlenecks, or logical flaws.
+- Provide concrete proof (e.g., attack vectors, quantitative impacts) — no vague concerns.
+
+## The Multi-Pass Protocol Pipeline
+
+All adversarial audits follow this iterative pipeline. Each phase must produce a structured journal entry.
+
+| Phase                     | Agent Role | Action                                                                                                           |
+| ------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------------- |
+| **0. Research**           | Agent A    | Use `search_web` or `grep_search` to find latest standards, benchmarks, or ecosystem guidelines before starting. |
+| **1. Recon/Profile**      | Agent A    | Measure and document the baseline state. Output: Map or Profile artifact.                                        |
+| **2. Adversarial Review** | Agent B    | Challenge the baseline. Output: Findings table with severity/impact ratings.                                     |
+| **3. Remediation**        | Agent A    | Develop a prioritized plan to fix the findings. Output: Remediation Plan.                                        |
+| **4. Copilot Validation** | External   | Trigger an independent validation pass using `gh copilot` to reduce self-review bias. Output: Copilot Findings.  |
+
+## Journaling & Artifacts
+
+- **Phase Isolation**: Do NOT skip phases or merge them. Produce the required journal entry for each phase.
+- **Consolidated Report**: At the end of Phase 4, merge all findings, remediations, and external validation results into a single consolidated artifact for the user. Do not produce scattered phase artifacts outside of the journal.
+- **Journal Opt-Out**: If the user explicitly opts out of journaling, proceed with the phases in memory and output the final consolidated report.
+
+_Refer back to the specific `SKILL.md` for the exact definitions of Agent A/B for the given domain and the specific categories to audit._