memory-journal-mcp 8.0.1 → 9.1.0

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

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

@@ -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.

package/skills/adversarial-security/references/feedback-loop.md

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

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