Append six identified tasks and 24 unchecked items for prototype
review, live Jev qualification, provider-service wiring, Pine
parity, chart qualification and native subsecond sampling.
Preserve existing task states, properties, prose and ordering. Link
the existing FSP synchronization task and retain annotation IPC
work with its current tracker. Record
|
||
|---|---|---|
| .. | ||
| claude-code | ||
| opencode | ||
| prompt-io | ||
| README.md | ||
README.md
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; track new integration ideas and proposals in issue #79.
Integrations
| Tool | Directory | Status |
|---|---|---|
| Claude Code | claude-code/ |
active |
| 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:
- A
README.mdcovering setup, available skills/commands, and usage examples - 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, notcommit_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