Features
Issue Planner
Turn a rough brief into repository-aware, reviewable GitHub work.
Plan before GitHub changes
Issue Planner reads a repository checkout, compares existing work, and asks only for decisions that cannot be derived from the codebase. It proposes either one standalone issue or one tracking parent with focused child issues and blocker relationships.
The interview is read-only. The planning model receives no GitHub credential and no GitHub mutation tool.
Create and refine a plan
Write the brief
Describe the outcome, constraints, and any known product decisions.
Answer missing decisions
The planner retains the conversation and asks focused questions when repository evidence is insufficient.
Review the proposal
Edit titles and bodies, inspect dependencies, and confirm that each issue is independently finishable.
Submit to GitHub
Approve the final proposal. Only then does the trusted submission path create issues and relationships.
Read transcript
The demo creates an Issue Planner brief, shows a repository inspection turn, answers one decision, reviews the proposed parent and child issues, and stops before GitHub submission.
Retained interviews and recovery
Planning state survives page navigation and runner interruptions. If a claimed turn loses its runner heartbeat, the lease can return the same turn to the queue. Reconnecting resumes with the pinned provider, model, and thinking level.
Frequently asked questions
Can Issue Planner modify my repository?
The planning interview uses a read-only checkout and receives no GitHub credential. GitHub issues are created only through the reviewed submission step.
Can I edit the proposed issues?
Yes. Review and edit the proposal before submission.
Does the planner detect duplicate work?
It compares the brief and repository context with existing issues before proposing new work.
Can I change models during an interview?
The selected provider, model, and thinking level are pinned for the retained plan so recovery does not silently substitute a different model.
Do provider credentials reach the hosted website?
No. Provider API keys and OAuth roots remain in the local runner environment. The hosted control plane receives sanitized availability, model catalog metadata, job events, and outcome evidence.
Can agents in one repository use different models?
Yes. Each built-in or custom agent selects its own provider, catalog model, supported thinking level, and repository tool image.