DEV Community: Weiwen Weng

Test Cases as Markdown in Git

Weiwen Weng — Wed, 21 Oct 2026 12:18:13 +0000

A spreadsheet works until two people edit it. A hosted test tool works until the team is six people and the UI is already in the way. If the work already lives in a Git repository, the manual test cases can live there too.

This is the layout I use. One Markdown file per case. YAML front matter for the fields you filter and link. A separate folder each time you execute. The files stay readable in any editor, and an agent can write a case because the schema is the file.

Who this is for

Solo developers and small teams who already have a repo. You want a procedure a person can run, a history of what changed, and a link from the case back to the ticket.

Automated tests stay in code. This format is the spec a human follows, and the record of a manual run.

The case and the run are different files

The case is the procedure. It should change when the product changes.

The run is one execution. It changes every time someone marks a case pass or fail.

Put both in the same file and every test session rewrites the spec. The diff used to mean "the login steps changed." After a few runs it means "someone tested this on Tuesday." Review becomes noise, and a merge between two testers gets worse.

Split them. In Gitoza the tree looks like this:

File	What it holds	When it changes
`.gitoza/test/cases/<project>/…/<case_id>.md`	Title, fields, steps, expected result	When the procedure changes
`.gitoza/test/runs/<run_id>/head.md`	Run title, tickets, release	When the run is created
`.gitoza/test/runs/<run_id>/cases.md`	Which cases are in the run	When membership changes
`.gitoza/test/runs/<run_id>/results.md`	Pass, fail, skip	During execution

The case id is the filename. AUTH-001.md is case AUTH-001. One case, one file. Creating a case in the app assigns an id like TC-…. A file you or an agent write can use any id of letters, numbers, underscores, and hyphens, as long as the filename matches.

Run files are YAML front matter only. A YAML mapping between --- fences, with an empty body. The case file is the one with a real Markdown procedure underneath.

YAML front matter is the row. The body is the procedure.

Fields you want to filter, assign, or link go between the --- lines. The steps a person follows go below them.

A file is valid with a title:

---
title: Verify login error message
---

That is enough for the app to index it. A case you will actually run picks up a few more fields. priority, status, and tags are for search. requirement_ids is the list of tickets this case covers. params holds data that changes by environment, so the steps can stay the same on staging and production.

---
title: Verify login error message
status: active
priority: high
tags:
  - auth
  - smoke
requirement_ids:
  - GITO-BUG001
params:
  environment: staging
---

## Steps

1. Open the login page.
2. Enter invalid credentials.
3. Submit the form.

## Expected

A clear error message is shown. A valid login redirects to the dashboard (see [[GITO-BUG001]]).

status is the life of the case: active, draft, or deprecated. Review is a different field, approve_status (draft, approved, rejected). Using one field for both makes a filter lie about what is ready to run.

One action per numbered step. In a manual run, that step is the thing on screen.

Traceability is text in the repo

requirement_ids on the case lists the tickets it covers. In the body, [[GITO-BUG001]] links to that ticket. Open the ticket and this case is listed under Tested by.

The link is a string in the file. Copy the repository and the link is still there. Close the desktop app and the link is still there.

A run points the other way. head.md lists the tickets that run covers, and can name the release it was executed against. On the ticket, those runs show up as Covered by runs. Results stay in the run folder. They are not copied back into the case.

---
run_id: R-A1B2C3
title: Login smoke, staging
requirement_ids:
  - GITO-BUG001
---

results.md is sparse. Only cases that have been executed appear. Counts are derived when you open the run, so a stale passed: 4 is not something two people have to merge.

---
run_id: R-A1B2C3
results:
  .gitoza/test/cases/MyProject/01_auth/AUTH-001.md:
    result: passed
    executed_at: "2026-04-02T09:15:00Z"
---

The app writes more bookkeeping around these keys (dates, review, comments). The split above is the part that keeps history readable.

Review the diff on its own branch

A case change is an ordinary Git diff. A step was added. A tag was removed. A ticket id was linked. That diff is the review.

These files live on a branch named gitoza, separate from application code. A pull request for a feature stays about the feature. Test and ticket edits are reviewed on their own branch: you look at a changelist, then confirm, and fetch, rebase, and push happen in the background. If two people edited the same item, sync pauses on Keep mine or Keep shared version.

Git history of the case file is the audit log. You can see who changed the expected result, and you can check out an older copy of the procedure.

What makes the repository painful

Three habits break this.

Screenshots committed as binaries. A PNG in the case history makes every clone heavier, and the diff stops being text. Refer to the image from the Markdown and keep the bytes in asset storage. The commit stays a documentation change.

Two people rewriting the same case. A Markdown procedure merges badly when both sides rewrite the steps. Smaller files limit the damage: one case per file, membership in cases.md, outcomes in results.md. When an overlap does happen, stop and pick a version. A silent merge in the middle of a YAML block is how a case disappears from search.

Pasting automation output into the case. A JUnit file is a result from a build, in the same family as results.md. Upload the XML to the place your CI results already go, and read it there. On the case, automated: true is enough to say code already covers the procedure. The stack trace from last night's job belongs with the build, beside the case.

Let an agent write the file

Give the agent the path and the headings. It does not need a plugin.

Create .gitoza/test/cases/<project>/<folder>/<case_id>.md.
The filename is the case id. Letters, numbers, underscores, and hyphens only.
Start the YAML front matter with title:. Add priority, status, tags, and requirement_ids when you know them.
Use ## Steps and ## Expected. One action per numbered step.
Put the ticket id in requirement_ids. If the sentence mentions the ticket, write [[TICKET-ID]] too.
Leave pass, fail, and skip out of the case file. Those belong in a run.

Refresh the index after the file is on disk. Search and filters read the YAML front matter. The body renders as a page. After that, edit in the UI. The raw file is there when you want a diff or an agent. Day to day you can ignore it.

A title alone is a valid case. Fill the other fields when the case is real.

I use this layout in Gitoza, a local desktop app for tickets, a wiki, and tests stored as Markdown in Git. Sync commits to the gitoza branch after you review the changelist. There is no account.

Source (Apache-2.0): github.com/gitoza-io/gitoza

Why Your AI IDE Wants Task Tickets as Markdown in the Repo

Weiwen Weng — Thu, 24 Sep 2026 13:03:30 +0000

Update: Same idea as before — structured fields + a readable body in the repo. The files are now .md (YAML front matter + Markdown body) instead of .yaml.

Here is my actual workday before I changed anything: write code in the IDE, alt-tab to the board to check what the ticket said, alt-tab back, forget half of it, alt-tab again. And when I finally got an AI agent doing real work for me, it could see all my code and none of my tasks. I was the API between the two.

