redhat-et / redhat-et/ProtoBot

Per-agent exposure of repo skills to Fullsend agents

Open
#100 2 comments 1 reaction 1 assignee View on GitHub

@lukaskellerstein is already working on this.

Since Sep 11, 2026.

blocked component:specification-toolkit infra
Dominant language
Go
Stars
5
Forks
6
Avg merge
23h 24m
Merged PRs (30d)
66

Description

What happens

Every skill under .agents/skills/ is offered to every Fullsend agent that
runs on this repo. The fullsend-review artifact of run
https://github.com/redhat-et/ProtoBot/actions/runs/34481374394 shows it: the
Claude Code init event lists pull-request, rebase-pr and review-pr,
our human workflow skills, next to Fullsend's own pr-review, docs-review
and code-review.

Two kinds of skill are about to join that tree, and neither belongs to
every bot:

  • #64 adds eliciting-requirements. It is a Specification Toolkit skill for
    the Drafting Table agent on OpenCode
    (architecture.md, interface 3).
    The maintenance bots (triage, review, retro) have no use for it, and the
    code agent could pick it up when it implements a requirements issue.
  • A spec-review skill, in preparation on branch lukas/review-docs-fullsend,
    checks a docs change against the architecture documents. Only the code and
    fix agents must run it, before they commit.

Fullsend has no switch for this. Repo skills are always loaded after an
injection scan, and a built-in skill wins on a name collision. Nothing
selects per agent.

What should happen

ProtoBot decides per Fullsend agent which of its own repo skills that agent
may use, without copying skills into .fullsend/skills/ or adding symlinks:

  • code and fix: spec-review
  • triage, review, retro, prioritize: none of ours
  • later, when Fullsend runs as the Job Site backend: Workers and Inspectors
    get the Job Site skills of that phase, and only those. Drafting Table
    skills stay with the Drafting Table agent on OpenCode
    (overview.md, Platform;
    components.md, Sandbox / Execution Environment).

The upstream request for the knob is fullsend-ai/fullsend#7228. Until it
lands, the only per-skill lever is disable-model-invocation: true in a
skill's frontmatter. A headless Claude Code run confirms that a skill with
that key stays out of the model's skill list, in bots and local sessions
alike, while /name still works for a human. That fits the three human
workflow skills. It does not fit a product skill the Drafting Table agent
must call, nor spec-review, which two bots must run.

Context

  • This is one concrete instance of the open question "Fullsend integration
    depth" in
    components.md:
    which Fullsend extension points can host ProtoBot's functions unchanged.
    Skill exposure per agent and per phase is one of them.
  • fullsend-ai/fullsend#7228 — the upstream feature request, filed
    2026-09-11.
  • #64 — the first product skill in .agents/skills/.
  • Decision needed from the maintainers: whether to set
    disable-model-invocation: true on pull-request, rebase-pr and
    review-pr now, as an interim measure.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.