Use when long-lived agents, project memories, system prompts, or playbooks are repeatedly summarized, rewritten, or optimized and risk losing domain detail, provenance, or execution learnings.
日本語の概要は準備中です。原文の説明を表示しています。
Use when Kubernetes Server-Side Apply reports field-manager conflicts, controllers overwrite fields, or force-conflicts risks pruning/defaulting side effects; diagnose ownership read-only before choosing relinquish, partition, or explicit transfer.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
kubectl apply --server-side or another SSA client reports a field conflict.Do not use this for client-side three-way-merge errors, immutable-field errors, ordinary Helm template design, or non-Kubernetes state conflicts. Do not treat managedFields as a historical audit log.
kubectl matched reasonably closely to the API server.--force-conflicts merely to make reconciliation green.metadata.managedFields directly; it is API-server-managed state.# Preserve the exact live object for offline inspection; redact sensitive data.
kubectl get deployment api -n prod -o json > /tmp/api-live.json
# Inventory manager/path claims without contacting the cluster.
python3 scripts/ssa_ownership.py inventory /tmp/api-live.json
# Parse an apply error captured as plain text.
python3 scripts/ssa_ownership.py conflicts /tmp/apply-error.txt
# Reproduce admission and ownership checks without persisting a change.
kubectl apply --server-side --dry-run=server \
--field-manager=my-deployer -f intended.yaml -o yaml
Record:
resourceVersion;--field-manager value;Fetch the live object once. Avoid loops that repeatedly apply while diagnosing: even no-op SSA requests can change managed-field metadata in some Kubernetes versions.
Completion: one timestamped live object, one intended object, and one exact error are available for comparison.
Inspect .metadata.managedFields[] by manager, operation, API version, subresource, and fieldsV1. Use the helper for a readable inventory, then verify important paths against the raw object.
python3 scripts/ssa_ownership.py inventory /tmp/api-live.json --pretty
Interpret ownership as a current field set, not proof of who last changed a value. The same manager string may be reused by unrelated clients; operation and workflow identity matter. For CRDs, inspect structural schema and list semantics (atomic, set, or map) because one apparent list item can be owned atomically or by keyed element.
Completion: every conflicting path has a current owner, operation, API version, and responsible controller/client—or is explicitly marked unknown.
Use the first matching class:
| Class | Evidence | Preferred direction |
|---|---|---|
| Accidental duplicate manager | Different clients reuse one manager name | Give each workflow a stable unique manager; retest |
| Shared desired field | Two reconcilers intentionally set the same scalar/atomic collection | Establish one source of truth; remove it from the other payload |
| Defaulted field | API defaulting adds a value that another client sends explicitly | Omit the default where safe or make one manager authoritative |
| Webhook-injected field | Mutating webhook owns/adds data after admission | Exclude it from deployer payload; test omission and pruning |
| Controller-owned status/subresource | Conflict concerns status or scale ownership | Use the proper subresource/client contract |
| List semantics mismatch | Ownership is at whole-list rather than keyed-item scope | Fix CRD schema or partition ownership; do not force blindly |
| Stale manager | Former controller still owns fields and no longer runs | Prove decommissioning, then plan explicit transfer |
| Version/schema drift | Manager entries or paths differ across served API versions | Compare conversion and schema behavior before transfer |
Do not infer “stale” from an old managed-field timestamp alone. Prove that no active controller uses that manager.
Run the exact rendered payload with the exact manager using server dry-run. Keep force disabled first.
kubectl apply --server-side --dry-run=server \
--field-manager="$MANAGER" -f intended.yaml -o json > /tmp/dry-run.json
Test one hypothesis at a time:
Compare values and field ownership, including fields absent from the intended payload. If a webhook does not support dry-run, stop and use a disposable environment rather than testing in production.
Completion: the failure boundary is reproducible, and one non-mutating variant removes the conflict without losing required fields—or the uncertainty is documented.
Decision order:
A transfer plan must name the old and new manager, exact paths, pause order, backup, canary object, rollback command, and post-apply ownership assertions. Never force an entire rendered object when only a small, deliberately reviewed field set requires transfer.
After an approved canary change:
kubectl get <kind> <name> -n <namespace> -o json > /tmp/after.json
python3 scripts/ssa_ownership.py inventory /tmp/after.json --pretty
kubectl diff --server-side --field-manager="$MANAGER" -f intended.yaml
Require all of these:
sideEffects and dry-run support, then reproduce in a disposable cluster.managedFields.conflict with kubectl on .spec.replicas. Diagnose it without changing the Deployment.”Expected observable behavior: prompts 1–2 map managers and paths, classify ownership, reproduce without mutation, and gate force behind approval; prompt 3 routes to a Helm/chart workflow instead.
Sourced facts: Kubernetes documents SSA field tracking in managedFields, conflict behavior, field-manager identity, merge markers/list topology, and force-conflict transfer. The cited issues demonstrate current cross-project failure modes involving no-op metadata updates, forced pruning of injected annotations, operator ownership, and stale provider payload fields.
Recommendations: the classification table, evidence packet, decision order, canary rules, and approval gates are original operational guidance synthesized for safe triage.
No source prose or code is redistributed. This skill and helper are original MIT-licensed work.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when long-lived agents, project memories, system prompts, or playbooks are repeatedly summarized, rewritten, or optimized and risk losing domain detail, provenance, or execution learnings.
日本語の概要は準備中です。原文の説明を表示しています。
Use this skill when the user explicitly asks to map, document, or onboard into an existing codebase. Trigger for prompts like "map this codebase", "document this architecture", "onboard me to this repo", or "create codebase docs". Do not trigger for routine feature implementation, bug fixes, or narrow code edits unless the user asks for repository-level discovery.
日本語の概要は準備中です。原文の説明を表示しています。
Adds educational comments to a code file so it becomes a learning resource, asking for the file (with a list of close matches) if none is given. Use when preparing code for learners, onboarding, or teaching.
日本語の概要は準備中です。原文の説明を表示しています。
Write, debug, and optimize Adobe Illustrator automation scripts using ExtendScript (JavaScript/JSX). Use when creating or modifying scripts that manipulate documents, layers, paths, text frames, colors, symbols, artboards, or any Illustrator DOM objects. Covers the complete JavaScript object model, coordinate system, measurement units, export workflows, and scripting best practices.
日本語の概要は準備中です。原文の説明を表示しています。
Patterns and techniques for adding governance, safety, and trust controls to AI agent systems. Use this skill when: - Building AI agents that call external tools (APIs, databases, file systems) - Implementing policy-based access controls for agent tool usage - Adding semantic intent classification to detect dangerous prompts - Creating trust scoring systems for multi-agent workflows - Building audit trails for agent actions and decisions - Enforcing rate limits, content filters, or tool restrictions on agents - Working with any agent framework (PydanticAI, CrewAI, OpenAI Agents, LangChain, AutoGen)
日本語の概要は準備中です。原文の説明を表示しています。
Check any AI agent codebase against the OWASP Agentic Security Initiative (ASI) Top 10 risks. Use this skill when: - Evaluating an agent system's security posture before production deployment - Running a compliance check against OWASP ASI 2026 standards - Mapping existing security controls to the 10 agentic risks - Generating a compliance report for security review or audit - Comparing agent framework security features against the standard - Any request like "is my agent OWASP compliant?", "check ASI compliance", or "agentic security audit"
日本語の概要は準備中です。原文の説明を表示しています。