sjunepark
24 verified skills23 total stars
summarize
Use the steipete/summarize CLI to summarize URLs, local files, stdin, YouTube links, podcasts, and media with LLM models. Use when installing or running summarize, configuring provider/API keys, tuning length/language/json/extract/slides flags, setting ~/.summarize/config.json defaults, or troubleshooting CLI errors.
tools1
post-implementation-review
Review already-implemented code for design, abstraction, ownership, structure, and maintainability issues; automatically apply straightforward recommended fixes and design-improving refactors when the best path is clear. Use only when the user explicitly asks for a post-implementation review, asks whether recent implementation work revealed design or structure problems, or asks whether implemented code should now be refactored. Ask before changing only when tradeoffs require developer taste, domain judgment, risk acceptance, or other decision-making.
development1
svelte
Build, review, refactor, and debug modern Svelte 5 components. Use for `.svelte` component design, runes, props, snippets, events, styling, context, local/shared reactive state, and Svelte reactivity gotchas, including SvelteKit apps when the issue is component-level rather than route/server-level.
development1
review-campaign
Long-running systematic codebase review with a persistent ledger in reviews/. Use to plan review areas, continue the next review pass, check campaign status, triage findings with the user, or apply auto-tier fixes. Modes: plan, continue, status, triage, fix (default continue).
development1
source-investigator
Investigate external libraries, frameworks, and unfamiliar repositories from exact source in a project-local temp clone. Use when docs are incomplete, version-specific behavior matters, codebase learning is needed, or large source exploration should be delegated to focused subagents instead of polluting the main context.
development1
diet
Review code for unearned weight, overengineering, and bolted-on design. Use when code seems overbuilt, helper-heavy, schema-heavy, field-heavy, wrapper-heavy, future-proofed, or bandaged on, or when the user asks what can be deleted, collapsed, inlined, questioned, put on a diet, trimmed, or made leaner.
tools1
briefing
Brief the user on the current task or session so they can decide next steps without reloading the codebase. Use only when they explicitly ask for a briefing, catch-up, current state, relevant architecture, implementation context, or task-scoped context recovery.
development1
architecture-md-writer
Create, update, review, or split ARCHITECTURE.md files that explain codebase shape, major components, runtime flow, code maps, and invariants. Use when architecture docs are missing, stale, too detailed, need nested subsystem docs, or need root-to-module architecture links.
development1
documentation-state-auditor
Audit repository docs for confusion between implemented state, intended or planned state, and unresolved questions, then recommend documentation boundaries, structure, progressive disclosure, and writing rules.
testing1
change-explainer
Explain a code or document change set for reviewers and maintainers, focusing on design, decisions, contracts, tradeoffs, and maintenance implications. Use for understanding a git diff, unstaged changes, commit, commit range, PR patch, or two versions of a file or document.
development1
pi-extension-intake
Evaluate, import, vendor, fork, and harden third-party pi extensions. Use when copying a pi extension into a repo, choosing vendoring vs internal fork vs patch-package vs direct dependency, auditing weakly maintained extension code, removing self-install or network-install behavior, or analyzing wrapper-package and npm package trust boundaries.
tools1
structure-review
Review code structure for unnecessary complexity and insufficient organization. Use when asked whether code is overengineered, too abstract, too flat, poorly organized/configurable/future-proof, has extra DB columns/fields/helpers, mixes responsibilities, feels heavier than needed, or should be simplified or reorganized while preserving readability.
tools1
tailwind-semantic-theme
Set up or refactor Tailwind v4 theming with shadcn-compatible semantic CSS tokens, without shadcn. Use only when explicitly named or when the exact methodology is requested: OKLCH `:root` and `.dark` variables, class-based dark mode, `@theme inline`, and shadcn-compatible token names.
development1
impeccable-june
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, empty states, UX review, visual hierarchy, information architecture, accessibility, performance, responsive behavior, theming, typography, spacing, layout, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, design systems, tokens, live browser iteration, and ambitious visual effects. Not for backend-only or non-UI tasks.
development1
learning-material-writer
Create or update repo learning material under docs/learning for programmers new to the codebase. Use only when the user explicitly asks for learning material, onboarding docs, a codebase guide, repo handbook, or docs/learning content. Treat it as onboarding guidance, not the source of truth for behavior or decisions.
development1
release-please-release
Prepare, audit, set up, and guide Release Please releases. Use when releasing, preparing or reviewing a release PR, adding Release Please, classifying SemVer impact or breaking changes, writing Release Please-compatible Conventional Commit guidance, or documenting release criteria. Release work requires existing Release Please config; setup requires an explicit setup request.
testing1
manual-branch-integrator
Manually integrate Git branch work without blind mechanical merges. Use when merging, transplanting, or refactoring branch work; resolving conflicts; preserving source-branch intent in a clean current-branch structure; or auditing that source additions, removals, tests, and docs landed intentionally.
development1
skills-cli
Manage skills with the skills CLI for Codex, Claude Code, and Pi. Use for discovering, installing, listing, updating, removing, or initializing skills; skills.sh; lock-file restore; node_modules sync; and project vs global agent installation troubleshooting.
tools1
sveltekit
Build, review, refactor, and debug modern SvelteKit apps. Use for routes, `+page/+layout/+server`, `load`, form actions, hooks, cookies, auth, invalidation, SSR, hydration, navigation, and URL/server/client state boundaries, even for small bugfixes or features.
tools1
agents-md-writer
Create, edit, review, or improve AGENTS.md files for agentic coding tools. Use when changing AGENTS.md guidance, drafting a new file, migrating legacy instruction files, defining nested overrides in monorepos, or debugging tool discovery and precedence behavior.
tools1
doc-comment-writer
Add or improve doc comments in source files without obvious restatements. Use when the user asks to document code, add doc comments, explain modules, functions, or types for maintainers, add a useful file-level overview, or make a file understandable without tracing internals.
development1
fs-merge
Merge multi-year Korean financial statements, 재무제표, BS, PL, 제조원가명세서, from PDFs or spreadsheets into one comparison .xlsx. Use when the user provides two or more Korean FS files and asks to consolidate, compare, 합본, 합치기, combine year-over-year statements, or build a merged workbook.
development1
teach
Teach how code, a subsystem, architecture area, feature flow, module, API/data boundary, or relevant technical concept works for reviewers and maintainers. Use when the user asks to understand code or concepts; focus on design, responsibilities, contracts, data flow, invariants, tradeoffs, and maintenance implications, not syntax or line-by-line execution. Use `change-explainer` for diffs, commits, or patches.
development1
post-implementation-review-loop
Iteratively review already-implemented code using the required phase_checkpoint_compact Pi extension tool at every continuing phase boundary; automatically apply straightforward Bucket I fixes, validate, and continue until no accepted Bucket I actions remain or the iteration limit is reached while Bucket II items receive recommended next actions.
tools