MongLong0214

commitlore-commits

Use when about to make a git commit and there is decision context worth recording — a constraint that shaped the change, an alternative that was tried and dropped, a warning for whoever touches this next. Drives the CommitLore capture pipeline, which drafts a record from the session transcript and the staged diff, machine-checks every quote against them, and binds what survives to the commit it was prepared for. Applies to an ordinary commit request, not only to one that names CommitLore: most commits carry nothing worth recording and this skill is silent on them, so the cost of considering it is a judgement the agent makes and drops. Trigger phrases include "commit this", "commit these changes", "finish up and commit", "commit this with commitlore", "write a commitlore record for this change", "capture the decision context for this commit", "what should I record about why I ruled out X", "커밋해줘", "수정 완료하고 커밋해", "commitlore 기록 남겨서 커밋해줘", "이 변경 결정 맥락 커밋에 남겨줘".

commitlore-query

Use when about to read, edit, or reason about a file and it would help to know its recorded decision history — active constraints, alternatives already ruled out, warnings left by a previous author, or which records have gone stale. Reads CommitLore records for a path or the whole repo without re-deriving them from raw git log. Trigger phrases include "what does commitlore know about this file", "why was X ruled out here", "any warnings on this path", "check for stale records", "has this approach been tried before", "이 파일에 대한 commitlore 기록 보여줘", "여기서 뭐가 기각됐는지 확인해줘".

commitlore-setup

Use when a git repository needs CommitLore wired up for the first time, or when its hook/notes configuration looks broken. Runs the diagnostic, installs the commit-msg validation hook, fixes the notes fetch refspec so records survive a clone or fetch, and builds the local record index. Trigger phrases include "set up commitlore in this repo", "install the commitlore hook", "commitlore doctor is warning", "why isn't commitlore capturing commits here", "wire up commit trailers", "commitlore 저장소에 붙여줘", "commitlore 훅 설치해줘".

commitlore-codex

Use when reading or changing a repository would benefit from its recorded decision history, or when a commit may need verified decision context. Query before edits, guard against previously rejected approaches, and capture supported records before committing.

sol-simplify-review

The default protocol for any merge-gate or pre-merge review: inventory the reviewed head once, exhaustively, then verify only closure and remediation regressions. Use whenever a change is about to be merged and someone is reviewing it — not only when asked for it by name, and not only when rounds have already gone badly. Writing a fresh ad-hoc review prompt for a merge is the failure this replaces, and it happens most under time pressure or when a usual reviewing model is unavailable: swap the model inside this protocol rather than abandoning it. Skip only for an ordinary small one-pass read where nothing merges.

sol-simplify-audit

Diagnoses a repository that has accumulated agent-built bureaucracy. Measures how much of the codebase exists to police the work rather than do it, finds the maintenance loops that produce commits with no product value, and ranks what to delete. Use when the user says "audit this repo for ceremony", "why is this repo so slow", "we spend all our time on tooling", "find the bureaucracy", "sol-simplify-audit", or when a project is visibly stalled on its own gates and validators. One-shot report; deletes nothing.

sol-simplify

Stops an agent from manufacturing process around its own work — invented gates, approval flows, traceability matrices, verification machinery, and governance documents nobody asked for. Use when producing any document, plan, PRD, spec, design doc, ticket, ADR, or roadmap; when setting up a repository, workflow, or CI; when adding a check, validator, or gate; and whenever work has stalled on its own tooling. Triggers include "sol-simplify", "PRD", "spec", "design doc", "plan this", "roadmap", "set up the repo", "quality gates", "process", "governance", "설계", "문서", "계획", "기획", "검증", "프로세스", or any complaint about bloat, ceremony, bureaucracy, or over-engineering. Never for product work — writing tests, fixing vulnerabilities, input validation, error handling, accessibility, or data migrations.

code-reviewer

Reviews a diff or a file for defects. Use when asked to review code, check a pull request, look for bugs, assess code quality, or give feedback on an implementation. Triggers include "review this", "code review", "PR 리뷰", "코드 리뷰", "버그 있는지 봐줘".

release-planner

Plans and documents software releases. Use when preparing a release, writing a rollout or deployment plan, defining release phases, cutting a release branch, drafting release notes, or coordinating a staged rollout. Triggers include "release", "rollout", "deploy plan", "release notes", "출시", "배포 계획", "릴리스".

security-review

Finds and fixes security vulnerabilities in application code. Use when asked about injection, XSS, CSRF, authentication or authorization flaws, secret handling, unsafe deserialization, or when hardening an endpoint. Triggers include "vulnerability", "SQL injection", "취약점", "보안", "인증 우회".

Testing & QA Listed

test-writer

Writes unit and integration tests. Use when asked to add tests, improve coverage, write a regression test for a bug, or set up a test file for existing code. Triggers include "write tests", "unit test", "regression test", "테스트 작성", "테스트 코드", "커버리지".

aos

Use when the operator asks what went wrong in a coding session, what they keep doing wrong across sessions, or how well they run their agents. Reads Codex and Claude Code transcripts already on disk (free, no model call), or runs a scored assessment against their agent CLIs (spends quota).

0 Updated today