Conventions
Repo Hub is capability-centered, not pipeline-centered. The agent is given capabilities — skills (specialized knowledge), MCPs (tools), and multi-repo context — and decides which to use for each task, applying its own judgment. There is no fixed sequence of phases the agent must march through.
The optional workflow section no longer defines a pipeline. It carries two things: where task documents live, and free-form prompt customization injected into the generated capabilities prompt.
Schema
workflow:
task_folder: "./tasks/{task_id}/"
fact_checker: true
prompt:
prepend: |
Always respond in Portuguese.
append: |
When in doubt, ask the user before proceeding.
sections:
after_repositories: |
The API uses a custom auth middleware. See api/docs/auth.md.
coding_guidelines: |
Use functional patterns. Prefer composition over inheritance.| Field | Type | Description |
|---|---|---|
task_folder | string | Optional convention for where task documents go (default: ./tasks). Nothing forces their creation. |
fact_checker | boolean | When true, requires the agent to verify external state (PR/deploy/branch status) with a tool before stating it. |
prompt | object | Free-form text injected into the capabilities prompt. |
Prompt Customization
The prompt field injects company-specific instructions into the generated capabilities prompt without editing generated files.
| Field | Description |
|---|---|
prepend | Injected right after the introduction |
append | Added at the very end of the generated prompt |
sections.after_repositories | Injected after the repositories list |
sections.after_delivery | Injected after the delivery section |
sections.<custom_name> | Any other key becomes a new ## Section Name |
Custom section keys are converted to title case (e.g., coding_guidelines becomes ## Coding Guidelines).
Why no pipeline?
Earlier versions of Repo Hub modeled development as a fixed pipeline (refine → code → review → qa → deliver) executed by stack-specialized agents. Modern models don’t need a stack-specialized “backend agent” vs “frontend agent”, and a rigid pipeline gets in the way more than it helps. Two things replaced it:
- Skills encapsulate how to do something well (how to review code, how to test, how to refine requirements). The agent pulls the relevant skill when the task calls for it — see Skills.
- Subagents, when you want an independent, fresh-context pass (e.g. an unbiased code review), are spawned on demand using your editor’s native subagent mechanism — not pre-declared as files.
If you previously declared workflow.pipeline or workflow.enforce_workflow, those fields are ignored (the CLI warns and continues). Move the knowledge they encoded into skills.
How It Runs
hub generatereads your config and produces a capabilities prompt (repositories, policies, conventions) plus connects your MCPs and installs your skills.- You open the project in your AI editor.
- The editor exposes MCP tools (in the tool schema) and skills (in the native skill index) to the agent automatically.
- The agent reads the capabilities prompt, sees the available skills and tools, and works — pulling skills and spawning subagents as the task requires.
The editor is the runtime. No daemon, no server, no separate process.