Examples

The same basic rhythm works for many kinds of work: understand what arrived, decide whether to commit to it, choose how to carry it out, and confirm the result.

The examples below show how that rhythm looks in practice. They are starting points rather than required processes.

Review a pull request

A pull request appears in the Inbox when someone requests your review.

1. Open the item and read the description, changes, and recent activity.
2. Choose Review now if it needs attention immediately, or move it to Todo for later.
3. Connect it to a goal only when the review belongs to a larger piece of work.
4. Review the change yourself, or use AI assistance to inspect the diff and surface questions.
5. Submit an approval, comments, or a request for changes.
6. Mark the task done after GitHub confirms that the review was submitted.

If the submission result is uncertain, Metryon keeps the action visible instead of sending the review again. You can check what reached GitHub before deciding how to recover.

Solve a bug

A bug may arrive through Jira, another integration, or a manual Inbox item.

1. Clarify the problem: expected behaviour, actual behaviour, impact, and any useful evidence.
2. Turn it into a task and set a priority that reflects its impact.
3. Link it to a goal if it affects a wider release or reliability outcome.
4. Associate the relevant repository and keep reproduction notes with the task.
5. Fix it manually or start an agent run with the task context and permission boundaries.
6. Run the relevant checks and confirm the original problem is resolved.
7. Mark the task done when the fix meets its acceptance criteria—not merely when the code has changed.

For a larger bug, separate investigation from implementation when the cause is still unclear. This keeps an early theory from quietly becoming the plan.

Implement a feature

Features usually benefit from a goal because they contain more than one step.

1. Create a goal that describes the user outcome and how you will recognise completion.
2. Add the tasks needed to reach it, such as design, implementation, testing, documentation, and release work.
3. Keep only the task receiving attention In progress; leave the rest in Todo.
4. Use a template when your feature work follows a repeatable shape.
5. Work manually, with AI assistance, or through an agent workflow as each task requires.
6. Review external changes before approving them.
7. Complete the goal when the outcome is available and verified, not simply when every implementation task is closed.

This separates the reason for the feature from the work required to deliver it. The plan can change without losing sight of the intended result.

Update documentation

Documentation work can start from a product change, an Inbox request, or a gap you notice while working.

1. Create a task that names the reader and the question the page should answer.
2. Connect it to the related feature goal when the documentation is part of delivery.
3. Associate the documentation repository and gather the relevant product context.
4. Draft the change yourself or let an agent prepare a first version.
5. Review the language, links, and rendered page.
6. Mark the task done after the updated page is published.

A small wording fix can remain a standalone task. A new documentation section may be easier to manage as a goal with separate writing, review, and publishing tasks.

Create user stories in Jira

Planned workflow

Jira intake in Metryon is currently read-only. Creating or updating Jira stories from Metryon will become available after Jira writes have the same approval, audit, and recovery safeguards as other external actions.

The intended workflow is:

1. Start from a goal, note, or Inbox item that contains the product need.
2. Draft one or more stories with a clear user outcome and acceptance criteria.
3. Choose the Jira project, issue type, and any required fields.
4. Review the proposed stories before allowing an external change.
5. Approve the creation action.
6. Let Metryon create the stories and keep their Jira keys linked to the original goal and tasks.
7. If Jira does not return a clear result, verify what was created before attempting the action again.

Until this is available, you can prepare the story in a Metryon note or task, create it in Jira manually, and add the Jira link back to the work in Metryon.

What stays consistent

The details change, but a few decisions remain the same:

• The Inbox is for deciding, not for storing accepted work indefinitely.
• A goal is useful when it adds purpose or groups several tasks.
• Todo holds commitments; In progress shows current attention.
• Manual work remains a valid choice even when automation is available.
• An external action is complete only when its result is known.