memory-journal-mcp 8.0.1 → 9.1.0

package/skills/github-commander/workflows/update-deps.md

@@ -1,109 +0,0 @@
-# Update Dependencies
-
-Run a structured dependency update with validation gates and journal audit trail.
-Generalized for any package manager (npm, yarn, pnpm, bun).
-
-## Phase 1 — Update Dependencies
-
-1. Detect package manager (see SKILL.md § Package Manager Auto-Detection)
-
-2. Update dependencies using the detected package manager:
-
-   | Package Manager | Update Command | Audit Command         |
-   | --------------- | -------------- | --------------------- |
-   | npm             | `npm update`   | `npm audit`           |
-   | yarn            | `yarn upgrade` | `yarn audit`          |
-   | pnpm            | `pnpm update`  | `pnpm audit`          |
-   | bun             | `bun update`   | _(no built-in audit)_ |
-
-3. Run dependency audit (if available for the package manager)
-
-4. If audit reports vulnerabilities:
-   - Attempt auto-fix (e.g., `npm audit fix`)
-   - For unfixable issues: check if lockfile overrides/resolutions can pin
-     transitive deps to patched versions
-   - Journal each vulnerability found
-
-5. Check for remaining outdated packages:
-
-   ```bash
-   # npm
-   npm outdated
-   # yarn
-   yarn outdated
-   # pnpm
-   pnpm outdated
-   ```
-
-6. For any remaining outdated packages:
-   - Update the version range in the manifest file
-   - Run install to update the lockfile
-   - **Skip intentionally pinned packages** (pre-release pins, exact-version
-     pins where Current = Wanted ≠ Latest)
-
-## Phase 2 — Dockerfile Dependencies (Optional)
-
-Skip this phase unless `PROJECT_HAS_DOCKERFILE` is `true` or a `Dockerfile`
-is detected in the project root.
-
-1. Scan the Dockerfile for manually patched packages (e.g., `npm pack <pkg>@<version>`)
-2. For each patched package:
-   - Check the registry for the latest version
-   - Check for known CVEs
-   - If a newer version exists, update the Dockerfile patch lines
-3. Check base image for updates:
-   - Verify the base image tag is pinned (not `latest`)
-   - Check for newer patch versions of the pinned base
-4. If the Dockerfile uses edge repositories for system packages, verify
-   those packages are current
-
-## Phase 3 — Validation Gates
-
-Run the standard validation gates from SKILL.md:
-
-1. **Gate 1**: Lint + Typecheck (`PROJECT_LINT_CMD`, `PROJECT_TYPECHECK_CMD`)
-2. **Gate 2**: Build (`PROJECT_BUILD_CMD`)
-3. **Gate 3**: Tests (`PROJECT_TEST_CMD`) _(Agent Note: Ensure OutputCharacterCount >= 10000 on test execution)_
-4. **Gate 4**: E2E Tests (`PROJECT_E2E_CMD`) _(Agent Note: Ensure OutputCharacterCount >= 10000)_
-
-Journal each gate result. Fix any failures caused by dependency updates.
-
-## Phase 4 — Journal & Changelog
-
-1. Journal the update:
-
-   ```
-   create_entry({
-     content: "Updated dependencies: <list of packages updated>. Audit: <clean/N vulnerabilities>.",
-     entry_type: "deps_update",
-     tags: ["commander", "deps-update"]
-   })
-   ```
-
-2. Update the project changelog (if it exists):
-   - Security fixes (CVE/GHSA) under a security section
-   - Version bumps under a changed/dependencies section
-   - **Do not duplicate existing section headers**
-
-## Phase 5 — Human Checkpoint
-
-Present to the human:
-
-- List of updated packages with old → new versions
-- Any vulnerabilities found and their status (fixed/unfixable)
-- Gate results
-- Changelog additions
-
-Wait for human approval before committing.
-
-## Phase 6 — Commit
-
-Stage only the files changed by this workflow:
-
-```bash
-git add package.json package-lock.json <changelog> <Dockerfile if changed>
-git diff --cached --stat
-git commit -m "chore: update dependencies"
-```
-
-**Do not push.** The human decides when to push or create a PR.

