Building Ham Radio Projects with AI: A Beginner’s GitHub Workflow

AI has made it possible for more of us to build the software we wish existed in our ham shacks. A logger, an AllStar dashboard, a club website, a station controller: we can describe an idea and start seeing results remarkably quickly.

That speed creates another problem. Ideas pile up in chat threads. We fix one thing and accidentally break another. Someone tests an old version. A useful suggestion disappears somewhere between a conversation on the repeater and the next round of prompts.

While developing Repeater Scribe, I have been putting a GitHub workflow in place to give that work some structure. I want to bring the same approach to the builders in the West Valley Amateur Radio Club—including the people who would never introduce themselves as software developers.

The goal is simple: capture the work, choose a small piece, build it, check it, and keep a record. AI can help with every step. We still decide what matters and whether the result works.

Field note: Workflow planning and beginner’s guide · Related project: Ham Radio / Repeater Scribe · September 12, 2026. GitHub procedures checked against official documentation on that date. The examples below are teaching examples, not claims of completed fixes.

Is this actually Agile?

Yes—“Agile” is a reasonable umbrella term. Agile emphasizes delivering useful software in small increments, responding to feedback, and adjusting how the team works. Those ideas fit a club where projects evolve as operators try them. The Agile principles explain that foundation.

More precisely, the approach here combines GitHub flow for making and reviewing changes with a Kanban-style board for showing where work stands. GitHub flow uses branches and pull requests; GitHub Projects provides the customizable board. GitHub itself does not require a particular development methodology. GitHub flow · About GitHub Projects.

For our purposes, start with small tasks, a clear owner, and a short review of what is ready next. Formal sprints and estimates can wait until there is a specific reason to use them. We have enough scheduled nets already.

The GitHub vocabulary, translated

Term	What it means for our project
Repository, or repo	The project’s files and their change history. Think of it as the shared project workbench.
Issue	A written task: a bug, feature request, documentation need, or question that requires work.
Project board	The view that shows what is waiting, underway, being checked, or finished.
Branch	A separate line of work where a change can be developed before it joins the main code.
Commit	A recorded set of file changes, with a message explaining the change.
Pull request, or PR	A proposed change submitted for discussion and review before it is merged.
Merge	Integrating the approved change into another branch—usually the project’s default branch, often named main.
Release / deployment	A release identifies a version for users; deployment puts a version into a running system.

An issue and a pull request have different jobs. The issue explains what needs to happen and why. The PR shows the changes intended to make it happen. A larger issue may need several PRs. For a first task, aim for one small issue and one focused PR.

A draft PR means the proposed changes are still being worked on. It can be discussed, but it must be marked ready before it can be merged. GitHub’s pull request reference covers the distinction.

Start with a board everyone can understand

Here is the board structure I recommend for this club workflow, following the planning, review, and validation stages we have been setting up for Repeater Scribe. These are custom status names we choose; they are not a required GitHub preset.

Status	What it means	What allows it to move forward
Backlog	Captured for consideration.	We understand the need and decide it is worth doing next.
Ready	Small enough to start, with a clear result expected.	Someone takes ownership and begins work.
In Progress	Someone is building or correcting it.	The proposed change is ready for review.
Review	The PR is checked for scope, correctness, and understandable changes.	Review concerns are addressed and relevant automated checks pass.
Validation	Someone tries the change and checks the promised behavior.	The agreed acceptance checks pass, with the result recorded.
Done	Validated work has been merged.	Record the PR link and any release or deployment follow-up.

For a beginner team, I recommend keeping the issue as the main board card throughout its life and linking the PR to it. You can also put PRs on the board, as we have discussed for Repeater Scribe, but an issue and its PR are separate items. Moving one does not automatically move the other unless a suitable automation is configured.

Pick one person responsible for keeping each task moving. Start with one active task per person. If validation fails, return it to In Progress and record what failed. If it is blocked, say what it is waiting for.

Done here means validated and merged. It does not mean installed on the club’s running server. Track deployment separately when someone still needs to update the actual application.

Write an issue before asking AI to build

An issue should let another person—or a fresh AI session—understand the task without reading your entire chat history. Search existing issues first. Then open the repository, choose Issues → New issue, and use the project’s template if one is provided. GitHub’s issue creation guide shows the browser steps.

For a bug, record what happened, what you expected, how to repeat it, and the app version and environment. For a feature, explain who needs it and what they should be able to do. In both cases, add acceptance criteria: a short checklist that defines a successful result.

For example, a small task inspired by a Repeater Scribe interface request could look like this:

Title: Add spacing between Play Audio and Re-transcribe buttons

Problem
The two buttons touch, making the actions harder to distinguish.

Expected behavior
The buttons have a visible gap and remain easy to use on a narrow screen.

How to check
Open a transcript entry where both actions are available.
Check a desktop window and a narrow phone-sized window.

Acceptance criteria
- A visible gap separates the buttons.
- Neither button overlaps or extends beyond its container.
- Both actions still work.

Scope
Adjust the layout. Keep the existing button labels and behavior.

That gives the AI a bounded job and gives a tester something concrete to verify. “Improve the interface” leaves far too much room for interpretation.

