Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
中文简介正在准备中。当前显示原文说明。
Configures health check endpoints for Kubernetes readiness/liveness/startup
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Type: L3 Worker Category: 7XX Project Bootstrap Parent: ln-770-crosscutting-setup
Configures health check endpoints for Kubernetes probes and monitoring.
| Aspect | Details |
|---|---|
| Input | Context Store from ln-770 |
| Output | Health check endpoints and Kubernetes probe configuration |
| Stacks | .NET (AspNetCore.Diagnostics.HealthChecks), Python (FastAPI routes) |
Accept Context Store and scan for dependencies to monitor.
Required Context:
STACK: .NET or PythonPROJECT_ROOT: Project directory pathIdempotency Check:
AddHealthChecks or MapHealthChecks/health route{ "status": "skipped" }Dependency Detection:
| Dependency | .NET Detection | Python Detection |
|---|---|---|
| PostgreSQL | Npgsql in csproj | psycopg2 or asyncpg in requirements |
| MySQL | MySql.Data in csproj | mysql-connector-python in requirements |
| Redis | StackExchange.Redis in csproj | redis in requirements |
| RabbitMQ | RabbitMQ.Client in csproj | pika or aio-pika in requirements |
| MongoDB | MongoDB.Driver in csproj | pymongo in requirements |
Define three types of health endpoints per Kubernetes best practices.
| Endpoint | Probe Type | Purpose | Checks |
|---|---|---|---|
/health/live | Liveness | Is app alive? | App responds (no dependency checks) |
/health/ready | Readiness | Can app serve traffic? | All dependencies healthy |
/health/startup | Startup (K8s 1.16+) | Is app initialized? | Initial warmup complete |
| Probe | Failure Action | Kubernetes Behavior |
|---|---|---|
| Liveness | Container restart | kubelet restarts container |
| Readiness | Remove from service | Traffic stopped, no restart |
| Startup | Delay other probes | Liveness/Readiness paused |
Use MCP tools for current documentation.
For .NET:
MCP ref: "ASP.NET Core health checks Kubernetes probes"
Context7: /dotnet/aspnetcore
For Python:
MCP ref: "FastAPI health check endpoint Kubernetes"
Context7: /tiangolo/fastapi
Key Patterns to Research:
Determine probe timing based on application characteristics.
| Parameter | Liveness | Readiness | Startup |
|---|---|---|---|
initialDelaySeconds | 10 | 5 | 0 |
periodSeconds | 10 | 5 | 5 |
timeoutSeconds | 5 | 3 | 3 |
failureThreshold | 3 | 3 | 30 |
successThreshold | 1 | 1 | 1 |
Startup Probe Calculation:
Max startup time = initialDelaySeconds + (periodSeconds × failureThreshold)
Default: 0 + (5 × 30) = 150 seconds
| File | Purpose |
|---|---|
Extensions/HealthCheckExtensions.cs | Health check registration |
HealthChecks/StartupHealthCheck.cs | Custom startup check |
Generation Process:
Packages to Add:
AspNetCore.HealthChecks.NpgSql (if PostgreSQL)AspNetCore.HealthChecks.Redis (if Redis)AspNetCore.HealthChecks.MySql (if MySQL)Registration Code:
builder.Services.AddHealthCheckServices(builder.Configuration);
// ...
app.MapHealthCheckEndpoints();
| File | Purpose |
|---|---|
routes/health.py | Health check router |
services/health_checker.py | Dependency health checks |
Generation Process:
Registration Code:
from routes.health import health_router
app.include_router(health_router)
Generate for inclusion in deployment.yaml:
livenessProbe:
httpGet:
path: /health/live
port: 5000
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /health/ready
port: 5000
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3
startupProbe:
httpGet:
path: /health/startup
port: 5000
periodSeconds: 5
failureThreshold: 30
Validation Steps:
Syntax check:
dotnet build --no-restorepython -m py_compile routes/health.pyEndpoint test:
curl http://localhost:5000/health/live
curl http://localhost:5000/health/ready
curl http://localhost:5000/health/startup
Verify response format:
{
"status": "Healthy",
"checks": {
"database": { "status": "Healthy", "duration": "00:00:00.0234" },
"redis": { "status": "Healthy", "duration": "00:00:00.0012" }
},
"totalDuration": "00:00:00.0250"
}
Dependency failure test:
/health/ready returns 503/health/live still returns 200{
"status": "success",
"files_created": [
"Extensions/HealthCheckExtensions.cs",
"HealthChecks/StartupHealthCheck.cs"
],
"packages_added": [
"AspNetCore.HealthChecks.NpgSql"
],
"registration_code": "builder.Services.AddHealthCheckServices(configuration);",
"message": "Configured health checks with liveness, readiness, and startup probes"
}
/health/live, /health/ready, /health/startup per Kubernetes best practicesAddHealthChecks/MapHealthChecks or /health route exists, return status: "skipped"dotnet build or py_compile)Version: 2.0.0 Last Updated: 2026-01-10
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
中文简介正在准备中。当前显示原文说明。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
中文简介正在准备中。当前显示原文说明。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
中文简介正在准备中。当前显示原文说明。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
中文简介正在准备中。当前显示原文说明。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
中文简介正在准备中。当前显示原文说明。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
中文简介正在准备中。当前显示原文说明。