package/skills/github-copilot-cli/SKILL.md

@@ -1,59 +0,0 @@
----
-name: github-copilot-cli
-description: |
-  Documentation and instructions for integrating the GitHub Copilot CLI (`copilot`)
-  into agentic workflows. Use this skill when you need a "second opinion" adversarial
-  review of a local codebase, a pre-push PR review using alternative advanced models,
-  or shell suggestion capabilities from GitHub. Activates on "Copilot CLI", "local PR review",
-  "codebase Copilot review", "second opinion", "use gh copilot", or "ask Copilot".
----
-
-# GitHub Copilot CLI
-
-The new GitHub Copilot agentic CLI is integrated directly into the GitHub CLI (`gh`). The older standalone `github-copilot-cli` package and the `gh-copilot` extension are deprecated. You must use `gh copilot` which now triggers the new agentic experience natively.
-
-When integrated into an AI workflow (AI evaluating AI), it acts as a robust secondary reviewer mapping against different context windows and potentially different foundational models than the primary agent, significantly reducing confirmation bias during PR or full-repository reviews.
-
-> **⚠️ CRITICAL — Non-Interactive Mode**: The `gh copilot` CLI must be run in non-interactive mode using the `-p` (or `--prompt`) flag. Omitting this flag will launch an interactive UI and hang the agent indefinitely. Use `-s` (silent) to suppress styling/decorations and output raw text.
-
-## Installation & Authentication Baseline
-
-Before using the CLI in automated pipelines, ensure the terminal environment is equipped and authenticated:
-
-```bash
-# 1. Verify availability
-gh copilot --version || echo "Copilot not installed"
-
-# 2. Pre-check / Authenticate
-# Check auth status first. If this fails, the environment cannot use Copilot.
-gh auth status
-# If unauthenticated, human interaction is required (which agents cannot do).
-# Fallback: Gracefully skip the Copilot execution step, log the skip reason, and proceed with other tasks.
-# gh auth login
-```
-
-## Agentic Interaction Strategies
-
-Because the Copilot CLI is primarily interactive, standalone non-interactive agents cannot easily navigate its interactive UI natively for arbitrary open-ended tasks.
-
-However, you can leverage its single-shot non-interactive mode (`-p`) for targeted tasks:
-
-### Direct Tool Commands
-
-For precise shell suggestions or file explanations in automated workflows:
-
-```bash
-# Shell Suggestion (Evaluates context and produces command)
-gh copilot -p -s "find all files over 5mb in the current directory"
-
-# File Explanation
-gh copilot -p -s "explain src/utils/crypto.ts"
-```
-
-## Workflows Integration
-
-This skill works synergistically with `github-commander`. Use the `copilot-audit` workflow via `github-commander` to execute a structured, auditable validation loop utilizing this CLI before generating PRs.
-
-### Quota & Rate Limiting
-
-Batch requests where possible when reviewing large repositories. Copilot CLI is subject to GitHub API rate limits. Instead of evaluating 50 files individually, group your prompts to evaluate architectural directories in conceptual batches.

package/skills/github-repo-setup/SKILL.md

