- Skills
- 10
- 仓库
- 1
- 职业覆盖
- 5
- 场景覆盖
- 2
- Stars
- ★ 0
SikongJueluo 的 Skills 10
teaching
Teach toward a maintainable implementation when the user asks to learn before building, or says they are unfamiliar with technology required by a development task. Use for conversational co-design tied to real project work; not for general explanations, standalone tutorials, or persistent courses.
teach-me
Learn enough to co-design and maintain a real development change.
review-with-me
Curate the code worth a human's attention and present it in reviewable slices.
refactor-ui
Improve an existing UI, screen, slide deck, or visual artifact that the user mostly accepts but finds too busy, unclear, inconsistent, ugly, plain, or over-decorated. Use when the user gives feedback on a rendered artifact and wants a bounded revision that preserves what works. Not for building from scratch, exploring an undecided visual direction, deck production or conversion, or implementing a specified design.
jj-describe
Write and apply concise, self-contained Conventional Commits descriptions for Jujutsu commits. Use when the user asks to describe a jj commit, and after completing a cohesive code or documentation change in a jj repository when the current non-empty commit is undescribed. Explain what changed and why without context-only planning labels such as P0 or P1.
jj-desc
Write a concise, self-contained Jujutsu commit description that explains what changed and why.
frontend-slides
Create, convert, or revise browser-based 16:9 HTML slide decks, including PPT/PPTX conversion, Chinese/CJK typography, and PDF export. Use when the user asks for a presentation, slide deck, pitch or talk slides, or wants an existing HTML deck changed. Not for ordinary websites, landing pages, written documents, or summarizing an existing presentation.
code-craft
Contract-first coding standard for writing code. Use before you implement a feature or fix, refactor code, or write tests, and when trimming code you just wrote that accumulated defensive guards, silent fallbacks, speculative abstractions, or unrelated changes. Write against the checked contract and the current requirement instead of coding around uncertainty. Not an independent review or merge decision; to review a diff, use code-craft-review.
code-craft-review
Independent code-quality review of a finished change. Use when asked to review a diff, files, or patch for unearned defensive code, silent fallbacks, speculative abstractions, naming, control flow, and scope, or when dispatched after implementation as the reviewer. Checks the change against the shared code-craft standard and reports actionable findings. Not an architecture review or a merge decision.
arch-code-review
Architecture-first merge-decision review. Use only on explicit request to review whether a diff/PR/branch can be merged. Infers the minimum closed loop this change must complete, inspects the diff against authoritative docs, gathers validation evidence, and decides mergeability. Not for ordinary coding, debugging, refactoring, or casual code reading.