14 lines
1.3 KiB
Markdown
14 lines
1.3 KiB
Markdown
## My Learning Goal
|
|
Learn enough about allium's architecture and pi.dev's plugin system to port allium while keeping most of it as upstream references, so I'm not maintaining a full fork. By the end of this session, have it running against my turn-limit extension and getting useful output — tests, constraint extraction, or logic factoring.
|
|
|
|
## Why It Matters
|
|
This is a gateway skill — cracking the porting pattern unlocks future plugins for pi.dev. It also makes a good blog post for both the allium and pi.dev communities, and moves my extensions from interactive code-and-fix toward specced, tested, and autonomous.
|
|
|
|
## My If-Then Plans
|
|
- If I get interrupted and need to resume on another machine, then I will check my private wiki (today's page, "porting allium to pi.dev" with file locations).
|
|
- If I hit the sandbox-merge problem, then I will create a third JSON file combining permissions for both Claude and pi.
|
|
- If I need multiple repositories active in the sandbox, then I will create a parent directory containing clones for all repos I need. If agents get confused, I will run bash in the sandbox and cd into the repo I need.
|
|
|
|
## My First Step
|
|
Try the simple install path (`npx skills add juxt/allium` or equivalent) and see what happens. If that doesn't work, read the allium repo structure and figure out what needs to move where.
|