Larchanka Skills
Twelve standalone skills for development: an agent loop with planning and review, pull request handling, TDD and email triage.
- 56 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- Skills run `gh`, scripts and utilities on your machine.
- The mail and Slack skills read correspondence, so limit the access they get.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/larchanka-skillsDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- Skills run `gh`, scripts and utilities on your machine.
- The mail and Slack skills read correspondence, so limit the access they get.
This is third-party code. Review the repository files before installing.
What it does
A collection of twelve standalone skills for development and automation, each in its own folder with a `SKILL.md`. `agent-loop` runs a cycle of planning, development, review and publishing subagents where the coordinator never reads code and only passes tasks on. `code-review` scores changes on five axes: correctness, readability, architecture, security and performance. `codebase-context-generator` builds project context from an AST and a dependency graph in Python. The rest cover `pull-request`, `refactoring`, `test-driven-development`, `planning-and-task-breakdown`, `project-change-intelligence`, `manual-automation`, `email-triage`, `slack-cli` and `yt-random-comment-picker`. The external tools you need depend on the skill: `gh`, `yt-dlp`, `jscpd`, tree-sitter and others.
Who it is for. Developers who want ready workflows for an agent, from planning a task through publishing a pull request.
Good fit when
- A feature goes from plan to pull request through a loop of subagents with review.
- A dependency and symbol map is built before a large edit.
- Branch changes are assessed against security and performance checklists.
- Incoming mail is sorted by priority with an agent.
Not a fit when
- You need one narrow skill and do not want a whole set.
- Installing `gh`, `yt-dlp` and other CLIs on the machine is not allowed.
- The team has its own review process and will not change it.
Example request
Break the task down, implement it with TDD and prepare a pull request after a five-axis review.Limitations
There is no single install command: each skill is standalone and is cloned or copied separately, with details in its `SKILL.md`. Some skills depend on external programs such as `gh`, `yt-dlp`, Chrome, `slackcli` or gog, and on Python packages from `requirements.txt`. `email-triage` and `slack-cli` work with mail and a team chat and need access to those accounts, so grant the minimum.
How to disable. Delete the individual skill folders from the agent skills directory and revoke any access granted to mail and Slack.
FAQ
How many skills are in the repository?
Twelve, each in its own folder with a `SKILL.md` and a `README.md`.
What does `agent-loop` do?
It coordinates planning, development, review and publishing subagents. The coordinator reads no files and writes no code. Review repeats until no findings remain.
Which axes does `code-review` use?
Five: correctness, readability and simplicity, architecture, security and performance.
Are external programs required?
It depends on the skill. The README has tables: `gh`, `yt-dlp`, `jscpd`, tree-sitter and others with install commands.
Can I take just one skill?
Yes, they are independent. Copy the folder you want and follow its `SKILL.md`.
Discussion
No questions or reviews yet.
Related
SkillsNine short skills: tests, review, ADR plans, slides, a wiki, image generation, worktrees and plan implementation.
Builder Skills
Skills for agents
A set of small skills from Builder.io for agent work habits: visual plans and diff recaps, docs-first checks, cross-agent review and clean status updates
A skills library for Claude Code, Cursor and Codex: team code review, TDD, stacked PRs and repository readiness scoring
Brooklyn skills: 25 portable agent skills for pull requests, triage, cleanup, UI checks and research
A set of independent skills against drift in large codebases: hard-cut, root-cause tracing, lean testing and CI right-sizing.
A set of 17 engineering skills: evidence-driven debugging, code review, git worktrees, SSH tunnels and mobile automation.
README in short
The repository describes twelve skills, their purpose and external tool requirements, and ends with a quick dependency install summary for macOS and Linux.
README badge
Original SKILL.md
--- name: code-review description: Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. metadata: version: 1.1.0 --- # Code Review and Quality ## Overview Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance. **The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it. ## When to Use - Before merging any PR or change - After completing a feature implementation - When another agent or model produced code you need to evaluate - When refactoring existing code - After any bug fix (review both the fix and the regression test) ## The Five-Axis Review Every review evaluates code across these dimensions: ### 1. Correctness Does the code do what it claims to do? - Does it match the spec or task requirements? - Are edge cases handled (null, empty, boundary values)? - Are error paths handled (not just the happy path)? - Does it pass all tests? Are the tests actually testing the right things? - Are there off-by-one errors, race conditions, or state inconsistencies? ### 2. Readability & Simplicity Can another engineer (or agent) understand this code without the author explaining it? - Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context) - Is the control flow straightforward (avoid nested ternaries, deep callbacks)? - Is the code organized logically (related code grouped, clear module boundaries)? - Are there any "clever" tricks that should be simplified?