Files
paperclip/.github/ISSUE_TEMPLATE/adapter_request.yml
T
Devin Foley ec60da41ca chore(github): add YAML issue forms for bug, feature, and adapter requests (#7575)
## Thinking Path

> - Paperclip orchestrates AI agents for zero-human companies
> - Most of the inbound feedback loop lives in GitHub Issues: bugs,
feature ideas, and new-adapter requests
> - Today the "New issue" page is a blank textarea, which means reports
arrive without a Paperclip version, without repro steps, and without a
clear separation between adapter requests and feature requests
> - That makes triage slow and routes a lot of low-information issues
back to the requester for follow-up questions before any work can start
> - This pull request adds `.github/ISSUE_TEMPLATE/` with three YAML
issue forms — bug, feature, adapter — plus a `config.yml` that disables
blank issues and points contributors at Discord `#dev` and `ROADMAP.md`
> - The benefit is that new issues come in with the fields a maintainer
needs to triage on the first read, and feature requests are nudged
toward the roadmap/Discord coordination path before they turn into
uncoordinated PRs

## What Changed

- Added `.github/ISSUE_TEMPLATE/config.yml` — sets
`blank_issues_enabled: false` and adds contact links for Discord `#dev`
and the roadmap.
- Added `.github/ISSUE_TEMPLATE/bug_report.yml` — required fields: what
happened, expected behavior, repro steps, Paperclip version/commit, and
a deployment-mode dropdown. Optional: Node version, OS, logs, additional
context.
- Added `.github/ISSUE_TEMPLATE/feature_request.yml` — required fields:
problem/motivation, proposed solution. Optional: alternatives,
ROADMAP.md alignment, additional context.
- Added `.github/ISSUE_TEMPLATE/adapter_request.yml` — required fields:
agent/provider name, why useful, how invoked. Optional:
willing-to-implement checkboxes, additional context.

Field structure and labels are lifted from @amitdhanda48's earlier
markdown-template proposal (#4260); this PR ports those four files to
GitHub's YAML issue-form schema so required fields are enforced at
submission time. The bundled `CONTRIBUTING.md` rewrite from that
proposal is intentionally out of scope and left for a separate decision.

## Verification

- `node -e
"require('js-yaml').load(require('fs').readFileSync(f,'utf8'))"` against
each of the four YAML files — all parse.
- Diff against `master` is `.github/ISSUE_TEMPLATE/` only: `git diff
--stat master...HEAD` shows 4 files, +162 lines, 0 deletions.
- Reviewer step: after merge, visit the repo's "New issue" page on
GitHub and confirm the three forms render in the chooser, blank issues
are disabled, and the Discord/roadmap contact links appear.

## Risks

- Low risk. Files are GitHub-config only — they have no runtime effect
on the server, UI, CLI, or any package. The only behavioral change is on
github.com's "New issue" page.
- If a YAML form has a schema mistake that `js-yaml` accepts but
GitHub's form renderer rejects, GitHub silently falls back to a blank
issue for that template. The mitigation is the post-merge render check
above.

## Model Used

- Claude (Anthropic) — `claude-opus-4-7`, extended-thinking + tool use,
running inside the Paperclip Claude Code harness.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have run tests locally and they pass (n/a — no code paths
exercised by the test suite; YAML parse-check run instead)
- [ ] I have added or updated tests where applicable (n/a — repo has no
test coverage for `.github/` config)
- [ ] If this change affects the UI, I have included before/after
screenshots (n/a — only the GitHub.com "New issue" page is affected;
render check happens post-merge on github.com)
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-06-04 22:29:30 -07:00

43 lines
1.4 KiB
YAML

name: New agent adapter
description: Request or propose support for a new AI agent or model provider
labels: [adapter]
body:
- type: markdown
attributes:
value: |
New agent adapters are welcome without prior discussion. If you plan to implement, prefer extending Paperclip via the [plugin system](https://github.com/paperclipai/paperclip/blob/master/doc/plugins/PLUGIN_SPEC.md) when possible.
- type: input
id: agent
attributes:
label: Agent or provider
description: Name of the agent, model, or CLI tool.
placeholder: e.g. Gemini CLI, LM Studio, Mistral
validations:
required: true
- type: textarea
id: why
attributes:
label: Why this adapter is useful
description: What use cases does this unlock? Who would benefit?
validations:
required: true
- type: textarea
id: how-invoked
attributes:
label: How the agent is invoked
description: CLI command, API endpoint, SDK — whatever is relevant. Link docs if available.
validations:
required: true
- type: checkboxes
id: willing
attributes:
label: Are you willing to implement it?
options:
- label: Yes, I plan to open a PR
- label: No, requesting for someone else to pick up
- type: textarea
id: context
attributes:
label: Additional context
description: Links, examples from existing adapters, configuration quirks, etc.