| description | Take a product brief through repository setup, a bounded coding run, executable verification and source checkpoint review. |
|---|
This walkthrough produces a local change and verification evidence. It does not push a branch or create a pull request. Complete installation and connect Studio to the API first. Verify the included Flycanon service before starting: required retrieval needs an authenticated scope and actual citations.
See the Studio console tour for the wizard steps and evidence views. Its screenshots use controlled fixtures.
In Repositories, select Add repository. Enter its name, Git clone URL, provider and actual default branch. For a local exercise, use an absolute path to a repository with at least one committed file. Use provider Generic Git.
forge's server must be able to clone the repository. Existing uncommitted work in your source checkout is not copied into the run. Configure authentication through the server's Git credential helper or SSH agent; never embed credentials in the URL.
Open Start a run and select the repository. Use a specific, bounded brief:
Build a pyfly API for a small task list. Users can create a task, list tasks,
mark one complete and receive a 404 for an unknown task. Use typed request and
response contracts, a service for task behavior and meaningful pytest tests.
Keep this first version in memory. Include exact launch instructions, declared
dependencies, lint/type checks and a make check target. Do not add a frontend.
Choose pyfly, API only, and a ready coding provider. For a PHP product, choose larafly and follow the larafly walkthrough.
If your brief requires a make check target, enter:
[["make", "check"]]Each Studio command has a 120-second timeout. The HTTP API allows an explicit timeout up to the server's accepted limit. For a generated project whose command is not known in advance, leave this field empty and let forge select a supported verification command from the actual project files.
Select Start building. Studio opens the run detail. Its timeline records progress, while Changes shows the changed paths and diff. Verification contains the commands and their real results. Artifacts lists retained outputs reported by the server.
A successful run contains a generated change and passing verification. A failed command or provider error leaves a failed run with evidence; it must not be treated as a passing build. If a run is still active, Cancel run requests cancellation. Retry run creates another attempt; inspect both.
Read the diff, verification output and generated README. Run the product's startup command, exercise the documented behavior and inspect any browser frontend at its intended screen sizes. A passing command does not establish visual quality, external service delivery or production readiness.
Local generation does not automatically deliver a pull request. See Git publication for explicit publication.
For a connected GitHub project with issue polling and a mapped reader, write:
@forge, how is this task going? What still needs my decision?
Use the same issue for follow-up questions. If Forge has published a confirmed pending question to you, you may answer later without mentioning the bot:
Sales reviews proposals. Operations may reassign them.
The native record links your exact words to the original typed question, even after a factory restart. Several pending questions produce a clarification with question excerpts. An edited question, different issue or different owner does not authorize an answer to the old context.
Conversation access does not approve work. A worker answer waits for current
response permission, and Continue the same task needs current continuation
permission. An administrator may explicitly admit the same retained answer after
renewing the exact permission; you do not need to repost it. An uncertain effect
is reconciled rather than replayed. See ticket conversations
for the implemented GitHub scope and qualification limits.