Problem
Users who git init . in their ~/.claude (or PAI install directory) have no clear way to know which files are PAI-managed vs their own customizations. This
makes it difficult to:
- Version control personal configurations without tracking upstream files
- Know what's safe to modify vs what may be overwritten on upgrade
- Maintain a clean separation between PAI core and user content
Proposal
- PAI-managed manifest - PAI declares which files/paths it maintains
- Install
.gitignore - Ships with the install (not source repo) so users can git init . and immediately have sensible ignores for PAI-managed paths
Example .gitignore at install location:
# PAI-managed - excluded from user versioning
skills/CORE/SYSTEM/
skills/Browser/
lib/
tools/
hooks/SessionStart.ts
# ... etc
Enhancement: TOML companion for tooling
A .gitignore solves the git use case, but tooling (upgrade scripts, integrity checks, conflict detection) benefits from programmatic parsing. Consider a
companion:
# pai-managed.toml
[managed]
paths = [
"skills/CORE/SYSTEM/**",
"lib/**",
"tools/**"
]
Same patterns, machine-readable. The .gitignore remains the human-facing artifact; TOML enables automation without regex parsing.
Problem
Users who
git init .in their~/.claude(or PAI install directory) have no clear way to know which files are PAI-managed vs their own customizations. Thismakes it difficult to:
Proposal
.gitignore- Ships with the install (not source repo) so users cangit init .and immediately have sensible ignores for PAI-managed pathsExample
.gitignoreat install location:Enhancement: TOML companion for tooling
A .gitignore solves the git use case, but tooling (upgrade scripts, integrity checks, conflict detection) benefits from programmatic parsing. Consider a
companion:
Same patterns, machine-readable. The .gitignore remains the human-facing artifact; TOML enables automation without regex parsing.