xmatic/pepa-pi-bot
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

docs: artifact-location rule + CONTRIBUTING for community growth

Browse Source 
The whole point of this project is that the agent's growth is shareable.
If skills and extensions silently land in ~/.pi/ on the maintainer's
laptop, every clone starts from zero and the repo becomes a fancy
README. Fix that with an explicit hard rule and a contributor guide.

- AGENTS.md: new "Artifact location — hard rule" subsection spelling out
  that skills/extensions/prompts/state/.pi-settings ALL live in this repo,
  never in ~/.pi/. Pi's own built-in skills (skill-creator, etc.) stay
  user-global; the agent may use them, but their *output* must land here.
- README: new "Everything in the repo" subsection covering the same rule
  in user-facing language, plus a pointer to CONTRIBUTING.md.
- CONTRIBUTING.md (new): skill/extension formats, server-agnostic and
  no-secrets requirements, smoke-test recipe, PR checklist.
- .gitignore: switch from blanket `.pi/` ignore to `.pi/*` + explicit
  un-ignore of `.pi/settings.json`, so project Pi config is reproducible.
- "Don't push without operator confirmation" → "without human
  confirmation via the repo" — consistent with the new control model.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
mayatnikov
2026-05-25 10:23:20 +03:00
co-authored by Claude Opus 4.7
parent e73784a293
commit fa0bbd8c59
4 changed files with 123 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+17 -3
View File
@@ -55,11 +55,25 @@ When you encounter a missing capability, your loop is:
1. **Decide** whether the capability is one-off (handle inline) or reusable (codify).
2. If reusable, create either:
- a **skill** under `skills/<short-name>.md` — markdown, with a frontmatter header (`name`, `description`, `when_to_use`) and a procedural body.
- or an **extension** under `extensions/<short-name>.ts` — for anything that needs to register a real Pi tool or hook into Mineflayer events.
3. Commit the new file with a clear message. The repo is on `main`. Don't push without operator confirmation.
- a **skill** under `./skills/<short-name>.md` — markdown, with a frontmatter header (`name`, `description`, `when_to_use`) and a procedural body.
- or an **extension** under `./extensions/<short-name>.ts` — for anything that needs to register a real Pi tool or hook into Mineflayer events.
3. Commit the new file with a clear message. The repo is on `main`. Don't push without human confirmation via the repo.
4. Update `README.md`'s **Status** section as milestones land.
### Artifact location — hard rule
Everything you author lives **in this repo**, never in `~/.pi/` or any other user-global location. This is what makes the project shareable:
- **Skills** → `./skills/<name>.md`. Not `~/.pi/skills/`. Not `~/.pi/agent/`.
- **Extensions** → `./extensions/<name>.{ts,js}`. Not globally `npm install`-ed.
- **Prompt templates** → `./prompts/<name>.md`. Not `~/.pi/prompts/`.
- **Per-session learnings, world state, base coords, etc.** → `./state/<MC_HOST>/...`. Gitignored by default, but **lives inside the repo**.
- **Pi project settings** → `./.pi/settings.json` (use `pi install -l <source>`, the `-l` makes it project-local). This file IS committed; without it a fresh clone can't reproduce your tool stack.
If you need to use Pi's built-in `skill-creator` or similar global tools, that's fine — just make sure the *output* lands under `./skills/` in this repo.
If something genuinely belongs in the user's global Pi config (a personal API key, a workflow only the human cares about), don't write it. Tell the human and let them decide.
Skills you might want early on (good for any server):
- `server-onboarding` — what auth flow this server uses; relogin / autologin pattern.