mcp-server-gmail-send: Instructions file for GitHub Copilot

Copilot / Assistant instructions for this repository

Purpose:

• Provide canonical guidance for AI assistants (GitHub Copilot, Copilot-for-Business, or other automated agents) when generating or modifying code in this repository.

Important: This file is an advisory convention for AI assistants and humans. It does not change runtime behavior or engine logic.

---

Editable by automated tools

• Allowed: repository root skill files (e.g., gmail_send_skill.py, ldr_compat.py), tests/ (unit tests), and documentation files (README, Skill.md) in the repository root.
• Disallowed: creating new top-level directories (for automated changes). Do not create skills/ or other new top-level folders without explicit human approval.
• Disallowed: config/, workflow_params.yaml, any files under secrets/, and any *_config.yaml or JSON files that contain credentials.

If an automated change would touch a disallowed file or would create new top-level directories, open an issue and request human review instead of making the change.

Style & Quality

• Follow existing project style (PEP8 for Python). Prefer adding type hints for public APIs.
• Keep changes minimal and focused; avoid reformatting unrelated files.
• Add/update unit tests for any behavioral change (happy path + 1 edge case if possible).
• If a skill's public API changes, update its mcp_config.json / *_config.json and README under skills/<skill>/.

Python quality rules

• Code style: follow PEP8. Use an automatic formatter (Black) for consistent formatting where possible.
• Linting: use ruff or flake8 to catch common issues. Autofix where safe (e.g., ruff --fix).
• Typing: prefer adding type annotations for public functions and methods. Run mypy (or ruff --select RUF001 if configured) on changed modules if available.
• Docstrings: public modules, classes and functions should have a short docstring describing purpose, inputs and outputs.
• Tests: add or update unit tests when changing behavior. Aim for at least a minimal test for the changed code (happy path + one edge case).
• Coverage: there is no hard global requirement, but changes to core modules should include tests that exercise new behavior; maintainers may request additional coverage for critical paths.
• Pre-commit checks: if the repository uses pre-commit, ensure new commits pass the configured hooks.
• Commands to run locally before committing changes (recommended):
  • pytest -q
  • ruff . --fix (or flake8 . if ruff is not available)
  • black . --check (or black . to reformat)
  • mypy . (optional, if mypy is used in this repo)