feat(amazon-location-service): Added Amazon Location Service plugin

[cgalvan]

feat: Add amazon-location-service plugin

Adds a new plugin that guides developers through adding geospatial features to their applications using Amazon Location Service. The skill auto-triggers when users ask about maps, geocoding, routing, places search, or other location-related functionality.

Resolves #55

Plugin overview

The amazon-location-service plugin helps developers integrate:

• Maps (dynamic tiles with MapLibre, static map images)
• Places search (autocomplete, text search, nearby search)
• Geocoding (forward and reverse)
• Routing (turn-by-turn directions, route matrices)
• Address verification and validation
• Authentication setup (API keys, Cognito)
• SDK integration and best practices

Plugin structure

plugins/amazon-location-service/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
└── skills/
    └── amazon-location-service/
        ├── SKILL.md
        └── references/
            ├── address-input.md
            ├── address-verification.md
            ├── calculate-routes.md
            ├── dynamic-map.md
            ├── places-search.md
            └── web-javascript.md

Changes outside the plugin directory

• .claude-plugin/marketplace.json — registered the new plugin
• README.md — added plugin to the listing table, install examples, and a plugin section
• AGENTS.md — updated TL;DR, directory structure, and MCP servers section
• .github/copilot-instructions.md — updated project overview
• docs/MAINTAINERS_GUIDE.md — added plugin team to the table
• docs/DESIGN_GUIDELINES.md — added as a good plugin scope example

Also added a note to AGENTS.md that CLAUDE.md is a symlink, so future contributors only edit one file.

Testing

Ran mise run build — all checks passed (markdown linting, manifest validation, cross-references, formatting, and security scans). Also tested by locally installing the plugin and verifying that Claude can activate the skill appropriately.

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[krokoko]

Hi, could you please open an RFC and link it to this pull request ? Thank you

[cgalvan]

Hi, could you please open an RFC and link it to this pull request ? Thank you

Yes! I've created the RFC #55 and have linked it to this PR

[krokoko]

Thank you @cgalvan !

I am wondering if it would make sense to split some files:

File	Lines	Assessment
address-input.md	281	Should split into API reference + code examples
address-verification.md	544	Should split into basic verification, batch flows, storage/pricing
calculate-routes.md	1,419	By far the largest. Should split into basic routing, map display, FlexiblePolyline, travel modes, waypoints, etc.
dynamic-map.md	348	Should split into setup, styles, advanced features
places-search.md	532	Should split into SearchText, SearchNearby, Suggest as separate files
web-javascript.md	503	Should split into authentication, client usage, error handling

For instance, the calculate-routes.md at 1,419 lines is essentially a complete developer guide. It includes exhaustive sections on Simple vs FlexiblePolyline format selection (with a hybrid strategy class, decision matrix, 6 use cases per format) that reads more like human-facing documentation than agent-optimized instructions.

[krokoko]

Also, for the skill description, you should include trigger phrases (map to user intent)

something like

description: |
  Integrates maps, geocoding, routing, places search, geofencing, and tracking
  via Amazon Location Service APIs. Triggers when user says: "add a map",
  "geocode an address", "calculate a route", "find nearby places",
  "add geospatial features", "Amazon Location Service", "MapLibre map".
  Use for location-aware web/mobile applications on AWS.

[krokoko]

The guidelines recommend explicit defaults with override syntax. The SKILL.md has recommendations scattered through the content (prefer bundled JS client, prefer resourceless operations, API Key for Maps/Places/Routes, Cognito for Geofencing/Tracking) but no consolidated "Defaults" section.

Recommendation: Add a clear defaults block:

## Defaults

- **JavaScript SDK**: Bundled client (@aws/amazon-location-client) for web development
- **API operations**: Resourceless (no pre-created AWS resources needed)
- **Authentication**: API Key for Maps/Places/Routes; Cognito for Geofencing/Tracking
- **Map style**: Standard
- **Coordinate format**: [longitude, latitude] (GeoJSON order)

Override: User can specify "use Cognito", "use modular SDK", or "use resource-based operations".

[krokoko]

The actual content quality of the reference files is strong

• API selection guidance is clear and decision-oriented
• Common mistakes section in SKILL.md is valuable and specific
• Code examples are well-structured with error handling
• Authentication guidance covers all methods with clear "when to use" guidance
• The pricing/storage considerations in address-verification.md are helpful

[cgalvan]

Thanks for the detailed feedback @krokoko! I really appreciate the thorough review.

I completely agree with adding explicit trigger phrases to the description and a consolidated "## Defaults" section to SKILL.md. Those are great suggestions and I'll make those changes.

Regarding the reference file size guidance - I actually used the skill-creator skill to evaluate this plugin after writing initial drafts, and it originally told me the reference files were too small and needed to be more comprehensive (it suggested expanding them to provide enough context for Claude to work effectively). The skill-creator uses progressive disclosure - Claude only loads reference files when needed, so they can be quite large. It recommends adding table of contents for files >300 lines, which I did.

However, I completely understand your point about the writing style being too human-documentation-like rather than agent-optimized. That's the real issue, not just the line count.

I did some initial testing with making the files more concise, and I saw some degradation in my benchmark performance. Additionally, Claude was no longer able to one-shot some of my ad-hoc testing prompts. This makes me a bit hesitant to change the structure too much before getting this initial release out.

For this release, I'd like to keep the structure as-is but I'm happy to work with you on making the content more concise and agent-optimized where needed.

For future iterations, I'd love to align on the best approach (split vs. consolidated files) and test it together to see what works best for Claude in practice. Would you be open to iterating on improvements after this initial release?

Thanks again for the great feedback on content quality - I want to make sure we maintain that while optimizing for agent use.

[krokoko]

Thank you ! I'm fine to keep it as is, was just worried about the file size but if you see a degradation with your benchmark, we can revisit that later