feat: project rules mapping

[eduwass]

Summary

Add project-scope rules support by introducing a shared canonical rules directory: .agents/rules.

When running dotagents in project scope, it now symlinks .agents/rules into each supported tool’s project rules location:

• .agents/rules → .claude/rules
• .agents/rules → .cursor/rules
• .agents/rules → .github/instructions (GitHub Copilot path-scoped instructions)

Related Post:
https://paddo.dev/blog/claude-rules-path-specific-native/

Why

Many tools now support folder-based, path-scoped rules. This change lets you:

• keep rules in one place (.agents/rules)
• reuse/share them across multiple agents/tools
• stay consistent with dotagents’ project-scope behavior (only affects the repo you run it in)

What Changed

• Add a new rules mapping in project scope (src/core/mappings.ts)
• Expand README project-scope “Where it links” section to list mappings explicitly (README.md)
• Add coverage to ensure project-scope rules links are created (tests/linking.test.ts)

Behavior / Safety

• Project scope only: does not touch ~/.claude, ~/.cursor, etc.
• Still does not link instruction files (AGENTS.md / CLAUDE.md / GEMINI.md) in project scope.

Notes / Limitations

• Tools use different rule formats. Keeping a shared .agents/rules folder is convenient, but you may need tool-specific files for path targeting:
  • Claude rules are typically Markdown with YAML frontmatter like paths: src/api/**/*.ts (you can verify what’s active via /memory in Claude Code).
  • Cursor rules are typically .mdc files with fields like globs.
  • GitHub Copilot’s .github/instructions expects *.instructions.md files with frontmatter like applyTo.
• A practical approach is to colocate multiple formats side-by-side (e.g. backend.md, backend.mdc, backend.instructions.md) and let each tool ignore what it doesn’t understand.

Testing

Adds a basic test covering the new rules symlinks (tests/linking.test.ts)

• bun test