memory-journal-mcp 7.7.0 → 8.0.0

package/skills/adversarial-security/references/copilot-security-prompts.md

@@ -0,0 +1,142 @@
+# GitHub CLI Security Prompts
+
+Reference for Phase 4 of the adversarial security protocol — the independent
+external validation pass using the GitHub CLI.
+
+## Why External Validation?
+
+After self-adversarial review (Phases 2–3), confirmation bias can still
+persist because the same model produced both the reconnaissance and the red
+team critique. The GitHub CLI invokes a fundamentally different model with a
+separate context window, catching blind spots that internal review misses.
+
+For security audits specifically, this matters because:
+
+- The Threat Modeler may have over-documented defenses that look stronger
+  than they are, and the Red Team (same model) may not have fully challenged
+  those assumptions
+- An independent model brings a fresh perspective without the context of
+  prior phases, which can surface entirely new attack vectors
+- Independent review is a standard practice in professional security auditing
+
+## Prerequisites
+
+1. **GitHub CLI installed**: `gh --version` (v2.x+)
+2. **Authenticated**: `gh auth status`
+3. **Copilot access**: `gh copilot --version` — the `copilot` subcommand is
+   built into modern `gh` CLI (no separate extension needed)
+
+If `gh copilot` is not available, skip Phase 4 gracefully and note the skip
+in the journal entry. The audit is still valid with Phases 1–3 alone.
+
+## Execution Mode
+
+> **⚠️ NON-INTERACTIVE ONLY**: `gh copilot` must be run with the `-p`
+> (or `--prompt`) flag for non-interactive execution. The legacy
+> `gh copilot explain` syntax is interactive and will hang in agent contexts.
+
+**Correct invocation pattern:**
+
+```
+Set-Location <target-repo>
+gh copilot -p "<prompt text>" --allow-tool "shell(find,cat,head,grep)"
+```
+
+**Key flags:**
+
+- `-p` / `--prompt`: Non-interactive mode (REQUIRED for agents)
+- `--allow-tool "shell(find,cat,head,grep)"`: Grants Copilot read-only
+  shell access to browse the repository. Without this, Copilot cannot
+  inspect source files and findings will be shallow.
+
+**Operational notes:**
+
+- Always `Set-Location` (or `cd`) to the target repository BEFORE invoking.
+  Copilot uses the cwd as its workspace root.
+- Each prompt invocation runs independently — there is no conversation state
+  between calls.
+- 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.
+- Long prompts work fine — the CLI accepts multi-line strings in quotes.
+
+> **⚠️ NO FABRICATION**: You MUST actually execute `gh copilot` and include
+> its real output verbatim. Do NOT fabricate, summarize from memory, or
+> predict what Copilot would say. If the command fails, document the failure
+> instead of producing synthetic output. The entire value of Phase 4 depends
+> on genuine independent analysis.
+
+## Prompt Templates
+
+These prompts are tailored for repository-wide security auditing. They
+differ from the adversarial-planner's plan-specific prompts in that they
+focus on concrete code patterns rather than architectural decisions.
+
+### Full Repository Security Audit
+
+**General Security Review:**
+"You are a senior security engineer performing a code audit. Review this repository for security vulnerabilities. Focus on:
+
+1. **Injection vectors** — SQL injection, command injection, path traversal, prototype pollution.
+2. **Authentication & authorization gaps**
+3. **Secret exposure**
+4. **Sandbox escapes**
+5. **Dependency risks**"
+
+**MCP-Specific Security Review:**
+"You are a security researcher specializing in AI agent tool ecosystems. Review this MCP server for security risks:
+
+1. **Tool poisoning** — Do any tool `description` fields contain hidden instructions?
+2. **Annotation accuracy** — Do annotations accurately reflect tool behavior?
+3. **Credential echo** — Do any tool responses include sensitive data?
+4. **Scope enforcement** — Are permission scopes consistently checked?
+5. **Input validation** — Are all tool input schemas properly validated?"
+
+**Supply Chain & Dependency Review:**
+"You are a supply chain security analyst. Review this project's dependency configuration for risks:
+
+1. **Lock file integrity**
+2. **Typosquatting**
+3. **Install scripts**
+4. **Deprecated packages**
+5. **Excessive permissions**
+6. **Transitive vulnerabilities**"
+
+**CI/CD Pipeline Security Review:**
+"You are a DevSecOps engineer. Review these GitHub Actions workflow files for security issues:
+
+1. **Action pinning**
+2. **Secret handling**
+3. **Permissions**
+4. **Security gates**
+5. **Artifact exposure**
+6. **Supply chain**"
+
+## Parsing Output
+
+The external review returns unstructured Markdown. To integrate findings into
+the protocol:
+
+1. **Extract findings** — parse the Markdown for tables or numbered lists
+2. **Map to categories** — classify each finding against the 10 audit
+   categories (Dependencies, Secrets, Injection, Auth, Transport, Docker,
+   CI/CD, Information Disclosure, Supply Chain, MCP-Specific)
+3. **Assign CWE IDs** — if the review didn't provide CWEs, assign the most
+   relevant ID from the audit-categories reference
+4. **Deduplicate** — compare against Phase 2 findings; skip items already
+   addressed in the remediation plan
+5. **Disposition** — apply the same Accept/Reject/Modify/Defer framework
+   from Phase 3 for any new findings
+
+## Prompt Selection Guide
+
+| Audit Depth | Project Type | Prompts to Use                         |
+| ----------- | ------------ | -------------------------------------- |
+| Recon       | Any          | Full Repository only                   |
+| Standard    | Non-MCP      | Full Repository + CI/CD                |
+| Standard    | MCP Server   | Full Repository + MCP-Specific + CI/CD |
+| Paranoid    | Any          | All 4 prompts                          |
+
+## Cross-References
+
+- **`adversarial-planner/references/copilot-integration.md`** — Plan-specific
+  review prompts (architecture, roadmap); use this skill for code-level
+  security review instead

