Repository navigation
[RSI Baseline] Package Repository Engineering as a reusable capability pack #788
Description
Parent Epic: #784
Why
FlyBot should not be hard-coded to software development. Repository development is the first domain workflow and should be installable/configurable on top of the generic FlyBot Runtime.
Scope
Create a versioned Repository Engineering capability pack containing:
- Repo Chief profile and task intake/triage rules.
- Developer, Tester, Reviewer and Release roles/profiles.
- Workflow definitions and acceptance conditions for Issue → branch/worktree → implement → verify → PR → review → CI → merge → release.
- Skills/templates for reproduction-first fixes, regression tests, PR evidence, changelog and release.
- Risk-tier policy and verifier report schema.
- Project configuration for repository URL, branch conventions, commands, test layers, release policy, approval requirements and adapters.
- Declared dependencies on Runtime, GitHub, Runner and Code Agent adapters.
- Versioning, install/upgrade and compatibility contract.
Design constraints
- Runtime owns generic scheduling, persistence, organization, permissions and audit.
- The capability pack owns repo-specific process and acceptance policy.
- GitHub remains the source of truth for Issues, PRs, CI, merge queue and Releases.
- No Grok Bot-specific dependency or hidden per-project state.
- Security enforcement must not rely solely on prompts; machine-checkable gates remain deterministic.
Acceptance criteria
- Pack installs into a clean FlyBot instance through documented steps.
- A repository is onboarded through explicit config rather than manually copying prompts and scripts.
- Pack version and effective policy are visible in run records.
- A non-coding capability can coexist without changing generic Runtime.
Activity
Birfy commentedon Oct 22, 2026
Written-by: Triage
enhancement|area:automation|needs-human. The direction is right and the mechanism partly exists: DSH already has installable packs (a pack is a named set of MCP servers and skills, attached to a Bot or a team), and this repository already ships its process as versioned artifacts —AGENTS.md,.github/labels.json,.github/agent/*,.github/workflows/*,docs/testing-layers.jsonand the patch series underpatches/ds-bot/. So "the process is hard-coded" is not quite true; the process is documented text and scripts that a person installs by reading, and the pack would make it installable by command.The blocking decision is what a pack may contain that a Bot's prompt may not:
merge-gate,enqueue-guardandreview-gateare deterministic scripts, and the pack must ship them as code with the same authority, not as instructions an LLM is asked to follow. Until that split is written down, the pack would be a prompt bundle, which is exactly what the design constraints say it must not be.To become
agent-ready: one installable pack with a version, a list of what it adds (skills, scripts, policy files), and one test that installing it into a clean instance produces the same gate behaviour as this repository — a gate that refuses a bad PR, not a prompt that says not to open one.