b4push-wisdom

Guide for setting up before-push validation (b4push) and CI checking. Covers analyzing project structure, creating run-b4push.sh, adding package.json entry, creating project-specific b4push skill, setting up GitHub Actions CI. Use when: (1) User says 'set up b4push', 'add CI', 'before push checks', (2) Setting up a new project's validation workflow, (3) User wants CI + local validation.

6 stars

byTakazudo

View on GitHub Installation ↓

Best use case

b4push-wisdom is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Teams using b4push-wisdom should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

You only need a quick one-off answer and do not need a reusable workflow.
You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/b4push-wisdom/SKILL.md --create-dirs "https://raw.githubusercontent.com/Takazudo/claude-resources/main/skills/b4push-wisdom/SKILL.md"

Manual Installation

Download SKILL.md from GitHub
Place it in .claude/skills/b4push-wisdom/SKILL.md inside your project
Restart your AI agent — it will auto-discover the skill

How b4push-wisdom Compares

Feature / Agent	b4push-wisdom	Standard Approach
Platform Support	Not specified	Limited / Varies
Context Awareness	High	Baseline
Installation Complexity	Unknown	N/A

Frequently Asked Questions

What does this skill do?

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# B4Push Wisdom — Full Validation Setup Guide

Set up comprehensive before-push validation and CI for any project. This covers three parts:

1. **b4push script** — local validation before pushing
2. **b4push skill** — Claude Code skill to run b4push with auto-fix
3. **CI workflow** — GitHub Actions to enforce checks on PRs and main

## Step 1: Analyze the project

Read `package.json` and explore the project structure to understand:

- **Package manager**: Check for `pnpm-lock.yaml`, `package-lock.json`, `yarn.lock`
- **Available scripts**: `check`, `build`, `test`, `lint`, `format`, `typecheck`
- **Workspace packages**: Check `pnpm-workspace.yaml` for sub-packages with their own tests
- **Doc site**: Look for `doc/`, `docs/`, `website/` directories with their own `package.json`
- **E2E tests**: Check for `playwright.config.*`, `cypress.config.*`
- **Data generation**: Check for `generate-*` scripts

## Step 2: Determine b4push steps

Common patterns (adapt to project):

| Step | Command | When to include |
| --- | --- | --- |
| Workspace tests | `pnpm --filter "@scope/*" test` | If pnpm workspace with test scripts |
| App unit tests | `pnpm --filter app-name test:unit` | If app has unit tests |
| Code quality | `pnpm check` or `pnpm lint && pnpm format` | Always |
| TypeScript | `pnpm typecheck` or `pnpm --filter name typecheck` | If TypeScript |
| Build | `pnpm build` | If build script exists |
| Doc quality | `cd doc && pnpm check` | If doc site has check script |
| Doc build | `cd doc && pnpm build` | If doc site exists |
| E2E tests | Start server + run playwright | If e2e tests exist |

## Step 3: Create `scripts/run-b4push.sh`

Use this template structure:

```bash
#!/usr/bin/env bash
set -euo pipefail

START_TIME=$(date +%s)
FAILURES=()

step() {
  echo ""
  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
  echo "▶ $1"
  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
}

pass() { echo "✅ $1"; }
fail() { echo "❌ $1"; FAILURES+=("$1"); }

ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"

# Steps here — each wrapped in:
# step "Step N/M: Description"
# if (cd "$ROOT_DIR" && command); then
#   pass "Description passed"
# else
#   fail "Description"
# fi

# Summary
END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))

echo ""
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "  SUMMARY (${DURATION}s)"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

if [ ${#FAILURES[@]} -eq 0 ]; then
  echo "✅ All checks passed! Safe to push."
  exit 0
else
  echo "❌ ${#FAILURES[@]} check(s) failed:"
  for f in "${FAILURES[@]}"; do
    echo "   - $f"
  done
  exit 1
fi
```

Key rules:

- `set -euo pipefail` for strict error handling
- Continue all steps even if some fail (collect in FAILURES array)
- Subshell execution `(cd "$ROOT_DIR" && command)` to isolate
- Summary at the end with elapsed time

Make executable: `chmod +x scripts/run-b4push.sh`

## Step 4: Add package.json script

```json
{
  "scripts": {
    "b4push": "./scripts/run-b4push.sh"
  }
}
```

