Forking a pack.

Take a live pack. Copy it into your workspace. Change what needs changing.

Forking is for the case where the pain taxonomy is right but the angles, weights, or tone need to bend to your business. It is the same workflow you would use to fork any config repo. We did not invent anything here. We just made the file shape predictable.

How

paitho packs fork devtools-infra --as my-team-devtools
        paitho packs edit my-team-devtools angles
        paitho packs evaluate my-team-devtools --against last-7-days

The CLI lives in npm i -g @paitho/cli. It calls the same REST endpoints documented in REST endpoints. If you prefer the UI, the pack editor is under Workspace → Packs.

What not to do

Do not edit signals.yml first. The signal taxonomy is the part most likely to be right. Edit angles.yml and tone.yml. If after a week of running you still feel the signals are wrong for your market, then edit the taxonomy or talk to us about a custom pack.

Versioning your fork

Forks are versioned the same way our public packs are. Every change creates a new semver. You can pin a campaign to a specific version. Read about prompt versioning for the same idea applied to LLM calls.