ワンクリックでManusで任意のスキルを実行

aspire-launch

スター5

フォーク0

更新日2026年5月23日 08:41

Start and stop CoreBankDemo AppHosts using the Aspire CLI. **When to use:** - When you need to start, stop, or wait for health of CoreBankDemo AppHosts using the Aspire CLI. - When you want to ensure services are running and healthy before interacting with APIs or running tests. **When NOT to use:** - Do NOT use for starting individual services outside of AppHosts. - Do NOT use `dotnet run` or `sleep` for orchestration or health checks—always use the Aspire CLI commands as described. - Do NOT use for inspecting logs, traces, or resource state—use the aspire-mcp skill for those tasks.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

loekd

loekd/CoreBankDemo

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

AppHosts

AppHost	Project path
Regular dev	`CoreBankDemo.AppHost/CoreBankDemo.AppHost.csproj`
Load testing	`CoreBankDemo.LoadTests/CoreBankDemo.LoadTests.csproj`

Start

aspire start --apphost <project-path> --non-interactive

Use --isolated in worktrees or shared environments.

Wait for healthy

After starting, use aspire wait to block until a resource is healthy:

aspire wait <resource-name> --non-interactive

Example:

aspire start --apphost CoreBankDemo.LoadTests/CoreBankDemo.LoadTests.csproj --non-interactive
aspire wait loadtest-support --non-interactive

Do NOT use sleep to wait for services — always use aspire wait.

Stop

aspire stop --apphost <project-path> --non-interactive

Force kill (stuck processes)

If the AppHost is stuck or aspire stop doesn't work, kill DCP (the Aspire orchestrator):

killall dcp

Rules

Never use dotnet run to start AppHosts — use aspire start.
Always specify --apphost — this repo has two AppHosts.
Always use aspire wait <resource> before probing APIs or running assertions.
Never use sleep to wait for health — use aspire wait.

このリポジトリの他の Skills

同じリポジトリ

corebank-trace-analysis

loekd/CoreBankDemo

Analyze OpenTelemetry traces after a CoreBankDemo load test to identify performance issues and errors. **When to use:** - After a load test completes (or fails), to investigate what happened at the infrastructure level - When `get_assertion_results` returns failures and you need to understand why - When you want to find slow spans, high-latency payment flows, or exceptions during a test run - When asked to analyze Jaeger traces, spans, or distributed tracing data for CoreBank or Payments **When NOT to use:** - For business-level assertions (exactly-once, balance conservation) — use LoadTestSupport MCP tools instead - Before the load test has run — there will be no relevant traces - For general .NET debugging unrelated to load testing

2026-06-025

load-test

loekd/CoreBankDemo

Run a full CoreBankDemo load test, wait for drain, and assert results via the LoadTestSupport API. **When to use:** - When you want to run a complete end-to-end load test of CoreBankDemo, including reset, execution, drain, and assertion, via the LoadTestSupport MCP API. - When you need to validate system resilience, idempotency, and correctness under load. **When NOT to use:** - Do NOT use for unit testing, manual, ad-hoc, or partial testing of individual services. - Do NOT use if you only want to run k6 or inspect a single component—use the relevant skill or tool instead. - Do NOT use the Aspire MCP CLI for these endpoints (see warning below).

2026-06-025

aspire-mcp

loekd/CoreBankDemo

Use Aspire MCP tools to inspect resource state, logs, and traces in CoreBankDemo. **When to use:** - When an AppHost is already running. - When you need to inspect the state, logs, or distributed traces of resources managed by an Aspire AppHost in CoreBankDemo. - When you want to use Aspire CLI or MCP tools to diagnose, monitor, or interact with running services. **When NOT to use:** - Do NOT use if no AppHost is running (start one with the aspire-launch skill first). - Do NOT use for direct database inspection, application-level debugging, or for actions outside the scope of Aspire-managed resources. - Do NOT use for running or stopping AppHosts themselves—use the aspire-launch skill for that purpose.

2026-05-235

conventions

loekd/CoreBankDemo

Coding conventions for CoreBankDemo: database, time, HTTP/business logic separation, validation, and logging. **When to use:** - When writing or reviewing code for CoreBankDemo to ensure consistency in database usage, time handling, controller/business logic separation, validation, and logging. - When you need to check or enforce project-wide coding standards. **When NOT to use:** - Do NOT use for framework-agnostic or non-CoreBankDemo projects. - Do NOT use for runtime troubleshooting or debugging—use the relevant skills for those tasks.

2026-05-235

messaging-patterns

loekd/CoreBankDemo

Inbox/Outbox implementation rules, MessageConstants usage, and partition assignment for CoreBankDemo. **When to use:** - When implementing or reviewing Inbox/Outbox processors in CoreBankDemo. - When you need to ensure correct usage of MessageConstants or partition assignment logic. **When NOT to use:** - Do NOT use for messaging patterns outside CoreBankDemo or for unrelated architectures. - Do NOT use for ad-hoc message handling that does not use the provided base classes.

2026-05-235

observability

loekd/CoreBankDemo

OpenTelemetry tracing rules for CoreBankDemo: ActivitySource registration, span creation, and trace context propagation. **When to use:** - When adding or reviewing tracing, ActivitySource, or span logic in CoreBankDemo. - When ensuring trace context propagation and distributed tracing best practices are followed. **When NOT to use:** - Do NOT use for tracing unrelated to CoreBankDemo or for non-OpenTelemetry tracing systems. - Do NOT use for runtime log inspection or debugging—use the aspire-mcp skill for those tasks.

2026-05-235

name

aspire-launch

description

AppHosts

AppHost	Project path
Regular dev	`CoreBankDemo.AppHost/CoreBankDemo.AppHost.csproj`
Load testing	`CoreBankDemo.LoadTests/CoreBankDemo.LoadTests.csproj`

Start

aspire start --apphost <project-path> --non-interactive

Use --isolated in worktrees or shared environments.

Wait for healthy

After starting, use aspire wait to block until a resource is healthy:

aspire wait <resource-name> --non-interactive

Example:

aspire start --apphost CoreBankDemo.LoadTests/CoreBankDemo.LoadTests.csproj --non-interactive
aspire wait loadtest-support --non-interactive

Do NOT use sleep to wait for services — always use aspire wait.

Stop

aspire stop --apphost <project-path> --non-interactive

Force kill (stuck processes)

If the AppHost is stuck or aspire stop doesn't work, kill DCP (the Aspire orchestrator):

killall dcp

Rules

Never use dotnet run to start AppHosts — use aspire start.
Always specify --apphost — this repo has two AppHosts.
Always use aspire wait <resource> before probing APIs or running assertions.
Never use sleep to wait for health — use aspire wait.