What's the best way to manage the tasks and project planning for this repo now?

[lolipopshock]

1. I am going to create a Github project page, it is going to serve with two purposes:
   • allowing us to manage tasks and track progress
   • we should also plan for features for the first public release and public road map
2. additionally, @sepo-agent you should also be able to work and manage the task together.

There are many templates for github project template. I wonder which one fits the best (also related to #125 ); also what are the views needed?
@sepo-agent /answer

[sepo-agent-app]

I’d start from GitHub’s Team planning project template, then add roadmap/release fields. It is the better fit than a pure feature-release template because this repo needs one durable operating board for backlog triage, active PRs, first public release planning, and Sepo-managed work. GitHub Projects supports table, board, and roadmap views over the same items, so one project can serve both task tracking and public-roadmap planning.

Repo context I checked:

• Sepo already treats GitHub as the collaboration surface: mentions, labels, issues, PRs, Actions, memory, and rubrics all stay in-repo (README.md, README.md).
• There is already an opt-in agent-project-manager.yml workflow for open issue/PR triage, summary generation, and optional priority/* + effort/* label updates (supported-workflows.md, agent-project-manager.yml).
• The project-manager prompt already defines the managed label system and requires exactly one priority and one effort label per assessed item (project-manager.md).
• The deterministic label code only permits the managed priority/* and effort/* families, so those labels are already part of the repo’s automation contract (project-management-labels.ts).
• Sepo execution itself should remain issue/PR driven through /implement, /review, /fix-pr, and /orchestrate, not project-card driven (agent-actions.md).

For #125: yes, keep priority/* and effort/* labels even after adding a Project. They are useful because labels are repo-native, visible outside the Project, easy for workflows to mutate safely, and already supported by Sepo’s project-manager pass. The Project should add higher-level planning fields, not replace these labels.

Recommended project fields:

• Status: Inbox, Backlog, Ready, In Progress, In Review, Blocked, Done, Later
• Release: public-v0, post-v0, exploration
• Roadmap phase: Now, Next, Later
• Workstream: Agent runtime, Orchestration, Project management, Distribution, Memory/Rubrics, Docs, Testing
• Owner: human or sepo-agent
• Agent route: none, answer, implement, review, fix-pr, orchestrate
• Keep GitHub labels for priority/*, effort/*, agent, and agent/* trigger labels.

Recommended views:

1. Triage

   • Table view.
   • Filter: open issues/PRs, Status:Inbox or missing priority/* / effort/*.
   • Purpose: decide priority, effort, release, and whether Sepo can work it.

2. Active Board

   • Board grouped by Status.
   • Filter: Status not Done/Later.
   • Purpose: day-to-day work tracking.

3. First Public Release

   • Table or board.
   • Filter: Release:public-v0.
   • Sort: priority, then effort.
   • Purpose: define what must land before the first public release.

4. Public Roadmap

   • Roadmap view grouped by Roadmap phase or Release.
   • Filter out internal-only maintenance unless it affects users.
   • Purpose: share Now/Next/Later publicly without exposing every internal task.

5. Sepo Queue

   • Table view.
   • Filter: Owner:sepo-agent or label agent / agent/*.
   • Columns: title, status, priority, effort, agent route, linked PR.
   • Purpose: see what Sepo can answer, implement, review, or orchestrate.

6. PRs To Ship

   • Table view for open PRs.
   • Include draft state, review status, priority, effort, linked issue.
   • Purpose: avoid planning only around issues while PRs sit unfinished.

Suggested operating process:

1. Create the Project from Team planning.
2. Add all open issues and PRs.
3. Add the custom fields above.
4. Run Agent / Project Manager manually in dry-run first.
5. After the label output looks right, enable label application with AGENT_PROJECT_MANAGEMENT_APPLY_LABELS=true and AGENT_PROJECT_MANAGEMENT_DRY_RUN=false.
6. Use the Project for human planning fields; use labels for automation-safe priority/effort signals.
7. For Sepo-owned work, set Owner=sepo-agent and use the issue body/comment with @sepo-agent /orchestrate or the relevant explicit route.

My recommendation: create a single project named Sepo Planning & Roadmap, start with Team planning, and add the views above. After you approve that structure, the next implementation step would be documenting this workflow in the repo and optionally tightening agent-project-manager output so it aligns with the Project fields.

[lolipopshock]

@sepo-agent /answer

Actually that leads to a very interesting question:

1. can the agent run the github command to create a the project given the project specification over github? (the github app should have the access)?
2. and we should consider do that in conjunction with perhaps a route for enabling the "project-planning" route?

[sepo-agent-app]

Yes, but I would not let the model freely run arbitrary gh project ... commands as the main mechanism.

GitHub Projects can be created/managed from automation: gh project create --owner <owner> --title <title> exists, and gh project field-create, gh project item-add, gh project edit, and gh project link cover most setup operations. The CLI docs say gh project needs the project token scope for normal user-token auth, and GitHub’s Projects API docs also show createProjectV2 via GraphQL. For GitHub App installation tokens, GitHub documents that Projects mutations may need additional App permissions; if createProjectV2 links to a repository via repositoryId, the App also needs repository Contents permission for that repository.

So the practical answer is:

• Can Sepo create the Project? Yes, if the authenticated token has Projects write access for the project owner.
• Can the normal GITHUB_TOKEN do it? I would not rely on it. Projects live at user/org scope, not just repo scope.
• Can the Sepo GitHub App do it? Likely yes for an org-owned Project if the App has org-level Projects: write permission and, when linking to this repo, the needed repo permission. If the App manifest does not currently include that permission, the installation owner must approve the permission upgrade.
• Should we implement it through raw agent shell access? No. The safer pattern is agent-proposed spec, deterministic CLI applies it.

This matches the repo’s current architecture. Existing routes are explicit and validated in ROUTES / EXPLICIT_ROUTE_COMMANDS (.agent/src/triage.ts). The current project manager already uses the right shape: the agent assesses issues/PRs and emits a structured plan, then deterministic code validates and applies only allowed label changes (.github/prompts/project-manager.md, .agent/src/project-management-labels.ts). I’d reuse that pattern for Project creation.

Recommended route design:

• Add a new explicit route: /project-planning.
• Keep it OWNER/admin-only by default, because it can create org/user-level resources.
• Make it two-mode:
  • plan: inspect repo backlog and produce a Project spec as JSON.
  • apply: create/update the Project from an approved spec.
• The agent should generate/adjust the spec, but a deterministic CLI should run the actual gh api graphql / gh project operations.
• Default to dry-run unless the request explicitly says apply/create.

Initial project spec shape could be:

{
  "owner": "self-evolving",
  "title": "Sepo Planning & Roadmap",
  "visibility": "PUBLIC",
  "link_repository": "self-evolving/repo",
  "fields": [
    { "name": "Status", "type": "single_select", "options": ["Inbox", "Backlog", "Ready", "In Progress", "In Review", "Blocked", "Done", "Later"] },
    { "name": "Release", "type": "single_select", "options": ["public-v0", "post-v0", "exploration"] },
    { "name": "Roadmap phase", "type": "single_select", "options": ["Now", "Next", "Later"] },
    { "name": "Workstream", "type": "single_select", "options": ["Agent runtime", "Orchestration", "Project management", "Distribution", "Memory/Rubrics", "Docs", "Testing"] },
    { "name": "Agent route", "type": "single_select", "options": ["none", "answer", "implement", "review", "fix-pr", "orchestrate"] }
  ],
  "views": ["Triage", "Active Board", "First Public Release", "Public Roadmap", "Sepo Queue", "PRs To Ship"]
}

Implementation plan, if approved:

1. Add project-planning to the route parser, label route support, docs, and access policy handling.
2. Add .github/prompts/project-planning.md that emits a strict JSON Project spec plus a human summary.
3. Add .agent/src/project-planning.ts and a CLI such as .agent/src/cli/apply-project-plan.ts.
4. Add .github/workflows/agent-project-planning.yml with dry_run / apply inputs and GitHub App auth.
5. Add tests for route parsing, spec validation, idempotency, and permission failure messages.
6. Document required GitHub App permissions and the recommended first Project setup.

For now, my recommendation is: create this as a dedicated /project-planning route, but make the first implementation dry-run spec generation plus permission check. Once that proves the App can see/create Projects for self-evolving, add the apply path.

[lolipopshock]

@sepo-agent /answer

Perhaps an even higher-level goal here is that, can we make the github project design seamlessly connected with our agent backend? Basically for the templates provided by githubs, they are optimized for existing human team rather than human agent teams. We might want to start with something super simple but adds critical features for us to manage the tasks and priorities. Here are some ideas (but not necessarily good ones):

1. In some kanban, you can drag a project to another column, and the agent will then start implementing it.
2. Also we can know how many tasks are executed by agents at the same time (also related to Display the corresponding label when running the action #25 )
   ...

I am not sure, what do you think?

[sepo-agent-app]

I think that is the right higher-level direction: we should design the Project as a human-agent operating surface, not just a human team board.

But I would be careful about the first trigger model. Dragging a card to a Kanban column and immediately starting implementation is attractive, but it is risky as v1 because a Project field change is less explicit than @sepo-agent /orchestrate or agent/orchestrate, and GitHub Projects webhooks are still a separate Projects/App surface. GitHub does have projects_v2_item webhooks for item activity, but they require GitHub App Projects permission and are documented as public preview. Sepo today is mostly Actions-driven through mentions, labels, and workflow dispatches, so the simplest reliable v1 should build on those existing triggers.

Current repo facts that matter:

• Sepo already supports explicit routes like /implement, /review, /fix-pr, /orchestrate, and label equivalents like agent/orchestrate (supported-workflows.md).
• Label-triggered runs are already one-shot: after routing, agent-label.yml removes the triggering agent/* label (supported-workflows.md).
• /orchestrate is already the right backend primitive for “let the agent decide the next action” and can dispatch implement/review/fix-pr flows (supported-workflows.md).
• agent-project-manager.yml already does periodic backlog assessment and priority/effort labeling, but it does not yet connect Project fields to agent execution (supported-workflows.md).
• Display the corresponding label when running the action #25 points at the missing piece: visible agent activity state, especially route labels that remain while an agent is actually running.

My recommendation: start with a very small “agent-native Project” design.

Fields:

• Status: Inbox, Backlog, Ready, Agent Queue, In Progress, In Review, Blocked, Done
• Executor: Human, Sepo, Mixed
• Agent route: none, answer, implement, review, fix-pr, orchestrate
• Agent state: idle, queued, running, blocked, failed, PR open, done
• Priority: can be mirrored from priority/* labels or kept as a Project field
• Effort: can be mirrored from effort/* labels or kept as a Project field
• Release: public-v0, post-v0, exploration

Views:

• Planning: all open items, grouped by Release or Roadmap phase.
• Agent Queue: Executor: Sepo and Agent state: queued/running/blocked/failed.
• Human Board: normal Kanban by Status, filtered to Executor != Sepo.
• Public Release: Release: public-v0.
• Agent Capacity: open issues/PRs where Agent state: running or label agent-running/*.

For v1, I would not make column drag itself execute code. I would make this workflow:

1. Human moves item to Status: Agent Queue.
2. Human sets Executor: Sepo.
3. Human sets Agent route: orchestrate or implement.
4. A scheduled/project-sync workflow detects queued items and applies the corresponding trigger label, for example agent/orchestrate.
5. Existing Sepo routing runs.
6. Sepo updates visible activity state:
   • add agent-running/orchestrate
   • set Project Agent state: running
   • remove or replace it at terminal state
7. Project view shows active agent load.

That gives us the “drag into queue” experience, but keeps execution explicit and auditable. It also makes #25 more important: trigger labels and activity labels should be separate. agent/orchestrate should mean “start this once”; agent-running/orchestrate should mean “Sepo is currently working.”

For concurrent task visibility, I would not compute it from Project columns alone. The source of truth should be:

• GitHub Actions runs for actual execution.
• Route activity labels for issue/PR-level visibility.
• Project Agent state field for planning UX.

Then the Project can show “how many tasks Sepo is running” by filtering Agent state: running, while a backend check can use Actions concurrency/runs to avoid over-dispatching. The existing workflows already have per-target concurrency groups, for example implementation is grouped by issue number (agent-implement.yml) and orchestrator by target/action/round (agent-orchestrator.yml). A later step could add a global AGENT_MAX_PARALLEL_TASKS gate.

So the sequence I’d use is:

1. MVP Project: simple fields/views, no automation from Project movement yet.
2. Activity labels from Display the corresponding label when running the action #25: show what Sepo is running and when it finishes.
3. Project sync one-way: Sepo writes Project fields from issue/PR/Actions state.
4. Queued Project items dispatch Sepo: scheduled sync detects Agent Queue and applies trigger labels.
5. Realtime Project webhook: later, if the GitHub App permission and webhook path are worth the complexity.

That keeps the first version simple while still moving toward the real goal: GitHub Project as the dashboard/control plane, Sepo backend as the execution engine.

[lolipopshock]

@sepo-agent /answer

I like it.

Executor: Human, Sepo, Mixed

Well maybe one idea is simply we should consider "assign" an issue or PR to the agent when we tag it?

Agent route: none, answer, implement, review, fix-pr, orchestrate
Agent state: idle, queued, running, blocked, failed, PR open, done

Not needed -- this is kinda too granular and complex now. Maybe after #25 is displayed, we can show the labels?

Priority: can be mirrored from priority/* labels or kept as a Project field
Effort: can be mirrored from effort/* labels or kept as a Project field

Frankly this should be the ideal way of project management? I think ideally project management should only be enabled when there's a corresponding project like that, and we can manage the labels in that way. And we should make it clear that it is an experimental feature (in the docs).

[sepo-agent-app]

Agreed. I’d simplify the model.

For now, the GitHub Project should be a planning surface, and labels should be the agent/backend signal layer. We do not need Executor, Agent route, or Agent state as Project fields yet. Once #25 is implemented, the active agent state can be visible through labels instead.

I’d revise the design to this:

Project fields:

• Status: Inbox, Backlog, Ready, In Progress, In Review, Blocked, Done, Later
• Priority: P0, P1, P2, P3
• Effort: Low, Medium, High
• Release: public-v0, post-v0, exploration
• Optional later: Workstream

Repo labels:

• priority/p0, priority/p1, priority/p2, priority/p3
• effort/low, effort/medium, effort/high
• one-shot trigger labels: agent/implement, agent/review, agent/fix-pr, agent/orchestrate
• activity labels from Display the corresponding label when running the action #25, for example agent-running/orchestrate or similar

On “assigning” to Sepo: yes, but I would make it best-effort. GitHub assignees are user-oriented; GitHub’s docs describe assignees as users, and the REST API can check whether a login is assignable before adding it. If sepo-agent-app or its bot identity is assignable in this repo, we can assign issues/PRs to it when Sepo starts work. If not, the fallback should be labels plus Project views. Assignment should be a UX convenience, not the source of truth.

The cleanest model is:

• Human wants Sepo to work: apply agent/orchestrate or mention @sepo-agent /orchestrate.
• Sepo accepts the task:
  • best-effort assign issue/PR to Sepo’s bot identity
  • add fixed agent status label if enabled
  • add route activity label from Display the corresponding label when running the action #25
• Sepo finishes:
  • remove route activity label
  • optionally unassign itself or leave assignment if the issue remains agent-owned
  • update status/summary through existing comments

For project management, I agree with your direction: it should probably be enabled only when a corresponding Project is configured. The current agent-project-manager.yml is already experimental-ish in shape: it is disabled by default and only applies labels when explicitly configured (supported-workflows.md). I’d make that more explicit:

• Add docs saying Project-backed project management is experimental.
• Add config like AGENT_PROJECT_MANAGEMENT_PROJECT_URL or AGENT_PROJECT_MANAGEMENT_PROJECT_ID.
• If unset, the project-manager can still do dry-run summaries, but should not pretend it is managing the roadmap.
• If set, the Project becomes the planning source of truth, and labels are synchronized/mirrored for repo search and agent automation.

The implementation order I’d recommend:

1. Finish Display the corresponding label when running the action #25 first: separate trigger labels from running/activity labels.
2. Add best-effort “assign to Sepo” on accepted agent work.
3. Create the simple Project with only Status, Priority, Effort, Release.
4. Update project-manager docs/config to say Project-backed planning is experimental and requires an explicit Project ID/URL.
5. Later add sync:
   • Project Priority/Effort -> repo labels
   • repo labels -> Project fields only as a fallback/bootstrap path

That keeps the first version understandable: humans plan in the Project, Sepo works from labels/mentions, and #25 makes active agent work visible without adding too many Project fields.

[lolipopshock]

@sepo-agent /answer

priority/p0, priority/p1, priority/p2, priority/p3
effort/low, effort/medium, effort/high

Can we avoid duplicating this priority in the repo labels because it's so distracting when we view the issues page? (in that when a new user opens this page, it will be very daunting for them to view it)?

Status: Inbox, Backlog, Ready, In Progress, In Review, Blocked, Done, Later
Can we simplify the label category? Inbox, In Progress, To Review, Done?

best-effort assign issue/PR to Sepo’s bot identity
No by default can we assign to @sepo-agent ?

[sepo-agent-app]

Yes, I agree with all three simplifications.

For priority/effort: we should avoid duplicating them as repo labels by default. The current implementation is label-first: the project manager prompt requires priority/* and effort/*, and the deterministic CLI only applies those managed labels (project-manager.md, project-management-labels.ts). That made sense before a GitHub Project existed, but with a Project, labels should not be the primary planning UI.

Better model:

• Project fields are the source of truth for planning:
  • Priority: P0, P1, P2, P3
  • Effort: Low, Medium, High
• Repo labels stay minimal and operational:
  • agent
  • agent/implement, agent/review, etc. as one-shot trigger labels
  • temporary running labels from Display the corresponding label when running the action #25, if we implement them
• priority/* and effort/* labels become optional legacy/fallback mode, not the default.

That also fits your concern: the Issues page should feel approachable to new users. A repo full of priority/effort labels looks busy and internal.

For Status: yes, I’d simplify to exactly:

• Inbox
• In Progress
• To Review
• Done

That is enough for now. Backlog, Ready, Blocked, Later can come later if the workflow needs them. For a small public repo, fewer columns are better.

For assignment: yes, default to assigning accepted work to @sepo-agent if GitHub says that login is assignable. GitHub’s assignee API supports checking whether a user can be assigned and returns 204 when assignable, 404 otherwise. It also manages PR assignees through the shared Issues endpoints. Source: GitHub REST assignees docs.

So the implementation should be:

1. Add config: AGENT_ASSIGNEE=sepo-agent.
2. When Sepo accepts an issue/PR task, check whether sepo-agent is assignable.
3. If yes, assign it.
4. If no, continue without failing and mention in logs/setup check.
5. Do not use sepo-agent-app unless explicitly configured.

I’d revise the project-management implementation plan to:

1. Mark Project-backed project management as experimental in docs.
2. Add AGENT_PROJECT_MANAGEMENT_PROJECT_ID or AGENT_PROJECT_MANAGEMENT_PROJECT_URL.
3. When no Project is configured, keep project management dry-run only by default.
4. When a Project is configured, update Project fields instead of applying priority/* / effort/* labels.
5. Keep label application behind an explicit legacy option.

The current docs already say project management is disabled by default and label writes require explicit config (supported-workflows.md, configuration-list.md). We can build on that without breaking existing behavior.

[lolipopshock]

@sepo-agent /answer

For assignment: yes, default to assigning accepted work to @sepo-agent if GitHub says that login is assignable.

This should be based on one our repo variable for the handler?

Add AGENT_PROJECT_MANAGEMENT_PROJECT_ID or AGENT_PROJECT_MANAGEMENT_PROJECT_URL.

This leads me to think that we should allow our github action to be able to modify the repo variable such that we can keep track of it?

And this may lead to a more general route, which is something like @sepo-agent /setup:

1. it can modify the repo variable
2. and specific when it decides to /setup project management, we should consider creating a github specific project for it in this way and the enable project management (with user confirmation) and then conduct it?

And this may lead to a more general route, which is something like @sepo-agent /setup:

Even more systematically, we should consider create an ISSUE template for repo setup such that the users can modify the settings easily?

[sepo-agent-app]

Yes on both points.

For assignment, it should derive from the existing handler variable first. The repo already has AGENT_HANDLE, defaulting to @sepo-agent (configuration-list.md). So the default assignee should be:

• AGENT_HANDLE=@sepo-agent
• normalized assignee login: sepo-agent

I’d avoid adding a separate AGENT_ASSIGNEE unless we discover that the mention handle and assignable login differ. A fallback override could be useful later, but the default should be “assign to the configured handler.”

On letting Actions modify repo variables: yes, GitHub has REST endpoints to create/update repository Actions variables, and GitHub App installation tokens can use them with Variables repository permission set to write. Source: GitHub REST Actions Variables docs. So a setup workflow can technically set things like:

• AGENT_HANDLE
• AGENT_STATUS_LABEL_ENABLED
• AGENT_PROJECT_MANAGEMENT_ENABLED
• AGENT_PROJECT_MANAGEMENT_PROJECT_ID
• AGENT_PROJECT_MANAGEMENT_PROJECT_URL
• maybe AGENT_PROJECT_MANAGEMENT_MODE=project-fields

But this should be treated as a privileged setup operation, not normal agent work. I would not let the model directly call gh variable set. The agent can propose a setup plan; deterministic code should apply only an allowlisted variable diff.

I like the /setup route, but I’d make it intentionally conservative:

• @sepo-agent /setup plan
  • reads the issue/template
  • inspects current variables/project state
  • posts a proposed diff
  • no mutation
• @sepo-agent /setup apply
  • requires OWNER/admin-level route access
  • applies only allowlisted variables
  • can create or link a GitHub Project
  • can enable project management
  • posts exactly what changed

That would be separate from the current onboarding check. Today onboarding creates trigger labels and a setup issue/checklist (README.md); /setup would be the higher-level “configure this repo” route. The route does not exist yet; current explicit routes are limited to answer/implement/create-action/fix-pr/review/orchestrate/skill (supported-workflows.md, triage.ts).

I also agree on an issue template. That is probably the right user-facing entry point.

Add something like .github/ISSUE_TEMPLATE/sepo-setup.yml:

• Agent handle: default @sepo-agent
• Assign work to handler: yes/no
• Enable status label: yes/no
• Enable project management: no / dry-run / project-backed
• Create GitHub Project: yes/no
• Project owner/title
• Project statuses: default Inbox, In Progress, To Review, Done
• Project priority field: yes/no
• Project effort field: yes/no
• Confirm: “Post /setup plan first; do not apply until I explicitly request /setup apply.”

Then /setup can consume that structured issue instead of guessing from free-form text.

For project management specifically, /setup apply could do this sequence:

1. Create or locate the GitHub Project.
2. Create the simple fields/views.
3. Store the Project ID/URL in repo variables.
4. Set AGENT_PROJECT_MANAGEMENT_ENABLED=true.
5. Keep writes in dry-run/project-field mode first.
6. Post next steps and the command to run the first project-manager pass.

This feels like the right architecture: issue template for human-editable setup intent, /setup plan for review, /setup apply for privileged deterministic mutation.

[lolipopshock]

@sepo-agent /answer

We talked a lot here; it seems there are some concrete sub tasks and issues that we should create first before proceeding?

Can you first print a list of bulleted points for suggested task separation and ordering and I can review it?

[sepo-agent-app]

Suggested task split and ordering:

• 1. Implement agent activity labels (Display the corresponding label when running the action #25 foundation)

  • Separate one-shot trigger labels from temporary running/activity labels.
  • Example: agent/orchestrate triggers once; agent-running/orchestrate shows active work.
  • This should land before Project integration because the Project can then simply display labels instead of duplicating agent state fields.

• 2. Assign accepted tasks to the configured agent handle

  • Derive assignee from AGENT_HANDLE by default, e.g. @sepo-agent -> sepo-agent.
  • Best-effort check whether that login is assignable.
  • Assign issues/PRs when Sepo accepts work; do not fail the run if assignment is unavailable.

• 3. Simplify Project planning model

  • Define the minimal Project fields:
    • Status: Inbox, In Progress, To Review, Done
    • Priority: P0, P1, P2, P3
    • Effort: Low, Medium, High
    • optional Release
  • Explicitly avoid repo-wide priority/* and effort/* labels by default.

• 4. Make project management Project-backed and experimental

  • Add docs/config clarifying that Project-backed project management is experimental.
  • Add config such as AGENT_PROJECT_MANAGEMENT_PROJECT_ID or AGENT_PROJECT_MANAGEMENT_PROJECT_URL.
  • If no Project is configured, project management should stay dry-run or summary-only.
  • If configured, Project fields become the planning source of truth.

• 5. Add a Sepo setup issue template

  • Create .github/ISSUE_TEMPLATE/sepo-setup.yml.
  • Let users configure setup intent in a structured way:
    • agent handle
    • assign-to-agent behavior
    • project management enabled/dry-run/project-backed
    • create/link GitHub Project
    • Project title/statuses/fields
  • The template should tell users to run /setup plan first.

• 6. Add a privileged /setup route

  • Add explicit route parsing for @sepo-agent /setup.
  • Start with @sepo-agent /setup plan.
  • It should inspect the setup issue and produce a proposed config/project diff without mutating anything.

• 7. Add deterministic /setup apply

  • Require explicit confirmation and strong route authorization.
  • Apply only allowlisted repo variables.
  • Do not let the model directly run arbitrary gh variable set.
  • Post an audit summary of all changed variables/resources.

• 8. Add GitHub Project creation/linking from setup

  • From /setup apply, optionally create or locate the configured GitHub Project.
  • Add the minimal fields/views.
  • Store the Project ID/URL in repo variables.
  • Enable project management only after the Project is ready.

• 9. Update project-manager behavior

  • Change current label-first project management into Project-field-first behavior.
  • Keep priority/effort labels as legacy opt-in only.
  • Update prompt, deterministic apply step, tests, and docs.

• 10. Later: Project-to-agent queue automation

  • After the above pieces are stable, consider scheduled sync from Project Status=In Progress / To Review into agent triggers.
  • Keep this later because Project field movement as execution trigger needs careful auth, idempotency, and audit behavior.