wtf
Explain the last message, or a supplied file, link, or passage, in plain language a person follows on the first read. Use when the user invokes wtf because they did not follow something. Use ce-explain to investigate how or why code works, and ce-noslop to rewrite prose.
- 0
- Installs
- —
- Rating
- —
- Success rate
- 2
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 7a245bcfe24d2a8c… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
wtf
The user did not follow something. Explain it the way you would to a smart colleague who was not in the room.
Done: the user can say what the source means and what, if anything, they need to decide or do, without going back to the source.
What to explain
The text the user passed with the invocation decides the target:
- Nothing passed: your most recent message.
- A file path or a link: read it, then explain it.
- A pasted passage: that passage.
- A short pointer such as "the migration part" or "step 3": only that part of the conversation.
If the target is still unclear, ask one short question instead of guessing.
How to explain
- Open with the point in one or two sentences: what this says and why the user should care. Write no preamble and no apology for the earlier wording.
- Then say what it means for them: what happened, what state things are in, and anything they need to decide or do.
- Explain the source; do not rewrite it. The explanation is shorter than the source because it leaves out whatever the user does not need in order to understand it or act on it. Do not walk a document section by section.
- Use everyday words. When a technical term matters, keep it and say what it means once, in passing. Keep the exact file names, commands, and values the user will need to use.
- Keep everything that changes what the user would do: failures, caveats, open questions, and requests. The explanation must not sound more positive or more certain than the source.
- Add no claims the source does not make. If the source is vague or contradicts itself, say so. If re-reading your own message shows it was wrong, say that and correct it.
- Plain does not mean childish. Do not force analogies, cheerlead, or talk down.
Files
2- SKILL.md
b90a6a998e2.1 KB - agents/openai.yaml
a1499d95ab43 B
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from EveryInc/compound-engineering-plugin8
Babysits an open GitHub PR until merge-ready. Use when asked to watch a PR over time — not for one-shot comment resolution or one CI failure. GitHub (incl. Enterprise) only.
Develop independent competing solutions to a defined brief, compare them, and synthesize a winning approach. Use when choosing well requires developing alternatives beyond their current form. Use ce-pov to judge developed material and ce-ideate to discover opportunities.
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology.
Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill needs a review receipt. Use when asked to apply this review's findings locally. Use ce-resolve-pr-feedback for feedback already left on a PR.
Create a git commit with a clear, value-communicating message. Use when the user asks to commit/save staged or unstaged changes with a repo-appropriate message.
Commit, push, and open a PR. Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or describing a PR body.
Document a solved problem as a durable repo learning. Use when verified work produced non-obvious reasoning absent from its final code, tests, or existing docs; avoid routine fixes whose artifacts already explain the lesson.
Refresh the repo's captured learnings against the current codebase. Use when auditing stale, overlapping, superseded, or drifted learnings; avoid general refactor, debugging, or code review unless the learnings store is explicit.