Add GitHub Copilot instructions for msticpy coding standards

[Copilot]

Establishes coding conventions and workflow guidance for GitHub Copilot to provide context-aware suggestions aligned with the project's standards.

Changes

• Added .github/copilot-instructions.md with:
  • Python standards: Built-in types for annotations (list[str] vs List[str]), numpy-style docstrings, 93-char line limit
  • Coding patterns: pathlib.Path over open(), %s-style logging over f-strings, top-level imports only
  • Testing: pytest with respx for httpx mocking, 85% coverage target, "[PLACEHOLDER]" for test secrets
  • Quality tooling: pre-commit, ruff, mypy workflows

This enables Copilot to generate code matching existing patterns without requiring manual post-generation fixes.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>✨ Set up Copilot instructions</issue_title>
<issue_description>### Package Structure

• Package name: msticpy (in msticpy)
• Import pattern: import msticpy as mp
• Source: msticpy contains implementation modules
• Tests: tests/ with pytest markers: unit, integration, slow
• Tools: tools/ supplementary tools not core to the package
• Documentate: docs - sphinx source files and notebooks

Code Conventions

Python Standards (Enforced by Ruff)

• Line length: 93 characters
• Type hints: Required (enforced by mypy, annotations checked)
  Always use built-in types like list, dict, for type annotations and avoid use types from typing.
  E.g. use list[str] instead of List[str], str | None instead of Optional[str].
• Docstrings: Required for public functions (D-series rules) - use numpy style.
  Document parameters, return type and exceptions raised for public functions/methods.
  • Single-line: Keep on same line as triple quotes: """Return the user name."""
  • Multi-line: Summary starts on new line after opening quotes, blank line before
    Parameters/Returns sections, blank line before closing quotes:

    def example(name: str) -> str:
        """
        Return a greeting for the given name.
    
        Parameters
        ----------
        name : str
            The name to greet.
    
        Returns
        -------
        str
            The greeting message.
    
        """

• Imports and Formatting: Sorted/grouped automatically (isort)

General Coding style

• Avoid using Python built-in open function for file operations. Use pathlib.Path
  methods instead. Prefer Path.* methods over legacy os.* methods
• Logging - create a logger per module `logger = logging.getLogger(name)
  When adding logging calls, use %s, %d style variable substitution rather than
  f-strings.
• Never use inline import statements. Always place imports at the top of the file
  (there are some exceptional cases where conditional imports are used but, these
  should also be at the top of the file, before the main code).
• When generating code, be careful with indentation - always replace lines using the
  same indentation unless introducing branches, etc.
• Try to avoid a line length of over 90 characters - thia applies to code, docstrings,
  comments and suppressions

Testing

Test Creation

• Always use pytest and generate pytest-style test functions.
• If you need to mock httpx requests, use the respx library.
• Test file modules should mirror the name/path of the tested module, e.g.
  dtxn_quality/path/module.py → tests/path/test_module.py
• Always add at least a single-line docstring to fixtures and test functions.
  If the context of the parameters is not obvious, explain them in the docstring.
• Unit test coverage should be >= 85% on new code.
• Test "secrets" - if you need to mock a secret value (password, key, etc.), always use
  the value "[PLACEHOLDER]" as the value of the secret.

Running Tests

pytest                           # All tests
pytest --cov=msticpy --cov-report=html

Code Quality Tools

Always run pre-commit before creating a PR
Always run mypy before creating a PR

Pre-commit Hooks

This project uses pre-commit for automated code quality checks. Install and enable:

pip install pre-commit
pre-commit install

Run manually on all files:

pre-commit run --all-files

Running Linters Manually

ruff check src --fix              # Lint and auto-fix
ruff format src                   # Format code
mypy src/dtxn_quality             # Type checking

Important: When running mypy, always run it to get the full output. It is slow, so
avoid preliminary runs to find error counts - run it once completely.

When Generating New Python Code

ALWAYS run pre-commit or equivalent checks after generating new Python code:

pre-commit run --all-files
# Or manually:
ruff check src --fix && ruff format src && mypy msticpy

Fix any errors before committing. Do not leave Ruff or mypy errors in generated code.

Commit Guidelines

• Write clear, descriptive commit messages
• Always run pre-commit hooks (or linters manually) before committing</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes ✨ Set up Copilot instructions #875

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.