Mention @sepo-agent on a GitHub issue, pull request, or discussion to answer questions, implement issues, review PRs, fix PR branches, or create durable scheduled agent workflows. Sepo runs inside GitHub Actions and keeps working context in repository-owned branches, so collaboration stays in GitHub instead of moving to a separate chat surface.
Sepo turns a repository into a self-evolving repository: a codebase that can react to user requests, preserve agent-facing memory and user/team rubrics, and improve both application code and its own automation over time. For the concept behind that architecture, see What is a self-evolving repository?.
- Fork this repository or use it as a template.
- Install the Sepo GitHub App and ensure GitHub Actions is enabled for your repository.
- Alternatively, you can use your own GitHub App when you want a self-managed app identity.
- See the setup guide for all auth options and trade-offs.
- Add at least one model-provider credential as a repository secret:
OPENAI_API_KEYfor Codex-backed runs.CLAUDE_CODE_OAUTH_TOKENfor Claude-backed runs.
- Open an issue and mention
@sepo-agentin the issue body or a comment. After a short delay, the workflow should add an eyes reaction and then post a response.
Check Install into an existing repository for the detailed guide. TL;DR: you (or your agent) should copy .agent/ and .github/, configure secrets, and initialize agent memory from GitHub Actions.
# Use a free-form mention when you want the router to infer the best route:
@sepo-agent can you explain how review synthesis works?
# Use an explicit slash route when you already know the action
@sepo-agent /implement implement issue #2
# Invoke arbitrary skills
@sepo-agent /skill <skill-name>
# Inside a PR
@sepo-agent /review
@sepo-agent /fix-pr
@sepo-agent /orchestrateWarning
Only authorized repository users can trigger Sepo. By default, repositories allow OWNER, MEMBER, COLLABORATOR, and CONTRIBUTOR associations; public repositories can tighten this with AGENT_ACCESS_POLICY. See Trigger access policy to customize that behavior.
For example, adding the agent/review label will run the review agent.
Use @sepo-agent /orchestrate (or agent/orchestrate) to run the orchestration route explicitly. It checks current target state, dispatches the right built-in action (implement, review, or fix-pr), and keeps that explicitly started chain moving through bounded follow-up handoffs until a stop condition is reached. Direct /implement, /review, and /fix-pr requests remain one-shot.
Sepo persists long-lived context in agent/memory and preference rules in agent/rubrics, both as repository-owned branches. This lets later runs resume with durable project context and team-specific guidance.
You can run Sepo on a schedule to handle recurring maintenance, triage, or monitoring tasks without a manual mention. For example, agent-daily-summary.yml can publish a daily repository activity summary discussion. Scheduled workflows still route through the same policy and memory layers, so they behave consistently with on-demand runs.
Every trigger converges on agent-router.yml, which extracts GitHub context, applies access policy, optionally triages free-form requests with a model, and dispatches to a specialized route. Agent sessions are persisted across runs with git refs and GitHub Actions artifacts, so a later mention can continue from prior context.
Durable context lives in two repository-owned branches:
agent/memorymirrors GitHub artifacts and stores curated project context.agent/rubricsstores user/team preferences that guide implementation and review.
Orchestration runs through agent-orchestrator.yml as an explicit route. Follow-up automation starts only when requested, and only workflows launched with explicit orchestration context hand back to the orchestrator.
Getting started:
Understanding the system:
Customizing and operating:
See the full documentation index for technical details, deployment options, and the complete docs tree.