bendyworks/rules-that-bend

Working agreements, engineering guidance, and skills for developing with
Claude Code, from
Bendyworks. They grew out of many sessions of
day-to-day work with Claude across many projects.
Every rule here bends: each guidance file is a shared default, and your
project's own rules win wherever the two disagree. Take what fits: import a
single guidance file, copy one skill, or install the whole plugin.
It all keeps evolving. It works for us, but expect rough edges --
issues and pull requests are welcome (see CONTRIBUTING).
This repository was formerly bendyworks/claude-skills. GitHub
redirects the old name here only while no other repository takes it, so
that name stays retired.
Install
The skills install as a Claude Code plugin. From inside Claude Code:
The repository name is only where the marketplace is fetched from: the
marketplace and its plugin both register as bendyworks, which is the
name you type from then on. Installed skills are namespaced: invoke them
as /bendyworks: , e.g. /bendyworks:gauntlet. Claude also
triggers them automatically when a task matches a skill's description.
To pick up updates later:
If you added the marketplace under its former name, everything keeps
working through GitHub's redirect. To point it at the new name instead,
remove it and install again:
Skills
| Skill | What it does |
| --- | --- |
| gauntlet | Harden the quality of a branch that already accomplishes your goal and you now want to improve. This is a Rails-oriented multi-front quality pass on a feature branch whose specs and lint already pass. True superset of Anthropic's built-in /code-review skill. Includes: code review, then parallel audits (idioms, test quality, validation bypass, security), consolidated into one punch list, and a fresh-eyes bug hunt on the result. Clear-cut findings get fixed without stopping; a finding for a case that cannot happen yet, or a nit or refactor in code the branch did not touch, is listed and left unfixed; the judgment calls come back to you as one batch of questions. |
| plan-issue | Plan a story end-to-end: interview, research, propose a plan with steps for a full life cycle, challenge it from a fresh perspective, record it, work the to-dos, and finish after ship. On GitHub Issues it marks the issue in progress when a session picks it up, where the repository has that label and the project has not declined it (it offers to create a missing one), so parallel sessions can see which issues are taken. Where the project has priority labels, an issue it drafts shows one proposed priority with a reason and is filed once you confirm it, and an issue nobody has judged gets a proposal when a session picks it up. |
| finished-issue-housekeeping | Post-ship cleanup once a story is merged and deployed (just merged, on a project in Deploy-on-Merge Mode): finalize the plan file, move the issue to Done (on GitHub, close it and remove its in progress label), prune branches, save the story's lessons as rules or skills, tidy memory and task lists, run an approval-gated permission-prompt sweep that can propose additions to the project's .claude/settings.json, and commit the files the pass wrote: to the default branch where the project declares that, otherwise on a draft pull request. The pass ends on one sentence saying whether the session is safe to leave, with each reason when it is not. On GitHub Issues, where the project has priority labels (or, for an issue bound for another repository, where that repository does), an issue the pass files is shown first with one proposed priority and a reason, and is filed once you confirm it. Where the project itself has priority labels, the pass also counts its open issues waiting for a priority, and when one was opened more than a week ago or more than five are waiting it offers a table of proposed labels for the oldest ten. |