MCP into Jira doesn't really fix this. It gives the agent a way to query the board, but that's another server, another auth flow, more schema in the context window — and the ticket still isn't in the pull request. The board updates later, by hand, if anyone remembers.

What I do instead

Tickets are just files in the repo:

.gitoza/tasks/tickets/{project}/{id}.md

What you actually need on top of that is a UI that renders the file and lets you edit it. Nobody wants to manage tasks by poking at raw markup all day.

Front matter for the machine, Markdown for the human:

---
title: Lockout after failed logins
type: bug
status: open
priority: high
tags: [auth]
---

## Description

Brief context for the agent and the reviewer.

## Acceptance criteria

- …

Here's what that looks like in Gitoza:

Two things fall out of this format, and both matter more than I expected.

The Markdown body means it renders. Description, acceptance criteria, checklists — you get a readable ticket in any preview pane, no special tooling required.

The front matter means state is structured. status, priority, type are real fields, not prose, so you can filter and roll them up without parsing English.

And for the agent it's just a file it already indexes. No tool call, no JQL, no "fetch issue then map fields." I can say "AUTH-102 is done, update it" or "draft a ticket for this bug" and it edits the ticket the same way it edits code. Way fewer steps, way fewer things to get wrong — a wrong field value shows up in the diff instead of silently landing in someone's SaaS board.

The other half of it: the ticket ships in the same PR as the change. Reviewers see scope and acceptance criteria next to the implementation, and after merge the file in the repo is the truth. No row someone forgot to flip.

I run the tool on itself

I build Gitoza, an open-source desktop app for exactly this (tickets, wiki, test cases, and runs as Markdown in Git), and I plan Gitoza with it. Every feature, every bug, every release is a ticket file in the project's own repo. Releases get planned, scoped, and closed without me opening a browser tab.

That's really the whole pitch. I stopped context-switching, and the agent finally got to see both halves of the job.

Try it: gitoza.com · GitHub

Skip MCP for Jira: Tickets as Markdown in Git

Weiwen Weng — Fri, 11 Sep 2026 08:52:22 +0000

The usual way to give Cursor a Jira or Linear ticket is middleware: an MCP server, a token, a tool schema. It works until the MCP process dies, the token rotates, and the agent spends a turn explaining it cannot list issues. You are back in the browser. That is a lot of moving parts for "read this task."

The agent already edits your .ts and .rs files. Tickets do not need a different transport. Put them on disk, in Git, next to the code.

flowchart LR
  agent[Cursor Agent]
  md[Ticket and wiki Markdown]
  git[Git]
  sqlite[(SQLite cache)]
  ui[Gitoza UI]

  agent -->|read and write| md
  md --> git
  md -->|incremental index| sqlite
  sqlite -->|lists and search| ui
  md -->|open detail| ui

Same folder for the agent and the UI. Git keeps history. SQLite is only a cache so lists stay fast.

Remote tickets break the loop the agent is good at

Read a file, change a file, show a diff. That is the loop. A remote ticket is none of those things.

The first time I wired Cursor to Jira through MCP it lasted about a day. Then the token rotated, the container needed a restart, and the chat window had no tools. Firewall rules and mcp.json drift are not "project context." They are ops for a read query.

The token is usually wider than the repo, too. Scoping every Jira project is tedious, so people ship read:jira-work and call it done. That ACL does not show up in the PR.

And when the agent updates a remote issue, the write is live. No staging area. If it hallucinates a status flip across ten tickets, there is no git reset. You get whatever the API already committed.

Tickets as Markdown in the repo

If the agent can patch src/lib.rs, it should be able to patch the ticket that says why. In Gitoza the tree looks like this:

.gitoza/
  tasks/tickets/
    Gitoza_handbook/
      .project.md            # ticket_prefix: GITO
      GITO-AIDEMO.md         # one file = one ticket
      GITO-WIKPDF.md
      releases/
        1.2.0.md
  wiki/
    01-overview/
      W-HBK000.md
    03-tickets/
      W-HBK010.md

One project folder, one file per ticket, and the filename stem is the ID (GITO-AIDEMO). There are no nested hierarchies—just a flat, predictable tree that both grep and an LLM context window can parse in milliseconds.

The schema is small on purpose. Identity lives in the filename, so you can omit ticket_id from the front matter. Extra keys are optional:

---
title: "AI Demo: Document native lifecycle from open to release"
type: task
status: open
priority: medium
reporter: Cursor Agent
tags:
  - native
  - demo
  - qa
---

We need a full flowchart of how native tickets move from open to release.

## Problem
Remote PM tools give agents no staging area and no rollback.

## Acceptance criteria
- [ ] Mermaid lifecycle diagram in this body
- [ ] Linked from [[wiki:W-HBK010|Tickets overview]]

That is the document Gitoza renders and the document Cursor opens. Wiki pages under .gitoza/wiki/ use the same shape: title, optional tags, Markdown body. No second format to teach the model.

Give it one example file and it copies the neighbor. It is not guessing a Jira JSON blob through a tool schema.

A prompt that actually works — no MCP, no API key:

Search .gitoza/tasks/tickets/Gitoza_handbook/ for any ticket about
exporting wiki pages to PDF.

If none exists, CREATE:
  .gitoza/tasks/tickets/Gitoza_handbook/GITO-WIKPDF.md

Frontmatter: title, type: task, status: open, priority: medium,
tags: [handbook, wiki], reporter: Cursor Agent.

Body: problem statement, 3-bullet AC, and [[wiki:W-HBK010|Tickets overview]].

If a match exists, report its id. Do not duplicate. No MCP.

The agent writes a file. Git sees an untracked path. Done.

SQLite is a cache, not the database

Markdown on disk is the source of truth. SQLite is there so the UI can virtualize thousands of rows without walking the tree on every keystroke.

When Cursor (or you) drops a new ticket, we do not rebuild the world. git status --porcelain, keep files under .gitoza/, upsert those rows. Past 200 changed files we just reindex; that is the escape hatch, not the common path.

// rust-backend/src/lib.rs
pub(crate) const INCREMENTAL_THRESHOLD: usize = 200;

if changed_tickets.len() > INCREMENTAL_THRESHOLD {
    let _ = tickets::reindex_tickets_for_repo(&conn, repo_path, slug);
} else {
    tickets::apply_incremental_ticket_changes(
        &conn, repo_path, slug, changed_tickets, &ticket_audit,
    )?;
}

Per file: parse, upsert, or delete the row if the file is gone.

