01 / Describe the problem
Name the user and the task they need to finish. Explain how they handle it today and what the application should make easier.
LEARN · APPLICATION DEVELOPMENT
Turn an application idea into a first release you can verify.
Start with one user, one problem, and one complete workflow. Define the result before asking an agent to build it, then carry the same acceptance criteria through review and deployment.
Keep the first release bounded.
02 / Define a working example
Supply sample records, roles, and the expected result. Make the smallest complete workflow clear enough to demonstrate.
03 / Review the delivered behavior
Inspect the change, run the relevant checks, and verify the published application against the original example.
Write a brief the agent can act on.
“Build a dashboard” leaves the agent to invent its users, metrics, and data. A more useful brief names the decision: an operations user needs to see which products are at or below a reorder threshold, using sample inventory records.
Add the fields, the threshold rule, who may view the result, and what should happen when a record is missing or stale. The agent can then propose a bounded implementation and identify decisions that still need your input.
| Part of the brief | Example |
|---|---|
| User and task | An operations user checks which products need replenishment. |
| Input | Sample products with available units and a reorder threshold. |
| Acceptance | Products at or below the threshold are flagged, including the equality case. |
| Later work | Connect the inventory system after the sample workflow is reviewed. |
Build a complete path before adding more features.
Ask the agent to plan the data shape, access rules, application behavior, and interface together. A useful first increment lets the user complete the task from start to finish, with enough error handling to understand a failed request.
Use sample data while the workflow is taking shape. Review a real integration separately, including source credentials, allowed records, update frequency, and what users should see if the source becomes unavailable.
Review the code and the evidence.
Check the diff against the brief. Tests should exercise the important behavior, including permissions and boundary cases. A successful build shows the application assembles; the tests and a walk through the live workflow show it does what users need.
Record what ran and what remains uncertain. If the change affects existing behavior, include a check that it still works. Keep the application’s normal review and merge requirements in place.
Keep a release record you can use again.
Write down the commit, deployed version, test time, environment, and outcome of each important check. Record failed checks and unresolved limits as well as successes. That gives the next agent task a concrete starting point.
| Check | Evidence to keep |
|---|---|
| Durable data | A test record is still available after reloading and signing in again. |
| Access boundaries | A second account cannot retrieve the first account’s private record. |
| A failed dependency | The user sees a useful error or clearly marked stale result; retries remain bounded. |
| Recovery | A backup restore or rollback is rehearsed safely, including compatibility with stored data. |
| Public pages | Known pages and missing pages return the intended status; mobile navigation and forms work. |
Verify the deployed first release.
For Redgold managed pipeline applications, the reviewable artifacts include data types, a route and pipeline manifest, transforms, and expected behavior. During preview, Redgold coordinates application creation, datasets, and managed deployment.
After publication, open the deployed application and repeat the agreed workflow. Confirm the intended revision, the visible result, and the access rules. Keep a record of that verification so the next task starts from a known release.