## Step 5: Create project-specific b4push skill

Create `.claude/skills/b4push/skill.md`:

```markdown
---
name: b4push
description: >-
  Run comprehensive pre-push validation covering [list steps]. Use when: (1) Completing a PR
  or feature implementation, (2) Before pushing significant changes, (3) After large refactors,
  (4) User says 'b4push', 'before push', 'check everything', or 'ready to push'.
user-invocable: true
allowed-tools:
  - Bash
---

# Before Push Check

Run `pnpm b4push` from the project root. This executes `scripts/run-b4push.sh`:

1. [Step list with descriptions]

Takes ~[duration]. All steps must pass.

## On failure

1. Read the failure output to identify which step failed
2. Auto-fix what you can:
   - Formatting: `pnpm check:fix` or `cd doc && pnpm check:fix`
   - Lint: `pnpm lint:fix` or `cd doc && pnpm lint:fix`
3. Re-run `pnpm b4push` to confirm all checks pass
4. Report the final status
```

## Step 6: Create GitHub Actions CI workflow (optional)

If the project uses GitHub and doesn't have CI yet, create `.github/workflows/ci.yml`:

```yaml
name: CI

on:
  pull_request:
    types: [opened, synchronize, reopened]
    branches: [main]
  push:
    branches: [main]

concurrency:
  group: ci-${{ github.head_ref || github.ref }}
  cancel-in-progress: true

jobs:
  checks:
    name: Checks
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 10

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'

      - run: pnpm install --frozen-lockfile

      # Mirror the b4push steps here
      - name: [Step description]
        run: [command]
```

The CI workflow should mirror the b4push steps so local and CI validation are consistent.

Key CI patterns:

- Cancel previous runs for same PR (`concurrency` group)
- Use `pnpm/action-setup@v4` + `actions/setup-node@v4` with cache
- `pnpm install --frozen-lockfile` for reproducible installs
- Each step as a separate `run` for clear failure identification

## Step 7: Test

Run `pnpm b4push` to verify all steps execute correctly. Fix any issues found.

## Reference projects

These projects have working b4push setups:

- **message (zudomessages)**: 4 steps (workspace tests, app tests, doc checks, doc build), ~1-2 min
- **mdx-formatter**: 6 steps (quality, build, test, doc data, doc quality, doc build), ~40s
- **zmod**: 9 steps including e2e with production server, ~3-4 min
- **zpanels**: Dual-track (quick ~3-5 min, full with e2e ~10-15 min)

Related Skills

prototype-first-wisdom

from Takazudo/claude-resources

Solve a complex bug or design problem by building a tiny isolated prototype first, instead of patching the production system in place. Trigger PROACTIVELY when (1) the same bug has resisted 2+ in-place fix attempts (fail-retry loop), (2) the user mentions "minimal prototype", "from zero", "from scratch", "simple script", "sandbox", "standalone", "isolate", "play around", or "try a sandbox version", (3) you find yourself ranking a list of suspects and ruling them out via source-grep on a runtime/visual bug, (4) the user is brainstorming many design options for a UI surface and wants speed (e.g., "make 20 patterns of the top page"), (5) the next reasonable step would be "instrument the existing complex code" — pause and consider this skill instead. Build the prototype in the repo-scoped Dropbox-synced cclogs dir (`$DROPBOX_CCLOGS_DIR/<repo>/<descriptive-name>/`) so it survives switching between Mac and WSL; the exception is a prototype that must import the repo's production code or use its workspace/Vite tooling — keep that one in `__inbox/<descriptive-name>/` in the project root (in-repo, gitignored) so relative imports resolve. Match the project's tech stack (HTML+CSS+vanilla JS for static sites, Vite+React for React apps, Node script for CLI/utility logic). Don't commit it — its value is the learning, not the artifact. **Variant for repeated regression cycles (8+ in-place fixes on the same bug class):** keep the prototype as a committed sub-package named `packages/prototype-<topic>/` — see the "Variant: project-level reference prototype" section below.

gh-actions-wisdom

from Takazudo/claude-resources

GitHub Actions workflow best practices and pitfalls reference. Use when: (1) Writing or reviewing .yml workflows, (2) Setting up CI/CD pipelines, (3) Debugging slow, expensive, or stuck workflow runs, (4) User says 'gh actions', 'github actions', 'workflow best practices', (5) Before creating or modifying any .github/workflows/ file. Keywords: GitHub Actions, CI/CD, workflow, timeout, concurrency, security, caching.