// rust-backend/src/tickets.rs
pub(crate) fn apply_incremental_ticket_changes(
    conn: &Connection,
    repo_path: &Path,
    slug: &str,
    changed: &[String],
    audit: &crate::AuditStampSource,
) -> Result<()> {
    for rel in changed {
        if !is_ticket_path(rel) {
            continue;
        }
        let abs = repo_path.join(rel);
        if abs.is_file() {
            let Some(d) = read_ticket_md(&abs)? else { continue };
            if validate_ticket_file_path_for_write(rel).is_err() {
                continue;
            }
            upsert_ticket_db(conn, detail_to_upsert(&d, rel, slug, audit))?;
        } else {
            conn.execute(
                "DELETE FROM tickets WHERE repo_slug = ? AND file_path = ?",
                params![slug, rel],
            )?;
        }
    }
    Ok(())
}

Lists hit SQLite. Opening a ticket re-reads the Markdown. updated_at / updated_by live in the index, not in the file, so agents do not invent timestamps. If the cache is stale, delete the rows and scan disk again.

Video: local agent, no MCP

Copy the workspace path from Gitoza, open that folder in Cursor, ask it to find / create / edit tickets. Gitoza picks up the files when they hit disk.

Watch the demo

Handbook used in the recording: github.com/gitoza-io/gitoza-handbook.

Collaboration: one branch, linear rebase

The usual objection is merge-conflict hell in .gitoza/tasks/. That happens if you copy GitHub Flow onto tickets: three branches, three people, one GITO-1.md. We don't.

One work branch, named gitoza. Publish is fetch → add → commit → rebase onto origin/gitoza → push.

flowchart TB
  fetch[fetch origin]
  add[add Markdown]
  commit[commit on gitoza]
  rebase[rebase onto origin/gitoza]
  conflict{Same ticket edited?}
  push[push]
  pick[Resolve in UI]
  history[Linear history]

  fetch --> add --> commit --> rebase --> conflict
  conflict -->|no| push
  conflict -->|yes| pick --> push
  push --> history

// crates/sync-engine/src/publish.rs
let rebase = git_run(
    self.repo_path,
    &["rebase", "-Xfind-renames=100%", origin_ref.as_str()],
)
.await;

Different tickets rebase cleanly. The same ticket is a real conflict, and the UI makes you pick a side. That is rarer than people expect, because each ticket is a small file.

If the agent wrecks a batch of tickets, you already know the fix. In the app you can restore / discard local changes the same way you would in VS Code — or drop to Git:

git checkout -- .gitoza/tasks/tickets/
# committed locally, not pushed:
git reset --hard HEAD~1

Nobody has to pick a feature branch. They see a linear timeline on gitoza.

Because tickets live locally, the whole backlog works offline on a train or behind a strict enterprise firewall—zero outbound webhooks required.

Try it: github.com/gitoza-io/gitoza

Link Tickets to Tests and Wiki in One Git Repo

Weiwen Weng — Sun, 30 Aug 2026 17:47:59 +0000

Most teams don't have a traceability problem. They have a glue problem.

The ticket is in Jira. The spec is in Confluence. The cases are in TestRail or Xray. Last week's run is a spreadsheet someone exported. Every "link" is a URL into another product, another login, another spinner. It looks fine in a slide deck. Day to day it rots: the wiki still points at a ticket that got closed and reopened under a new key; the TMS still lists cases for a story that never shipped.

There's a simpler pattern: keep the whole graph as files in one Git repo. Tickets, wiki pages, test cases, and runs are just YAML on disk. Following a link means opening a file—not waiting on three APIs to agree.

Four kinds of files, one tree

.gitoza/
  tasks/tickets/{project}/{ticket-id}.yaml
  wiki/{folders}/W-xxxxxx.yaml
  test/cases/{project}/…/{case-id}.yaml
  test/runs/R-XXXXXX/

The id is the filename. Tickets look like AUTH-102.yaml. Wiki pages use W-… stems. Runs use readable R-… folder names. Requirement ids on tickets, cases, and runs are the same kind of string you'd put in a TMS field—except they live next to the body, in Git.

Releases can sit beside tickets if you want them. Optional. You don't need a fourth SaaS for the graph to exist.

How the links actually work

You don't paste Jira URLs into Confluence and hope.

In any Markdown body—ticket, wiki, case, or run—you insert a link that searches tickets and wiki pages and writes something like:

[[AUTH-102]] — opens the ticket
[[wiki:W-ABC123]] — opens the wiki page

Bare [[…]] is a ticket. Prefix wiki: for a page. Unresolved targets get an amber dotted underline, so you see the hole before you sync.

On the ticket itself, related lists come from the same ids: children, cases that test it, runs that cover it. Click a wiki link in a case or run and the page opens. No integration job. No "issue content" macro.

A wiki spec can look like this:

# Lockout after failed logins

Story: [[AUTH-102]]

See also [[wiki:W-ABC123|Auth overview]].

A case carries a requirement_id (tickets and runs can too), so coverage is a field you can search—not a comment someone forgot to update.

Why the click feels instant

SaaS linking is a network sport. Open a story → wait for Confluence → wait for Xray → the related-issues panel flashes empty, then fills, then jumps.

When the YAML is already on disk, following a link is a local lookup. Search and related lists hit an index derived from the files—not a vendor round-trip. Offline still works. Ticket → wiki → run feels like switching files in an IDE, because that's basically what it is.

You still sync when you want the team to see changes. Browsing doesn't wait for that push.

Traceability without a second product

Vendor TMS tools win on links: story → cases → execution. File-based setups need the same discipline—just as fields and filenames, not as glue.

From	To	How
Wiki spec	Ticket	`[[TICKET-ID]]` in the body
Ticket	Wiki	`[[wiki:W-…]]`
Ticket	Cases / runs	requirement ids
Case or run	Wiki	wiki link in the body
Case	Automation	filename id tagged on Playwright / Robot

You don't get magic bi-directional sync with Jira out of a text file. You get a graph you can grep, review in a PR, and open with no account. People who push back on "tests in Git" usually aren't wrong about the missing piece: without stable ids and a UI that follows them, it feels incomplete next to Xray. The ids were never the hard part. Putting tickets and wiki in the same tree as the cases is.

The agent can walk the same graph

If the spec, the ticket, and the run are files, an AI IDE can already read them. Useful asks look more like:

Which open tickets in auth have no cases?
Does this run cover AUTH-102?
Which wiki page describes the lockout behavior?

No MCP setup per product. The graph is already in the repo.

What I built for this

I built a desktop app (Gitoza) around this layout: tickets, wiki, cases, and runs in one workspace, with a link picker and related lists on the ticket. Confirm changes before you push. Connect the product repo or a dedicated planning repo—the format doesn't care.

