cal/claude-configs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1922d25469
claude-configs/skills/_templates/EXTENDING.md

3.6 KiB
Raw Blame History

Extending Shared Skills to a New Project

This directory contains shared workflow templates that can be reused across projects. Each project provides its own config; the templates provide the logic.

How It Works

~/.claude/skills/_templates/          ← shared workflow logic (this directory)
  pr-pipeline-workflow.md             ← review→fix→merge steps
  release-workflow.md                 ← CalVer tag→push steps
  release-core.sh                     ← parameterized release script
  EXTENDING.md                        ← this file

<project>/.claude/skills/             ← per-project config
  pr-pipeline/SKILL.md               ← agent names, repo mapping, → template pointer
  release/SKILL.md                   ← service mapping, deploy commands, → template pointer
  release/release.sh                 ← thin wrapper calling release-core.sh
  release/release-config.env         ← bash-sourceable service/image map

Adding pr-pipeline to a New Project

  1. Create <project>/.claude/skills/pr-pipeline/SKILL.md:
---
name: pr-pipeline
description: Review-fix-merge pipeline for <Project Name> PRs.
---

# PR Pipeline — <Project Name>

## Config

| Key | Value |
|---|---|
| REVIEWER_AGENT | `pr-reviewer` |
| REVIEWER_MODEL | `sonnet` |
| FIXER_AGENT | `engineer` |
| FIXER_MODEL | `sonnet` |
| MERGER_AGENT | `<project-ops-agent>` |
| MERGER_MODEL | `sonnet` |

### Repo Mapping

| Short name | Gitea repo | Owner |
|---|---|---|
| `database` | `<project>-database` | `cal` |
| `discord` | `<project>-v2` | `cal` |

## Workflow

Follow the workflow defined in `~/.claude/skills/_templates/pr-pipeline-workflow.md`,
substituting the config values above.

Key decisions:

  • MERGER_AGENT must match an agent defined in the project's .claude/agents/ directory
  • REVIEWER_AGENT and FIXER_AGENT are typically global agents (pr-reviewer, engineer)
  • Repo mapping short names are arbitrary — pick whatever feels natural for the project

Adding release to a New Project

  1. Create <project>/.claude/skills/release/release-config.env:
BASEDIR="/mnt/NV2/Development/<project>"

declare -A SERVICE_DIRS=(
  [database]="database"
  [discord]="discord-app-v2"
)

declare -A SERVICE_IMAGES=(
  [database]="manticorum67/<project>-database"
  [discord]="manticorum67/<project>-discordapp"
)
  1. Create <project>/.claude/skills/release/release.sh:
#!/usr/bin/env bash
exec bash ~/.claude/skills/_templates/release-core.sh \
  --config "$(dirname "$0")/release-config.env" "$@"
  1. Create <project>/.claude/skills/release/SKILL.md with:
    • Config section (BASEDIR, service mapping table, deploy commands)
    • Usage/examples section with the correct paths
    • Workflow section pointing to ~/.claude/skills/_templates/release-workflow.md

Key decisions:

  • Only list services that need manual CalVer release in the config. If a repo auto-tags on merge (like some CI setups), omit it from SERVICE_DIRS.
  • Deploy commands are project-specific — list them in the SKILL.md so Claude knows how to deploy after tagging.
  • SERVICE_IMAGES can omit services that don't produce Docker images (e.g., CLI-only tools).

Modifying Shared Workflow Logic

Edit the template files in ~/.claude/skills/_templates/. Changes propagate to all projects automatically.

Rules:

  • Templates must not contain project-specific strings (no repo names, paths, or agent names)
  • Use {PLACEHOLDER} notation for values that come from project config
  • Test changes against at least the Paper Dynasty skills before considering them stable