package/skills/adversarial-security/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-security/references/feedback-loop.md

@@ -0,0 +1,206 @@
+# Feedback Loop & Documentation
+
+Reference for journaling, cross-session learning, and retrospective patterns
+used throughout the adversarial security protocol.
+
+## Journal Entry Templates
+
+Each phase of the protocol creates a journal entry using `create_entry`. The
+structured entry types and tags enable precise retrieval in future sessions.
+
+### Phase 1 — Reconnaissance
+
+```
+create_entry({
+  content: "# Security Reconnaissance: [Repository Name]\n\n[full recon content]",
+  entry_type: "security_recon",
+  tags: ["adversarial-security", "recon"],
+  project_number: <project number>
+})
+```
+
+### Phase 2 — Red Team Review
+
+```
+create_entry({
+  content: "# Red Team Review: [Repository Name]\n\nOverall Score: X/5.0 — Grade Y\n\n[findings table and scores]",
+  entry_type: "security_redteam",
+  tags: ["adversarial-security", "redteam"],
+  project_number: <project number>
+})
+```
+
+### Phase 3 — Remediation Plan
+
+```
+create_entry({
+  content: "# Remediation Plan: [Repository Name]\n\n[disposition table + quick wins + architectural changes]",
+  entry_type: "security_remediation",
+  tags: ["adversarial-security", "remediation"],
+  project_number: <project number>
+})
+```
+
+### Phase 4 — External Validation
+
+```
+create_entry({
+  content: "# External Security Validation: [Repository Name]\n\n[external review findings + final dispositions]",
+  entry_type: "copilot_validation",
+  tags: ["adversarial-security", "external-validation"],
+  project_number: <project number>
+})
+```
+
+### Final Report
+
+The consolidated final report is written as a user-facing artifact, not a
+journal entry. However, a summary entry should be created to enable future
+retrieval:
+
+```
+create_entry({
+  content: "# Security Audit Complete: [Repository Name]\n\nScore: X/5.0 (Grade Y)\nCritical: N, High: N, Medium: N, Low: N\n\n## Key Findings\n- [top 3 findings summary]\n\n## Remediations Applied\n- [accepted remediations]\n\n## Accepted Risks\n- [deferred items with justification]",
+  entry_type: "security_audit_complete",
+  tags: ["adversarial-security", "audit-complete", "session-summary"],
+  project_number: <project number>
+})
+```
+
+## Linking Entries
+
+Connect audit entries to each other and to related work using relationships:
+
+```
+link_entries({
+  from_entry_id: <redteam_entry_id>,
+  to_entry_id: <recon_entry_id>,
+  relationship_type: "references",
+  description: "Red team review of reconnaissance findings"
+})
+
+link_entries({
+  from_entry_id: <remediation_entry_id>,
+  to_entry_id: <redteam_entry_id>,
+  relationship_type: "evolves_from",
+  description: "Remediation plan based on red team findings"
+})
+
+link_entries({
+  from_entry_id: <implementation_entry_id>,
+  to_entry_id: <remediation_entry_id>,
+  relationship_type: "implements",
+  description: "Security fix implementing remediation plan"
+})
+
+link_entries({
+  from_entry_id: <audit_entry_id>,
+  to_entry_id: <prior_audit_entry_id>,
+  relationship_type: "evolves_from",
+  description: "Follow-up audit after prior remediation cycle"
+})
+```
+
+## Cross-Session Learning
+
+Before starting a new audit, search for prior security work to track
+progress and avoid re-discovering known issues.
+
+### Find Prior Audits for the Same Repository
+
+```
+search_entries({
+  query: "<repository name>",
+  entry_type: "security_recon",
+  tags: ["adversarial-security"]
+})
+```
+
+### Find Recurring Vulnerability Patterns
+
+If the same vulnerability type appears across multiple audits, it signals a
+systemic pattern worth addressing at the architecture level:
+
+```
+search_entries({
+  query: "<vulnerability type, e.g., 'missing auth check'>",
+  entry_type: "security_redteam",
+  tags: ["adversarial-security", "redteam"]
+})
+```
+
+### Find Cross-Project Security Patterns
+
+Use cross-project insights to identify shared vulnerabilities across the
+ecosystem:
+
+```
+get_cross_project_insights({
+  query: "security vulnerability",
+  tags: ["adversarial-security"]
+})
+```
+
+### Find Audits for a Specific Issue
+
+```
+search_entries({
+  query: "security",
+  issue_number: <issue_number>,
+  tags: ["adversarial-security"]
+})
+```
+
+### Track Remediation Progress
+
+Compare the current audit's findings against prior accepted risks and
+deferred items:
+
+```
+search_entries({
+  query: "<repository name> accepted risk",
+  entry_type: "security_remediation",
+  tags: ["adversarial-security", "remediation"]
+})
+```
+
+## Session Retrospective
+
+After completing a full audit cycle (all 4 phases), create a retrospective
+entry summarizing key insights. This is the primary mechanism for building
+institutional security knowledge.
+
+### Retrospective Template
+
+```
+create_entry({
+  content: "# Security Audit Retrospective: [Repository Name]\n\n## Key Insights\n- [What the Threat Modeler missed that the Red Team caught]\n- [What external validation caught that internal review missed]\n- [Vulnerability patterns worth institutionalizing as CI checks]\n- [Defenses that proved effective under adversarial review]\n\n## Metrics\n- Initial security score: X/5.0 (Grade Y)\n- Final security score: X/5.0 (Grade Y)\n- Red team passes: N\n- Critical findings: N (addressed: N, deferred: N)\n- High findings: N (addressed: N, deferred: N)\n- New CWEs identified: [list]\n\n## Process Improvements\n- [Adjustments for future audit cycles]\n- [New patterns to add to audit-categories.md]\n- [Categories that need deeper scrutiny next time]",
+  entry_type: "retrospective",
+  tags: ["adversarial-security", "retrospective", "session-summary"],
+  project_number: <project number>
+})
+```
+
+## Tag Convention
+
+| Tag                    | Purpose                                        |
+| ---------------------- | ---------------------------------------------- |
+| `adversarial-security` | All entries from this skill (primary filter)   |
+| `recon`                | Phase 1 output                                 |
+| `redteam`              | Phase 2 output                                 |
+| `remediation`          | Phase 3 output                                 |
+| `external-validation`  | Phase 4 output                                 |
+| `audit-complete`       | Final consolidated summary                     |
+| `retrospective`        | Post-cycle review                              |
+| `session-summary`      | Enables retrieval via session summary searches |
+
+## Entry Type Reference
+
+| Entry Type                | Phase | Description                                     |
+| ------------------------- | ----- | ----------------------------------------------- |
+| `security_recon`          | 1     | Reconnaissance and threat model                 |
+| `security_redteam`        | 2     | Red team findings with scores                   |
+| `security_remediation`    | 3     | Remediation plan with dispositions              |
+| `copilot_validation`      | 4     | External validation findings (via `gh copilot`) |
+| `security_audit_complete` | Final | Consolidated audit summary                      |
+| `retrospective`           | Post  | Session retrospective with metrics              |

package/skills/adversarial-security/references/journal-opt-out.md

@@ -0,0 +1,7 @@
+### Journal Opt-Out
+
+If the user explicitly requests **no journal entries** (e.g., "without entering
+anything in memory-journal-mcp"), skip all `create_entry` calls and produce
+only the final consolidated artifact. The audit is still valid without journal
+entries — they are a documentation benefit, not a correctness requirement.
+Note the opt-out in the report metadata.