Create a ticket (filename is the id), add a wiki page, insert [[that-id]], put the same requirement id on a case, drop it in a run, click through. Sync when you're ready.

gitoza.com — free for personal use, no account.

Traceability that depends on three SaaS products is an integration project. Traceability that is filenames, [[links]], and requirement ids in one repo is just files.

Task Tickets as Markdown in Git — Ask If It's Implemented

Weiwen Weng — Fri, 14 Aug 2026 08:33:31 +0000

SaaS boards and the codebase drift apart. A task ticket stays open after the code shipped. Another is marked done and never landed. Managers follow the board; engineers follow the repo. Nobody has a cheap way to ask: is this actually in the code?

The fix is not a better dashboard. It is task tickets as Markdown on disk—plus wiki Markdown—so an AI IDE can read them like any other file. Gitoza is the local-first UI for that layout. Files live in Git so the team can sync: the product repo, or a dedicated Git repo for planning. What matters is local files, not a vendor database.

When task tickets drift from the codebase

Cloud trackers live in a different universe from the branch you just merged. That is ticket–code drift: the board and Git no longer describe the same work.

Typical mess:

Implementation is in main. The ticket is still open.
The ticket is done. The function was never written—or it was reverted.
Two people file the same bug two weeks apart. The board grows; the work doubles.

You cannot ask Jira “does this match the repo?” without glue, exports, and hope. The agent in your IDE already sees the code. It cannot see a SaaS board unless you copy-paste.

When Markdown task tickets sit on disk, the agent can open them. Give it the ticket folder and the code folder—same clone or two checkouts—and the question becomes ordinary.

Markdown task tickets and a Git wiki on disk

Gitoza stores Git-based task management as files:

.gitoza/tasks/tickets/{project}/{ticket-id}.md
.gitoza/wiki/

The ticket id is the filename. YAML front matter holds status, assignee, priority, type, tags. The Markdown body holds the description. Wiki pages (sidebar: Library) are nested Markdown under .gitoza/wiki/—docs, diagrams, the notes that used to live in a Confluence tab nobody opens.

Those paths live in a Git repo you connect as a workspace. Many teams keep task tickets beside the product. Others use a dedicated planning repo so tickets are not mixed into application history. Either way the format is the same: Markdown with front matter on disk.

Browse and edit in the desktop app: tree + detail, same pattern as Tickets. Search hits the local index. No spinner waiting on a vendor API. That is why a local-first ticket tracker feels quicker than SaaS—the source of truth is disk, not a round-trip.

Ask an AI IDE if a ticket is already implemented

Point an AI IDE (Cursor, VS Code with an agent, or similar) at the Markdown task tickets—and at the source tree, even if that is a second folder. Then ask what a Kanban column cannot answer:

Is AUTH-102 implemented in this branch?
This ticket is still open—did the code already land?
This ticket is done—where is the change?

Those three close the status ↔ code gap. You are not trusting the board. You are checking the files.

Check if a bug ticket already exists

The same files stop duplicate work:

Is there already a bug ticket about lockout after failed logins?

If the answer is yes, you do not file another ticket, and you do not implement the same fix twice. That is how Markdown tickets in Git keep the backlog clean—search on disk, not another Jira query.

You only attach the ticket files you care about. Retrieval is grep and the local index. Native files beat a Jira MCP bridge. The agent does not care whether those files came from the product remote or a dedicated tickets remote.

How teams sync task tickets with Git

Local-first does not mean solo-only. You edit on disk, then Sync on the gitoza branch when you want the team to see it. Git is the bus. That is the part that scares people: Git merge conflicts.

The fear is larger than the rate.

Why Git conflicts on Markdown tickets are rarer than they feel

Two people changing the same task ticket is not automatically a conflict. Git merges by line. You conflict when both sides rewrite the same field (or the same stretch of body)—not because you both touched the file.

Gitoza is shaped so that happens less often:

No competing timestamps in the ticket file. Last-updated metadata is not a hardcoded clock stamped into the file on every keystroke. Audit fields are owned by the local index; Git history already has commit time. Two people editing different fields do not fight over “who saved last.”
Orthogonal edits merge. One person adds tags. Another changes status. A third updates the body. A fourth reassigns. Those are different lines. Git usually just takes both.
Comments append. New comments go on the end. That is an add, not a rewrite of the same paragraph—so two people commenting do not collide the way two people rewriting a description do.
When it does collide, there is a UI. Resolve Conflicts is keep mine, keep theirs, or mixed per file. You do not need the command line for the routine case.

Conflicts still happen if two people rewrite the same sentence of the body at once. That is the honest case—and it is the same class of edit that would clobber a field in a SaaS form, except here you see both versions.

The system is stable because the files are small, the schema is boring, and the merge rules match how people actually work: status here, tags there, comments at the bottom.

Gitoza: local-first task tickets, wiki, and optional tests

Gitoza is task and ticket management in Git: Tickets, Releases, Library (wiki), optional tests under .gitoza/test/. Connect the product repo or a dedicated planning repo. Confirm Changes before you push. Conflict panels when rebase needs a decision. Your AI IDE reads the same Markdown without MCP.

Bottom line

A board that is not on disk will always drift. Gitoza keeps task tickets as Markdown—and wiki as Markdown—so the AI IDE has something it can actually read. Same repo as the code, or a dedicated Git repo. That is enough to ask whether work is implemented, whether a ticket already exists, and whether the backlog is lying—without waiting on SaaS. Git sync is how the team shares; field-level merges, appended comments, and a keep-mine / keep-theirs UI are why that sync is less intimidating than the word “conflict” suggests.

Try it: github.com/gitoza-io/gitoza

Why Markdown Tickets Beat Jira MCP for AI IDEs Like Cursor

Weiwen Weng — Mon, 10 Aug 2026 15:14:29 +0000

Your AI IDE already reads the repo. If tickets are Markdown with front matter next to the code, the agent can search the backlog the same way it reads a module — no MCP, no JQL translator, no cloud hop for every ask.

MCP into Jira is the bolt-on path. At a few thousand tickets — or around 10,000 — the gap shows up in latency, hit rate, and junk in the context window.

Native path: tickets as Markdown

.gitoza/tasks/tickets/{project}/{ticket-id}.md

The ticket id is the filename (without .md). With stable keys (status, assignee, priority, type), an agent can answer:

Open bugs in auth assigned to me
What is still open on this release?
Which tickets mention the checkout API?

Retrieval is local — IDE index, grep, or a SQLite-backed app index. You only pay network time for the model, not for fetching every ticket over REST.

Minimal example (AUTH-102.md):

