RFC: Add capacity-block-and-training-plan-finder skill

[ArmaanButt]

Summary

Add a skill that finds reservable AWS accelerator capacity by scanning EC2 Capacity Block offerings (ec2:DescribeCapacityBlockOfferings) and SageMaker Training Plan offerings (sagemaker:SearchTrainingPlanOfferings) across regions and instance types for a given count, duration, and start date. It fans out region×instance-type lookups in parallel, isolates per-region errors, falls back to halved count/duration when nothing is found, and returns available offerings (region, AZ, start/end dates, upfront fee, number of parts) as a ranked table.

It is derived from an existing working AWS sample — a single-file Streamlit app (sample-capacity-finder-for-ec2-capacity-block-and-sagemaker-training-plan) — repackaged as an agent-invokable skill.

Motivation

Startups training and fine-tuning models depend on scarce GPU/Trainium capacity (P4/P5/P6, Trn1/Trn2). Finding it today means clicking through the console region-by-region across two "find 8× p5.48xlarge for 14 days starting next Monday" in one natural-language step — read-only, across all supported regions at once — which fits the startups audience racing to secure training capacity.

Proposed Solution

• A SKILL.md plus a small Streamlit-free Python helper that reuses the two boto3 calls.
• Inputs: instance types, instance count, regions (or "all"), duration in days (mapped to hours), start date, optional end date.
• Parallel scan via a bounded thread pool, per-region error isolation, and an automatic halved-parameter fallback when the initial search returns nothing.
• Strictly read-only IAM: ec2:DescribeCapacityBlockOfferings, sagemaker:SearchTrainingPlanOfferings.
• Output as a table, with optional structured JSON for chaining (see Open Questions).

Alternatives Considered

• Keep it only as the standalone Streamlit app — great for humans, but not invokable as an agent skill and not distributable through this marketplace.
• New dedicated plugin vs. folding into an existing plugin (e.g. aws-dev-toolkit) — either works; deferring the routing decision to maintainers (see Open Questions).

Open Questions

• Which plugin should host this skill — an existing one such as aws-dev-toolkit (solution-architecture/), or a new standalone plugin with its own marketplace.jsonentry? Which team folder and CODEOWNERS should own it?
• Should output be a table only, or also emit structured JSON so results can be piped into downstream automation (e.g. a follow-on reservation step)?
• How should the supported instance-type and region lists be maintained over time?

Drawbacks

• The offerings APIs evolve and their results vary by account entitlement, so responses can be empty or misleading without context — the skill must explain this.
• The instance-type and region lists need occasional maintenance as new hardware launches.

[rsmets]

Thanks, well-scoped RFC; GPU/Trainium capacity discovery is a real pain point!

On implementation: consider the reference approach, same split I suggested for bq-assess (Issue #132 and PR #139 ). Rather than vendoring a Python helper, either reference the existing AWS sample project for the tool, or have the skill call the AWS CLI directly (aws ec2 describe-capacity-block-offerings, aws sagemaker search-training-plan-offerings). Both are read-only, so the CLI covers it without bundling boto3 code.