@@ -1,136 +0,0 @@
----
-name: github-repo-setup
-description: |
-  Reusable scaffold for public TypeScript/Node.js repositories under
-  a target organization. Use when creating a new GitHub repository to generate all
-  community standards, CI/CD, config files, labels, and topics in one pass.
----
-
-# GitHub Repository Setup
-
-Scaffold a new public TypeScript/Node.js repo with community standards, CI, and strict tooling.
-
-## Prerequisites
-
-- Git CLI with SSH (`~/.ssh/id_ed25519`)
-- GitHub CLI (`gh`) authenticated as `{{ORG_NAME}}`
-- Node.js 24+
-- Default branch: `main`
-- Credentials: Load from a secure environment file (e.g., `{{SECRETS_ENV_PATH}}`) or OS credential stores. **CRITICAL: NEVER hardcode this path in shared templates or commit `.env` files.**
-
-## Parameters
-
-Replace these placeholders throughout:
-
-| Placeholder            | Example                  |
-| ---------------------- | ------------------------ |
-| `{{ORG_NAME}}`         | `neverinfamous`          |
-| `{{REPO_NAME}}`        | `my-mcp-server`          |
-| `{{DESCRIPTION}}`      | `MCP server for X`       |
-| `{{YEAR}}`             | `2026`                   |
-| `{{SECRETS_ENV_PATH}}` | `C:\path\to\secrets.env` |
-
----
-
-## 1. Create Files (~28 total)
-
-Read the reference file listed in the **Template Source** column for exact file contents. Files marked _inline_ are defined directly below the table.
-
-### File Manifest
-
-| File                                          | Purpose                             | Template Source                                             |
-| --------------------------------------------- | ----------------------------------- | ----------------------------------------------------------- |
-| **Community Standards**                       |                                     |                                                             |
-| `LICENSE`                                     | MIT license                         | _inline_                                                    |
-| `README.md`                                   | Badges, quick start, TOC, examples  | Adapt from reference repos                                  |
-| `CONTRIBUTING.md`                             | Fork → Clone → Branch → PR workflow | [community-standards.md](references/community-standards.md) |
-| `CODE_OF_CONDUCT.md`                          | Contributor Covenant 2.1            | [community-standards.md](references/community-standards.md) |
-| `SECURITY.md`                                 | Vulnerability reporting process     | [community-standards.md](references/community-standards.md) |
-| `CHANGELOG.md`                                | Keep a Changelog format (empty)     | _inline_                                                    |
-| `UNRELEASED.md`                               | SSoT for unreleased changes         | _inline_                                                    |
-| **GitHub Automation**                         |                                     |                                                             |
-| `.github/workflows/codeql.yml`                | CodeQL static analysis              | [github-automation.md](references/github-automation.md)     |
-| `.github/workflows/lint-and-test.yml`         | CI: lint, typecheck, build, test    | [github-automation.md](references/github-automation.md)     |
-| `.github/workflows/secrets-scanning.yml`      | TruffleHog + Gitleaks               | [github-automation.md](references/github-automation.md)     |
-| `.github/workflows/dependabot-auto-merge.yml` | Auto-squash patch/minor PRs         | [github-automation.md](references/github-automation.md)     |
-| `.github/workflows/e2e.yml`                   | Playwright E2E tests                | [github-automation.md](references/github-automation.md)     |
-| `.github/dependabot.yml`                      | Grouped dependency updates          | [github-automation.md](references/github-automation.md)     |
-| `.github/ISSUE_TEMPLATE/bug_report.md`        | Rich bug report template            | [github-automation.md](references/github-automation.md)     |
-| `.github/ISSUE_TEMPLATE/feature_request.md`   | Feature request template            | [github-automation.md](references/github-automation.md)     |
-| `.github/ISSUE_TEMPLATE/config.yml`           | Blank issue redirect                | [github-automation.md](references/github-automation.md)     |
-| `.github/pull_request_template.md`            | Comprehensive PR checklist          | [github-automation.md](references/github-automation.md)     |
-| **Project Config**                            |                                     |                                                             |
-| `.gitignore`                                  | Comprehensive ignores               | _inline_                                                    |
-| `.gitattributes`                              | Line ending normalization           | _inline_                                                    |
-| `.prettierrc`                                 | Code formatting config              | [project-config.md](references/project-config.md)           |
-| `.prettierignore`                             | Prettier exclusions                 | [project-config.md](references/project-config.md)           |
-| `.gitleaks.toml`                              | Secret scanning config              | [project-config.md](references/project-config.md)           |
-| `package.json`                                | Project manifest                    | _inline_                                                    |
-| `tsconfig.json`                               | TypeScript strict config            | [project-config.md](references/project-config.md)           |
-| `eslint.config.js`                            | ESLint 10 strict + test config      | [project-config.md](references/project-config.md)           |
-| `tsup.config.ts`                              | Build configuration                 | [project-config.md](references/project-config.md)           |
-| `vitest.config.ts`                            | Test configuration                  | [project-config.md](references/project-config.md)           |
-| `src/index.ts`                                | Entry point placeholder             | Empty file                                                  |
-
----
-
-### Inline Templates
-
-See **[inline-templates.md](references/inline-templates.md)** for the boilerplate contents of `LICENSE`, `CHANGELOG.md`, `UNRELEASED.md`, `.gitattributes`, `.gitignore`, and `package.json`.
-
-> **Note**: AI-suggested versions may be outdated. Always run `npm outdated` and `npx npm-check-updates -u` after install.
-
----
-
-## 2. Init Repo & Push
-
-> **CRITICAL HITL GATE**: You MUST stop and ask the user for explicit confirmation before running the `gh repo create` and `git push` commands. Creating a public repository is a destructive and public action.
-
-```powershell
-cd {{TARGET_DIRECTORY}}
-git init
-git add .
-git commit -m "Initial commit: Repository setup"
-gh repo create {{ORG_NAME}}/{{REPO_NAME}} --public --source=. --remote=origin --description "{{DESCRIPTION}}"
-git push -u origin main
-```
-
-> **Note**: `git add .` is appropriate here because this is a brand-new repo with a clean `.gitignore`. For established repos, always use selective staging per user rules.
-
-## 3. Labels, Topics & GitHub Settings
-
-```powershell
-# Labels
-gh label create dependencies --description "Dependency PRs" --color 0052CC --repo {{ORG_NAME}}/{{REPO_NAME}} --force
-gh label create github-actions --description "GitHub Actions" --color FF6B6B --repo {{ORG_NAME}}/{{REPO_NAME}} --force
-gh label create npm --description "NPM updates" --color CB3837 --repo {{ORG_NAME}}/{{REPO_NAME}} --force
-gh label create bug --description "Bug reports" --color d73a49 --repo {{ORG_NAME}}/{{REPO_NAME}} --force
-gh label create enhancement --description "Feature requests" --color a2eeef --repo {{ORG_NAME}}/{{REPO_NAME}} --force
-
-# Topics
-gh repo edit {{ORG_NAME}}/{{REPO_NAME}} --add-topic typescript --add-topic nodejs
-
-# Security settings (automate instead of manual UI)
-gh api repos/{{ORG_NAME}}/{{REPO_NAME}} -X PATCH -f security_and_analysis.secret_scanning.status=enabled
-gh api repos/{{ORG_NAME}}/{{REPO_NAME}} -X PATCH -f security_and_analysis.secret_scanning_push_protection.status=enabled
-```
-
-## 4. Verify
-
-```powershell
-npm install          # 0 vulnerabilities
-npm run build        # Compiles
-npm run typecheck    # No errors
-npm run lint         # No errors
-git status           # .gitignore working
-npm outdated         # Update if needed
-git remote -v        # origin → github.com/{{ORG_NAME}}/{{REPO_NAME}}
-gh repo view         # Displays repo info
-```
-
-## Reference Repos
-
-- `{{ORG_NAME}}/db-mcp` (SQLite)
-- `{{ORG_NAME}}/mysql-mcp` (MySQL)
-- `{{ORG_NAME}}/postgres-mcp` (PostgreSQL)
-- `{{ORG_NAME}}/memory-journal-mcp` (Memory Journal)

