TechLead Bits | Software Dev • Leadership • Productivity

Skill Packaging Engineering teams are actively building internal collections of skills for agents: code review, troubleshooting, design preparation, onboarding, security practices. And it looks great until you hit the question: how do you distribute those skills across dozens of teams and multiple harnesses? For Claude you need to put skills into .claude, for Cursor into .cursor, for Gemini into .gemini, etc. And things become even messier when you need to roll out updates. To solve this problem big companies mostly build their own in-house solutions. Smaller companies usually just copy files from some shared repository and manage this complexity manually. I don’t like reinventing the wheel, so when my team faced the same problem, we started looking for an existing solution we could reuse. And the only actively maintained tool we managed to find was apm by Microsoft. APM is a package manager for prompts, skills, and MCPs. In other words, it’s maven or gomod for agents. APM package structure: my-package/ ├── apm.yml └── .apm/ ├── instructions/ │ └── my.instructions.md ├── skills/ │ └── my-skill/ │ └── SKILL.md ├── agents/ └── prompts/ To install the package in a target repo you need to define apm.yaml with a list of required dependencies: name: my-projecty version: 1.0.0 targets: - claude - copilot dependencies: apm: - <git-address>/my-package - <git-address>/another-package mcp: [] After that you just run: apm install and the required skills will be installed into the corresponding harness folders (.claude, .copilot, etc.). The tool works with Github and on-prem git installations like Gitlab. APM is not perfect. It had some unpleasant (but not critical) issues, and sometimes you can really feel that it was heavily vibe-coded in Python . But despite all that, the tool actually works: you have a spec to define your skills\prompts packages, distribute and update them with simple apm update. And on top of apm dependencies format it’s pretty easy to vibe-code your own internal skills marketplace. #ai #engineering #agents

The Fearless Organization The most dangerous teams are the quiet teams. There are no disagreements, no bad news, no conflicts. Looks like harmony until the real incident. That's the topic of the book The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth by Amy C. Edmondson. Amy is a professor of Leadership and Management at the Harvard Business School. She has studied the phenomenon of psychological safety and its impact on team performance for many years across different organizations. She defines psychological safety as follows: a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes, and that the team is safe for inter-personal risk taking. What it means in practice: - people are not afraid to ask questions - they do not hide problems - they are not afraid to look stupid - they do not avoid conflicts - they can freely express their opinions and bring suggestions Why does it matter? There is a good example from the book that explains that. Imagine a doctor prescribes treatment for a child. A nurse notices that doctors usually prescribe drug A in such cases, but this time it is missing. In a team with high psychological safety, the nurse will clarify this with the doctor and may help prevent a medical error. In a team with low psychological safety, she may be afraid to ask. And the consequences can be dramatic. The core idea is simple. But the book contains a lot of real stories where a low level of psychological safety leads to dramatic results (e.g. Volkswagen emission scandal, pilot mistakes that caused plane crashes). The author repeatedly highlights that the more complex and critical the profession is, the more important psychological safety becomes. How does this relate to our daily work? We as leaders are responsible for the psychological climate in the team: how well we listen to people, accept different opinions, react to questions, mistakes, or bad news. It's our daily routine that either helps the team become more effective, or leads people to hide problems and the real state of things. Overall, I really liked the book. It explains the idea in simple language with many real examples. And what is important for me, all arguments and recommendations are supported by sociological research, experiments and practical psychology. So psychological safety is not just an idea. It is a proven behavioral model and set of practices that can actually help leaders build better teams. P.S. One of the best real examples of psychological safety is Pixar. I wrote about it earlier in overview of Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration: parts 1,2,3. #booknook #softskills #leadership

Agent Readiness Framework A few weeks ago I wrote that adopting coding agents requires strong engineering practices. Test stability, linting, documentation, security controls matter much more than a particular harness or model. Agent Readiness framework is an attempt to formalize these criteria for a particular repository and define how much autonomy can be safely delegated to agents. The framework evaluates repos across 8 dimensions: - Style & Validation - Build System - Testing - Documentation - Dev Environment - Code Quality - Observability - Security & Governance Based on these dimensions, the framework defines 5 levels of repo maturity: 🔸 Level 1: Functional. Basic checks: README, linters, unit tests. 🔸 Level 2: Documented. Detailed documentation and basic automations: AGENT.md, reproducible dev env, contribution guides. 🔸 Level 3: Standardized. E2E tests, observability, security scanning, maintained documentation. 🔸 Level 4: Optimized. Fast validation loops, canary deployments, build optimization. Process is optimized for fast feedback. 🔸 Level 5: Autonomous. Task decomposition, multi-service orchestration, self-healing logic, auto-remediation. The idea is simple: the higher the maturity level, the more predictable and reliable agent results. But looking at these levels, I can see that most repos are actually somewhere between Level 1 and Level 3. Framework authors also provide a tool to automatically measure these criteria and maturity level, but it's available only after registration and using proprietary APIs. Scanned examples you can find at https://factory.ai/agent-readiness. There is also an open-source alternative https://github.com/kodustech/agent-readiness. The project doesn't look active, but it gets the job done. It analyzes the repo and generates a report with the overall maturity level, findings for each dimension, and suggestions for improvements. Some rules are not very accurate. Looks like the project was mainly designed for python and js code verification. But anyway the tool gives you a good sense of what to pay attention to in your codebase. What I like about this framework is that it shows that agent effectiveness is actually limited by the maturity of engineering practices. And it provides measurable and actionable results, that are easy to convert into an improvement plan for a particular repo. #ai #engineering