Bigger ideas need smaller pieces. An event export request might be split into transcript download, combined audio export, and a callsign report, with an issue tying the overall feature together. Each piece should produce a result someone can check.

Let AI help keep the record

Your AI assistant can turn a messy conversation into a useful issue. Give it a prompt like this:

Turn the following report into a GitHub issue for [repository].
Search for an existing issue first if you have repository access.
Include the problem, expected behavior, reproduction steps when known,
acceptance criteria, and explicit scope boundaries.
Do not invent versions, test results, or missing observations.
Identify any missing information that prevents the task from being actionable.
Create the issue if you have authorized write access; otherwise return
ready-to-paste text. Return the issue URL when created.
Do not implement the change yet.

Report: [describe the problem or idea]

A chat assistant only has the repository access provided by its environment. Asking it to use GitHub does not grant access. If it cannot create the issue, paste its draft into GitHub yourself. Look for the actual issue URL before assuming the task was recorded.

Once a decision is made, put it in the issue or PR. Chats are useful for exploring ideas; GitHub should hold the current requirements, decisions, and test results so the next person can pick up the work.

Take one task from Ready to Done

Choose it. Agree on the acceptance criteria, assign an owner, and move the issue from Ready to In Progress.
Build it. Have the coding assistant read the issue and repository instructions, make a focused change on a branch, and open a draft PR.
Review it. When the change is ready, mark the PR ready for review and move the issue to Review. Read the explanation and examine the changed files. Ask for help understanding anything unclear.
Validate it. Run the proposed version in a suitable test setup. Move the issue to Validation and work through the acceptance criteria. Record which version or commit was tested and what happened.
Finish it. After review and validation pass, the maintainer merges the PR, closes the completed issue, and sets the board card to Done. Record any remaining release or deployment task.

Here is a prompt for the coding assistant once you have selected an issue:

Implement [issue URL] in [repository].
Read the issue, relevant discussion, and repository contribution instructions.
Summarize the acceptance criteria, then implement the agreed scope on a branch.
Keep unrelated cleanup out of this change; report additional findings separately.
Run the relevant checks and report exactly what passed, failed, or was not run.
Open a draft pull request explaining the problem, the change, and how to test it.
Reference the issue in the PR description.
Return the PR URL and any validation steps that still require a person.
Do not merge or deploy.

This is also where a little restraint helps. An AI reviewer may suggest a dozen improvements to a small change. Evaluate each one: does it identify a real problem in this work, or propose optional cleanup? Fix relevant defects. Capture worthwhile separate work as another issue. Ask the reviewer to explain the failure scenario when the benefit is unclear.

Review and validation answer different questions

Review asks whether the proposed change makes sense. Did it stay within scope? Does the explanation match the files changed? Did it accidentally remove a useful behavior? Are there unresolved concerns?

Validation asks whether it does the job for an operator. For the button example, open the actual screen, check the gap at both sizes, and use both buttons. An automated test result cannot tell you whether the interface feels sensible during a net.

Club members can contribute directly here. A net control operator knows whether a logger supports the way a net runs. An AllStar operator can recognize misleading node status. Someone following installation instructions for the first time can find a missing step that the author no longer notices.

Record the outcome in the PR: what build you used, what you tried, what passed, and what still failed. If you only inspected a screenshot, say so. If the AI could not run a test, leave that test outstanding. Confident prose is not a test result.

Connect the PR to the issue correctly

Put the issue reference in the PR description, the main summary at the top of the PR. If the PR completes the issue, use:

Closes #123

When that PR is merged into the repository’s default branch, GitHub can automatically close the issue. For a PR that only contributes part of the work, use an ordinary reference:

Refs #123

Refs is a writing convention, not an automatic closing keyword. The issue number provides the reference. Do not rely on a closing phrase buried in an ordinary comment to close the issue. GitHub documents the linking and closing rules here.

Board status, issue closure, PR readiness, and deployment are separate things. Add automation after the team understands the manual steps, and verify what each rule actually changes.

Set up your first project

Use one repository for the project. Add a README that explains its purpose, how to run it, and where contributors should report problems. Existing projects can keep their current repository.
Create a GitHub Project with a board view. Add the six Status values above, then add your repository’s issues. A repository holds the files; a Project organizes the work. GitHub’s project setup guide covers creating the Project.
Start with three real tasks. Capture one bug, one small improvement, and one documentation need. Choose one to move to Ready.
Write the working agreement in the repository. Include the board meanings, who can approve and merge, how to test changes, and what Done means. Tell your AI assistant to read it when starting work.
Complete one full cycle. Take the small task through implementation, review, validation, and merge before adding elaborate automation.

At the next club development check-in, open the board. What is ready? What is stuck? What needs someone to test it? Those questions give a short conversation a useful outcome.

The same habits apply to station documentation, equipment inventories, and hardware projects. An issue can track a bench test or a mounting problem; a PR can review changes to the instructions or design files. The physical result still needs to be checked in the real world.

For our WVARC builders, here is the first assignment: take one bug or idea from your current AI conversation and turn it into an issue with a clear acceptance checklist. Then carry that one task all the way through. A little structure gives our rapid experimentation a history that the whole team can use.