Make AIDLC reliable. OMA is a Claude Code · Kiro plugin marketplace that turns the AIDLC methodology's two reliability axes — Ontology Engineering (correctness) and Harness Engineering (safety) — into installable plugins, with AIDLC Workflows as the process spine and AgenticOps closing the feedback loop back into the ontology.
한국어 README · Documentation · Plugins · Steering · Releases · References
OMA's goal is a one-install easy button: add the marketplace, install the plugins, and the AIDLC methodology's two reliability axes — Ontology Engineering and Harness Engineering — are active in Claude Code or Kiro without hand-rolling any schemas, policies, or hooks. You approve at checkpoints; agents do the rest.
/plugin marketplace add https://github.com/aws-samples/sample-oh-my-aidlcops
/plugin install ai-infra@oh-my-aidlcops agenticops@oh-my-aidlcops aidlc@oh-my-aidlcops modernization@oh-my-aidlcops
# → typed ontology + harness DSL + AWS hosted MCP wiring, ready to use
OMA is being built into an open toolset for enterprise operations automation. The trajectory:
- Today — Ontology + Harness Engineering as installable plugins, AWS Hosted MCP (awslabs/mcp) as the default runtime data layer, AgenticOps closing the feedback loop.
- Next — deeper AWS Hosted MCP coverage plus first-class DevOps agent and Security agent integrations, so deploy, observability, and security review run as governed agents inside the same approval model.
- The promise — install a few plugins and get enterprise-grade operations automation that is auditable, policy-gated, and harness-constrained by default — not a bespoke platform you assemble yourself.
Release v0.4.0-preview.1 repositions the project around the reliability
dual-axis and renames plugins for clarity, building on the enterprise ontology +
harness surface introduced in v0.3:
- Reliability dual-axis docs — dedicated Ontology Engineering (correctness) and Harness Engineering (safety) pages mapping each axis to its OMA implementation, with honest partial/roadmap status for harness patterns.
- Plugin renames —
agentic-platform → ai-infra, andaidlc-inception+aidlc-constructionmerged into a singleaidlcplugin. - 8 ontology entities —
Agent,Skill,Deployment,Incident,Budget,Risk, plusSpecandADR(Draft 2020-12) closing the Phase-1 → Construction traceability chain. - Harness DSL v2 — optional
workflows(DAG),telemetry(OpenTelemetry),policies(declarative runtime deny rules),metadata.labels.version: 1files compile unchanged. - Pure-CC policy enforcement — a plugin's
policiesblock compiles into aPreToolUsehook (hooks/enforce.py+hooks/harness-rules.json) that blocks matching tool calls before they run. Pure Claude Code, no external policy engine, noopabinary. - Enterprise gates —
oma doctor --enterprise(8 probes),oma compile --strict-enterprise,oma validate <entity.yaml>, and JSON-L audit events viapython -m tools.oma_audit.append.
Full details in CHANGELOG.md and on the Releases page.
oh-my-aidlcops (OMA) is the sibling project of
oh-my-claudecode (OMC).
Where OMC orchestrates generic Claude Code workflows, OMA specializes in making
the AIDLC loop — Inception → Construction → Operations — reliable enough to
run with agents.
The AIDLC methodology identifies that AI-driven development breaks down in three recurring ways, and none of them are about model quality:
- Hallucination & drift — concepts mean different things across prompts and sessions, so handoffs only work because a human re-interprets them.
- Runaway execution — without architectural limits an agent loop can fire hundreds of retries (the methodology's fintech case: 847 retries, ~$2,200, a 3-hour outage) before anyone notices.
- Self-grading — the agent that wrote the code also writes the tests, so its own blind spots survive verification.
The methodology answers these with a reliability dual-axis: Ontology Engineering guarantees the correctness of what agents produce (the WHAT/WHEN), and Harness Engineering enforces the safety of how they execute (the HOW). OMA is the installable implementation of that dual-axis on AWS.
| Methodology axis | Guarantees | OMA implementation | Entry point |
|---|---|---|---|
| Ontology Engineering | Correctness (WHAT · WHEN) | 8 JSON-Schema entities in schemas/ontology/, oma validate, schema-evolution rules |
/oma:inception, oma validate |
| Harness Engineering | Safety (HOW) | Harness DSL v2 (policies → PreToolUse enforcement, telemetry), oma compile --strict-enterprise, pinned MCP, sandboxed budget eval |
oma doctor --enterprise, oma compile |
| AgenticOps (Outer Loop) | Living ontology | self-improving-loop, continuous-eval, incident-response feeding operational signal back into the ontology |
/oma:agenticops, /oma:self-improving |
AIDLC Workflows — the AWS-official
awslabs/aidlc-workflows 3-phase loop —
is the process spine these pillars hang on. OMA contributes only *.opt-in.md
extensions to it and never forks the core. The result: AIDLC stops being "design
and build, then hope," and becomes a lifecycle where every artifact is a validated
ontology document and every agent action runs inside a harness.
- Platform engineers building agentic AI on AWS EKS.
- Teams running LLM/agent workloads who want AIDLC to cover operations, not just design and construction.
- Teams modernizing legacy workloads onto AWS using a repeatable 6R workflow.
- Claude Code or Kiro users who want a drop-in marketplace rather than hand-rolling skills.
| Plugin | What it does | Example skills |
|---|---|---|
ai-infra |
Build & run the Agentic AI Platform on EKS | agentic-eks-bootstrap, vllm-serving-setup, inference-gateway-routing, langfuse-observability, gpu-resource-management, ai-gateway-guardrails |
agenticops |
Operate it with agents | self-improving-loop, autopilot-deploy, incident-response, continuous-eval, cost-governance, audit-trail, anomaly-detection, root-cause-analysis, automated-remediation, slo-management, predictive-scaling |
aidlc |
AIDLC Phase 1 (Inception) + Phase 2 (Construction) extensions | requirements-analysis, user-stories, workflow-planning, component-design, code-generation, test-strategy, risk-discovery, quality-gates |
modernization |
Legacy workload modernization to AWS (6R strategy) | workload-assessment, modernization-strategy, to-be-architecture, containerization, cutover-planning |
OMA inherits the Tier-0 pattern from OMC — high-leverage workflows you invoke once and let run, with human approval only at checkpoints.
| Command | Purpose |
|---|---|
/oma:autopilot |
Full AIDLC loop autopilot (Inception → Construction → Operations) |
/oma:aidlc-loop |
Single-feature AIDLC one-pass |
/oma:agenticops |
Operations mode (continuous-eval + incident-response + cost-governance) |
/oma:self-improving |
Feedback loop — traces (via your opt-in trace MCP) to skill/prompt improvement PR |
/oma:platform-bootstrap |
5-checkpoint Agentic AI Platform build on EKS |
/oma:modernize |
Legacy workload modernization (6R decision → cutover) |
/oma:review |
AIDLC artifact review (ADR, spec, design, PR) |
/oma:cancel |
Terminate active Tier-0 mode |
install.sh downloads the pinned release tarball, extracts to ~/.oma, and
symlinks ~/.local/bin/oma. oma setup then writes a project profile,
seeds the ontology, installs the plugins, and runs oma doctor to confirm
the environment.
curl -fsSL https://raw.githubusercontent.com/aws-samples/sample-oh-my-aidlcops/v0.4.0-preview.1/install.sh | bash
cd my-project
oma setup
oma doctorSee the Easy Button docs
for what oma setup writes, how the 12 doctor probes work, and how the
ontology + harness DSL get enforced at runtime.
Tech Preview notice —
v0.4.0-preview.1treatsprofile.yamlv1, the 8 ontology schemas, and Harness DSL v2 as stable. Everything else (CLI UX, doctor report shape) may evolve before GA. See Support Policy.
claudeInside the Claude Code session:
/plugin marketplace add https://github.com/aws-samples/sample-oh-my-aidlcops
/plugin install ai-infra@oh-my-aidlcops
/plugin install agenticops@oh-my-aidlcops
/plugin install aidlc@oh-my-aidlcops
/plugin install modernization@oh-my-aidlcops
/plugin list
/plugin installaccepts a single plugin id per invocation. Pasting the six lines above lets Claude Code run them sequentially. For a shell one-liner, useclaude <<'EOF' ... EOFto feed the commands via stdin.
git clone https://github.com/aws-samples/sample-oh-my-aidlcops
bash sample-oh-my-aidlcops/scripts/install/claude.shThe manual script creates
~/.claude/plugins/symlinks and merges MCP servers + hooks intosettings.json. On Claude Code 2.0+ this alone does NOT register plugins with/plugin list. Use it only for legacy 1.x environments, offline CI, or when you want to wire MCP servers without activating the marketplace.
git clone https://github.com/aws-samples/sample-oh-my-aidlcops
bash sample-oh-my-aidlcops/scripts/install/kiro.shcd <your-project>
bash <path-to-oma>/scripts/init-omao.shbash scripts/install/aidlc-extensions.sh
# Clones awslabs/aidlc-workflows into ~/.aidlc and symlinks OMA's opt-in extensions.After oma setup, four commands are worth exercising on day one:
# 1. Diagnostic only — 8 probes, never changes state.
oma doctor --enterprise
# → [doctor:enterprise] 8 probes OK (0 warnings)
# 2. Enforce the gate — rejects DSL v1, missing approval_chain, legacy
# string artifacts, and unclassified Risks.
oma compile --strict-enterprise
# → compiled ai-infra: plugins/ai-infra/.mcp.json ...
# 3. Validate an ontology entity (Spec / ADR / Deployment / Incident /
# Budget / Risk / Agent / Skill) against its JSON Schema.
oma validate path/to/deployment.yaml
# → [oma validate] path/to/deployment.yaml: schema OK
# 4. Print the execution plan for a DSL v2 workflow (stub: no runtime yet).
oma run-workflow ai-infra platform-bootstrap
# → execution order: preflight -> provision -> verifyAdoption is one flag away — every enterprise field is optional
until you opt in via --strict-enterprise. See
Enterprise readiness
for the phased adoption checklist.
OMA aligns ontology entities with four authoritative references so audit-facing conversations work without invented vocabulary:
| Framework | Where it lands in OMA | Docs |
|---|---|---|
| Model Context Protocol v1.0 | Agent.mcp_uri (canonical MCP server URI) |
Foundation |
| SLSA v1.1 Provenance | Deployment.artifact.{digest,provenance_uri,signing} |
SLSA provenance |
| NIST AI RMF (AI 100-1) | Risk.nist_ai_rmf_subcategory, AuditEvent.compliance.nist_ai_rmf |
NIST AI RMF mapping |
| OWASP Top 10 for LLM Apps | Risk.owasp_llm_top10_id (LLM01..LLM10) |
OWASP LLM Top 10 mapping |
OpenTelemetry (traces/metrics/logs) and FinOps Framework cost categories
feed the DSL v2 telemetry and Budget surfaces respectively.
If OMA was useful, a ⭐ on the GitHub repository helps us prioritize maintenance and keeps release notifications flowing to you. It is entirely optional — nothing in the CLI changes based on your star status.
User request
│
▼
Tier-0 trigger ─── matches keyword? ──▶ /oma:<workflow>
│
▼
Plugin dispatch
│
├─▶ ai-infra (build/run runtime)
├─▶ agenticops (operate)
├─▶ aidlc (Phase 1 + Phase 2)
└─▶ modernization (legacy → AWS)
│
▼
Skills execute, calling AWS Hosted MCP
│
├─▶ eks, cloudwatch, prometheus, aws-iac, cost-explorer, ...
│
▼
Checkpoint — human approves
│
▼
Operations phase continues autonomously
│
└─▶ self-improving-loop feeds corrections back to Construction
OMA plugins rest on two shared layers:
- Ontology (
ontology/,schemas/ontology/) — eight JSON Schemas that define the vocabulary every plugin and skill agrees on:Agent,Skill,Deployment,Incident,Budget,Risk, plusSpecandADR. A handoff between Construction and Operations is no longer a prose description; it is a validatedDeploymentdocument. See ontology/README.md and ontology/glossary.md. - Harness DSL (
schemas/harness/dsl.schema.json,tools/oma_compile/) — one<plugin>.oma.yamlper plugin is the single source of agents, MCP servers, hooks, and triggers.python -m tools.oma_compiletranslates it to the native.mcp.jsonandkiro-agents/*.agent.jsonfiles that Claude Code and Kiro already consume, so marketplace installs stay unchanged.
<plugin>.oma.yaml ──(oma-compile)──▶ .mcp.json
▶ kiro-agents/<agent>.agent.json
▶ .omao/triggers.json (merged across plugins)
CI (.github/workflows/oma-foundation.yml) validates every schema fixture and
runs oma-compile --check to reject drift between DSL sources and committed
native files.
This repository ships with conservative defaults. A few things are worth calling out before you use it in production:
- MCP servers are pinned to exact PyPI versions in every
.mcp.jsonandkiro-agents/*.agent.json.@latestis not used anywhere — a compromised upstream release cannot silently land alongside AWS credentials. - EKS MCP is read-only by default. The bundled Kiro agent profile does
not pass
--allow-writeor--allow-sensitive-data-accesstoawslabs.eks-mcp-server. Add them explicitly when you need to provision or mutate EKS resources, and audit that change. - IAM is least-privilege. The
langfuse-observabilityskill uses a customer-managed policy scoped to the Langfuse bucket ARN; AWS managedAmazonS3FullAccess(s3:*account-wide) is explicitly rejected with a "Bad Example" block in the skill. budget.yamlexpressions are sandboxed. Thecost-governanceskill evaluatesrule["when"]viasimpleeval(AST walker, zero builtins, zero callables). A documented Bad Example shows why Pythoneval()on a user-editable file is an RCE vector.- Session state stays local.
.omao/state/,.omao/plans/,.omao/logs/,.omao/notepad.md, and.omao/project-memory.jsonare gitignored —audit-trailcaptures prompts verbatim (PII, approver identity, SOC2 retention content) and must never leave the machine. - Hooks require a real JSON encoder.
hooks/session-start.shusesjq(withpython3/pythonas ordered fallbacks) and exits non-zero rather than emitting shell-interpolated JSON, preventing state-file injection into the session context.
OMA stands on top of existing AWS and community work rather than reinventing.
| Source | License | How OMA uses it |
|---|---|---|
| awslabs/agent-plugins | Apache-2.0 | Adopts plugin, skill-frontmatter, mcp, marketplace JSON schemas. |
| awslabs/aidlc-workflows | MIT-0 | Consumed as AIDLC core; OMA contributes only *.opt-in.md extensions. |
| awslabs/mcp | Apache-2.0 | 11 hosted MCP servers referenced via uvx stdio. |
| aws-samples/sample-apex-skills | MIT-0 | Workflow 5-checkpoint template pattern. |
| aws-samples/sample-ai-driven-modernization-with-kiro | MIT-0 | Risk-discovery, audit-trail, quality-gates, 6R strategy methodology. |
| Atom-oh/oh-my-cloud-skills | MIT | Eval script patterns, Kiro conversion reference. |
| oh-my-claudecode | — | Tier-0 orchestration and .omc/ state inheritance. |
Full attribution in NOTICE. See REFERENCES.md for the complete catalogue of every upstream repo, authoritative spec, framework, and runtime tool that OMA touches.
MIT No Attribution (MIT-0). See LICENSE.
OMA is in Tech Preview (v0.4.0-preview.1). See CONTRIBUTING.md
for the working agreement (English-only artifacts, no AI attribution, commit
per unit of work) plus the PR/branch-naming guidelines, and
CODE_OF_CONDUCT.md for the Amazon Open Source Code of
Conduct. Issues and PRs are especially welcome for skill quality, MCP coverage
gaps, and Kiro compatibility testing.
For security issues, do not open a public GitHub issue — follow the AWS vulnerability reporting process instead.