dev-create-b4push-script

from Takazudo/claude-resources

Create a before-push validation script (b4push) and project-level b4push skill. Analyzes the project, identifies check steps (quality, build, test, doc site, e2e), generates scripts/run-b4push.sh, adds package.json entry, creates .claude/skills/b4push/skill.md. Use when: (1) User says 'create b4push', 'add b4push', 'before push script', (2) Setting up a new project's CI/validation workflow.

zudoesa-articlify

from Takazudo/claude-resources

Convert conversation context into an esa article via the zudoesa-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write esa article', 'esa記事', 'esaに書いて', 'articlify for esa', or /zudoesa-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.

zudoesa-apply-voice

from Takazudo/claude-resources

Apply Takazudo's esa writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's esa style, (2) User says 'apply voice', 'esa voice', 'esa文体で', 'esa風に書いて', '文体を適用', (3) User provides text to transform to esa style. Reads writing-style.md and vocabulary-rule.md from takazudo-esa-writing repo and applies the rules.

zudocg-articlify

from Takazudo/claude-resources

Convert conversation context into a CodeGrid article via the zudocg-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write codegrid article', 'CodeGrid記事', 'codegridに書いて', 'articlify for codegrid', or /zudocg-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.

zudocg-apply-voice

from Takazudo/claude-resources

Apply Takazudo's CodeGrid writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's CodeGrid style, (2) User says 'apply voice', 'codegrid voice', 'codegrid文体で', 'codegrid風に書いて', '文体を適用', (3) User provides text to transform to CodeGrid style. Reads writing-style.md and vocabulary-rule.md from takazudo-codegrid-writing repo and applies the rules.

zpaper-articlify

from Takazudo/claude-resources

Convert conversation context into a zpaper blog article via the zpaper-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write zpaper article', 'zpaper記事', 'zpaperに書いて', 'articlify for zpaper', or /zpaper-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.

zpaper-apply-voice

from Takazudo/claude-resources

Apply Takazudo's zpaper blog writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's zpaper style, (2) User says 'apply voice', 'zpaper voice', 'zpaper文体で', 'zpaper風に書いて', 'ブログ文体を適用', (3) User provides text to transform to zpaper style. Reads writing-style.md and vocabulary-rule.md from the zpaper repo and applies the rules.

xlsx

from Takazudo/claude-resources

Spreadsheet creation, editing, and analysis. Use when working with .xlsx, .xlsm, .csv, .tsv files for: (1) Creating spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modifying existing spreadsheets while preserving formulas, (4) Data analysis and visualization, (5) Recalculating formulas.

x

from Takazudo/claude-resources

Facade for development workflows. Routes on two axes: plan-first vs implement-now (escalates to /big-plan -a when the request needs research / decomposition / has unclear scope — the appended -a makes the plan chain into implementation in-session), then single vs multi on the ready-to-build fast paths (/x-as-pr single-topic, /x-wt-teams multi-topic parallel). Use when: (1) User says '/x' followed by dev instructions, (2) User wants to start development without choosing the workflow skill, (3) User says 'dev', 'implement', or 'build' with a task. Default option: -v (verify-ui). Review-loop (-l) is opt-in — without -l the downstream skill runs a single /deep-review pass. Forwards -a (autonomy/auto-chain) and -m (merge at the end + cleanup + CI watch) through every route; auto-fix of raised findings (-f) and issue-raising (-ri) are downstream defaults, with -nf/--no-fix and -nori/--no-raise-issues as the forwarded opt-outs. -a and -m are orthogonal — full hands-off end-to-end is -a -m.

x-wt-teams

from Takazudo/claude-resources

Parallel multi-topic development using git worktrees, base branches, and Claude Code agent teams. Use when: (1) User wants to work on multiple related features in parallel, (2) User mentions 'worktree', 'base branch', 'parallel development', 'split into topics', or 'multi-topic'. FULLY AUTONOMOUS — creates worktrees, spawns teams, coordinates everything. Also supports Super-Epic child mode for [Epic] issues from /big-plan with '**Super-epic:** #N' markers (targets the super-epic base branch instead of main).