Brummel
253273b007
Establishes the repository structure for the skills plugin: - README + INSTALL describing the two-layer split (plugin mechanics vs per-project profile) - docs/design, profile-schema, pipeline, agent-template covering the universal discipline constants and the profile slot model - templates/project-profile.yml as a copy-and-fill starting point - templates/CLAUDE.md.fragment with the baseline orchestrator rules a project can import - install.sh / uninstall.sh wiring skills/ + agents/ into ~/.claude/ via idempotent symlinks - skills/ and agents/ directories empty except for migration READMEs; the actual SKILL bodies and agent files migrate from ~/dev/ailang/skills/ in the next iteration. No skill or agent runs yet — this commit only stands up the structure and documents the substitution model.
skills/
One subdirectory per skill, each containing a SKILL.md plus
any skill-local resources.
The skeleton commit ships this directory empty. The actual
skill bodies are migrated from AILang's in-tree
~/dev/ailang/skills/ and generalised against the profile
schema (../docs/profile-schema.md) in iteration 1.
Expected layout after migration:
skills/
├── brainstorm/
│ └── SKILL.md
├── planner/
│ └── SKILL.md
├── implement/
│ └── SKILL.md
├── audit/
│ └── SKILL.md
├── debug/
│ └── SKILL.md
├── fieldtest/
│ └── SKILL.md
└── docwriter/
└── SKILL.md
Migration checklist per skill:
- Strip project-specific paths (
docs/specs,docs/plans,design/INDEX.md,crates/,bench/). - Strip project-specific commands (
cargo build,bench/check.py). - Replace literals with profile-slot references in prose.
- Strip project vocabulary (
AILang,Form A,.ail.json,Boss); use the profile's vocabulary slots. - Strip project-specific contracts (honesty-rule,
feature-acceptance). These belong in the project's own
CLAUDE.md, not the plugin. - Verify the body still reads coherently for a generic project — would it make sense in a Python web service? A TypeScript library?