메뉴
Use when the user wants to add support for a new resource type to an existing formae plugin
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/platform-engineering-labs/formae-mcp --skill formae-plugin-add-resource명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | formae-plugin-add-resource |
| description | Use when the user wants to add support for a new resource type to an existing formae plugin |
Add support for a new resource type to an existing formae resource plugin, following the plugin SDK tutorial and using TDD.
After ANY code changes to the plugin, you MUST run make install before running tests. Integration tests and conformance tests run against the INSTALLED plugin binary, not the source code. Skipping this step means you're testing stale code.
Ask the user where their plugin lives. Check that the directory exists and contains a valid plugin project (look for formae-plugin.pkl, Makefile, and the plugin Go source). Run /init so you have full context on the codebase.
Ask the user which resource type they want to add. Then research the provider's API for that resource thoroughly:
Look at how Terraform or Pulumi model the equivalent resource for schema design reference.
Present your research findings and a proposed resource schema to the user for approval before proceeding.
Fetch the plugin SDK tutorial from https://docs.formae.io/en/latest/plugin-sdk/tutorial/ and follow steps 2–10, adapting each lesson to the new resource type. Study the existing resource implementations in the plugin for patterns and conventions to follow.
Reference prior art plugins for real-world patterns:
https://github.com/platform-engineering-labs/formae-plugin-awshttps://github.com/platform-engineering-labs/formae-plugin-azurehttps://github.com/platform-engineering-labs/formae-plugin-gcphttps://github.com/platform-engineering-labs/formae-plugin-ocihttps://github.com/platform-engineering-labs/formae-plugin-ovhSteps to follow:
@ResourceType, @CreateOnly, @ReadOnly)OperationErrorCode patterns from the SDKErrors go in the result, not the error return. Domain-level failures — NotFound, AlreadyExists, InvalidRequest, ServiceInternalError — are reported through an OperationErrorCode on the result, not the Go error return. Where that code lives depends on the result type: ReadResult has a top-level ErrorCode; CreateResult, UpdateResult, DeleteResult, and StatusResult carry it on their nested ProgressResult (ProgressResult.ErrorCode, set alongside OperationStatus: OperationStatusFailure); ListResult has no error-code field — a list-level failure is the one case that returns a Go error. The Go error return is otherwise reserved for transport-level failures where you can't construct a meaningful result at all (e.g., transport.NewClient failing, context cancellation).
Concretely:
Read against a missing resource: return &resource.ReadResult{ErrorCode: resource.OperationErrorCodeNotFound}, nil — not nil, errors.New("not found").Create with bad input properties: return &resource.CreateResult{ProgressResult: &resource.ProgressResult{OperationStatus: OperationStatusFailure, ErrorCode: OperationErrorCodeInvalidRequest, StatusMessage: "..."}}, nil.ErrorCode before returning.Returning a non-nil error from a CRUD method bypasses formae's retry/state-machine logic and the agent treats it as an unrecoverable plugin bug. Review every return nil, err and ask "could this be a result with ErrorCode instead?"
MANDATORY: TDD for steps 3–7. Each tutorial lesson includes integration tests (e.g., TestCreate, TestRead, TestReadNotFound, TestUpdate, TestDelete, TestDeleteNotFound, TestList). For EVERY CRUD operation you MUST follow this exact loop:
https://docs.formae.io/en/latest/plugin-sdk/tutorial/05-create/)make install && go test -tags=integration ./... — confirm the test passes.NEVER write implementation code before its corresponding test. NEVER skip writing tests.
Run make install && make conformance-test.
Fix any failures and re-run. All CRUD and discovery tests must pass before continuing.
Ask the user if they want to do a manual end-to-end test. If yes:
formae apply --mode reconcile --simulate to verify the planformae apply --mode reconcile to create real resourcesformae inventory to verify resources are managedformae destroy to clean upUpdate the plugin's README.md:
Before reporting completion, verify each item:
make install && make conformance-test)make install before running tests — tests run against the installed binarypkl eval to evaluate forma files — ALWAYS use formae eval --output-consumer machine