Update dependencies, update project docs, guides, prompts

Author: bhousel

.gitattributes

@@ -0,0 +1,11 @@
+* text=lf
+*.bat eol=crlf
+*.js eol=lf
+*.mjs eol=lf
+*.cjs eol=lf
+*.ts eol=lf
+
+*.json linguist-detectable
+*.md linguist-documentation
+
+dist/** linguist-generated

.github/prompts/commit.prompt.md

@@ -0,0 +1,19 @@
+---
+description: Stage and commit all changes in this repo
+---
+
+You are performing a git commit for this repo. Do the following steps in order:
+
+1. Run `git status` to see what's modified
+2. Run `git add -A` to stage everything (`.gitignore` already excludes transient runtime files)
+3. If there is nothing to stage, say so clearly and stop — do not create an empty commit
+4. Write a commit message that summarizes the recent work to a temp file, then run `git commit -F <tempfile>` and delete the temp file afterward.
+   - Do NOT use `git commit -m` — multi-line messages with special characters break shell quoting.
+   - Do NOT use heredoc syntax (`<< 'EOF'`) — it interacts badly with the terminal tool.
+   - Instead, use `printf` to write the temp file, one `'line'` argument per line:
+     ```
+     printf '%s\n' 'First line' '' 'Second line' 'Third line' > /tmp/commitmsg.txt
+     git commit -F /tmp/commitmsg.txt
+     rm /tmp/commitmsg.txt
+     ```
+5. Run `git push` to push commits up to the origin

.github/prompts/reflect.prompt.md

@@ -0,0 +1,72 @@
+---
+description: Reflect on recent work and bring all project documentation up to date
+---
+
+You are doing a documentation update pass. Recent code changes may have left docs, guides, and inline comments out of date. Your job is to find and fix those gaps — not to write new documentation for its own sake.
+
+**Do not commit.** Make all edits and stop. The user will review before committing.
+
+## How to approach this
+
+First, get oriented:
+1. Review the current chat session history — this is your primary source of context for what was discussed, decided, and changed
+2. Run `git log --oneline -20` to see recent commits and confirm what was actually landed
+3. Use `#codebase` to survey the current state of the project
+
+Then work through each documentation layer below.
+
+---
+
+## Documentation layers to check
+
+### SCRATCHPAD.md (if present)
+A working-memory file for agents (gitignored). Update it with:
+- Any new quirks, gotchas, or lessons learned from recent work
+- Any known issues or follow-up tasks worth remembering
+- Remove anything that is now resolved or stale
+
+### AGENTS.md (if present)
+Agent context file. Check that:
+- The described project structure still matches reality
+- Any tool, script, or workflow guidance is still accurate
+- Nothing important from recent work is missing
+
+### README.md
+The public face of the project. Check that:
+- The feature list / description still reflects what the project does
+- Setup and usage instructions still work as written
+- Any referenced scripts, commands, or file paths still exist and are correct
+- Version numbers or compatibility notes aren't stale
+
+### CONTRIBUTING.md (if present)
+Check that:
+- Development setup instructions are still accurate
+- Any described workflow (build steps, naming conventions, PR process) reflects current practice
+
+### Other markdown files (CHANGELOG.md, RELEASE.md, etc.)
+- CHANGELOG: verify the most recent entry matches the current `package.json` version (or equivalent). Flag if they're out of sync — but do not generate a new changelog entry here; that's for `/release`.
+- RELEASE.md or similar: check that documented release steps match current tooling
+
+### Prompt files (`.github/prompts/*.prompt.md`, `.instructions.md`, etc.)
+Check that:
+- Referenced file paths, script names, and commands still exist
+- Any example version numbers or outputs are not misleading
+- Steps are still in the right order
+
+### Inline code documentation
+Look for comments in source files that reference something that has since changed:
+- Outdated file paths or module names
+- Comments describing behavior that has been refactored
+- TODO/FIXME comments that have been resolved by recent work (remove or update them)
+
+---
+
+## How to respond
+
+For each layer, report one of:
+- ✅ **Up to date** — nothing to do
+- 🟡 **Updated** — briefly describe what you changed
+- 💡 **Flag for user** — something needs a human decision (e.g. a CHANGELOG version mismatch, a structural README question)
+
+Keep it brief. One line per finding is enough.
+Make all edits directly — don't ask for permission on small fixes.

.github/prompts/release.prompt.md

@@ -0,0 +1,34 @@
+---
+description: Prepare a new release (CHANGELOG, version bump)
+argument-hint: version number, for example: `A.B.C` or `A.B.C-pre.D`
+---
+
+You are preparing release **${input:version}** for this repo. Do the following steps in order:
+
+1. **Confirm the version** — the new release version is `${input:version}`. Read `package.json` to verify this is a valid bump from the current version.
+   - The version must follow semver format, for example: `A.B.C` or `A.B.C-pre.D`
+   - It must be strictly greater than the current version in `package.json`
+   - If either check fails, stop immediately and explain the problem clearly — do not proceed with any further steps.
+
+2. **Identify commits since the last release** by running:
+   ```
+   git log --oneline
+   ```
+   Find the commit that corresponds to the previous release (look for the version bump or a release tag) and note all commits after it.
+
+3. **Look up PR numbers** by fetching:
+   ```
+   https://github.com/bhousel/node-diff3/pulls?q=is%3Apr+is%3Aclosed
+   ```
+   Match each commit to its PR number.  PR titles listed there are authoritative — prefer them over raw commit messages.
+
+4. **Update `CHANGELOG.md`** — insert a new section immediately above the previous release heading. Follow the existing format exactly:
+   - Header: `# ${input:version}`
+   - Date: `##### YYYY-Mon-DD` (use today's date)
+   - Bullet points for each user-visible change (features, fixes, improvements)
+   - For bug/fix commits, write a plain bullet
+   - Internal/dev-only commits (CI config, agent setup, etc.) can be omitted or grouped into a single terse bullet
+   - Add reference links at the bottom of the section:
+     - PR links: `[#NNN]: https://github.com/bhousel/node-diff3/issues/NNN`
+
+5. **Update `package.json`** — set `"version"` to `"${input:version}"`.

.github/prompts/suggest.prompt.md

@@ -0,0 +1,55 @@
+---
+description: Review the codebase and suggest (then implement) concrete improvements
+---
+
+You are doing an improvement review of this codebase. The goal is to find **concrete, actionable improvements** — not a wishlist. Think like an experienced senior engineer or architect who respects the existing style and doesn't over-engineer.
+
+## What to read first
+
+Get a broad picture of the project before forming any opinions. Use `#codebase` to survey the whole workspace — pay particular attention to:
+- Package/dependency manifests (`package.json`, `Cargo.toml`, `pyproject.toml`, etc.)
+- Compiler/type-checker config (`tsconfig.json`, `mypy.ini`, etc.)
+- Runtime/bundler config (`bunfig.toml`, `vite.config.*`, etc.)
+- Build and tooling scripts
+- The README — how the project presents itself and what it's for
+
+## Categories to evaluate
+
+For each category below, look for real issues and note them. Skip categories where things look fine — don't invent problems.
+
+**Correctness / bugs**
+- Are there any scripts or config values that are plainly wrong? (e.g. calling `npm run` in a Bun-only project)
+- Any TypeScript errors or implicit `any` types?
+- Any typos in user-facing strings (error messages, log output)?
+
+**TypeScript quality**
+- Are types as precise as they should be? (e.g. `String[]` vs `string[]`, missing type annotations on parameters)
+- Are there untyped third-party modules that need a `.d.ts` declaration?
+- Are there `tsconfig.json` options enabled that don't apply to this project?
+
+**Runtime / tooling overlap**
+- Does the project use Node.js APIs where a Bun-native equivalent exists and is simpler? (e.g. `node:fs` vs `Bun.file()`)
+- Are there npm/yarn artifacts in the scripts that should use `bun`?
+- Are there dependencies that Bun now handles natively (e.g. a test runner, a bundler)?
+
+**Dev experience**
+- Is there a fast linter+formatter that would be easy to add? (Biome is a good fit for Bun projects — one tool, zero config, very fast)
+- Are there missing or misleading `package.json` scripts?
+- Is the `.gitignore` / `.gitattributes` complete and correct?
+
+**Code clarity**
+- Are there comments that are outdated or misleading?
+- Are there any obvious simplifications (not refactors — just noise removal)?
+
+## How to respond
+
+1. **Group findings by category.** Within each category, distinguish between:
+   - 🔴 Real issues (bugs, broken things) — implement the fix immediately
+   - 🟡 Improvements (best practices, clarity) — implement unless non-trivial
+   - 💡 Suggestions (optional tools, bigger changes) — describe but don't implement; let the user decide
+
+2. **Be direct and brief.** One sentence per finding is usually enough. Don't pad.
+
+3. **Implement the 🔴 and 🟡 items** using file edits. Verify there are no new TypeScript errors afterward.
+
+4. **Do not over-engineer.** A bug fix doesn't need surrounding code cleaned up. A simple improvement doesn't need extra configurability. Only change what needs changing.

.github/prompts/sync.prompt.md

@@ -0,0 +1,67 @@
+---
+description: Sync scaffold files in this project against a source repo, creating or updating files with details adapted to this project
+argument-hint: source repo URL or owner/repo, e.g. https://github.com/<owner>/<repo>
+---
+
+You are doing a scaffold sync. For each file in the manifest below, fetch the source version, compare it to the local version, and **create or update the local file** — substituting any source-specific details with this project's equivalent. The goal is to carry the source's structure and generic content forward while keeping this project's identity intact.
+
+## Setup
+
+The source repo is: **${input:source_repo}**
+
+Before doing anything else:
+1. Read this project's `package.json` (or equivalent manifest) to learn: project name, description, repo URL, license, author(s), and language/runtime.
+2. Read the source repo's `package.json` too — you'll need to know which details to substitute.
+3. Convert the source repo URL to a raw content base URL:
+   - `https://github.com/owner/repo` → `https://raw.githubusercontent.com/owner/repo/main`
+
+---
+
+## Scaffold file manifest
+
+Process each file below. For every file: fetch the source, read the local version (if it exists), then apply the specific instructions listed.
+
+- `.github/prompts/commit.prompt.md` — generic workflow; substitute any repo-specific examples or URLs
+- `.github/prompts/reflect.prompt.md` — generic; substitute any repo-specific layer references (file names, tools, etc.)
+- `.github/prompts/release.prompt.md` — adapt the workflow to this project's release process (don't just string-replace tool names — rethink the steps if the workflow is fundamentally different); substitute repo URL and tooling references
+- `.github/prompts/suggest.prompt.md` — generic; substitute any repo-specific examples or file paths
+- `.github/prompts/sync.prompt.md` — generic; the argument-hint uses a placeholder URL and should not need substitution
+- `.gitattributes` — adapt file-type entries to match this project's actual file types (e.g. add `*.sh` if the project has shell scripts, drop `*.ts` if it doesn't use TypeScript); if local file exists, add missing entries without removing local-only ones
+- `.gitignore` — merge: add entries from source that are absent locally; do not remove local-only entries
+- `AGENTS.md` — the general guidelines section is portable; substitute project-specific references (scratchpad notes, file paths, tool names) with this project's equivalents; preserve any local sections that have no counterpart in the source
+- `CONTRIBUTING.md` — adapt to this project's tooling and runtime (don't just string-replace tool names — rethink setup steps and commands if the build workflow differs); keep the source's structural sections
+- `LICENSE.md` — if the local license type matches this project's `package.json`, it's correct — skip regardless of what the source uses; only flag if the local file contradicts this project's own `package.json`
+- `README.md` — preserve this project's actual description, icon list, and any unique content; adopt structural sections (badge layout, contributing footer, license block) from the source if they are absent locally; do not overwrite meaningful local content with source content
+- `RELEASE.md` — substitute this project's repo URL, branch names, and tooling references
+- `bunfig.toml` — skip entirely if this project does not use Bun; otherwise apply source content with any registry or test configuration substituted for this project's equivalents
+- `tsconfig.json` — apply structural changes and new compiler options from the source; flag any option that differs in value and ask before overwriting, since local values may be intentional
+
+---
+
+## Steps
+
+For each file in the manifest:
+
+1. Fetch the raw source content from `{raw_base_url}/{file_path}` (skip gracefully if the source repo doesn't have it)
+2. Check whether the file exists locally
+3. Identify all source-specific values: repo name, org, URLs, package names, author names, version numbers, tool names — anything that belongs to the source project rather than the template structure
+4. Replace each source-specific value with the corresponding value from this project (from `package.json` or existing local files)
+5. Create or update the local file with the adapted content
+
+---
+
+## How to report
+
+After processing all files, produce a summary table:
+
+| File | Status | Notes |
+|------|--------|-------|
+| `.github/prompts/commit.prompt.md` | ✅ In sync / 🔄 Updated / ✨ Created / ⏭️ Skipped | … |
+| … | … | … |
+
+For each **🔄 Updated** or **✨ Created** file: briefly describe what was substituted or what structural changes were adopted.
+
+For **⏭️ Skipped** files: one line explaining why (e.g. "source repo doesn't have this file" or "Bun not used in this project").
+
+For files that were **✅ In sync**: one line is enough.
+

.gitignore

@@ -1,10 +1,12 @@
-coverage/
-dist/
-node_modules/
-
 .DS_Store
-.vscode
+SCRATCHPAD.md
+
 npm-debug.log
-lerna-debug.log
 package-lock.json
+pnpm-lock.yaml
 yarn.lock
+
+.vscode/
+coverage/
+dist/
+node_modules/

AGENTS.md

@@ -0,0 +1,47 @@
+# Agent Context
+
+This file contains agent-specific guidance only.
+
+Read [`README.md`](README.md) and [`CONTRIBUTING.md`](CONTRIBUTING.md) first for general project information.
+
+---
+
+## Scratchpad
+
+You can use a `SCRATCHPAD.md` file (gitignored) for persistent working memory across chat sessions. At the start of a session, read it for additional context on recent work, lessons learned, and known quirks. As you work, feel free to update the scratchpad with any learnings that a future session would benefit from knowing.
+
+## Prompt Files
+
+This project has reusable Copilot prompt files in `.github/prompts/`:
+
+- `/commit` — stage and commit all changes
+- `/reflect` — update all project documentation with the current state of the code
+- `/release` — prepare a new release (CHANGELOG entry + version bump); accepts version number as input
+- `/suggest` — review the codebase and suggest concrete improvements
+- `/sync` — sync scaffold files against a source repo; accepts source repo URL as input
+
+When asked to do one of these tasks, prefer using the prompt file rather than improvising.
+
+## General Guidelines
+
+### Communication style
+- Be concise. Maintainers review many contributions — get to the point.
+- Plain language over formal structure. A sentence or two beats a page of headings.
+- Don't explain things the maintainer already knows (project context, how Git works, etc.).
+- If a PR does one thing, describe that one thing.
+
+### Constructive Pushback
+- **Don't just implement what's asked** — briefly flag if you see a concern. The user values a 1-2 sentence heads-up over silent compliance.
+- This includes: unnecessary abstractions, deprecated patterns, simpler alternatives, or potential footguns.
+- When the user proposes a solution, briefly evaluate whether a more elegant solution exists.
+
+### Secrets hygiene
+- Before making any edit or commit, ask: **could this write a secret in plaintext somewhere it shouldn't be?**
+- Never put tokens, keys, or passwords in plaintext in any unencryped file.
+
+### Comments
+- **Never remove comments** when modifying files unless:
+  - The comment applies to code being removed
+  - The meaning of the code has changed
+  - Specifically asked to remove them
+- Comments contain valuable domain knowledge - preserve them

CONTRIBUTING.md

@@ -29,3 +29,9 @@ It's also good to check on the dependencies sometimes with commands like:
 - `bun update --interactive`  - choose which updates to apply
 
 Try to keep things simple!
+
+## AI-Assisted Contributions
+
+We welcome contributions made with the help of AI tools.
+If you use them, you are responsible for understanding and reviewing the output before submitting it.
+Generated code, issues, and PR descriptions should be clear and relevant — not verbose for the sake of it.

LICENSE.md

@@ -8,7 +8,7 @@ For more detail please visit:
 
 Copyright (c) 2006, 2008 Tony Garnock-Jones &lt;tonyg@lshift.net&gt;<br/>
 Copyright (c) 2006, 2008 LShift Ltd. &lt;query@lshift.net&gt;<br/>
-Copyright (c) 2019-2025 Bryan Housel &lt;bhousel@gmail.com&gt;<br/>
+Copyright (c) 2019-2026 Bryan Housel &lt;bhousel@gmail.com&gt;<br/>
 
 Permission is hereby granted, free of charge, to any person
 obtaining a copy of this software and associated documentation files