---
title: Lockout after failed logins
priority: medium
status: open
type: bug
---

# Lockout after failed logins

## Description

Brief context for the agent and the team.

Point the agent at .gitoza/tasks/tickets/ and ask. Same loop as code review.

Same ask over Jira MCP

Useful when Atlassian must stay the system of record. For day-to-day agent work it adds a chain on every answer: natural language → tool call → JQL → REST → JSON → maybe another call if the first page was wrong.

Fine for one known issue key. Heavy for wide or multi-step backlog questions.

Speed, precision, cost

	Markdown in the repo	Jira over MCP
AI access	Native (files the IDE already sees)	Tools + network
Latency	Disk / local index	Network + JQL + paging
Narrow asks	High when keys are consistent	Depends on JQL
Tokens	Ticket text you chose	Schemas + JSON bloat
Quotas	None for local reads	Cloud / MCP caps
Offline	Works	Needs the cloud

Precision caveat: “summarize all 10k tickets” still will not fit one context window. Filter first, then summarize — locally that is search/grep, not “hope the JQL was right.”

Cost direction: local plain text is cheaper per useful answer than tool-shaped round trips. Many checks never need an LLM — a terminal search is enough.

Skip the bridge

If the team already works in an AI IDE, put the backlog where the agent already looks: the repo. Files need no tool schema, no JQL translation, and no second system for “what is open this sprint.”

MCP is a workaround for a backlog trapped in a vendor API. Markdown tickets remove that trap — Git is the data plane.

Try it: github.com/gitoza-io/gitoza

Manage Tickets in Git as Markdown — No Login, No Jira MCP, Works Offline

Weiwen Weng — Sat, 08 Aug 2026 07:46:09 +0000

Driving tickets through MCP into Jira sounds neat until auth, scopes, rate limits, and field mappings eat the day. The IDE still cannot see the backlog unless that glue is perfect.

There is a simpler pattern — closer to Obsidian than to another SaaS hop: keep tickets as Markdown files in the repo, then link them locally. No login. No vendor API for every lookup.

Tickets as files

Put tickets under something like:

.gitoza/tasks/tickets/{project}/{ticket-id}.md

Releases under .gitoza/tasks/releases/. Links are just paths and IDs:

Ticket ↔ ticket (parent/child, [[TICKET-ID]])
Ticket ↔ release
Ticket ↔ test case in .gitoza/test/cases/

Open the file, follow the link, done. Structured enough for search and agents — not another cloud board.

YAML front matter holds status, priority, assignees, and tags. The Markdown body holds the description — same shape as wiki pages and test cases.

Why this wins

Offline by default. Source of truth is on disk. Searching a release or following a link does not wait on VPN or a flaky API. Sync to a remote when you want to share; editing does not require that round-trip.

AI already speaks files. Agents in Cursor / VS Code read Markdown with front matter well. Ask what is open this sprint, which tickets lack cases, what sits on a release — without standing up MCP to a tracker first. Prefer a local model? Same repo, same folders, no ticket payload leaving your machine for a hosted “AI” bolted onto a SaaS board.

One tree for planning and tests (optional):

Area	Path
Tickets	`.gitoza/tasks/tickets/`
Releases	`.gitoza/tasks/releases/`
Cases / runs	`.gitoza/test/`

Bottom line

Tickets as files, Obsidian-style links, local speed, AI without a brittle cloud bridge — and no login to start.

Try it: github.com/gitoza-io/gitoza

Markdown Test Cases in Git: What r/QualityAssurance Actually Said

Weiwen Weng — Sun, 02 Aug 2026 16:10:08 +0000

I asked r/QualityAssurance a blunt question: is managing manual test cases as Markdown files inside Git a good idea?

The thread got lively. People were not hostile to the idea. Many were already sympathetic to tests as code, a dedicated branch, AI helpers that can actually read the catalog. The pushback was more interesting than the praise. It lined up with problems I had hit building the same workflow for real teams.

Where the room agreed

When you frame cases as plain text in a repo you control, the reaction is usually positive:

No vendor database as the system of record
Diffs and history that look like application code
Collaboration through Git instead of another sync product
AI tools (Cursor, Copilot, and the rest) that already live in the IDE

That part is not controversial anymore. Engineers have watched automation live in Git for years. Manual cases still often sit in a SaaS form or a spreadsheet. Closing that gap feels overdue.

Where people who tried it got burned

Agreement on the idea is not the same as a durable practice.

Commenters who had lived with XML dumps, folder trees, or home-grown markdown catalogs were blunt: without tooling, the suite becomes hard to browse, easy to break, and painful to keep alive. Raw files scale poorly for day-to-day authoring. Someone always ends up maintaining a fragile convention that nobody else wants to touch.

Others were clear they would stay on web tools like Xray (and the Jira orbit around them). Not because Markdown is wrong — because managers get dashboards, links, and process they already trust. "Files in Git" sounds like an engineer hobby until it feels like a product.

And then the traceability question: how do you keep cases tied to user stories and bug tickets when you leave the vendor UI? Without a stable id story, file-based QA looks incomplete next to a TMS that speaks Jira natively.

Those are fair objections. Ignoring them is how "test cases in Git" dies after a pilot.

The missing piece was never Git — it was the UI

Plenty of teams have tried putting cases in the repo. Almost nobody ships a local UI that renders and manages those files the way a TMS renders rows in a database.

That gap is the whole story.

Reading Markdown in a text editor is not a test management workflow. Browsing suites, editing steps, recording Pass / Fail / Skip, and seeing automation coverage — that is. Once you have a client that treats the files as the source of truth, the day-to-day experience stops being "weird Git experiment" and starts looking like the web tools people already know. In practice, stability and feature coverage land in the same ballpark. Latency often wins: everything is on disk. There is no round trip to a hosted API every time you open a case.

Runs that do not rewrite history when cases change

File-based catalogs usually fail at execution history.

You create a run, add cases, execute. Two weeks later someone edits step 3 on a case that was already in that run. If the run only stores a live path, yesterday's sign-off silently becomes today's wording. Auditors hate that. So do release leads.

Git already has the answer if you use it deliberately. When Gitoza adds cases to a run, it records:

the case path in the repository
the commit SHA at the moment the case was picked (picked_at_sha)

Results attach to that membership. Later edits to the live case file do not rewrite what was executed. You can still open the catalog at HEAD for new work; historical runs resolve content against the SHA they were pinned to. Versioning is not a separate "export a PDF" step — it is how the run is stored.

That is the difference between "we keep Markdown in Git" and "runs are evidence."

Traceability without living inside Jira

