Work with the project agent
Ask grounded questions about your system and plans, inspect citations, and save suggestions for human review.
Open Project agent after selecting a project. The conversation is permanently associated with that project. It can use the human brief, selected repositories and tool evidence, current security findings, roadmap, cycles, and proposed ideas.
Ask a specific question
- “Which security issues should we address before this cycle finishes?”
- “Explain how the API connects to the datastore, and what evidence is missing.”
- “Given our goal of easier first contributions, what small feature could we validate next?”
- “What changed between the previous review and the current one?”
- “Which voted features are blocked, and what needs to happen before we plan them?”
The agent routes a question to a security, architecture, or product specialist. Bounded read-only tools retrieve relevant context. A separate verification step checks the cited evidence before an answer is retained. Unsupported claims are withheld or described as hypotheses and coverage gaps.
Know what a reference establishes
| Reference | It can support | It cannot establish by itself |
|---|---|---|
| Source observation | What the connected source recorded at that revision | The parts of the system that were not collected |
| Human project brief | A named team's recorded goal or constraint | Observed behavior, approved ADRs, or customer demand |
| Roadmap or cycle record | The delivery state the team recorded | A verified security fix or successful deployment |
| Proposed feature idea | A possible next step and its basis | A validated requirement or approved release commitment |
| Security finding record | A recorded issue, its state, and linked evidence | Exploitation or a verified fix |
| Security query coverage | Recorded counts for a stated search and source scope | Absence of vulnerabilities in the actual system |
Expand supporting references to read the provenance. Review uncertainty alongside the answer. Large contexts are bounded; inspect the planning counts and complete roadmap when you need a full inventory.
Understand the planning context
The agent can read recorded votes, direct dependencies and their delivery states, assignees, estimates, target dates, linked finding state, and cycle progress. Votes are feedback from participating accounts; they do not establish broad market demand or override security work. A completed or canceled dependency satisfies the roadmap's delivery guard, but does not prove its associated security issue was fixed.
Planning context favors unfinished work, the active cycle, in-progress or blocked tasks, then the team's priority and recorded votes. It includes up to 150 work items, 20 cycles, and 20 proposed ideas. These are context-selection rules; they do not reorder the team's roadmap or change priorities. Cycle counts cover the full cycle, including its recorded totals and carryover when it closed.
Expand Planning context below an answer to see the included and total record counts. The agent can search and page through the admitted work; records outside that selection remain unknown to the answer. Direct blocker summaries can include prerequisites outside the main work selection. Each work item reports its full dependency count and how many blocker details were omitted. Use Inspect the complete roadmap to review all work. A missing item in an answer does not mean that item does not exist.
Roadmap references open the specific work item. Cycle references open that cycle's retained work, and idea references lead to the project ideas section.
Inspect security beyond the initial snapshot
The agent starts with a bounded context. For security questions, it can search the complete finding list for the project's selected sources, filter severity or lifecycle state, and request additional pages. A finding outside the initial context can still be retrieved and cited. Workspace-only conversations retain their bounded snapshot; select a project for this wider lookup.
When you open a finding from a project, Ask Hyperoru keeps that project selected and prepares a question about the finding. Review or edit the question before sending it.
Expand Security context to see open finding summaries included, details retrieved by targeted lookup, and how many records each query matched. Each answer admits at most 100 targeted finding records across six lookups, in pages of up to 20. Each finding includes up to five source excerpts and its full evidence count. These limits keep individual answers focused; Inspect complete project security opens the full inventory.
An empty search has its own count reference. It means no recorded findings match those filters in the selected scope, not that the system is secure. A record may be incomplete, stale, or unsupported by runtime observations. Read the cited evidence and uncertainty before deciding on a fix.
The service rechecks retrieved records and query counts before retaining the answer, reusing a cached answer, saving its recommendation, or accepting it into the roadmap. If those facts changed, ask a fresh question. Finding references open their source record; count references open project security, whose view can cover more repositories than a restricted question.
Keep decisions with people
Choose Save idea on a recommendation to add it to the project brain. Review its basis and accept or dismiss it there. Only acceptance creates roadmap work. If the brief or source evidence has changed, ask for an updated answer before saving the old recommendation.
Changes to the admitted roadmap, dependencies, votes, or cycle state also require a fresh recommendation before saving or accepting an agent idea. The saved proposal itself does not invalidate its planning context. You can still dismiss a proposal whose context has changed. Older proposals without a recorded planning snapshot require a fresh answer before acceptance.
The agent does not publish a feature, reorder priorities, mark a fix verified, or merge code. Existing remediation workflows have their own proposal, approval, and verification controls.
Handle interrupted work
Conversations and completed answers survive reload. An in-progress answer shows its current stage and can be stopped. The service applies per-user and workspace concurrency, daily question limits, and model budgets. If a run is limited or fails, the question remains in the conversation with a reason; no successful answer is fabricated.
Model and worker configuration are required to generate live answers. A connected repository alone does not start an AI service or provide model credit. Archived projects keep their history and require restoration before starting a new answer.