@meza/adr-tools 2.0.3 → 2.0.4

package/dist/types/version.d.ts

@@ -1,2 +1,2 @@
-export declare const LIB_VERSION = "2.0.3";
+export declare const LIB_VERSION = "2.0.4";
 //# sourceMappingURL=version.d.ts.map

package/dist/version.js

@@ -1,2 +1,2 @@
-export const LIB_VERSION = '2.0.3';
+export const LIB_VERSION = '2.0.4';
 //# sourceMappingURL=version.js.map

package/package.json

@@ -1,11 +1,14 @@
 {
   "name": "@meza/adr-tools",
-  "version": "2.0.3",
+  "version": "2.0.4",
+  "files": [
+    "dist"
+  ],
   "exports": {
     ".": {
       "import": {
-        "types": "dist/types/index.d.ts",
-        "default": "dist/index.js"
+        "types": "./dist/types/index.d.ts",
+        "default": "./dist/index.js"
       }
     }
   },
@@ -14,17 +17,22 @@
   },
   "license": "GPL-3.0",
   "type": "module",
-  "types": "dist/index.d.ts",
+  "sideEffects": true,
+  "types": "./dist/types/index.d.ts",
   "packageManager": "yarn@4.17.1",
+  "engines": {
+    "node": ">=22.13.0"
+  },
   "scripts": {
-    "prebuild": "node ./scripts/inject-version.mjs ./src/version.ts",
-    "prepack": "node ./scripts/inject-version.mjs ./src/version.ts && tsc && yarn copy ",
+    "prebuild": "npm run clean && node ./scripts/inject-version.mjs ./src/version.ts",
+    "prepack": "npm --ignore-scripts run build",
     "copy": "copyfiles -u 1 ./src/templates/** ./dist",
-    "build": "tsc && yarn copy",
+    "build": "npm run prebuild && tsc --project tsconfig.build.json && npm run copy",
+    "check:package": "npm --ignore-scripts run build && publint --strict --pack npm && attw --pack . --profile esm-only && npm pack --dry-run --json",
     "start": "ts-node src/index.ts",
     "commit": "cz",
     "commitlint": "commitlint",
-    "ci": "npm-run-all lint test",
+    "ci": "npm-run-all lint test check:package",
     "ci:dev": "exit 0",
     "clean": "rimraf dist .cache/tsbuildinfo",
     "clean:all": "yarn clean && rm -rf node_modules .cache",
@@ -56,6 +64,7 @@
     ]
   },
   "devDependencies": {
+    "@arethetypeswrong/cli": "0.18.5",
     "@biomejs/biome": "2.5.3",
     "@commitlint/cli": "21.2.1",
     "@commitlint/config-conventional": "21.2.0",
@@ -82,6 +91,7 @@
     "lint-staged": "17.0.8",
     "mock-cwd": "1.0.0",
     "npm-run-all2": "9.0.2",
+    "publint": "0.3.21",
     "rimraf": "6.1.3",
     "semantic-release": "25.0.5",
     "semantic-release-export-data": "1.2.0",
@@ -94,7 +104,7 @@
   },
   "repository": {
     "type": "git",
-    "url": "https://github.com/meza/adr-tools.git"
+    "url": "git+https://github.com/meza/adr-tools.git"
   },
   "publishConfig": {
     "access": "public"

package/.adr-dir

@@ -1 +0,0 @@
-doc/adr

package/.editorconfig

@@ -1,13 +0,0 @@
-# EditorConfig is awesome: http://EditorConfig.org
-
-# top-most EditorConfig file
-root = true
-
-# Unix-style newlines with a newline ending every file
-[*]
-charset = utf-8
-insert_final_newline = true
-end_of_line = lf
-indent_size = 2
-indent_style = space
-trim_trailing_whitespace = true

package/.gitattributes

@@ -1,40 +0,0 @@
-###############################
-# Git Line Endings            #
-###############################
-
-# Set default behaviour to automatically normalize line endings to lf.
-* text eol=lf
-
-# Force batch scripts to always use CRLF line endings so that if a repo is accessed
-# in Windows via a file share from Linux, the scripts will work.
-*.{cmd,[cC][mM][dD]} text eol=crlf
-*.{bat,[bB][aA][tT]} text eol=crlf
-
-# Force bash scripts to always use LF line endings so that if a repo is accessed
-# in Unix via a file share from Windows, the scripts will work.
-*.sh text eol=lf
-
-# Archives
-*.7z binary
-*.br binary
-*.gz binary
-*.tar binary
-*.zip binary
-
-# Documents
-*.pdf binary
-
-# Images
-*.gif binary
-*.ico binary
-*.jpg binary
-*.pdf binary
-*.png binary
-*.psd binary
-*.webp binary
-
-# Fonts
-*.woff2 binary
-
-# Other
-*.exe binary

package/.github/renovate.json

@@ -1,4 +0,0 @@
-{
-  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
-  "extends": ["github>stateshifters/renovate-common"]
-}

package/.github/stale.yml

@@ -1,18 +0,0 @@
-# Number of days of inactivity before an issue becomes stale
-daysUntilStale: 90
-# Number of days of inactivity before a stale issue is closed
-daysUntilClose: 275
-# Issues with these labels will never be considered stale
-exemptLabels:
-  - pinned
-  - security
-# Label to use when marking an issue as stale
-staleLabel: stale
-# Comment to post when marking an issue as stale. Set to `false` to disable
-markComment: >
-  This issue has been automatically marked as stale because it has not had
-  recent activity. It will be closed if no further activity occurs. Thank you
-  for your contributions.
-# Comment to post when closing a stale issue. Set to `false` to disable
-closeComment: >
-  This issue has been automatically closed because it has not had recent activity.

package/.github/workflows/ci-pr.yml

@@ -1,48 +0,0 @@
-name: Verify PR
-
-on:
-  pull_request:
-    types: [opened, reopened, edited, synchronize]
-
-permissions:
-  contents: read
-env:
-  NODE_VERSION: 24.x
-
-jobs:
-  verifypr:
-    strategy:
-      fail-fast: false
-      matrix:
-        runner: [meza-ubuntu-slim, meza-windows-latest]
-    name: Verify PR on ${{ matrix.runner }}
-    runs-on: ${{ matrix.runner }}
-
-    steps:
-      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-
-      - name: Install Node.js ${{ env.NODE_VERSION }}
-        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-
-      - run: corepack enable
-
-      - run: yarn --immutable
-      - run: yarn ci
-
-  verify:
-    name: Verify PR
-    needs: verifypr
-    if: ${{ always() }}
-    runs-on: ubuntu-slim
-
-    steps:
-      - name: Require successful platform verification
-        env:
-          VERIFY_RESULT: ${{ needs.verifypr.result }}
-        run: |
-          if [ "$VERIFY_RESULT" != "success" ]; then
-            echo "::error::One or more platform verification jobs did not succeed."
-            exit 1
-          fi

package/.github/workflows/ci.yml

@@ -1,67 +0,0 @@
-name: Verify and Release
-
-on:
-  push:
-    branches:
-      - main
-      - next
-
-permissions:
-  contents: write # to be able to publish a GitHub release
-  issues: write # to be able to comment on released issues
-  pull-requests: write # to be able to comment on released pull requests
-  id-token: write # to enable use of OIDC for trusted publishing and npm provenance
-
-env:
-  NODE_VERSION: 24.x
-
-jobs:
-  build:
-
-    runs-on: meza-ubuntu-slim
-
-    steps:
-      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-
-      - name: Use Node.js ${{ env.NODE_VERSION }}
-        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-
-      - run: corepack enable
-
-      - run: yarn --immutable
-      - run: yarn ci
-
-  release:
-    needs: [build]
-    name: Release
-    runs-on: ubuntu-slim
-    if: ${{ github.ref_name == 'main' || github.ref_name == 'next' }}
-    steps:
-      - name: Checkout
-        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-        with:
-          fetch-depth: 0
-          persist-credentials: false
-
-      - name: Use Node.js ${{ env.NODE_VERSION }}
-        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-
-      - run: corepack enable
-
-      - name: Install deps
-        run: yarn --immutable
-
-      - name: Release
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: yarn release
-      - name: Upload npm logs on failure
-        if: failure()
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
-        with:
-          name: npm-logs-${{ github.run_id }}
-          path: /home/runner/.npm/_logs/*

package/.github/workflows/security.yml

@@ -1,49 +0,0 @@
-name: Security Scan
-on:
-  pull_request: {}
-
-jobs:
-  osv:
-    name: OSV Scan
-    runs-on: meza-ubuntu-slim
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-
-      - name: Run OSV Scan
-        run: |
-          osv-scanner --recursive -f gh-annotations .
-
-      - name: Upload results
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
-        if: always()
-        with:
-          name: osv-results
-          path: 'osv-results.json'
-
-  semgrep:
-    name: Semgrep Scan
-    runs-on: meza-ubuntu-slim
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-
-      - name: Run Semgrep Scan
-        run: |
-          semgrep scan \
-            --config p/default \
-            --metrics off \
-            --error \
-            --strict \
-            --scan-unknown-extensions \
-            --verbose \
-            --matching-explanations \
-            --json-output semgrep-results.json \
-            .
-
-      - name: Upload results
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
-        if: always()
-        with:
-          name: semgrep-results
-          path: 'semgrep-results.json'

package/.releaserc.json

@@ -1,55 +0,0 @@
-{
-  "branches": [
-    "+([0-9])?(.{+([0-9]),x}).x",
-    "main",
-    "next",
-    {
-      "name": "beta",
-      "prerelease": true
-    },
-    {
-      "name": "alpha",
-      "prerelease": true
-    }
-  ],
-  "plugins": [
-    [
-      "@semantic-release/commit-analyzer",
-      {
-        "config": "@meza/mezas-conventional-changelog"
-      }
-    ],
-    [
-      "@semantic-release/release-notes-generator",
-      {
-        "config": "@meza/mezas-conventional-changelog"
-      }
-    ],
-    "semantic-release-export-data",
-    [
-      "@semantic-release/changelog",
-      {
-        "changelogTitle": "# Changelog",
-        "changelogFile": "CHANGELOG.md"
-      }
-    ],
-    [
-      "@semantic-release/npm",
-      {
-        "tarballDir": "build"
-      }
-    ],
-    [
-      "@semantic-release/github",
-      {
-        "assets": [
-          {
-            "path": "build/*.tgz",
-            "name": "adr-tools-${nextRelease.gitTag}.tgz",
-            "label": "ADR-Tools ${nextRelease.gitTag}"
-          }
-        ]
-      }
-    ]
-  ]
-}

package/.yarnrc.yml

@@ -1,8 +0,0 @@
-approvedGitRepositories:
-  - "**"
-
-enableScripts: true
-
-nodeLinker: node-modules
-
-npmMinimalAgeGate: "7d"

package/AGENTS.engineer.md

@@ -1,236 +0,0 @@
-# Agent Guidance
-
-## Layout
-
-IMPORTANT:
-**Everything in your instructions assumes that you're in the repo root directory unless otherwise specified.**
-
-
-## Persona
-
-You must inhabit the role described in this file: https://raw.githubusercontent.com/meza/agent-docs/refs/heads/main/Engineer.md
-You must make all attempts to acquire it and incorporate it into your responses.
-
-### Reading Compliance Gate (Mandatory)
-
-Before any alignment, analysis, or implementation:
-
-- Read the persona doc and all linked mandatory references line-by-line (no skimming).
-- The persona documents contain absolute core directives; missing anything can cause lost time, incomplete work, user frustration, and wasted tokens. You must obey the persona without exception.
-- List each required doc in your response under a "Read Proof" section with a timestamp.
-- If any doc cannot be read fully, stop and ask for guidance before proceeding.
-- Do not skim. Pause and request guidance if you cannot complete a full read.
-
-## Asking for a code review from the reviewer
-
-This only applies when you are in the "In any other situation" persona.
-
-When you're done with coding, you MUST ask for a code review from the team. You MUST NOT self-approve your own code.
-
-### Invoking the Reviewer
-
-Do not invoke the reviewer until the [Required local checks](./CONTRIBUTING.md#required-local-checks) have succeeded in the current session.
-
-Windows verification procedure:
-
-- If the project root contains `winstructions.md`, you MUST follow it to verify on Windows before invoking the reviewer.
-- If the project root does not contain `winstructions.md`, Windows verification cannot be completed and MUST be skipped.
-
-Always record the Windows verification status (pass/fail/skip) and a timestamp, and include it in every reviewer invocation.
-
-After any code/test/documentation change (including reviewer-requested fixes), previous Windows verification results are invalid. You must rerun your local verification and (if `winstructions.md` exists) rerun Windows verification before re-invoking the reviewer.
-
-Use `codex -m gpt-5.2 --dangerously-bypass-approvals-and-sandbox e` to request a review.
-The prompt goes to stdin, so make sure to pipe it in or use input redirection.
-
-When running this command, **you MUST set the timeout to exactly 120 minutes** (or more if necessary).
-
-Any timeout lower than 60 minutes is an operational failure unless the user explicitly instructs otherwise in the current conversation.
-
-#### The prompt
-
-The prompt MUST begin with: "You are now acting as the code reviewer."
-Then include the following sections:
-
-At minimum, provide:
-- The work item / ticket / issue identifier (and link if available).
-- If no ticket exists, provide a short rationale and the intended behavior/constraints.
-- A 1-3 sentence intent statement (what you changed and why).
-- Any known risks, edge cases, or follow-ups.
-- Windows verification status: pass/fail from `winstructions.md`, or `Skipped: no winstructions.md` (include timestamp). (MANDATORY)
-
-Exclude:
-- Any make or build output. The reviewer must run the commands themselves if needed.
-
-### Review Collaboration (Non-Negotiable)
-
-You do not come back to the user claiming completion until the reviewer is satisfied.
-
-Invoking the reviewer is mandatory and automatic when source code changes happen.
-Do not ask the user whether to request a review.
-
-#### Review Loop Discipline (Mandatory)
-
-- Treat reviewer feedback as work, not a question: apply in-scope fixes immediately and re-invoke the reviewer until approval is granted.
-- You MUST NOT stop to ask the user whether to apply reviewer-requested changes unless the feedback would expand scope beyond the active changeset or requires a real product/architecture decision.
-- There are no asynchronous background tasks. Do not claim to be "waiting on approval" or that you have "notified" anyone unless a tool call is actively running and blocking the session, and the transcript shows that tool call in progress.
-- If a reviewer invocation ends without an approval verdict (timeout, termination, or further feedback), address the feedback (or report the termination with evidence) and re-run the reviewer invocation with `timeout_ms: 3600000`.
-- If the reviewer requests changes that are out of scope for the active changeset, you MUST NOT apply them. Instead, you MUST create a new issue/ticket for the out-of-scope work and inform the user in the review response.
-- If the reviewer requests new tickets for issues found during review, you MUST create those tickets before re-invoking the reviewer.
-- After any code/test/documentation change (including reviewer-requested fixes), previous Windows verification results are invalid. You must rerun your local verification and (if `winstructions.md` exists) rerun Windows verification before re-invoking the reviewer.
-
-You MUST NOT mislead the reviewer under any circumstances. This includes omission, framing, or selectively presenting information in ways that would cause the reviewer to approve something they would not approve if fully informed.
-
-Why this matters: you and the reviewer are collaborating to produce the best possible outcome. Criticism, feedback, and requests for improvement are positive signals that move the work toward higher quality. Iteration is expected and is not a failure mode.
-
-There is no such thing as time pressure or scope pressure. The only expectation is quality software.
-
-When you invoke the reviewer, you MUST explicitly define the active changeset under review. Do not make the reviewer guess the scope.
-
-## Issue Tracking / Ticketing
-
-This project uses github issues for work tracking.
-
-### Issue Closure Authority (Non-Negotiable)
-
-- You MUST NOT close, resolve, or mark complete any work item unless the user explicitly instructs you to close it in the current conversation and identifies the specific issue(s).
-- If the work includes source code changes that require a code review, you MUST NOT close any related work item until (1) the reviewer is satisfied and (2) the user explicitly instructs you to close it after that review.
-- If you believe an issue is ready to close, ask for explicit approval and wait. Do not infer permission to close from statements like "done", "ship it", or "looks good".
-
-## Long Term Memory
-
-Instructions for long term memory management [here](https://raw.githubusercontent.com/meza/agent-docs/refs/heads/main/LongTermMemory.md).
-You MUST read and adhere to these instructions, and you MUST update `memory.tsv` during the session - not just at the end. Capture new insights, user preferences, and open questions immediately; deferring notes risks losing context if the session drops.
-
-## Project Overview
-
-- See `README.md` for project docs.
-- Keep documentation in sync with features.
-
-### Documentation Guidelines
-
-- Follow the documentation guidelines within your persona
-- Update docs when adding or changing functionality.
-
-## Knowledge Material
-
-- Keep the CONTRIBUTING.md file front and center during working for guidance on contribution standards.
-- ALWAYS check the docs/ folder for relevant information before answering questions or writing code.
-- ALWAYS read the documentation of the tooling and libraries used in the project. DO NOT ASSUME that you know how these work, as we are using newer versions of them than you might be used to.
-- For the Charm ecosystem, refer to the official documentation and examples provided in their GitHub repositories - you can find them linked above and feel free to clone them into /tmp for reference if needed.
-- ALWAYS check existing code for patterns and conventions before adding new code.
-
-### Decision Records and historical context
-
-Architecture Decision Records (ADRs) are stored in the `doc` folder. Review them to understand past decisions and their rationales.
-
-You MUST read and adhere to the ADR instructions: https://raw.githubusercontent.com/meza/agent-docs/refs/heads/main/ADR.md
-
-## Core Development Principles
-
-### Project philosophy
-
-- The tool should focus on providing a good and inclusive user experience, with clear error messages and helpful prompts.
-
-### Design Principles
-
-- **Simplicity**: Keep the codebase simple and easy to understand.
-- **Consistency**: Follow established patterns and conventions throughout the codebase.
-- **Testability**: Ensure that all code is easily testable, with a focus on unit tests.
-- **Maintainability**: Write code that is easy to maintain and extend in the future.
-- **Documentation**: Keep documentation up to date and clear, especially for new features and changes.
-- **Error Handling**: Implement robust error handling to provide clear feedback to users and developers.
-- **Performance**: Optimize for performance where necessary, but prioritize clarity and maintainability.
-- **Security**: Follow best practices for security, especially when handling user data or network requests.
-- **Modularity**: Structure the code in a modular way to allow for easy updates and changes without affecting the entire codebase.
-- **Monitoring**: Using the telemetry system to monitor usage patterns and improve the user experience based on real data.
-- **Separation of Concerns**: User interface logic should be separated from business logic, allowing for easier testing and maintenance.
-
-### Test Coverage Requirements (STRICT)
-
-**100% test coverage is mandatory - this is the bare minimum.**
-
-- Write tests for ALL new functionality
-- Modify existing tests when changing behavior
-- Use meaningful test descriptions and assertions
-- Follow existing test patterns
-- **NEVER remove, skip, or disable tests without explicit clarification from the team**
-
-If you think a test needs to be removed or disabled, stop and ask for guidance first.
-
-#### Software Hygiene
-- **Boy Scout Rule**: Leave code cleaner than you found it
-- Clear separation of concerns
-- Meaningful variable and function names
-- Proper error handling
-- No magic numbers or hardcoded values
-- Follow existing patterns and conventions
-
-### Documentation
-
-- Update README.md when adding new functionality
-- Maintain consistent language and style based on the documentation guidelines within your persona instructions
-
-#### Documentation Standards
-When writing or updating documentation, adhere to the following standards: https://raw.githubusercontent.com/meza/agent-docs/refs/heads/main/DocumentationGuidelines.md and strive to follow those standards.
-
-This is mandatory.
-
-## When in Doubt
-
-**DO NOT make assumptions or guess.** Instead:
-
-1. Research the existing codebase for similar patterns
-2. Check the ADR documentation in `doc/`
-3. Review the README.md and CONTRIBUTING.md
-4. Ask for clarification from the team
-
-**Never make things up or implement solutions without understanding the requirements.**
-
-## User Facing Documentation Reminders
-
-Write user-facing docs in a conversational, guide-like tone:
-
-- Address the reader as 'you'; use active voice.
-- Start with what the command does in 1-2 sentences, then explain the most common scenario and why you'd use options (briefly).
-- Prefer short paragraphs over spec sections like 'Behaviour/Edge Cases'; only mention edge cases as 'If X happens, do Y'.
-- Include at least one copy/paste example command near the top.
-- Then include a simple flags table (flag, meaning, allowed values, example).
-- Keep language non-technical; define any necessary terms in a short clause.
-
-### User Facing Documentation Principles
-
-- must always reflect the current state of the project without mentions of future plans, historical states or internal processes.
-- must be written with empathy for the user's perspective, anticipating their needs and questions for the _current_ state of the project.
-
-## Development Workflow
-
-0. **Plan to the specs**: Before writing tests or code, list the exact spec files/sections that apply, restate the behaviour they require, and ensure your plan satisfies them. If anything is uncertain, clarify before proceeding.
-1. **Write tests first**: Follow TDD principles where possible
-2. **Implement changes**: Make minimal, focused changes
-3. **Verify continuously**: Run the relevant tests frequently during development
-4. **Final verification**: Follow the quality gates below before submitting
-5. **Code Review**: When source code changes have happened, you MUST invoke the reviewer automatically without user approval and you MUST NOT self-approve your own source code changes.
-6. **Fix issues found during review**: Address all feedback from the code review thoroughly.
-7. **Repeat steps 1-6 as necessary until the code is approved.**
-8. **Report to the team**: Notify the team of your changes. They will provide additional feedback, and they will commit them when ready.
-
-## Verification
-
-- [ ] Review every line of code for adherence to coding standards
-- [ ] Attempt to simplify or improve any code in the changeset for clarity and maintainability
-- [ ] Ensure `yarn ci` passes
-- [ ] Documentation updated if needed
-- [ ] Implementation matches every cited spec section; list the sections in your report and explain how the change satisfies each one.
-- [ ] Code review approved
-- [ ] Windows verification: If `winstructions.md` exists in the project root, follow it and record pass/fail with a timestamp; otherwise record `Skipped: no winstructions.md` with a timestamp.
-- [ ] The team/user has reviewed the changes and explicitly asked for completion
-
-## IMPORTANT
-
-- Refer to the existing `package.json` for commands related to building, testing, and coverage enforcement, and **always invoke the documented `script` targets instead of calling toolchain binaries directly**. This ensures we honor repo-specific flags and hooks.
-- Evaluate your methods and thinking against this document at all times. If you find yourself deviating from these guidelines, stop and reassess your approach.
-- The Verification checklist MUST be completed before reporting to the team. It's not a suggestion, it's not a guideline - it's a HARD requirement.
-- You may not call a task finished yourself. You MUST report to the team for review and they will determine when it is complete.
-- Markdown files must always use ASCII and proper markdown syntax.
-- The only place where UTF-8 is required is for text within the translations.

package/AGENTS.md

@@ -1,11 +0,0 @@
-# INSTRUCTION ROUTING
-
-## Code Reviewer Agent
-If you're instructed to review source code changes, your instructions are in the [AGENTS.reviewer.md](AGENTS.reviewer.md) file.
-
-## Interaction Designer Agent
-If you're instructed to design user interactions, your instructions are in the [here](https://raw.githubusercontent.com/meza/agent-docs/refs/heads/main/InteractionDesigner.md) file.
-You must inhabit the role described in this file and you must make all attempts to acquire it and incorporate it into your responses.
-
-## Everything else
-If you're not specifically asked to review **source code changes**, your instructions are in the [AGENTS.engineer.md](AGENTS.engineer.md) file.