Vendor TMS tools win on links: story → cases → bugs. File-based setups need the same discipline, just as fields.

In Gitoza case front matter, that usually means:

requirement_ids for the user story or ticket keys
tags for product area / smoke / risk
optional custom keys under params (for example jira_key) when your tracker needs a second handle
for automation, the case filename as the id, mirrored as a tag on Playwright or Robot specs — see linking manual and automated cases

You do not get magic bi-directional sync with Jira out of a text file. You get stable ids you can filter, export, and review in a PR — and you keep the catalog next to the code those stories shipped.

Managers and testers need different surfaces — same data

This is the split the Reddit thread kept circling.

QA managers lean on Xray, Jira, and similar products because reporting and process live there. That convenience is real.

Testers who write cases all day pay for it in browser forms, slow saves, and UIs that were never designed for long-form authoring. Asking a tester to draft dozens of careful cases in a web TMS is a bit like asking a programmer to write production code in a ticket comment box. Possible. Not the job you want.

Gitoza's bet is simple: keep the data plane in Git (Markdown cases and runs you own), and give testers an IDE-shaped client — browse, edit, run, sync — while managers still get review, dashboards, and history without renting the catalog to a vendor database.

If your org will never leave Jira Test Management, stay there. If your pain is authoring speed, ownership, AI access, and audit trails that look like commits, file-based cases with a real UI are no longer a science project.

Try it: github.com/gitoza-io/gitoza

Link Manual Test Cases to Playwright and Robot Specs

Weiwen Weng — Wed, 22 Jul 2026 15:44:09 +0000

Most teams already keep Playwright or Robot Framework specs next to the product. Manual cases often live somewhere else — a spreadsheet, a cloud TMS, or a wiki page nobody updates after the first release.

That is why automation coverage is usually a quarterly guess: the catalog and the specs never share an id.

Put both in the same Git repo, give every manual case a stable id, and linking becomes a text match. Any IDE agent can do that if the cases are files it can already see — no custom AI product inside a test tool.

One repo, two layers of the same suite

Manual cases are YAML files under .gitoza-lite/test/cases/ (VS Code / Cursor extension) or .gitoza/test/cases/ (Desktop app). The filename without .yaml is the case id.
Automated tests live wherever your team already puts them — tests/, e2e/, robot/ — in the same repository.
Traceability is a shared id: put that case id on the automation side as a tag (or name), and on the YAML side as automated: true plus a params pointer.

A PR can change the case, the Playwright spec, and the link in one review.

Step 1 — Draft manual cases in the IDE

Open the repo in Cursor or VS Code. Point the agent at a few existing case files so it learns your title style, tags, and step length. Then feed it a user story, a ticket, or a screenshot.

Ask for several cases at once, not one shallow step. A useful prompt looks like:

Read .gitoza-lite/test/cases/shopflow/auth/ for format. From ticket SHOP-184, draft three YAML cases (happy path, invalid password, locked account). Filename = case id. Use tags auth and smoke where it fits.

Save the files under the suite folder. Then open the Gitoza Lite Test Repository tab to browse, edit, and — when you are ready — run them as a manual suite with Pass / Fail / Skip.

The extension does not ship its own model. It keeps cases as plain YAML so whatever assistant you already use can read and write them.

A minimal case:

---
title: Login with valid credentials
priority: high
tags: [smoke, auth]
status: active
---

## Steps
1. Open the login page
2. Enter valid credentials

## Expected result
User is redirected to the dashboard.

If the file is AUTH-001.yaml, the case id is AUTH-001. That string is the join key for everything below.

Step 2 — Put the case id on the automation side

Before coverage can be marked, automation needs a handle that matches the YAML filename.

Playwright — tags must start with @ (or include the id in the test title):

import { test, expect } from "@playwright/test";

test("login with valid credentials", {
  tag: ["@AUTH-001", "@smoke"],
}, async ({ page }) => {
  // ...
});

Robot Framework — use [Tags]:

*** Test Cases ***
Login With Valid Credentials
    [Tags]    AUTH-001    smoke
    Open Login Page
    Submit Valid Credentials
    Dashboard Should Be Visible

Same idea for other runners: one stable token that equals the case id. Prefer the id over a free-text title match — titles drift; filenames should not. When matching Playwright tags to YAML, strip the leading @ so @AUTH-001 maps to AUTH-001.yaml.

Step 3 — Flip `automated` and fill `params`

Once specs carry the case id, close the loop on the YAML side — with Cursor or a small script:

Scan tests/ for Playwright tags matching case ids under .gitoza-lite/test/cases/. For each hit, set automated: true on the YAML case and add params.playwright with the relative spec path. If a case id appears in tags but not in YAML, list the gaps. Do not set automated: true unless the tag and filename match after stripping @.

You end up with something like:

---
title: Login with valid credentials
tags: [smoke, auth]
automated: true
params:
  playwright: tests/auth/login.spec.ts
---

## Steps
1. Open the login page
2. Enter valid credentials

## Expected result
User is redirected to the dashboard.

For Robot, the same field under params might be robot: tests/auth/login.robot. Teams often add a custom key as well — auto_tag: AUTH-001 or suite: 01_user_authentication — so filters and scripts stay boring. params is a free key-value map; agree on a small schema in the repo README and stick to it.

automated: true is the coverage flag. params is the pointer. Tags on the YAML side stay useful for smoke, priority, and feature filters — they do not have to duplicate the automation path.

Treat agent output like any other PR: review git diff before merge. A wrong tag match that flips automated: true is worse than a missing link — catch it in review, or run the same rules in CI so chat is optional.

Why Git beats a TMS link field

In a vendor database, linking is usually a URL paste or a fragile title search. Agents cannot see the catalog unless you build API glue.

In Git, the agent (or a script) reads cases and specs in one workspace, and git diff shows exactly which cases flipped to automated. Coverage is "scan tags ↔ case ids," not "update the spreadsheet after the sprint."

A concrete loop

Feature lands on a branch.
Agent drafts or updates manual YAML under .gitoza-lite/test/cases/…/{CASE-ID}.yaml.
Automation engineer (or the same agent) implements Playwright / Robot and tags the test with {CASE-ID}.
Agent or script sets automated: true and params on the matching case.
Manual testers execute what is still unautomated; Desktop dashboards can show automation rate when you use the full app.

Start with one suite. Do not try to backfill five years of TestRail in a weekend. Ship the next feature with case + spec + link in the same PR.

Try it (free VS Code extension): Gitoza on Marketplace
Full post: gitoza.com/blog/ai-link-manual-automated-test-cases

Stop Using Raw WebDriver in Robot Framework

Weiwen Weng — Thu, 09 Jul 2026 18:14:55 +0000

