[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-aws-labs-hyperpod-devops-agent-solution":3,"mdc--gagrnl-key":51,"related-repo-aws-labs-hyperpod-devops-agent-solution":465,"related-org-aws-labs-hyperpod-devops-agent-solution":503},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":29,"repoUrl":30,"updatedAt":31,"license":32,"forks":33,"topics":34,"repo":46,"sourceUrl":49,"mdContent":50},"hyperpod-devops-agent-solution","monitor SageMaker HyperPod infrastructure","How this Agent Space monitors SageMaker HyperPod — the design and intent of the HyperPod x DevOps Agent solution (event-driven webhook bridge, Lambda-gated periodic audit, triage\u002FRCA skills, email notifications). Read this to understand WHY a HyperPod investigation was created and what the monitoring pipeline does. For the concrete resource\u002Ftopology map (ARNs, IDs, log groups), see the understanding-agent-space skill instead.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},"aws-labs","AWS Labs","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Faws-labs.png","awslabs",[13,17,20,23,26],{"name":14,"slug":15,"type":16},"Observability","observability","tag",{"name":18,"slug":19,"type":16},"DevOps","devops",{"name":21,"slug":22,"type":16},"Monitoring","monitoring",{"name":24,"slug":25,"type":16},"Agents","agents",{"name":27,"slug":28,"type":16},"AWS","aws",472,"https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fawsome-distributed-ai","2026-09-02T07:47:35.452244",null,206,[28,35,36,37,38,39,40,41,42,43,44,45],"distributed-inference","distributed-training","efa","eks","generative-ai","gpu","hyperpod","kubernetes","parallelcluster","physical-ai","slurm",{"repoUrl":30,"stars":29,"forks":33,"topics":47,"description":48},[28,35,36,37,38,39,40,41,42,43,44,45],"Collection of best practices, reference architectures, model training examples and utilities to train large models on AWS. ","https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fawsome-distributed-ai\u002Ftree\u002FHEAD\u002Farchitectures\u002Fsagemaker-hyperpod-slurm\u002Ftools\u002Fdevops-agent\u002Fskills\u002Fhyperpod-devops-agent-solution","---\nname: hyperpod-devops-agent-solution\ndescription: How this Agent Space monitors SageMaker HyperPod — the design and intent of the HyperPod x DevOps Agent solution (event-driven webhook bridge, Lambda-gated periodic audit, triage\u002FRCA skills, email notifications). Read this to understand WHY a HyperPod investigation was created and what the monitoring pipeline does. For the concrete resource\u002Ftopology map (ARNs, IDs, log groups), see the understanding-agent-space skill instead.\nmetadata:\n  version: \"1.0.0\"\n  agent_types: [\"GENERIC\"]\n---\n\n# HyperPod x DevOps Agent — how this solution monitors the cluster\n\nThis Agent Space is wired to monitor one or more **SageMaker HyperPod**\nclusters. This document explains the **design and intent** of that\nmonitoring so investigations reason correctly and operators (via chat)\ncan understand how their cluster is watched.\n\n> Scope: this is the *how it works* doc. For the concrete resource map\n> (what exists, ARNs, instance IDs, log groups, VPC\u002Fsubnet\u002FSG IDs), use\n> the `understanding-agent-space` skill.\n\n## Two independent detection paths\n\nHyperPod problems reach DevOps Agent through **two** paths, by design:\n\n1. **Event-driven webhook bridge (all HyperPod control-plane faults).**\n   A Lambda subscribes to `aws.sagemaker` HyperPod EventBridge events\n   (Cluster State Change, Node Health, Cluster Event), drops routine\n   `Info`-level noise, and HMAC-POSTs the rest to the DevOps Agent\n   generic webhook — which creates an investigation. This is how node\n   health faults, capacity errors, lifecycle-script failures, and\n   cluster state changes are detected, on **both EKS and Slurm**\n   (Slurm requires Continuous Provisioning for the correct event shape).\n\n2. **Periodic-audit Lambda (Kubernetes state only).**\n   Some conditions are NOT in the HyperPod event stream — notably\n   Kubernetes **CrashLoopBackOff** pods and **NotReady** nodes. A\n   scheduled Lambda inspects those via the EKS API and **only invokes an\n   investigation when a real issue is present** (thresholds are\n   configurable). On a healthy cluster it posts nothing. On **Slurm**\n   there is no Kubernetes to inspect, so this path does nothing except\n   the heartbeat below.\n\n**Implication for investigations:** if you are investigating a\n\"HyperPod periodic audit\" task, the audit Lambda already detected a\nconcrete issue (or a control-plane fault arrived via the bridge). Treat\nthe reported issue as real and **confirm + explain it — don't assume it\nwas a routine poll**. The Lambda inlines what it found into the task\n`description` string (one `- [tag] type on resource: detail` line per\nissue) — the DevOps Agent platform preserves the top-level `description`\nverbatim but flattens nested payload sub-objects, so the description\ntext, not a `data.metadata.*` field, is where the skill reads the\nfindings.\n\n## Daily heartbeat (liveness)\n\nOnce per day the audit Lambda fires a **heartbeat**. Its purpose is\n**pipeline liveness** — letting operators confirm the solution itself is\nalive and reaching the console — not incident detection (the 15-minute\naudit and the event-driven bridge do that). Do not treat a heartbeat as\nan incident.\n\nThe heartbeat run still inspects cluster state:\n\n- **Healthy cluster (the usual case):** an \"all clear, no open issues\"\n  heartbeat — a **silent liveness signal**, visible in the console but\n  never emailed. Triage skips it (nothing to investigate); the skipped\n  task is itself the liveness signal.\n- **A real issue exists at heartbeat time:** the Lambda builds an\n  *issues* payload instead, which is triaged and root-caused like any\n  detection and **can email**.\n\n## Triage → RCA → notification\n\n- **Triage** (`hyperpod-incident-triage`, INCIDENT_TRIAGE) decides\n  LINK \u002F SKIP \u002F PROCEED. It keeps *different* fault types on the *same*\n  instance group as separate investigations (the default correlator\n  would merge them) and skips concurrent periodic audits.\n- **RCA** (`hyperpod-incident-rca`, INCIDENT_RCA) runs on PROCEED:\n  reconstructs the timeline from `list-cluster-events`, cluster\u002Fnode\n  state, and HMA CloudWatch streams; classifies as\n  **Suppress \u002F Monitor \u002F Escalate \u002F Resolved**; and writes a verdict\n  with a plain-English **Summary** (what happened → likely cause →\n  recommended action).\n- **Email notifier** sends one SES email per completed investigation\n  (scoped to this Agent Space). It suppresses `Suppress` verdicts,\n  no-finding investigations, and heartbeats, and leads the subject with\n  the Summary's first sentence.\n\n## What this solution does NOT do\n\n- It does **not** poll for HyperPod control-plane faults — those are\n  event-driven via the bridge. The audit only covers Kubernetes state.\n- The DevOps Agent runtime **cannot open SSM sessions to nodes** (a\n  fixed permission guardrail), so on-node signals (dmesg Xid lines, DCGM\n  counters, EFA fabric errors, slurmctld logs) are reached only\n  indirectly via HMA CloudWatch streams \u002F K8s labels \u002F control-plane\n  events — not by shelling into the node.\n",{"data":52,"body":57},{"name":4,"description":6,"metadata":53},{"version":54,"agent_types":55},"1.0.0",[56],"GENERIC",{"type":58,"children":59},"root",[60,69,90,116,123,135,211,259,265,284,289,334,340,432,438],{"type":61,"tag":62,"props":63,"children":65},"element","h1",{"id":64},"hyperpod-x-devops-agent-how-this-solution-monitors-the-cluster",[66],{"type":67,"value":68},"text","HyperPod x DevOps Agent — how this solution monitors the cluster",{"type":61,"tag":70,"props":71,"children":72},"p",{},[73,75,81,83,88],{"type":67,"value":74},"This Agent Space is wired to monitor one or more ",{"type":61,"tag":76,"props":77,"children":78},"strong",{},[79],{"type":67,"value":80},"SageMaker HyperPod",{"type":67,"value":82},"\nclusters. This document explains the ",{"type":61,"tag":76,"props":84,"children":85},{},[86],{"type":67,"value":87},"design and intent",{"type":67,"value":89}," of that\nmonitoring so investigations reason correctly and operators (via chat)\ncan understand how their cluster is watched.",{"type":61,"tag":91,"props":92,"children":93},"blockquote",{},[94],{"type":61,"tag":70,"props":95,"children":96},{},[97,99,105,107,114],{"type":67,"value":98},"Scope: this is the ",{"type":61,"tag":100,"props":101,"children":102},"em",{},[103],{"type":67,"value":104},"how it works",{"type":67,"value":106}," doc. For the concrete resource map\n(what exists, ARNs, instance IDs, log groups, VPC\u002Fsubnet\u002FSG IDs), use\nthe ",{"type":61,"tag":108,"props":109,"children":111},"code",{"className":110},[],[112],{"type":67,"value":113},"understanding-agent-space",{"type":67,"value":115}," skill.",{"type":61,"tag":117,"props":118,"children":120},"h2",{"id":119},"two-independent-detection-paths",[121],{"type":67,"value":122},"Two independent detection paths",{"type":61,"tag":70,"props":124,"children":125},{},[126,128,133],{"type":67,"value":127},"HyperPod problems reach DevOps Agent through ",{"type":61,"tag":76,"props":129,"children":130},{},[131],{"type":67,"value":132},"two",{"type":67,"value":134}," paths, by design:",{"type":61,"tag":136,"props":137,"children":138},"ol",{},[139,173],{"type":61,"tag":140,"props":141,"children":142},"li",{},[143,148,150,156,158,164,166,171],{"type":61,"tag":76,"props":144,"children":145},{},[146],{"type":67,"value":147},"Event-driven webhook bridge (all HyperPod control-plane faults).",{"type":67,"value":149},"\nA Lambda subscribes to ",{"type":61,"tag":108,"props":151,"children":153},{"className":152},[],[154],{"type":67,"value":155},"aws.sagemaker",{"type":67,"value":157}," HyperPod EventBridge events\n(Cluster State Change, Node Health, Cluster Event), drops routine\n",{"type":61,"tag":108,"props":159,"children":161},{"className":160},[],[162],{"type":67,"value":163},"Info",{"type":67,"value":165},"-level noise, and HMAC-POSTs the rest to the DevOps Agent\ngeneric webhook — which creates an investigation. This is how node\nhealth faults, capacity errors, lifecycle-script failures, and\ncluster state changes are detected, on ",{"type":61,"tag":76,"props":167,"children":168},{},[169],{"type":67,"value":170},"both EKS and Slurm",{"type":67,"value":172},"\n(Slurm requires Continuous Provisioning for the correct event shape).",{"type":61,"tag":140,"props":174,"children":175},{},[176,181,183,188,190,195,197,202,204,209],{"type":61,"tag":76,"props":177,"children":178},{},[179],{"type":67,"value":180},"Periodic-audit Lambda (Kubernetes state only).",{"type":67,"value":182},"\nSome conditions are NOT in the HyperPod event stream — notably\nKubernetes ",{"type":61,"tag":76,"props":184,"children":185},{},[186],{"type":67,"value":187},"CrashLoopBackOff",{"type":67,"value":189}," pods and ",{"type":61,"tag":76,"props":191,"children":192},{},[193],{"type":67,"value":194},"NotReady",{"type":67,"value":196}," nodes. A\nscheduled Lambda inspects those via the EKS API and ",{"type":61,"tag":76,"props":198,"children":199},{},[200],{"type":67,"value":201},"only invokes an\ninvestigation when a real issue is present",{"type":67,"value":203}," (thresholds are\nconfigurable). On a healthy cluster it posts nothing. On ",{"type":61,"tag":76,"props":205,"children":206},{},[207],{"type":67,"value":208},"Slurm",{"type":67,"value":210},"\nthere is no Kubernetes to inspect, so this path does nothing except\nthe heartbeat below.",{"type":61,"tag":70,"props":212,"children":213},{},[214,219,221,226,228,234,236,242,244,249,251,257],{"type":61,"tag":76,"props":215,"children":216},{},[217],{"type":67,"value":218},"Implication for investigations:",{"type":67,"value":220}," if you are investigating a\n\"HyperPod periodic audit\" task, the audit Lambda already detected a\nconcrete issue (or a control-plane fault arrived via the bridge). Treat\nthe reported issue as real and ",{"type":61,"tag":76,"props":222,"children":223},{},[224],{"type":67,"value":225},"confirm + explain it — don't assume it\nwas a routine poll",{"type":67,"value":227},". The Lambda inlines what it found into the task\n",{"type":61,"tag":108,"props":229,"children":231},{"className":230},[],[232],{"type":67,"value":233},"description",{"type":67,"value":235}," string (one ",{"type":61,"tag":108,"props":237,"children":239},{"className":238},[],[240],{"type":67,"value":241},"- [tag] type on resource: detail",{"type":67,"value":243}," line per\nissue) — the DevOps Agent platform preserves the top-level ",{"type":61,"tag":108,"props":245,"children":247},{"className":246},[],[248],{"type":67,"value":233},{"type":67,"value":250},"\nverbatim but flattens nested payload sub-objects, so the description\ntext, not a ",{"type":61,"tag":108,"props":252,"children":254},{"className":253},[],[255],{"type":67,"value":256},"data.metadata.*",{"type":67,"value":258}," field, is where the skill reads the\nfindings.",{"type":61,"tag":117,"props":260,"children":262},{"id":261},"daily-heartbeat-liveness",[263],{"type":67,"value":264},"Daily heartbeat (liveness)",{"type":61,"tag":70,"props":266,"children":267},{},[268,270,275,277,282],{"type":67,"value":269},"Once per day the audit Lambda fires a ",{"type":61,"tag":76,"props":271,"children":272},{},[273],{"type":67,"value":274},"heartbeat",{"type":67,"value":276},". Its purpose is\n",{"type":61,"tag":76,"props":278,"children":279},{},[280],{"type":67,"value":281},"pipeline liveness",{"type":67,"value":283}," — letting operators confirm the solution itself is\nalive and reaching the console — not incident detection (the 15-minute\naudit and the event-driven bridge do that). Do not treat a heartbeat as\nan incident.",{"type":61,"tag":70,"props":285,"children":286},{},[287],{"type":67,"value":288},"The heartbeat run still inspects cluster state:",{"type":61,"tag":290,"props":291,"children":292},"ul",{},[293,310],{"type":61,"tag":140,"props":294,"children":295},{},[296,301,303,308],{"type":61,"tag":76,"props":297,"children":298},{},[299],{"type":67,"value":300},"Healthy cluster (the usual case):",{"type":67,"value":302}," an \"all clear, no open issues\"\nheartbeat — a ",{"type":61,"tag":76,"props":304,"children":305},{},[306],{"type":67,"value":307},"silent liveness signal",{"type":67,"value":309},", visible in the console but\nnever emailed. Triage skips it (nothing to investigate); the skipped\ntask is itself the liveness signal.",{"type":61,"tag":140,"props":311,"children":312},{},[313,318,320,325,327,332],{"type":61,"tag":76,"props":314,"children":315},{},[316],{"type":67,"value":317},"A real issue exists at heartbeat time:",{"type":67,"value":319}," the Lambda builds an\n",{"type":61,"tag":100,"props":321,"children":322},{},[323],{"type":67,"value":324},"issues",{"type":67,"value":326}," payload instead, which is triaged and root-caused like any\ndetection and ",{"type":61,"tag":76,"props":328,"children":329},{},[330],{"type":67,"value":331},"can email",{"type":67,"value":333},".",{"type":61,"tag":117,"props":335,"children":337},{"id":336},"triage-rca-notification",[338],{"type":67,"value":339},"Triage → RCA → notification",{"type":61,"tag":290,"props":341,"children":342},{},[343,375,414],{"type":61,"tag":140,"props":344,"children":345},{},[346,351,353,359,361,366,368,373],{"type":61,"tag":76,"props":347,"children":348},{},[349],{"type":67,"value":350},"Triage",{"type":67,"value":352}," (",{"type":61,"tag":108,"props":354,"children":356},{"className":355},[],[357],{"type":67,"value":358},"hyperpod-incident-triage",{"type":67,"value":360},", INCIDENT_TRIAGE) decides\nLINK \u002F SKIP \u002F PROCEED. It keeps ",{"type":61,"tag":100,"props":362,"children":363},{},[364],{"type":67,"value":365},"different",{"type":67,"value":367}," fault types on the ",{"type":61,"tag":100,"props":369,"children":370},{},[371],{"type":67,"value":372},"same",{"type":67,"value":374},"\ninstance group as separate investigations (the default correlator\nwould merge them) and skips concurrent periodic audits.",{"type":61,"tag":140,"props":376,"children":377},{},[378,383,384,390,392,398,400,405,407,412],{"type":61,"tag":76,"props":379,"children":380},{},[381],{"type":67,"value":382},"RCA",{"type":67,"value":352},{"type":61,"tag":108,"props":385,"children":387},{"className":386},[],[388],{"type":67,"value":389},"hyperpod-incident-rca",{"type":67,"value":391},", INCIDENT_RCA) runs on PROCEED:\nreconstructs the timeline from ",{"type":61,"tag":108,"props":393,"children":395},{"className":394},[],[396],{"type":67,"value":397},"list-cluster-events",{"type":67,"value":399},", cluster\u002Fnode\nstate, and HMA CloudWatch streams; classifies as\n",{"type":61,"tag":76,"props":401,"children":402},{},[403],{"type":67,"value":404},"Suppress \u002F Monitor \u002F Escalate \u002F Resolved",{"type":67,"value":406},"; and writes a verdict\nwith a plain-English ",{"type":61,"tag":76,"props":408,"children":409},{},[410],{"type":67,"value":411},"Summary",{"type":67,"value":413}," (what happened → likely cause →\nrecommended action).",{"type":61,"tag":140,"props":415,"children":416},{},[417,422,424,430],{"type":61,"tag":76,"props":418,"children":419},{},[420],{"type":67,"value":421},"Email notifier",{"type":67,"value":423}," sends one SES email per completed investigation\n(scoped to this Agent Space). It suppresses ",{"type":61,"tag":108,"props":425,"children":427},{"className":426},[],[428],{"type":67,"value":429},"Suppress",{"type":67,"value":431}," verdicts,\nno-finding investigations, and heartbeats, and leads the subject with\nthe Summary's first sentence.",{"type":61,"tag":117,"props":433,"children":435},{"id":434},"what-this-solution-does-not-do",[436],{"type":67,"value":437},"What this solution does NOT do",{"type":61,"tag":290,"props":439,"children":440},{},[441,453],{"type":61,"tag":140,"props":442,"children":443},{},[444,446,451],{"type":67,"value":445},"It does ",{"type":61,"tag":76,"props":447,"children":448},{},[449],{"type":67,"value":450},"not",{"type":67,"value":452}," poll for HyperPod control-plane faults — those are\nevent-driven via the bridge. The audit only covers Kubernetes state.",{"type":61,"tag":140,"props":454,"children":455},{},[456,458,463],{"type":67,"value":457},"The DevOps Agent runtime ",{"type":61,"tag":76,"props":459,"children":460},{},[461],{"type":67,"value":462},"cannot open SSM sessions to nodes",{"type":67,"value":464}," (a\nfixed permission guardrail), so on-node signals (dmesg Xid lines, DCGM\ncounters, EFA fabric errors, slurmctld logs) are reached only\nindirectly via HMA CloudWatch streams \u002F K8s labels \u002F control-plane\nevents — not by shelling into the node.",{"items":466,"total":502},[467,475,491],{"slug":4,"name":4,"fn":5,"description":6,"org":468,"tags":469,"stars":29,"repoUrl":30,"updatedAt":31},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[470,471,472,473,474],{"name":24,"slug":25,"type":16},{"name":27,"slug":28,"type":16},{"name":18,"slug":19,"type":16},{"name":21,"slug":22,"type":16},{"name":14,"slug":15,"type":16},{"slug":389,"name":389,"fn":476,"description":477,"org":478,"tags":479,"stars":29,"repoUrl":30,"updatedAt":490},"perform root-cause analysis for HyperPod incidents","Root-cause analysis for a SageMaker HyperPod incident, after triage has decided to PROCEED. Runs at the INCIDENT_RCA stage. Reads describe-cluster, list-cluster-nodes, list-cluster-events, and HMA CloudWatch streams; reconstructs a timeline; classifies as Suppress \u002F Monitor \u002F Escalate \u002F Resolved against time budgets and recurrence statistics from the HyperPod mental model. Produces a human-readable verdict report with recommended operator actions. The complementary INCIDENT_TRIAGE skill `hyperpod-incident-triage` decides LINKED \u002F SKIPPED \u002F PROCEED before this skill runs.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[480,481,484,487],{"name":27,"slug":28,"type":16},{"name":482,"slug":483,"type":16},"Debugging","debugging",{"name":485,"slug":486,"type":16},"Incident Response","incident-response",{"name":488,"slug":489,"type":16},"Operations","operations","2026-09-02T07:47:38.297082",{"slug":358,"name":358,"fn":492,"description":493,"org":494,"tags":495,"stars":29,"repoUrl":30,"updatedAt":501},"triage SageMaker HyperPod incidents","Correlation and skip rules for SageMaker HyperPod incident triage. Keeps distinct fault types on the same instance group as separate investigations (the default correlator merges them), and prevents periodic-audit re-investigation of an unchanged cluster. Applies at the Incident Triage stage before any investigation runs.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[496,497,498,499],{"name":27,"slug":28,"type":16},{"name":485,"slug":486,"type":16},{"name":488,"slug":489,"type":16},{"name":350,"slug":500,"type":16},"triage","2026-09-02T07:47:39.537858",3,{"items":504,"total":675},[505,520,541,551,564,577,587,597,613,624,644,660],{"slug":506,"name":506,"fn":507,"description":508,"org":509,"tags":510,"stars":517,"repoUrl":518,"updatedAt":519},"agentcore-investigation","investigate Bedrock AgentCore runtime sessions","Investigate Bedrock AgentCore runtime sessions via CloudWatch Logs Insights — resolve session\u002Ftrace IDs, query OTEL spans, filter noise, build timelines. Use when debugging AgentCore agent sessions, tracing tool calls, or analyzing latency.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[511,512,513,516],{"name":27,"slug":28,"type":16},{"name":482,"slug":483,"type":16},{"name":514,"slug":515,"type":16},"Logs","logs",{"name":14,"slug":15,"type":16},9645,"https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fmcp","2026-07-12T08:37:22.601527",{"slug":521,"name":522,"fn":523,"description":524,"org":525,"tags":526,"stars":517,"repoUrl":518,"updatedAt":540},"amazon-aurora-dsql","amazon aurora dsql","build applications with Aurora DSQL","Deprecated compatibility redirect for Aurora DSQL guidance. Use when a request concerns DSQL, Aurora DSQL, distributed SQL, DSQL schemas, migrations, queries, authentication, performance, or application development.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[527,530,531,534,537],{"name":528,"slug":529,"type":16},"Aurora","aurora",{"name":27,"slug":28,"type":16},{"name":532,"slug":533,"type":16},"Database","database",{"name":535,"slug":536,"type":16},"Serverless","serverless",{"name":538,"slug":539,"type":16},"SQL","sql","2026-09-02T07:20:51.53702",{"slug":542,"name":543,"fn":523,"description":524,"org":544,"tags":545,"stars":517,"repoUrl":518,"updatedAt":550},"aurora-dsql","aurora dsql",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[546,547,548,549],{"name":27,"slug":28,"type":16},{"name":532,"slug":533,"type":16},{"name":535,"slug":536,"type":16},{"name":538,"slug":539,"type":16},"2026-09-02T07:20:46.533217",{"slug":552,"name":553,"fn":523,"description":524,"org":554,"tags":555,"stars":517,"repoUrl":518,"updatedAt":563},"aws-dsql","aws dsql",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[556,557,558,561,562],{"name":27,"slug":28,"type":16},{"name":532,"slug":533,"type":16},{"name":559,"slug":560,"type":16},"Migration","migration",{"name":535,"slug":536,"type":16},{"name":538,"slug":539,"type":16},"2026-09-02T07:20:49.531712",{"slug":565,"name":566,"fn":523,"description":524,"org":567,"tags":568,"stars":517,"repoUrl":518,"updatedAt":576},"distributed-postgres","distributed postgres",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[569,570,571,574,575],{"name":27,"slug":28,"type":16},{"name":532,"slug":533,"type":16},{"name":572,"slug":573,"type":16},"PostgreSQL","postgresql",{"name":535,"slug":536,"type":16},{"name":538,"slug":539,"type":16},"2026-09-02T07:20:47.592534",{"slug":578,"name":579,"fn":523,"description":524,"org":580,"tags":581,"stars":517,"repoUrl":518,"updatedAt":586},"distributed-sql","distributed sql",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[582,583,584,585],{"name":27,"slug":28,"type":16},{"name":532,"slug":533,"type":16},{"name":535,"slug":536,"type":16},{"name":538,"slug":539,"type":16},"2026-09-02T07:20:50.520015",{"slug":588,"name":588,"fn":523,"description":524,"org":589,"tags":590,"stars":517,"repoUrl":518,"updatedAt":596},"dsql",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[591,592,593,594,595],{"name":27,"slug":28,"type":16},{"name":532,"slug":533,"type":16},{"name":559,"slug":560,"type":16},{"name":535,"slug":536,"type":16},{"name":538,"slug":539,"type":16},"2026-09-02T07:20:48.570617",{"slug":598,"name":598,"fn":599,"description":600,"org":601,"tags":602,"stars":610,"repoUrl":611,"updatedAt":612},"aidlc","orchestrate AI-driven development lifecycle workflows","AI-DLC workflow orchestrator. Start, resume, or manage an AI-driven development lifecycle. Scopes are defined one file per scope under `.kiro\u002Fscopes\u002F`; run `bun .kiro\u002Ftools\u002Faidlc-utility.ts help` for the authoritative list and descriptions. Utilities: --status, --doctor, --stage, --phase, --scope, --depth, --test-strategy, --review, --version, --help, plus the intent and space verbs. Or describe what you want to build and the scope will be auto-detected.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[603,604,607],{"name":24,"slug":25,"type":16},{"name":605,"slug":606,"type":16},"Automation","automation",{"name":608,"slug":609,"type":16},"Workflow","workflow",4261,"https:\u002F\u002Fgithub.com\u002Fawslabs\u002Faidlc-workflows","2026-09-02T07:47:34.75815",{"slug":614,"name":614,"fn":615,"description":616,"org":617,"tags":618,"stars":610,"repoUrl":611,"updatedAt":623},"aidlc-jump","navigate AI-DLC workflow stages and phases","Jump the active AI-DLC workflow to a stage or phase. A Cursor-native shortcut for `\u002Faidlc --stage \u003Ctarget>` or `\u002Faidlc --phase \u003Ctarget>`.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[619,620],{"name":605,"slug":606,"type":16},{"name":621,"slug":622,"type":16},"Navigation","navigation","2026-09-02T07:48:09.505949",{"slug":625,"name":625,"fn":626,"description":627,"org":628,"tags":629,"stars":610,"repoUrl":611,"updatedAt":643},"aidlc-knowledge","index documents for AI-DLC agent citation","Index the team's own documents — PDFs, Word files, Markdown, plain text — into a per-space catalog the AI-DLC agents can cite. Wraps `aidlc-knowledge.ts`: onboard, sync, list, show, associate, dissociate, rebind, summarize. Every catalog row is written by the tool under a workspace lock; this skill never edits the catalog by hand and never advances workflow state.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[630,631,634,637,640],{"name":24,"slug":25,"type":16},{"name":632,"slug":633,"type":16},"Documents","documents",{"name":635,"slug":636,"type":16},"Knowledge Management","knowledge-management",{"name":638,"slug":639,"type":16},"Markdown","markdown",{"name":641,"slug":642,"type":16},"PDF","pdf","2026-09-02T07:48:10.614775",{"slug":645,"name":645,"fn":646,"description":647,"org":648,"tags":649,"stars":610,"repoUrl":611,"updatedAt":659},"aidlc-outcomes-pack","generate AI-DLC workflow handover documentation","Generate a comprehensive handover document at workflow close so the team can own, operate, and continue the system without re-running the workflow. Stage\u002Fphase\u002Flearning counts come from `aidlc-runtime.ts summary`; prose comes from the artefacts. Writes OUTCOMES.md but never mutates workflow state or emits audit events.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[650,653,656],{"name":651,"slug":652,"type":16},"Documentation","documentation",{"name":654,"slug":655,"type":16},"Process Documentation","process-documentation",{"name":657,"slug":658,"type":16},"Reporting","reporting","2026-09-02T07:47:34.212738",{"slug":661,"name":661,"fn":662,"description":663,"org":664,"tags":665,"stars":610,"repoUrl":611,"updatedAt":674},"aidlc-replay","generate AI-DLC session narrative reports","Print a structured session narrative for stakeholders who weren't in the room. Numbers (stage counts, phase rollup, duration) come from `aidlc-runtime.ts summary`; prose comes from the audit trail and artefacts. Renders to the terminal only — writes no file, never mutates workflow state, never emits audit events.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[666,669,670,673],{"name":667,"slug":668,"type":16},"Audit","audit",{"name":651,"slug":652,"type":16},{"name":671,"slug":672,"type":16},"Engineering","engineering",{"name":657,"slug":658,"type":16},"2026-09-02T07:47:45.055994",142]