Use case · Feature development
Ship the feature. Keep the review.
Hand Ysra an issue or product brief and a repository. Come back to a candidate you can run, read, and question — with the proof attached.
Buildacme/web · mainExample
“Add organization invites. Admins invite by email; invitees land in the right workspace. Prove the happy path in the browser.”
01 · The outcome
A reviewable repository change that does what the issue asked, with evidence that it does.
02 · What Ysra receives
- The issue or product brief
- The repository and base branch
- Constraints: what must not change
- Acceptance criteria, if you have them
03 · What stays with you
- Which repository and branch Ysra works on
- The budget, and any extension of it
- Whether to commit, push, or open a pull request
04 · What Ysra does
- 01UnderstandReads the repository structure, conventions, and the code the change will touch before editing anything.
- 02PlanProposes the approach. In plan-first mode you approve the specification before work begins.
- 03ImplementEdits files, runs commands, and starts the app in an isolated workspace.
- 04Native checksRuns the repository’s own tests, type checks, lint, and build.
- 05Browser workflowFor runnable web products, exercises the new journey and keeps screenshots.
- 06Independent reviewAssesses the candidate against the request, separately from the implementation.
- 07Pull requestPrepared when you grant delivery authority.
05 · The evidence that comes back
- Diff with per-file line changes
- Commands run and their results
- Acceptance results per criterion
- Browser screenshots and viewport
- Build Report
06 · What can happen next
- Point at the preview to request a precise edit
- Open the pull request
- Rewind to a checkpoint and take a different path
Give Ysra the outcome. Keep the authority.
Start a software task, ask from company context, or put a repeatable workflow on a schedule.