Other Skills: Compressed Communication, Handoff, Teaching, Writing Skills, and Safety Guardrails

Why not elaborate on each one

Matt's README categorizes skills into three types:

• Engineering: For writing real code daily
• Productivity: General workflow tools
• Misc: Small tools he keeps for personal use

The previous articles have covered the main engineering skills. This article combines the remaining productivity and misc skills because most of them are not full development processes, but rather small, useful switches for specific scenarios.

If you're only installing 5, I still recommend prioritizing:

• /grill-me
• /grill-with-docs
• /to-prd + /to-issues
• /tdd
• /improve-codebase-architecture

But if you've already got the main skills running, the following will make your daily experience smoother.

Productivity Skills

caveman: Extreme Communication Compression

/caveman is a "low token mode." It asks the agent to remove pleasantries, filler words, over-explanation, and vague buffering, retaining only technical information.

It's suitable when:

• You're iterating frequently and don't want to read long responses
• Debugging and only need facts, reasons, and next steps
• Long contexts are almost full, and output needs to be compressed
• You want to force the AI to be less verbose

It doesn't make the AI rude, but rather makes it use shorter syntax while retaining full technical precision. Note that it remains active until you explicitly exit it.

I would treat it as a temporary setting, not a long-term default. For high-risk operations, safety warnings, and complex multi-step instructions, being too brief can lead to misinterpretation.

handoff: Handing off the current conversation to the next agent

The goal of /handoff is to compress the current conversation into a handoff document and save it to the system's temporary directory, rather than polluting the current workspace.

It will include:

• Current goals
• Decisions made
• Key paths and files
• Remaining tasks
• Suggestions for which skills the next agent should call
• Redacted sensitive information

It's especially suitable when a long task is interrupted, the context is almost full, or you want to switch to a different agent.

The key point is: do not duplicate content already present in PRDs, issues, ADRs, commits, or diffs; only reference paths or URLs. The value of a handoff document is to fill in the state scattered across the conversation, not to recreate project documentation.

teach: Turning the current directory into a learning workspace

/teach is the heaviest of this group. It treats the current directory as a long-term learning workspace, maintaining:

• MISSION.md: Why you are learning this topic
• RESOURCES.md: A list of high-quality resources
• learning-records/*.md: Learning records, similar to ADRs
• lessons/*.html: Interactive lessons, one per session
• reference/*.html: Quick reference materials
• NOTES.md: Teaching preferences and work notes

Its highlight is treating learning as a long-term system, not a one-off Q&A. It particularly emphasizes:

• Mission first: Why you learn is more important than what you learn
• Retrieval practice: Using recall exercises to build long-term memory
• Spacing / interleaving: Don't be fooled by short-term fluency
• High-trust resources: Find resources first, don't rely solely on the model's memory

If you're just asking "explain X," you don't need it; if you want to study a topic for several weeks, it's very suitable.

write-a-skill: Scaffolding for writing new skills

/write-a-skill is Matt's abstraction of the skill structure itself.

It requires a skill to have at least:

skill-name/
├── SKILL.md
├── REFERENCE.md
├── EXAMPLES.md
└── scripts/

Of course, the latter three are not mandatory and are only added when the content is too long, examples are valuable, or operations can be scripted.

Its most important judgment is: description is the only information the agent sees first when deciding whether to load a skill. Therefore, the description cannot be vague like "helps process documents"; it must state:

• What capabilities it provides
• When it should be triggered
• What the trigger words or context are

This aligns with my own experience writing skills: many skills fail not because the main body is poorly written, but because the description is too generic, and the agent doesn't know it should load it.

Misc Skills

git-guardrails-claude-code: Blocking dangerous git commands

This skill equips Claude Code with a PreToolUse hook to intercept dangerous git commands before executing Bash.

By default, it blocks:

• git push
• git reset --hard
• git clean -f / git clean -fd
• git branch -D
• git checkout . / git restore .

Its value is direct: preventing the agent from pushing, hard resetting, or cleaning untracked files without your authorization.

If you frequently let AI work in real repositories, this skill is well worth installing. It's not about distrusting AI, but about intercepting highly destructive operations at the tool layer, rather than relying on prompts.

setup-pre-commit: Adding pre-commit checks to a project

/setup-pre-commit will set up:

• Husky pre-commit hook
• lint-staged + Prettier
• typecheck
• test

It will first detect the package manager, then decide what to run in the pre-commit hook based on the project's existing scripts. If typecheck or test are not present, it won't create them but will omit them and inform you.

The value of this skill is not in the configuration itself, but in Matt's quality philosophy: don't just let the AI say the code is fine; make it pass deterministic checks.

migrate-to-shoehorn: Reducing as in tests

This is a very Total TypeScript-style small tool. It migrates TypeScript as type assertions in tests to @total-typescript/shoehorn.

Typical replacements:

It is explicitly for test code, not production code.

This skill is narrow, but it aligns with Matt's engineering taste: don't create 20 meaningless fields in tests for the sake of the type system, and don't completely turn off type safety with bare as.

scaffold-exercises: Generating exercise directories for course repositories

This skill clearly comes from Matt's own course creation workflow. It creates directories according to specifications:

exercises/
└── 05-memory-skill-building/
    └── 05.02-short-term-memory/
        ├── explainer/
        ├── problem/
        └── solution/

Each subdirectory must have a non-empty readme.md, main.ts if necessary, and must pass pnpm ai-hero-cli internal lint.

It's not useful for most engineering projects, but it's very practical for courses, bootcamps, and exercise repositories. More importantly, it demonstrates a characteristic of a good skill: delegating repetitive, mechanical, and detail-prone formatting work to the agent.

Directories not recommended for the main line at present

The upstream repository also contains deprecated/, in-progress/, and personal/.

I suggest not writing them into formal usage guides for now:

If they are to be written about in the future, a separate article on "Matt Pocock skills repository archaeology" could be made, rather than mixing them with stable recommendations.

Commonalities of this set of small tools

These skills may seem scattered, but they share a common principle:

Turn things that agents tend to drift on into small, well-defined work patterns.

• caveman prevents communication drift
• handoff prevents context loss
• teach prevents learning from becoming a one-off Q&A
• write-a-skill prevents ad-hoc skill structures
• git-guardrails prevents dangerous commands from relying on self-awareness
• setup-pre-commit prevents quality checks from relying on AI's self-description
• migrate-to-shoehorn prevents test type assertions from getting out of control
• scaffold-exercises prevents manual omissions in course structures

This is also the most valuable aspect of Matt's repository to learn from: skills don't need to be grand. A small, frequent deviation, if it can be consistently corrected by 20 lines of instructions, is worth writing as a skill.

References