kirkchen
GitHub10 skills
applykirkchenUse when implementing a Beat change — requires gherkin or proposal artifact to be done firstarchivekirkchenUse when a Beat change is complete (implemented, or distilled and verified) and ready to archive — not for verifying implementationdesignkirkchenUse when starting a Beat change to create spec artifacts — not for task breakdown, implementation, or explorationdistillkirkchenUse when extracting BDD specs from existing code — for adopting Beat in an established codebase or distilling a module into feature filesexplorekirkchenUse when thinking through ideas, investigating problems, or clarifying requirements — before or during a Beat changeplankirkchenUse when breaking down a Beat change spec into tasks — not for spec creation or implementationsetupkirkchenUse when initializing Beat or updating its config — not for editing config.yaml directly or non-Beat toolsverifykirkchenUse when validating implementation against spec artifacts before archive — not for design, planning, or implementationpr-reviewkirkchenUse when reviewing a PR/MR diff for security, logic, performance, cross-file impact, test coverage, or spec compliance findings. NOT for writing PR descriptions, design reviews requiring business judgment, implementation work, release notes, or deep CVE/supply-chain audits.self-reviewkirkchenUse when doing dev-stage self-review on the current branch before pushing or opening a PR — runs an auto-loop of codex review (cross-model, OpenAI) + per-finding fix + re-review until findings converge or stop conditions fire. Codex follows pr-review's multi-role methodology (security / staff-engineer / sdet / spec-auditor). Triggers — 'self review', 'self-review', '自己 review', '自我 review', 'cross-model review', 'pre-push review', 'review and fix my branch'. NOT for live PR review with sticky/in