67 lines
2.1 KiB
Markdown
67 lines
2.1 KiB
Markdown
# AI Tooling Integrations
|
|
|
|
Documentation and usage guides for AI-assisted
|
|
development tools integrated with this repo.
|
|
|
|
Each subdirectory corresponds to a specific AI tool
|
|
or frontend and contains usage docs for the
|
|
custom skills/prompts/workflows configured for it.
|
|
|
|
Originally introduced in
|
|
[PR #69](https://www.pikers.dev/pikers/piker/pulls/69);
|
|
track new integration ideas and proposals in
|
|
[issue #79](https://www.pikers.dev/pikers/piker/issues/79).
|
|
|
|
## Integrations
|
|
|
|
| Tool | Directory | Status |
|
|
|------|-----------|--------|
|
|
| [Claude Code](https://github.com/anthropics/claude-code) | [`claude-code/`](claude-code/) | active |
|
|
| [OpenCode](https://opencode.ai/) | [`opencode/`](opencode/) | active |
|
|
|
|
## Shared Skills
|
|
|
|
Provider-neutral skill bundles should use the portable Agent Skills
|
|
subset and live under `.agents/skills/` as their single source.
|
|
OpenCode discovers that project directory natively. Relative links in
|
|
provider directories such as `.claude/skills/` may bridge clients which
|
|
do not yet scan `.agents/skills/`; never copy the skill body.
|
|
|
|
Existing repo skills under `.claude/skills/` predate this convention
|
|
and can migrate separately without coupling their history to new skills.
|
|
|
|
Harness-specific command files should only delegate to a
|
|
shared skill. They must not duplicate the skill body.
|
|
|
|
## Adding a New Integration
|
|
|
|
Create a subdirectory named after the tool (use
|
|
lowercase + hyphens), then add:
|
|
|
|
1. A `README.md` covering setup, available
|
|
skills/commands, and usage examples
|
|
2. Any tool-specific config or prompt files
|
|
|
|
```
|
|
ai/
|
|
├── README.md # <- you are here
|
|
├── claude-code/
|
|
│ └── README.md
|
|
├── opencode/
|
|
│ └── README.md
|
|
└── <your-tool>/
|
|
└── README.md
|
|
```
|
|
|
|
## Conventions
|
|
|
|
- Skill/command names use **hyphen-case**
|
|
(`commit-msg`, not `commit_msg`)
|
|
- Each integration doc should describe **what**
|
|
the skill does, **how** to invoke it, and any
|
|
**output** artifacts it produces
|
|
- Keep docs concise; link to the shared skill source files
|
|
rather than duplicating content
|
|
- Keep skill bodies harness-neutral; isolate slash-command
|
|
syntax and permissions in each harness integration
|