A lot of Robot Framework projects still look like plain Selenium scripts with .robot file extensions.

Someone imports webdriver, creates driver = webdriver.Chrome(), then calls find_element and send_keys in Python helpers. Robot Framework runs the suite, but readable keywords, shared libraries, and consistent waits never show up in the tests.

If you already use Robot Framework with SeleniumLibrary, you do not need the raw WebDriver API. SeleniumLibrary gives you high-level keywords. The Page Object Model gives you structure. Together they keep tests short and UI changes localized.

We published a small MIT template that shows the layout: rf-seleniumlibrary-pageobject-template. It targets Sauce Demo — clone it, run four tests, fork the folder structure.

What breaks when you mix in raw WebDriver

driver = webdriver.Chrome()
driver.find_element(By.ID, "user-name").send_keys("standard_user")
driver.find_element(By.ID, "password").send_keys("secret_sauce")
driver.find_element(By.ID, "login-button").click()

Fine for a script. Painful in a growing suite.

Locators spread across helpers and test files. Waits become time.sleep(2) in one place and missing in another. You end up maintaining SeleniumLibrary and a parallel WebDriver stack. CI fails on a Tuesday night and you are not sure which path opened the browser.

Before and after

Before	After
`driver.find_element(...).send_keys(...)`	`Login With Valid Credentials ${VALID_USER} ${VALID_PASSWORD}`
Locators in every file	`LoginLocators.USERNAME` in one module
Ad-hoc sleeps	`wait_until_element_is_visible` in `BasePage.click()`
Two browser stacks	One `SeleniumLibrary` instance per suite

Four layers

Layer	Job	Example
Locators	Selectors per screen	`login_locators.py`
BasePage	Shared waits and actions	`click()`, `enter_text()`
Page library	Screen keywords	`LoginPage.login()`
Robot test	Scenario only	`Inventory Should Be Visible`

Folder layout in the repo:

resources/locators/   → selectors
pages/                → Python page libraries
tests/                → thin .robot files

Locators stay in one place

class LoginLocators:
    USERNAME = "id:user-name"
    PASSWORD = "id:password"
    SUBMIT = "id:login-button"

Prefer stable attributes like data-test when the app exposes them.

BasePage owns the waits

def click(self, locator):
    self.seleniumlib.wait_until_element_is_visible(locator)
    self.seleniumlib.click_element(locator)

@property
def seleniumlib(self):
    return BuiltIn().get_library_instance("SeleniumLibrary")

Import SeleniumLibrary once in common.resource. Page objects look up that same instance — no driver argument passed between keywords. If you create driver = webdriver.Chrome() outside SeleniumLibrary, your page keywords will not see that browser.

A thin test

*** Test Cases ***
Valid Login
    Login With Valid Credentials    ${VALID_USER}    ${VALID_PASSWORD}
    Inventory Should Be Visible

No locators. No driver setup. Browser open/close in Test Setup / Test Teardown.

Quick start

git clone https://github.com/gitoza-io/rf-seleniumlibrary-pageobject-template.git
cd rf-seleniumlibrary-pageobject-template
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
robot --pythonpath . --outputdir results tests/

Use --pythonpath . from the repo root so pages.* imports resolve. Four passing tests = layout is wired.

Migrating without a rewrite

Move locators to resources/locators/
Add BasePage with click / enter_text
Wrap login as the first page library
Import SeleniumLibrary once in common.resource
Rewrite one .robot file, delete webdriver imports from its helpers

Repeat screen by screen. Leave the rest alone until you touch that feature.

Playwright and Cypress are valid for greenfield work. Plenty of teams still run RF and SeleniumLibrary in production — for them, dropping find_element for Page Objects is a low-risk upgrade that pays off on the next UI refactor.

Full guide: gitoza.com/blog/robot-framework-seleniumlibrary-page-object-model

Template repo: github.com/gitoza-io/rf-seleniumlibrary-pageobject-template

Excel Test Case Management: When Spreadsheets Stop Working

Weiwen Weng — Sun, 05 Jul 2026 13:45:31 +0000

Most teams start with an Excel sheet. One tab per feature, columns for steps and expected results, maybe a status column someone colors green by hand. It is cheap, familiar, and fine for ten cases.

Then the product grows. The sheet does not.

Where the sheet starts to hurt

Excel stores text, not test runs. It does not know what "Pass" means in your release process, who executed a case yesterday, or which build you tested. Run history ends up in another tab, another file, or someone's memory.

File names tell the rest of the story. test-cases-v3-FINAL.xlsx becomes v3-FINAL-John-edits.xlsx on a shared drive. Two people update the same row. Someone sorts a column and IDs no longer match the bug tracker. There is no diff, no reviewer, no clear answer to "who changed step 4 before we shipped."

Meanwhile your app, automated tests, and CI live in Git. Manual cases sit in a file that never rides along with your repo history. When a feature changes, the sheet is usually one sync meeting behind.

Spreadsheets are fine for a one-off checklist. They are a poor system of record once QA is ongoing.

Excel vs files in Git

The usual upgrade path is a cloud TMS. That solves collaboration, but your catalog moves into someone else's database — another login, per-seat pricing, awkward exports, and another place sensitive scenarios live.

A lighter step for many teams is test cases as files in a repository you already control. Each case is a small Markdown file: YAML front matter up top, steps and expected results in the body. Git gives you history and review without a separate process. A thin editor on top lets you browse suites, edit cases, and record runs — pass/fail and notes saved as structured files, not colored cells.

A case looks like this:

---
title: Login with valid credentials
tags: [smoke, auth]
priority: high
---

## Steps
1. Open the login page
2. Enter valid credentials

## Expected result
User is redirected to the dashboard.

That is roughly how Gitoza works. You connect a repo (GitHub, GitLab, or any remote you already use), keep cases on a dedicated branch, and work from the open-source desktop app. Cases, runs, tickets, and wiki stay as Markdown in Git — the system of record is your repository, not another SaaS database.

What actually changes

Runs stop living in side tabs. You assign cases, record results, and the history stays next to the cases themselves — on the same branch, versioned with every sync.

When a feature ships, you can see case changes in git commits — who changed what, and when — instead of chasing the latest spreadsheet on a shared drive. Tags, priorities, and links to automation specs are easier to keep consistent when each case is a file, not row 427 in a sheet that someone sorted last Tuesday.

You do not need to rip out Excel tomorrow. If the sheet is fighting you on every release, moving cases into Git is often less painful than another "please use the latest file" email.

More on the file format: Markdown Test Cases in Git.

Try it: github.com/gitoza-io/gitoza

