Menu
스토어 심사 거절 대응. 거절 사유 분석, 메타데이터 자동 수정, 재제출.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Convert raw feature requirements, bug reports, or rough task descriptions into a goal-optimized prompt for the agentic coding tool that will run it — Claude Code or OpenAI Codex. 거친 요구사항·버그 리포트·대충 적은 작업 설명을, 그 작업을 실제로 실행할 코딩 에이전트(Claude Code 또는 Codex)에 맞춘 goal 최적화 프롬프트로 변환한다. Use when the user wants a requirement shaped into a prompt/spec/goal for an agent — "이거 프롬프트로 만들어줘 / 변환해줘", "코덱스(codex)/클로드코드용으로", "목표·범위·완료조건 갖춘 프롬프트로" — or mentions the goal feature or /goal command. By default targets the agent running the skill (Claude Code → Claude-optimized, Codex → Codex-optimized); honors an explicit named target. Proactively fire on vague requirements headed to a coding agent ("대시보드 빠르게 해줘", "add auth", "로그인 버그 고쳐줘"). Not for implementing/debugging it yourself, codex code review, explaining /goal, translating, editing AGENTS.md, multi-agent orchestration (cmux/herdr), or writing a plan.
Use when the user wants to turn a repetitive, reviewable task into a controlled agent loop — phrases like "이거 자동화/반복하고 싶어", "루프로 돌리고 싶어", "정기적으로 점검하게 해줘", "loop engineering", "agent loop 설계", or wants to audit existing loops ("루프 점검", "loop audit"). Designs a loop with trigger·state·verification·human-gate·stop + 7 guardrails + 6 metrics, maps it onto an existing engine (herdr/loop/Cron/Workflow/Codex Automations), and writes a spec to docs/loops/. Does NOT execute loops itself and is NOT for one-off prompts (use goalcraft) or multi-agent run orchestration (use herdr/cmux).
Convert a recurring or repetitive task description into a Claude Code /loop prompt — the loop sibling of goalcraft. 반복·주기적 작업 설명을 Claude Code /loop 용 프롬프트로 변환한다(goalcraft의 loop 형제). Use when the user wants a task shaped into a /loop prompt — "루프 프롬프트로 만들어줘", "/loop 용으로", "주기적으로 반복하게", "매 N분마다 ~", "~까지 반복해서", "이거 loop으로 돌려줘" — or mentions the /loop command, recurring/scheduled in-session execution, or babysitting/polling a long-running thing. Picks the mode (fixed interval → cron, self-paced → model self-paces, or loop.md default) and bakes in an objective stop condition, an iteration ceiling, and a verification check. Proactively fire on recurring-execution requests ("배포 끝날 때까지 확인", "CI 통과할 때까지 반복", "keep checking the deploy"). Not for single-shot tasks or /goal until-condition prompts (→ goalcraft, which owns /goal), running the loop yourself, deciding whether something should be a loop or auditing loop governance (→ loop-engineering), translating, or explaining /loop.
Use when creating, revising, or critiquing frontend UI (web or mobile) where visual quality, product fit, design-system fidelity, or avoiding generic "AI-slop" output matters — e.g. "make this look good", "why does this look AI-generated", building a landing page / app screen / dashboard, or a design pass on existing UI. Turns vague design intent into a decision-first workflow: classify the surface, decide direction before code, escape default looks, build to measurable craft standards, and verify the rendered result. Portable across Claude Code and Codex.
Use when the user asks to inspect, summarize, explain, configure, connect, curate, or troubleshoot the session-journal Obsidian logging workflow for Claude Code or Codex — including pointing it at an existing/Obsidian-Sync vault, keeping AI-generated notes distinct from hand-authored ones, multi-machine setup, distilling durable knowledge, or verifying the vault config.
Use when the user asks to save durable lessons from session-journal into the LLM-Wiki, collect mistakes or insights from agent work, create reviewable wiki draft candidates, or report those draft candidates to Slack.
| name | release-fix |
| description | 스토어 심사 거절 대응. 거절 사유 분석, 메타데이터 자동 수정, 재제출. |
| user_invocable | true |
| allowed_tools | ["Bash","Read","Write","Edit"] |
~/.claude/plugins/marketplaces/gprecious-marketplace/claude-plugins/app-release/bin/app-release rejection-analyzer
⚠️
rejection-analyzer는 거절 사유 원문을 읽지 못한다. ASC API는 review 상태(REJECTED)만 노출하고 사유 텍스트는 노출하지 않는다. analyzer는 상태 문자열만 보고 분류하므로 iOS 거절은 사실상 항상category: unknown이 된다. 거절 사유 원문은 Apple 이메일(링크만 있음)도 아니고 API도 아니라 Resolution Center(웹)에만 있다 →https://appstoreconnect.apple.com/apps/<ascAppId>/distribution/reviewsubmissions/details/<submissionId>. 로그인은 사용자가 해야 한다(Claude는 비밀번호·2FA 불가). 사람이 사유 텍스트를 읽어와야 분류·수정이 가능하다. 상세:../../LESSONS.mdL1·L2.
거절된 플랫폼과 사유를 표로 표시. 권장 수정안을 제안한다. unknown이면 사용자에게 Resolution Center에서 사유 원문을 확인해 전달해달라고 요청한 뒤, 그 텍스트로 카테고리(metadata/binary/policy)를 판단한다.
release.config.json.store를 편집하거나, 메타데이터를 직접 수정 후 /release-metadata --apply로 재반영.