菜单
Wiki synchronization workflow for slf4j-toys — cloning, updating, editing, committing, and pushing content to the GitHub wiki. Use whenever planning or coding behavior changes, new features, or architectural modifications that need to be reflected in the project wiki.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create GitHub issues from AI-reported findings stored in the external findings directory (e.g., C:\git\slf4j-toys-findings\<analyzer>\<NN-scope>\). Use whenever converting analysis findings into trackable GitHub issues: reading finding files, extracting metadata into labels, creating issues via `gh issue create`, and closing resolved/accepted findings with resolution comments. Trigger on requests like "create issues", "convert findings to issues", "open GitHub issues", or any request to publish findings as repository issues — even when the word "issue" is not used explicitly.
Format and lifecycle for persisting analysis findings of slf4j-toys as Markdown files under an external findings directory (e.g., C:\git\slf4j-toys-findings\<analyzer>\<NN-scope>\). Use whenever saving new findings from a code review or audit, updating an existing finding (status change, fix validation, accepted-risk classification), renaming finding files with -accepted/-fixed suffixes, or maintaining the geral.md index. Trigger on requests like "guarde os achados", "documente as questões encontradas", "valide se o achado X foi corrigido", "marque como resolvido/aceito", or any request to record or revisit review results — even if the word "finding" is not used.
Operational workflow for Trunk-Based Development in slf4j-toys — git worktrees, branch/worktree naming, commit and push gates, rebase-based sync, opening and merging PRs, cleaning up stale branches, and cutting releases. Use at the start of ANY code, test, build-config, or non-exempt documentation change in this repo — before writing the first line — to create the dedicated branch/worktree first (never edit directly on main); do not wait to be asked about git mechanics specifically. Trigger on the request's intent, not on git-specific wording: "fix this bug/issue/problem", "implement/add this feature", and "improve/refactor this" are all trunk-based-development triggers exactly like "create a branch for X" is — and so is starting to *plan* one of these (a fix, an improvement, a new feature), even before any code is written. This includes Plan Mode: read this skill the moment planning begins, not just before ExitPlanMode — the plan must account for branch/worktree creation as its first step from the outset, no
Systematic code review and security audit methodology for slf4j-toys — analyzing Java packages for correctness, security, concurrency, design, performance, and style issues, and documenting findings as individual Markdown files under .findings/. Use whenever asked to review, audit, or analyze code for bugs, vulnerabilities, or quality issues. Covers finding categories and prefixes, file naming, per-finding Markdown structure, README index, and a principle-driven investigation approach that adapts to any code under review.
Writing conventions for Git commit messages in slf4j-toys — content only, not staging or pushing. Use whenever composing a commit message: the Conventional Commits header format (type(scope): summary), body structure, commit types and scopes, test-coverage mention, and AI attribution trailer. For staging/push/force-push mechanics and when to commit, see `trunk-based-development`; for passing a multi-line message through PowerShell, see `powershell`.
Writing conventions for Pull Request titles and descriptions in slf4j-toys — content only, not the git/gh mechanics of opening or merging one. Use whenever drafting, reviewing, or updating PR title/description text: the mandatory body sections (Context, Problem, Solution, Code Changes, Test Results), goal-oriented title format (not Conventional Commits), issue-closing keywords, and AI attribution phrasing. For the operational side (when to open a PR, how to create/merge it, branch lifecycle), see `trunk-based-development` instead.
| name | update-wiki |
| description | Wiki synchronization workflow for slf4j-toys — cloning, updating, editing, committing, and pushing content to the GitHub wiki. Use whenever planning or coding behavior changes, new features, or architectural modifications that need to be reflected in the project wiki. |
The project wiki (https://github.com/useful-toys/slf4j-toys.wiki.git) lives as a separate Git repository from the main codebase. To keep documentation in sync with code changes, this repo carries a wiki/ directory that is a full checkout of the wiki repository. Editing wiki pages directly in this working tree alongside code changes makes it straightforward to update documentation as part of the same feature or fix.
We accept that the wiki may occasionally be ahead of the code's main branch — a wiki update pushed before a PR merges is acceptable for simplicity.
Invoke this skill whenever:
wiki/ directory is checked out from https://github.com/useful-toys/slf4j-toys.wiki.git.master branch of the wiki repository (GitHub wikis use master as the default, not main).master.wiki/ directory is listed in .gitignore; its changes do not interfere with the main repository.if (-not (Test-Path -LiteralPath "wiki")) {
git clone https://github.com/useful-toys/slf4j-toys.wiki.git wiki
} else {
git -C wiki pull --ff-only origin master
}
If the fast-forward pull fails, the local wiki has diverged from the remote — stop and ask the user for guidance.
Make changes to the Markdown files under wiki/. Follow the existing conventions of the wiki:
[[PageName]] syntax for internal wiki linksStage the changed wiki files and commit with a descriptive message:
git -C wiki add <changed-page.md>
git -C wiki commit -m "Update <PageName>: <summary of change>"
Commit messages in the wiki repository are free-form (no Conventional Commits requirement). Keep them clear and descriptive.
git -C wiki push origin master
After pushing, the changes are immediately live on the GitHub wiki.
When committing the code change that motivated the wiki update, mention the wiki change in the commit message body so it's traceable (e.g., "Updated wiki: ").
trunk-based-development — branch and worktree mechanics for the main repository (not the wiki)git-commit-message — commit message conventions for the main repositorypowershell — PowerShell syntax for the git commands used in this workflow