Test Management Compliance: Cloud SaaS vs Local-First

Weiwen Weng — Fri, 03 Jul 2026 16:03:51 +0000

Security sends a forty-question vendor questionnaire. Legal asks whether your test cases contain customer PII or staging screenshots. Procurement forwards next year's per-seat renewal.

The decision is not which UI looks best in a demo. It is whether you can keep sensitive test knowledge off a vendor's cloud — without staffing a server farm.

Test cases are not harmless notes. They hold user stories, credentials in steps, production-like screenshots, and run history. For finance, healthcare, or EU-facing teams, that is operational data — not "just QA."

Cloud SaaS vs local-first at a glance

Question	Cloud SaaS	Local-first (e.g. Gitoza)
Where is the canonical copy?	Vendor cloud DB	Your repo / your storage
Does test data cross vendor boundary?	Yes, by design	No vendor DB; sync via your Git remote or BYO S3
Audit trail	Vendor activity log	Git commit history (author, timestamp, diff)
Typical small-team cost model	Per-seat subscription (hosted data)	Lower per-seat subscription; no hosted TMS DB
Manual tester UX	Web UI	Desktop UI
Exit strategy	Export / API	Files already yours

Planning aid, not legal advice — your security team signs off.

Where cloud TMS friction starts

TestRail, Testmo, Qase, and similar tools store cases in a vendor-operated database. Rollout is fast. Manual testers get web forms without a terminal.

The compliance pitch is usually SOC 2, ISO 27001, and a DPA. That certifies the vendor's operation — not whether your test catalog belongs in their multi-tenant cloud.

Question 12 on a typical security questionnaire: Where is customer data processed? Your cases may include staging screenshots with real-looking records. Meanwhile your cases sit in a US region while your customers are in Frankfurt.

On audit trails: activity logs help, but the system of record is still editable rows. Proving "we tested exactly this before release 4.2" often means trusting vendor retention — not a history your org already controls.

Then there is seat math. Twenty testers at roughly $30–45 per seat per month adds up before renewals. Desktop tools like Gitoza also charge per seat — but you are not paying to host your test catalog in a vendor database.

What about on-prem?

Self-hosted TestRail Server or Jira + Xray behind the firewall can be right at enterprise scale. For a twenty-person QA org without a platform team, six figures all-in is not rare. Many regulated teams end up on cloud SaaS and hope the DPA holds.

Local-first in one paragraph

Local-first keeps the canonical copy in files you control — typically a Git repo — while a desktop app gives manual testers the UI they expect from SaaS.

No vendor database as system of record. You pay a per-seat license for the app — not a recurring fee to store your test catalog in a vendor cloud.

With Gitoza, cases live on a dedicated gitoza branch in a shadow clone; testers do not touch main. Git history is the audit log — every change is a commit with author, timestamp, and diff.

Checklist before you shortlist

Inventory — What sensitive data is in cases and runs today?
Residency — Where must it live? Can US-hosted SaaS meet your contracts?
Canonical copy — If you stop paying, what do you still own without an export project?
History integrity — Can an admin alter past results without a durable trail?
Seat math — Three-year cost at current headcount and +50% growth?
Manual tester path — Can non-engineers run tests without CLI or VPN?
Vendor count — How many new subprocessors does this tool add to annual review?
Migration — Realistic effort to move in and out in one release cycle?

If 2, 3, and 7 are red, cloud SaaS needs a harder look.

Before you pick the dashboard

A vendor's SOC 2 report describes how they run their platform. Your auditor will still ask where your case library lived when release 4.2 shipped — and whether anyone could rewrite that history without leaving a trace.

Those are different questions. Certified cloud TMS vendors serve plenty of regulated customers well. Local-first does not replace legal review or a signed DPA. It just moves custody: the canonical copy sits in your repo, not a vendor row you export at renewal time.

If custody matters in your industry — and for many QA teams it does — answer that on paper before the UI demo wins the room.

Try Gitoza: Desktop download · VS Code extension

DEV Community: Weiwen Weng

Test Cases as Markdown in Git

Who this is for

The case and the run are different files

YAML front matter is the row. The body is the procedure.

Traceability is text in the repo

Review the diff on its own branch

What makes the repository painful

Let an agent write the file

Why Your AI IDE Wants Task Tickets as Markdown in the Repo

What I do instead

I run the tool on itself

Skip MCP for Jira: Tickets as Markdown in Git

Remote tickets break the loop the agent is good at

Tickets as Markdown in the repo

SQLite is a cache, not the database

Video: local agent, no MCP

Collaboration: one branch, linear rebase

Link Tickets to Tests and Wiki in One Git Repo

Four kinds of files, one tree

How the links actually work

Why the click feels instant

Traceability without a second product

The agent can walk the same graph

What I built for this

Task Tickets as Markdown in Git — Ask If It's Implemented

When task tickets drift from the codebase

Markdown task tickets and a Git wiki on disk

Ask an AI IDE if a ticket is already implemented

Check if a bug ticket already exists

How teams sync task tickets with Git

Why Git conflicts on Markdown tickets are rarer than they feel

Gitoza: local-first task tickets, wiki, and optional tests

Bottom line

Why Markdown Tickets Beat Jira MCP for AI IDEs Like Cursor

Native path: tickets as Markdown

Same ask over Jira MCP

Speed, precision, cost

Skip the bridge

Manage Tickets in Git as Markdown — No Login, No Jira MCP, Works Offline

Tickets as files

Why this wins

Bottom line

Markdown Test Cases in Git: What r/QualityAssurance Actually Said

Where the room agreed

Where people who tried it got burned

The missing piece was never Git — it was the UI

Runs that do not rewrite history when cases change

Traceability without living inside Jira

Managers and testers need different surfaces — same data

Link Manual Test Cases to Playwright and Robot Specs

One repo, two layers of the same suite

Step 1 — Draft manual cases in the IDE

Step 2 — Put the case id on the automation side

Step 3 — Flip automated and fill params

Why Git beats a TMS link field

A concrete loop

Stop Using Raw WebDriver in Robot Framework

What breaks when you mix in raw WebDriver

Before and after

Four layers

Locators stay in one place

BasePage owns the waits

A thin test

Quick start

Migrating without a rewrite

Excel Test Case Management: When Spreadsheets Stop Working

Where the sheet starts to hurt

Excel vs files in Git

What actually changes

Test Management Compliance: Cloud SaaS vs Local-First

Cloud SaaS vs local-first at a glance

Where cloud TMS friction starts

What about on-prem?

Local-first in one paragraph

Checklist before you shortlist

Before you pick the dashboard

Step 3 — Flip `automated` and fill `params`