RFC: Help teams choose the right Claude access path

## Summary

I’d like to add a small, agent-friendly skill that helps startup teams choose among the Anthropic API, Claude Platform on AWS, and Claude on Amazon Bedrock. The skill would turn a team’s operating constraints into a first-pass recommendation and the smallest useful test to run next.

This is one layer of a two-part artifact. The deeper customer-runnable Notebook/CLI lab is following the separate AWS process for a standalone `awslabs` repository. This RFC is only for the lightweight skill that makes the decision workflow discoverable inside the tools founders already use and can later point to the full lab once that repository is public.

## Motivation

“Where should we use Claude?” sounds like a product comparison, but the answer usually depends on operating requirements: who must run inference, whether private networking is required, which identity and audit controls matter, whether Anthropic-native tools are essential, and whether the team also needs other model providers.

The relevant documentation exists, but it is spread across product pages and does not give a team a repeatable way to work through those trade-offs. People often build their own spreadsheet or discover an important gap after a prototype is already underway.

A focused skill can improve that first conversation without pretending there is one universally correct answer. The separate lab can provide deeper, customer-run validation without making the skill itself large or credential-dependent.

## Proposed Solution

Add a focused `claude-platform-evaluation` skill with a small set of public-source references.

The skill would:

- accept either a free-form situation description or a short guided intake
- separate must-haves, preferences, acceptable alternatives, and unknowns
- compare the three access paths without silently falling back to another provider
- identify where an Anthropic-native capability is unavailable and describe relevant AWS-native or gateway alternatives without claiming they are equivalent
- use public, dated sources for capability claims
- remain offline by default and never ask a user to paste credentials
- finish with a recommendation, unresolved risks, and the smallest test that could change the decision
- link to the standalone customer-runnable lab after that repository completes the AWS open-source release process

The first contribution should stay deliberately thin: `SKILL.md`, decision references, and representative synthetic scenarios. The Notebook, CLI, live probes, schemas, and generated reports remain in the standalone project rather than being copied into this monorepo.

This is narrower than `agent-advisor`, which helps with agent architecture and runtime decisions, and different from `llm-to-bedrock`, which migrates an existing codebase to Bedrock. This proposal is about choosing the Claude access path before those later decisions or migrations.

## Alternatives Considered

Publishing only the standalone lab would provide the deepest hands-on experience, but it would be less discoverable when a founder or engineer first asks the platform question inside an AI coding tool.

Putting the complete lab into this monorepo would duplicate release concerns and make the plugin unnecessarily heavy. Keeping a thin skill here and the executable lab in its own repository gives each artifact a clear role.

A static comparison table is easier to publish, but it becomes stale quickly and does not distinguish hard requirements from preferences or unresolved assumptions.

## Open Questions

- Does the thin skill fit better in AWS Startup Advisor or the Solution Architecture plugin under the current contribution boundaries?
- Is the boundary with `agent-advisor`, `llm-to-bedrock`, and Agent Toolkit for AWS clear enough?
- Should the first version remain guidance-only until the standalone lab is public?
- Once the standalone repository is available, what is the preferred way for a skill in this monorepo to reference or invoke it?

## Drawbacks

Capabilities and documentation change, so references need freshness dates and periodic review. A short decision workflow can also oversimplify company-specific security, procurement, support, and compliance requirements, so its recommendation must remain a starting point for validation rather than an approval to deploy.

The two-artifact approach also creates coordination work: the skill must not promise lab behavior or a repository URL until the standalone project is actually approved and public.

Start by reading the proposed boundaries for the `claude-platform-evaluation` skill and comparing them with `agent-advisor`, `llm-to-bedrock`, and the AWS Startup Advisor and Solution Architecture plugins. The mentioned deliverables are `SKILL.md`, decision references, and representative synthetic scenarios; completion requires resolving the open placement and scope questions without adding the standalone Notebook or CLI lab.

Written by the indexing model from the issue text.