Sharing Claude Code Workflows: CLAUDE.md, Skills, Hooks and CI

1.CLAUDE.md: context every session starts with

A good prompt helps one developer for one session. To make a workflow repeatable across a team, it has to live in files that Claude Code loads automatically. The first of these is CLAUDE.md, a markdown file of project-specific instructions, conventions and context that Claude reads at the start of every session. /init generates a starter version. Keep it short and practical. It works best for things Claude cannot work out from the code, such as your preferred test runner:

# Code style
- Use ES modules (import/export) syntax, not CommonJS (require)
- Destructure imports when possible (eg. import { foo } from 'bar')

# Workflow
- Be sure to typecheck when you're done making a series of code changes
- Prefer running single tests, and not the whole test suite, for performance

CLAUDE.md can also control what survives context compaction. For example, an instruction to always keep the list of modified files and the test commands means a long session does not lose them.

Sources12

2.Skills: a team prompt library as files

When a team keeps typing the same multi-step prompt, turn it into a skill. A skill is a SKILL.md file with frontmatter and instructions. Claude can load it when its description matches the task, or you can run it as a slash command. Inside the instructions, $ARGUMENTS is replaced by whatever you type after the command. disable-model-invocation: true means the skill runs only when you invoke it yourself, which suits workflows with side effects such as pushing a PR.

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue:  ? .

Where you save the skill decides who gets it. A personal skill in ~/.claude/skills/ follows you across your own projects on that machine only. A project skill in .claude/skills/ loads for anyone working in the repository once it is committed. That makes the repository the natural home for a team prompt library. The older .claude/commands/ format still works, but skills are preferred for new work because they can also include supporting files. For delegated reviews, the same idea applies to subagents. The best-practices guide's example is a security-reviewer with a limited set of tools and its own instructions:

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Sources3

3.Hooks: actions that always run

CLAUDE.md and skills are instructions that Claude interprets. Hooks are different: they are shell commands that Claude Code runs automatically at fixed points in its lifecycle, whatever the model decides. Use them for rules that must hold every time, such as formatting each edited file, blocking edits to protected files, or sending a notification when Claude needs input. This hook runs Prettier after every Edit or Write tool call:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" }]
      }
    ],

The matcher field limits which tools trigger the hook. A SessionStart hook with the compact matcher can re-inject reminders, such as "use Bun, not npm", after compaction.

Sources4

4.Taking workflows into scripts and CI

The last step is running Claude without anyone at a terminal. The -p flag makes Claude Code scriptable, so you can pipe input in and read output for batch jobs or CI:

git log --oneline -20 | claude -p "summarize these recent commits"

For repository events, use the Claude Code GitHub Action. /install-github-app handles setup. It runs in two modes. In interactive mode, the workflow gives no prompt, and Claude waits for an @claude mention in an issue or PR, then replies in a comment. In automation mode, the workflow supplies a prompt, which can be a project skill such as /skill-name, and Claude runs without waiting for a mention. By default, its results go to the workflow run log, not a comment. The code-review plugin posts findings on the PR only when you pass --comment. For recurring jobs, choose by where the work has to run: Routines run in the cloud even when your computer is off, desktop scheduled tasks need local files, GitHub Actions ties into repository events, and /loop polls during an open session.

Sources56

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A skill saved in ~/.claude/skills/ is available to everyone on the team.Why is that wrong?

   Personal skills load only for your own projects on your own machine. To share a skill, put it in the project's .claude/skills/ and commit it.

   Covered in Skills: a team prompt library as files

2. 2.A thorough CLAUDE.md should walk through every file in the codebase.Why is that wrong?

   File-by-file descriptions are on the exclude list. Claude can read the code itself, so CLAUDE.md should hold what it cannot work out on its own.

   Covered in CLAUDE.md: context every session starts with

3. 3.When the GitHub Action runs with a prompt, Claude posts its results as a PR comment automatically.Why is that wrong?

   In automation mode, results go to the workflow run log by default. Claude posts to the issue or PR only if the prompt tells it to and it has a tool that can post.

   Covered in Taking workflows into scripts and CI

Practise it for real

Create a personal skill that summarizes your uncommitted changes and flags risks

1. 1.Run: mkdir -p ~/.claude/skills/summarize-changes

   Why: Personal skills live in ~/.claude/skills/<skill-name>/ and load in all your projects on this machine

   You should see: An empty summarize-changes directory

2. 2.Create SKILL.md in that directory with a description frontmatter, a '## Current changes' heading followed by !git diff HEAD, and instructions to summarize the diff in two or three bullets and list risks

   Why: The description tells Claude when to load the skill, and the !git diff HEAD line puts the live diff into the skill's content

   You should see: A SKILL.md file whose description mentions what changed, commit messages and diff review

3. 3.In a repository with uncommitted edits, start claude and ask: What did I change?

   Why: Checks that Claude loads the skill automatically when the request matches its description

   You should see: A short bullet summary of your diff followed by any risks, such as missing error handling

4. 4.Run /summarize-changes directly

   Why: Checks that the skill also works as an explicit slash command

   You should see: The same kind of summary, or a note that there are no uncommitted changes if the diff is empty