lencx skills
lencx-skills
Two skills for Claude Code and Codex: keel works through architecture questions, coding-protocol keeps code edits inside the task
- 197 ★ on the repository
- Last commit
- MIT
Minimal access
Why this level
- The skills are instructions and reference files, they run nothing themselves and make no network calls
- Coding-protocol narrows what the agent does, but the agent still edits files and Git with the permissions it already has
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/lencx-skillsDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewMinimal accessThe tool runs nothing and makes no network calls.
- The skills are instructions and reference files, they run nothing themselves and make no network calls
- Coding-protocol narrows what the agent does, but the agent still edits files and Git with the permissions it already has
This is third-party code. Review the repository files before installing.
What it does
A pair of skills installed together. Keel kicks in when you must choose, review or keep load-bearing architecture: who owns what, where module boundaries run, who holds state, what the contracts and recovery paths look like. It works in four modes: decision (compare options), judgment of an existing design, governance of an architecture already adopted, and exit when the architecture is fixed and only implementation remains. Coding-protocol applies to code edits, debugging, review, implementation plans and Git operations. It scales caution with risk. For reading it changes nothing, for a contained edit it runs the narrowest check, for a bug or refactor it reproduces the problem and finds consumers of the changed code, and before an irreversible action it pins down the target, the authority and the recovery path. Conclusions rest on code, tests and command output, and a check counts as passed only if it was actually run. Both skills check whether the task suits them. If it does not, the skill says so, looks for a suitable owning skill in the catalog and hands the work over.
Who it is for. Developers and tech leads who give an agent edits in an existing repository and want it to respect architectural boundaries and stay inside the task.
Good fit when
- You are designing a new service and want a comparison of several viable options for module boundaries and state ownership
- An RFC or a finished design exists, and the agent should judge it against stated criteria without proposing a replacement
- Architecture rules in the repository are bypassed again and again, and you must decide whether to restore the guard, move the rule or delete it
- An agent fixes a bug in a shared contract, and the edit needs a reproduction and a list of consumers first
- Before a commit or merge, other people's uncommitted changes in the working tree must stay untouched
Not a fit when
- The architecture is already fixed and only implementation is left: keel exits such a task by itself
- You need a code explanation or a prose edit with no contract changes: coding-protocol does not take such tasks
- The set is already installed as a plugin: a second install method duplicates every skill
- You want advice on a specific framework: the skills describe a general way of working and are not tied to a stack
Example request
Use keel to compare two options for the boundary between the orders module and the payments module and recommend one, naming the assumptions the choice depends onLimitations
- The skills are large: keel's SKILL.md runs about 130 lines and six reference files load as work goes on, so small tasks spend context for little.
- The skill texts are in English. The modes are strict: on an unsuitable task a skill states the mismatch and steps aside.
- Installing both ways creates duplicates, so pick either the skills installer or the plugin.
- The latest commit is dated 21 August 2026, and the repository has no tests or sample runs.
How to disable. Delete the keel and coding-protocol folders from the agent's skills directory. If you installed the plugin, disable lencx-skills in the Claude Code or Codex plugin manager.
FAQ
How is keel different from coding-protocol?
Keel handles architecture-level questions: boundaries, state ownership, contracts, migrations. Coding-protocol governs the editing process itself: checks, evidence, preserving other people's changes. When the architecture is already chosen, keel yields to plain implementation.
How do I install lencx/skills in Claude Code?
Run `npx skills@latest add lencx/skills -a claude-code -g`, or add the plugin with `claude plugin marketplace add lencx/skills` and `claude plugin install lencx-skills@lencx`. Pick one of the two, or the skills will appear twice.
What does keel do when the architecture is already fixed?
It exits the task: it states that only implementation remains, looks in the skill catalog for a suitable owning skill and leaves the work to the agent's general mode.
Which agents does lencx/skills support?
Claude Code and Codex. Each has a native plugin, and `npx skills@latest add lencx/skills -a claude-code -g` or `-a codex -g` installs the skills for the chosen agent.
What does coding-protocol do when I only need code explained?
Nothing. It skips explanations and prose edits that change no contracts: it states the mismatch and hands the task back to the agent's general mode.
Discussion
No questions or reviews yet.
Related
SkillsA Claude Code skill that delegates tasks to OpenAI's Codex CLI for code analysis, review and edits
Standalone skills for the whole development lifecycle: product, architecture, planning, implementation, QA, delivery and operations
14 skills that find the gaps in a task before the code: interviews, plans, assumption tests and proof that a bug fix works
22 skills for the full Claude Code project lifecycle: setup and task scope, code review, pre-push checks and session notes.
A set of Claude Code utilities: background skills, expert agents, slash commands and prompt templates for development
61 small skills for Codex across 13 areas: codebase orientation, tests, migrations, security, CI and pull request review
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| lencx skills (this card) | no | 197 | |
| The Architect | no | 574 | a plugin that interviews you and writes a build plan, while here the skills judge and govern the architecture of an existing system |
| architecture-map | no | 383 | a skill that draws a repository map, while keel makes architecture decisions and keeps them enforced |
README in short
The README covers installation (the skills installer or a native plugin for Claude Code and Codex), the list of two skills and recommended companions: Matt Pocock's Skills for engineering workflows and Impeccable for interface design. The author advises stating the goal, success criteria and constraints and leaving the step plan to the agent.
README badge
Original SKILL.md
--- name: keel description: "Design, review, or govern load-bearing architecture for open choices, design judgments, or long-lived health; skip fixed-architecture execution. Applies to new/existing systems. Private/local/reversible module boundaries qualify; scale rigor to impact. Covers responsibility/authority, interfaces/contracts, dependency/state/recovery, structural seams, guards/exceptions, drift/rot, migration, retirement, deletion, and rewrite risk." --- # Keel Keel discovers, judges, and governs load-bearing arrangements. It shapes the best-supported direction and keeps declared architecture enforceable, economical, migratable, and deletable as the system evolves. Use *keel* at module, boundary, and system scale for responsibility between parts, authority or ownership, interfaces or contracts, dependency direction, state or recovery ownership, and seams that isolate future change. Use repository-native terms and treat applicable instructions, records, contracts, and entry paths as evidence rather than decoration. ## State And Ownership Inspect only enough of the request, governing sources, and representative call sites or contracts to select the current state. Transition only when evidence changes the architecture job: - **Decision** — establish, change, or compare a load-bearing arrangement. This includes greenfield work and an authorized improvement to an existing target. - **Judgment** — evaluate the adequacy, conformance, or feasibility of a supplied architecture, design, RFC, change set, or existing system. Keep the target fixed. If it is infeasible, finish Open with evidence and required decision authority; enter Decision only when selection or improvement is authorized. - **Governance** — decide whether to restore, retain, migrate, retire, or remove a declared or evidenced architecture arrangement or control, or judge its long-lived health. Evidence must show a load-bearing obligation, recurring bypass, or architecture drift rather than ordinary maintenance. Enter Decision only when an authorized remedy requires a new load-bearing arrangement. - **Exit** — the request and governing sources fix a feasible material architecture and the remaining task only implements, diagnoses, tunes, tests, or verifies within it. Re-enter only when evidence opens a materially different load-bearing Decision, Judgment, or Governance issue. Private, local, reversible, and single-consumer choices can still require Decision or Judgment; scale evidence and ceremony to impact, reversibility, and uncertainty. Focused workflows own their domain evidence, criteria, method, vocabulary, artifact, professional judgment, and completion condition. Keel integrates only the load-bearing architecture result under declared decision authority; execution workflows own mutation, work preservation, test mechanics, and verification. Automatic or forced loading grants neither applicability nor action authority. On Exit, inspect the skill catalog when the host exposes one, select and completely read a suitable owning workflow when present, and otherwise continue with the general workflow. Stop using Keel-specific routes, references, and output framing. ## Solve Constructively Decision, Judgment, and Governance share a bounded evidence loop but do different work. Decision compares directions. Judgment tests the supplied target and transitions to Decision before proposing improvements. Governance compares applicable restoration, retention, migration, retirement, removal, and no-action responses. 1. **Frame and inspect** — state the current state's question, desired outcome, authority, hard constraints, and criteria. **Greenfield evidence** consists of user goals, explicit external constraints, provenance-bearing focused or domain findings, and operating context. Treat architecture shapes as candidates, label assumptions, and treat absent repository precedent as unavailable rather than inventing inherited architecture. Search only for evidence likely to change the framing, candidate set, or result. 2. **Form, test, or compare** — for Decision, derive the smallest set of materially distinct viable directions needed to expose the real tradeoff. For Judgment, test the supplied target against the same declared criteria without generating replacement directions. For Governance, compare only applicable interventions. Include a simpler or no-change result when credible; do not invent alternatives when constraints leave one path. Use a bounded model, characterization, conformance check, or reversible experiment when it is the cheapest decision-changing evidence. 3. **Integrate and return** — preserve focused-workflow findings, assess evidence and any real candidates on the same criteria, and return the best-supported direction, verdict, or governance action with its material tradeoffs and confidence. Surface a better option the user did not name when evidence supports it without silently changing the goal. 4. **Deepen only the supported result** — resolve numbered concerns only when their answers can still change the result, adoption, recovery, or retirement plan. Stop when more search, options, or detail are unlikely to change the result or close a material risk. If new evidence reopens a viable direction, compare it rather than defending the incumbent. Decision, Judgment, and Governance finish in one of two states; Exit hands off without this framing: - **Closed** — the best-supported result, applicable authority, accountability, and material risks are resolved; no known unknown can still change the result.