소스 정보
- 저장소
- tomevault-io/skills-registry
- 최근 소스 활동
- 2026년 4월 28일 22:53
- 감지된 SKILL.md 언어
- 영어
- 스타
- 0
- 포크
- 0
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/tomevault-io/skills-registry --skill implementation-patterns명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
| Use when this capability is needed.
> Use when this capability is needed.
Review architecture and API design for the vfs-s3 project. Use when the user mentions @architect, asks to review an issue's design, discuss module boundaries, API shape, or architectural decisions for vfs-s3. Also trigger when the user wants to create an ADR (Architecture Decision Record) or evaluate a technical approach for the project. Intended for dispatch from Codex automation or Claude routines; GitHub trigger phrase: @vfs-s3-bot please prepare design doc Use when this capability is needed.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | implementation-patterns |
| description | >- Use when this capability is needed. |
| Pattern | Best For | Tradeoff |
|---|---|---|
| Check-Before-Act | Creating resources | Race conditions possible |
| Upsert | APIs with atomic operations | Not universally available |
| Force Overwrite | Content that can be safely replaced | Destructive if misused |
| Unique Identifiers | Natural deduplication | ID logic can be complex |
| Tombstone Markers | Multi-step operations | Markers need cleanup |
Five patterns for making operations idempotent. Each has tradeoffs; choose based on your constraints.
| Pattern | Best For | Tradeoff |
|---|---|---|
| Check-Before-Act | Creating resources | Race conditions possible |
| Upsert | APIs with atomic operations | Not universally available |
| Force Overwrite | Content that can be safely replaced | Destructive if misused |
| Unique Identifiers | Natural deduplication | ID logic can be complex |
| Tombstone Markers | Multi-step operations | Markers need cleanup |
The most common pattern. Check if the target state exists before attempting to create it.
if git ls-remote --heads origin "$BRANCH" | grep -q "$BRANCH"; then
git checkout -B "$BRANCH" "origin/$BRANCH"
else
git checkout -b "$BRANCH"
fi
Use APIs or commands that handle both cases atomically.
gh release create v1.0.0 --notes "Release" || gh release edit v1.0.0 --notes "Release"
Don't check, just overwrite. Safe when overwriting with identical content is acceptable.
git push --force-with-lease origin "$BRANCH"
Generate deterministic IDs so duplicate operations target the same resource.
BRANCH="update-$(sha256sum file.txt | cut -c1-8)"
Leave markers indicating operations completed.
MARKER=".completed-$RUN_ID"
[ -f "$MARKER" ] && exit 0
# Do work...
touch "$MARKER"
See examples.md for detailed code examples.
| Scenario | Recommended Pattern |
|---|---|
| Creating resources (PRs, branches, files) | Check-Before-Act |
| Updating existing resources | Upsert or Force Overwrite |
| Operations with natural keys | Unique Identifiers |
| Complex multi-step operations | Tombstone Markers |
| API supports atomic operations | Upsert |
Combine Patterns
Real-world automation often combines multiple patterns. A workflow might use Check-Before-Act for PR creation, Force Overwrite for branch updates, and Unique Identifiers for naming.
| Pattern | Best For | Tradeoff |
|---|---|---|
| Check-Before-Act | Creating resources | Race conditions possible |
| Upsert | APIs with atomic operations | Not universally available |
| Force Overwrite | Content that can be safely replaced | Destructive if misused |
| Unique Identifiers | Natural deduplication | ID logic can be complex |
| Tombstone Markers | Multi-step operations | Markers need cleanup |
The most common pattern. Check if the target state exists before attempting to create it.
if git ls-remote --heads origin "$BRANCH" | grep -q "$BRANCH"; then
git checkout -B "$BRANCH" "origin/$BRANCH"
else
git checkout -b "$BRANCH"
fi
Use APIs or commands that handle both cases atomically.
gh release create v1.0.0 --notes "Release" || gh release edit v1.0.0 --notes "Release"
Don't check, just overwrite. Safe when overwriting with identical content is acceptable.
git push --force-with-lease origin "$BRANCH"
Generate deterministic IDs so duplicate operations target the same resource.
BRANCH="update-$(sha256sum file.txt | cut -c1-8)"
Leave markers indicating operations completed.
MARKER=".completed-$RUN_ID"
[ -f "$MARKER" ] && exit 0
# Do work...
touch "$MARKER"
See examples.md for detailed code examples.
| Scenario | Recommended Pattern |
|---|---|
| Creating resources (PRs, branches, files) | Check-Before-Act |
| Updating existing resources | Upsert or Force Overwrite |
| Operations with natural keys | Unique Identifiers |
| Complex multi-step operations | Tombstone Markers |
| API supports atomic operations | Upsert |
Combine Patterns
Real-world automation often combines multiple patterns. A workflow might use Check-Before-Act for PR creation, Force Overwrite for branch updates, and Unique Identifiers for naming.
| Pattern | Best For | Tradeoff |
|---|---|---|
| Check-Before-Act | Creating resources | Race conditions possible |
| Upsert | APIs with atomic operations | Not universally available |
| Force Overwrite | Content that can be safely replaced | Destructive if misused |
| Unique Identifiers | Natural deduplication | ID logic can be complex |
| Tombstone Markers | Multi-step operations | Markers need cleanup |
The most common pattern. Check if the target state exists before attempting to create it.
if git ls-remote --heads origin "$BRANCH" | grep -q "$BRANCH"; then
git checkout -B "$BRANCH" "origin/$BRANCH"
else
git checkout -b "$BRANCH"
fi
Use APIs or commands that handle both cases atomically.
gh release create v1.0.0 --notes "Release" || gh release edit v1.0.0 --notes "Release"
Don't check, just overwrite. Safe when overwriting with identical content is acceptable.
git push --force-with-lease origin "$BRANCH"
Generate deterministic IDs so duplicate operations target the same resource.
BRANCH="update-$(sha256sum file.txt | cut -c1-8)"
Leave markers indicating operations completed.
MARKER=".completed-$RUN_ID"
[ -f "$MARKER" ] && exit 0
# Do work...
touch "$MARKER"
flowchart TD
A[Need idempotency] --> B{API has upsert?}
B -->|Yes| C[Use Upsert]
B -->|No| D{Safe to overwrite?}
D -->|Yes| E[Use Force Overwrite]
D -->|No| F{Natural unique key?}
F -->|Yes| G[Use Unique Identifiers]
F -->|No| H{Multi-step operation?}
H -->|Yes| I[Use Tombstone Markers]
H -->|No| J[Use Check-Before-Act]
%% Ghostty Hardcore Theme
style A fill:#5e7175,color:#f8f8f3
style B fill:#fd971e,color:#1b1d1e
style C fill:#a7e22e,color:#1b1d1e
style D fill:#fd971e,color:#1b1d1e
style E fill:#e6db74,color:#1b1d1e
style F fill:#fd971e,color:#1b1d1e
style G fill:#65d9ef,color:#1b1d1e
style H fill:#fd971e,color:#1b1d1e
style I fill:#9e6ffe,color:#1b1d1e
style J fill:#65d9ef,color:#1b1d1e
| Scenario | Recommended Pattern |
|---|---|
| Creating resources (PRs, branches, files) | Check-Before-Act |
| Updating existing resources | Upsert or Force Overwrite |
| Operations with natural keys | Unique Identifiers |
| Complex multi-step operations | Tombstone Markers |
| API supports atomic operations | Upsert |
Combine Patterns
Real-world automation often combines multiple patterns. A workflow might use Check-Before-Act for PR creation, Force Overwrite for branch updates, and Unique Identifiers for naming.
See examples.md for code examples.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.