package/skills/github-repo-setup/references/community-standards.md

@@ -1,136 +0,0 @@
-# Community Standards Templates
-
-Full templates for community health files. Read on demand when setting up a new repo.
-
----
-
-## CONTRIBUTING.md
-
-```markdown
-# Contributing to {{REPO_NAME}}
-
-Thank you for your interest in contributing! This guide will help you get started.
-
-## Getting Started
-
-1. **Fork** the repository
-2. **Clone** your fork: `git clone git@github.com:YOUR_USERNAME/{{REPO_NAME}}.git`
-3. **Create a branch**: `git checkout -b feature/your-feature`
-4. **Install dependencies**: `npm install`
-5. **Make your changes**
-6. **Run checks**: `npm run check && npm run test`
-7. **Commit**: `git commit -m "feat: description of your change"`
-8. **Push**: `git push origin feature/your-feature`
-9. **Open a Pull Request**
-
-## Development Setup
-
-### Prerequisites
-
-- Node.js >= 24.0.0
-- npm
-
-### Commands
-
-| Command             | Description               |
-| ------------------- | ------------------------- |
-| `npm run build`     | Build the project         |
-| `npm run dev`       | Start development mode    |
-| `npm run lint`      | Run ESLint                |
-| `npm run lint:fix`  | Auto-fix lint issues      |
-| `npm run typecheck` | TypeScript type checking  |
-| `npm run test`      | Run unit tests            |
-| `npm run test:e2e`  | Run E2E tests             |
-| `npm run check`     | Lint + typecheck combined |
-
-## Code Style
-
-- TypeScript strict mode with ESLint 10
-- Prettier for formatting (runs automatically in CI)
-- Follow existing patterns in the codebase
-
-## Commit Messages
-
-Use [Conventional Commits](https://www.conventionalcommits.org/):
-
-- `feat:` — New feature
-- `fix:` — Bug fix
-- `docs:` — Documentation only
-- `refactor:` — Code change that neither fixes a bug nor adds a feature
-- `test:` — Adding or updating tests
-- `chore:` — Maintenance tasks
-
-## Pull Request Process
-
-1. Update documentation if needed
-2. Add tests for new functionality
-3. Ensure all checks pass
-4. One approval required for merge
-
-## Reporting Issues
-
-Use the [Issue Templates](https://github.com/neverinfamous/{{REPO_NAME}}/issues/new/choose) to report bugs or request features.
-
-## License
-
-By contributing, you agree that your contributions will be licensed under the MIT License.
-```
-
----
-
-## CODE_OF_CONDUCT.md
-
-Use the [Contributor Covenant v2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/) with contact: `admin@adamic.tech`.
-
-Download the full text from the link above and replace the contact placeholder. The file should be ~130 lines.
-
----
-
-## SECURITY.md
-
-```markdown
-# Security Policy
-
-## Supported Versions
-
-| Version  | Supported |
-| -------- | --------- |
-| Latest   | ✅        |
-| < Latest | ❌        |
-
-## Reporting a Vulnerability
-
-**Please do not report security vulnerabilities through public GitHub issues.**
-
-Instead, please report them via email to **admin@adamic.tech**.
-
-### What to Include
-
-- Description of the vulnerability
-- Steps to reproduce the issue
-- Potential impact
-- Suggested fix (if any)
-
-### Response Timeline
-
-- **48 hours** — Initial acknowledgment
-- **7 days** — Assessment and action plan
-- **30 days** — Fix released (for confirmed vulnerabilities)
-
-### Safe Harbor
-
-We consider security research conducted in good faith to be authorized. We will not pursue legal action against researchers who:
-
-- Make a good faith effort to avoid privacy violations and data destruction
-- Provide us reasonable time to address the issue before disclosure
-- Do not exploit the vulnerability beyond what is necessary to demonstrate it
-
-## Security Best Practices
-
-When contributing, please follow these security practices:
-
-- Never commit secrets, API keys, or credentials
-- Use parameterized queries for any database operations
-- Validate and sanitize all user inputs
-- Follow the principle of least privilege
-```