메뉴
Run a structured quality review before shipping code at any checkpoint such as PRs, releases, or milestones. Use whenever the user says.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/terrylica/cc-skills --skill pre-ship-review명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
user wants to create a macOS Calendar event with sound alarms and paired Reminders, schedule a meeting, RSVP to an invitation, or set reminders.
Park a draft message/text in macOS Notes for the operator to review and edit, then read it back before acting (e.g. before sending to a real person). Notes is the source of truth (AppleScript CRUD, iCloud-synced, provenance-stamped with the Claude Code session UUID); Stickies is a best-effort view-only desktop mirror. Use whenever you draft something a human should confirm/edit before it is sent or committed — messages, replies, announcements, anything outbound. TRIGGERS - park this draft, park the message, hold this draft, let me edit first, draft for my approval, save to notes for review, read back the draft.
Programmatic Firecrawl usage via the public API, academic paper routing, recursive deep research, and raw corpus persistence.
SOC 직업 분류 기준
| name | pre-ship-review |
| description | Run a structured quality review before shipping code at any checkpoint such as PRs, releases, or milestones. Use whenever the user says. |
| allowed-tools | Bash, Read, Grep, Glob |
Structured quality review before shipping code at any checkpoint: PRs, releases, milestones. Catches the failures that occur at integration boundaries -- where contracts, examples, constants, and tests must all agree.
Core thesis: AI-generated code excels at isolated components but fails systematically at boundaries between components. This skill systematically checks those boundaries.
Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.
Use before any significant code shipment:
NOT needed for: single-file cosmetic changes, documentation-only updates, dependency bumps.
MANDATORY: Select and load the appropriate template before starting review.
1. Detect changed files and scope (git diff --name-only against base branch)
2. Run Phase 1 - External tool checks (Pyright, Vulture, import-linter, deptry, Semgrep, Griffe)
3. Run Phase 2 - cc-skills orchestration (code-hardcode-audit, dead-code-detector, pr-gfm-validator)
4. Run Phase 2 conditional checks based on file types changed
5. Phase 3 - Verify every function parameter has at least one caller passing it by name
6. Phase 3 - Verify every config/example parameter maps to an actual function kwarg
7. Phase 3 - Check for architecture boundary violations (hardcoded feature lists, cross-layer coupling)
8. Phase 3 - Verify domain constants and formulas are correct (cross-reference cited sources)
9. Phase 3 - Audit test quality - do tests test what they claim (not side effects)?
10. Phase 3 - Check for implicit dependencies between new components
11. Phase 3 - Look for O(n^2) patterns where O(n) suffices
12. Phase 3 - Verify error messages give actionable guidance
13. Phase 3 - Confirm examples reflect actual behavior, not aspirational behavior
14. Compile findings report with severity and suggested fixes
1. Verify the fix addresses root cause, not symptom
2. Verify the fix does not mask information flow
3. Check that new test reproduces the original bug (fails without fix)
4. Run Phase 1 - External tool checks on changed files
5. Run Phase 2 - cc-skills checks on changed files
6. Verify constants consistency if any values changed
7. Compile findings report
1. Verify all callers updated to match new signatures
2. Run Phase 1 - External tool checks (especially Griffe for API drift)
3. Run Phase 2 - cc-skills checks (especially dead-code-detector)
4. Verify examples/docs updated to match new parameter names
5. Verify no dead imports from removed features
6. Check for introduced cross-boundary coupling
7. Compile findings report
Run static analysis tools on changed files. Skip any tool that is not installed (graceful degradation).
Detect scope:
git diff --name-only $(git merge-base HEAD main)...HEAD
Run in parallel:
pyright --outputjson <changed_py_files> # Type contracts
vulture <changed_py_files> --min-confidence 80 # Dead code / YAGNI
lint-imports # Architecture boundaries
deptry . # Dependency hygiene
semgrep --config .semgrep/ <changed_files> # Custom pattern rules
griffe check --against main <package> # API signature drift
What each tool catches:
| Tool | Anti-Pattern | Install |
|---|---|---|
| Pyright (strict) | Interface contracts, return types, cross-file type errors | pip install pyright |
| Vulture | Dead code, unused constants/imports (YAGNI) | pip install vulture |
| import-linter | Architecture boundary violations, forbidden imports | pip install import-linter |
| deptry | Unused/missing/transitive dependencies | pip install deptry |
| Semgrep | Non-determinism, silent param absorption, banned patterns | brew install semgrep |
| Griffe | Breaking API changes, signature drift vs base branch | pip install griffe |
Graceful degradation: If a tool is not installed, log a warning and skip it. Never fail the entire review because one optional tool is missing.
For detailed tool procedures, see Automated Checks Reference. For installation instructions, see Tool Install Guide.
Invoke existing cc-skills that complement external tools.
Always run:
Run conditionally based on changed file types:
| Condition | Skill to invoke |
|---|---|
| Python files changed | impl-standards (error handling, constants, logging) |
| 500+ lines changed | code-clone-assistant (duplicate code detection) |
| Plugin/hook files changed | plugin-validator (structure, silent failures) |
| Markdown/docs changed | link-validation (broken links, path policy) |
These checks require understanding intent, domain correctness, and architectural fitness. Go through each one manually.
Check 1: Architecture Boundaries
Check 2: Domain Correctness
Check 3: Test Quality
Check 4: Dependency Transparency
Check 5: Performance
Check 6: Error Message Quality
Check 7: Example Accuracy
**kwargs or **_?For detailed check procedures, see Judgment Checks Reference.
Phase 1 (Tools):
- [ ] Pyright strict passes on changed files (no type errors)
- [ ] Vulture finds no unused code in new files (or allowlisted)
- [ ] import-linter passes (no architecture boundary violations)
- [ ] deptry passes (no unused/missing dependencies)
- [ ] Semgrep custom rules pass (no non-determinism, no silent param absorption)
- [ ] Griffe shows no unintended API breaking changes vs base branch
Phase 2 (cc-skills):
- [ ] code-hardcode-audit passes (no magic numbers or secrets)
- [ ] dead-code-detector passes (no unused code)
- [ ] PR description links valid (pr-gfm-validator)
Phase 3 (Judgment):
- [ ] No new cross-boundary coupling introduced
- [ ] Domain constants and formulas are mathematically correct
- [ ] Tests actually test what they claim (not side effects)
- [ ] Implicit dependencies between components are documented
- [ ] No O(n^2) where O(n) suffices
- [ ] Error messages give actionable guidance
- [ ] Examples reflect actual behavior, not aspirational behavior
This skill is built on a taxonomy of 9 integration boundary anti-patterns. For the full catalog with examples, detection heuristics, and fix approaches, see Anti-Pattern Catalog.
| # | Anti-Pattern | Detection Method |
|---|---|---|
| 1 | Interface contract violation | Pyright + Griffe + manual trace |
| 2 | Misleading examples | Semgrep + manual config-to-code comparison |
| 3 | Architecture boundary violation | import-linter + manual review |
| 4 | Incorrect domain constants | Semgrep + domain expertise |
| 5 | Testing gaps | mutmut + manual test audit |
| 6 | Non-determinism | Semgrep custom rules |
| 7 | YAGNI | Vulture + dead-code-detector |
| 8 | Hidden dependencies | Manual dependency trace |
| 9 | Performance anti-patterns | Manual complexity analysis |
After modifying THIS skill:
references/ links resolve correctlyreferences/evolution-log.md| Issue | Cause | Solution |
|---|---|---|
| Tool not found | External tool not installed | Install per tool-install-guide.md or skip (graceful degradation) |
| Too many Vulture false positives | Framework entry points look unused | Create allowlist: vulture --make-whitelist > whitelist.py |
| Semgrep too slow | Large codebase scan | Scope to changed files only: semgrep --include=<changed> |
| import-linter has no contracts | Project not configured | Add [importlinter] section to pyproject.toml |
| Griffe reports false breaking changes | Intentional API change | Use griffe check --against main --allow-breaking |
| Phase 3 finds nothing but reviewer finds issues | New anti-pattern category | Add to catalog and evolution-log.md |
| cc-skill not triggering | Skill not installed in marketplace | Verify with /plugin list |
For detailed information, see:
After this skill completes, reflect before closing the task:
Do NOT defer. The next invocation inherits whatever you leave behind.