메뉴
Use when centralizing duplicated presentation/logging helpers (log, ok, fail, section, etc.) scattered across many shell scripts in a fleet, so consumers can safely source the shared module regardless of their own validation or exit-code conventions.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | side-effect-free-helper-library |
| description | Use when centralizing duplicated presentation/logging helpers (log, ok, fail, section, etc.) scattered across many shell scripts in a fleet, so consumers can safely source the shared module regardless of their own validation or exit-code conventions. |
| status | active |
| version | "2026-07-05T00:00:00.000Z" |
You're consolidating duplicated helper functions (output formatting, logging, success/fail markers) that are copy-pasted across dozens to hundreds of scripts in a fleet, and different consumers currently validate inputs or handle exit codes differently. Also applies to any shared shell library being adopted incrementally across a large, heterogeneous set of existing scripts.
Make the shared module silent on source — sourcing it must never validate
arguments, check for required keys/env vars, or exit/return non-zero as a side
effect of being loaded. All of that stays in the consumer (common.sh,
sops/_lib.sh, or whatever each script already uses for its own init checks).
This decouples "initialization validation" from "presentation formatting" so
scripts with different validation needs can all adopt the same output helpers
without conflict.
Provide a small, composable function set: log, ok, fail, die,
section, warn, info. Document the exit-code contract precisely and
distinguish them clearly:
fail() prints an error-style message and returns 0 (non-fatal — caller
decides what happens next).die() is the only function that actually exits the process.
This distinction has to be explicit in the docs, since the two look similar at
a glance but have opposite control-flow implications.Use ASCII-only glyphs (*, !, x) instead of Unicode symbols (✓, ✗)
to avoid encoding/mojibake issues across terminals and CI log viewers.
Gate color on TTY detection: [ -t 2 ] (checking fd 2, since output goes to
stderr) before emitting ANSI color codes, so piped/CI output stays clean.
Route all presentation output to stderr, keeping stdout reserved for machine-parseable data. This lets consumers pipe stdout for parsing while still seeing human-readable logs.
Provide a migration recipe for consumers: drop the local helper
definitions, then source the centralized module — path depends on depth:
source ../phases/output.sh for subdirectory scripts, phases/output.sh for
top-level ones.
Migrate mechanically to avoid corruption: use a content-agnostic awk
replacement that operates by line range with the source line passed in as an
env var, rather than pattern-matching text — this sidesteps mojibake/encoding
corruption during bulk find-and-replace across many files.
Verify each migration batch in three ways: bash -n <file> per file
(syntax check), a repo-wide parse sweep confirming all consumers still parse
(e.g. all 240+ scripts), and a render-preview comparison to confirm output
formatting is visually unchanged.
fail() (non-fatal, returns 0) with die() (exits) in either the
implementation or the docs will cause scripts to either exit when they shouldn't
or silently continue when they should have stopped.sed/pattern-match
risks mojibake; use line-range-based, content-agnostic replacement instead, and
verify with a full parse sweep after each batch, not just a sample.React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Use when implementing multiple related enhancements, or a large feature that must be split across risk boundaries, and you need to decide branch/PR structure. Covers accumulating related work on one shared branch with atomic commits per enhancement, splitting risky multi-PR features along risk seams, and safely handling a branch that has both committed and dirty (uncommitted) work when shipping.
Use when a rebase or merge reports conflicts on a file where both branches only appended or inserted new content (append-only logs, registries, holding-pen documents) rather than editing the same lines. Recognizes the conflict as a false signal and resolves it as a union-keep-both operation instead of a real semantic merge.
Use when reskinning an app with a real brand's visual identity — extract the actual palette from a live site's raw CSS (not markdown), recreate logo/icon assets programmatically with documented extraction rationale, and codify everything as versioned, named design tokens rather than one-off hardcoded values.
Use when building a skill, doc, or knowledge base for an existing internal service or codebase, or when asked to audit past sessions for recurring failures and gaps — mine prior Claude conversation transcripts instead of reverse-engineering from logs or current code alone.