primer-mcp 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- primer_mcp-0.1.0/.github/workflows/ci.yml +23 -0
- primer_mcp-0.1.0/.gitignore +221 -0
- primer_mcp-0.1.0/.python-version +1 -0
- primer_mcp-0.1.0/CLAUDE.md +104 -0
- primer_mcp-0.1.0/LICENSE +21 -0
- primer_mcp-0.1.0/PKG-INFO +200 -0
- primer_mcp-0.1.0/README.md +153 -0
- primer_mcp-0.1.0/docs/architecture.md +289 -0
- primer_mcp-0.1.0/docs/epic-001.md +134 -0
- primer_mcp-0.1.0/docs/planning.md +42 -0
- primer_mcp-0.1.0/pyproject.toml +73 -0
- primer_mcp-0.1.0/src/primer_mcp/__init__.py +5 -0
- primer_mcp-0.1.0/src/primer_mcp/__main__.py +47 -0
- primer_mcp-0.1.0/src/primer_mcp/errors.py +17 -0
- primer_mcp-0.1.0/src/primer_mcp/export.py +395 -0
- primer_mcp-0.1.0/src/primer_mcp/graph.py +216 -0
- primer_mcp-0.1.0/src/primer_mcp/models.py +139 -0
- primer_mcp-0.1.0/src/primer_mcp/project.py +139 -0
- primer_mcp-0.1.0/src/primer_mcp/server.py +509 -0
- primer_mcp-0.1.0/src/primer_mcp/static/__init__.py +0 -0
- primer_mcp-0.1.0/src/primer_mcp/static/vis-network.min.js +34 -0
- primer_mcp-0.1.0/src/primer_mcp/storage.py +52 -0
- primer_mcp-0.1.0/src/primer_mcp/store.py +518 -0
- primer_mcp-0.1.0/src/primer_mcp/templates.py +93 -0
- primer_mcp-0.1.0/src/primer_mcp/tickets.py +514 -0
- primer_mcp-0.1.0/tests/conftest.py +11 -0
- primer_mcp-0.1.0/tests/test_export.py +262 -0
- primer_mcp-0.1.0/tests/test_graph.py +325 -0
- primer_mcp-0.1.0/tests/test_models.py +127 -0
- primer_mcp-0.1.0/tests/test_project.py +132 -0
- primer_mcp-0.1.0/tests/test_server.py +291 -0
- primer_mcp-0.1.0/tests/test_storage.py +105 -0
- primer_mcp-0.1.0/tests/test_store.py +592 -0
- primer_mcp-0.1.0/tests/test_tickets.py +755 -0
- primer_mcp-0.1.0/uv.lock +1140 -0
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
name: CI
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
push:
|
|
5
|
+
branches: [main]
|
|
6
|
+
pull_request:
|
|
7
|
+
branches: [main]
|
|
8
|
+
|
|
9
|
+
jobs:
|
|
10
|
+
check:
|
|
11
|
+
runs-on: ubuntu-latest
|
|
12
|
+
strategy:
|
|
13
|
+
matrix:
|
|
14
|
+
python-version: ["3.12", "3.13", "3.14"]
|
|
15
|
+
steps:
|
|
16
|
+
- uses: actions/checkout@v4
|
|
17
|
+
- uses: astral-sh/setup-uv@v6
|
|
18
|
+
- run: uv python install ${{ matrix.python-version }}
|
|
19
|
+
- run: uv sync --python ${{ matrix.python-version }}
|
|
20
|
+
- run: uv run ruff check src/ tests/
|
|
21
|
+
- run: uv run ruff format --check src/ tests/
|
|
22
|
+
- run: uv run mypy
|
|
23
|
+
- run: uv run pytest
|
|
@@ -0,0 +1,221 @@
|
|
|
1
|
+
# Byte-compiled / optimized / DLL files
|
|
2
|
+
__pycache__/
|
|
3
|
+
*.py[codz]
|
|
4
|
+
*$py.class
|
|
5
|
+
|
|
6
|
+
# C extensions
|
|
7
|
+
*.so
|
|
8
|
+
|
|
9
|
+
# Distribution / packaging
|
|
10
|
+
.Python
|
|
11
|
+
build/
|
|
12
|
+
develop-eggs/
|
|
13
|
+
dist/
|
|
14
|
+
downloads/
|
|
15
|
+
eggs/
|
|
16
|
+
.eggs/
|
|
17
|
+
lib/
|
|
18
|
+
lib64/
|
|
19
|
+
parts/
|
|
20
|
+
sdist/
|
|
21
|
+
var/
|
|
22
|
+
wheels/
|
|
23
|
+
share/python-wheels/
|
|
24
|
+
*.egg-info/
|
|
25
|
+
.installed.cfg
|
|
26
|
+
*.egg
|
|
27
|
+
MANIFEST
|
|
28
|
+
|
|
29
|
+
# PyInstaller
|
|
30
|
+
# Usually these files are written by a python script from a template
|
|
31
|
+
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
|
32
|
+
*.manifest
|
|
33
|
+
*.spec
|
|
34
|
+
|
|
35
|
+
# Installer logs
|
|
36
|
+
pip-log.txt
|
|
37
|
+
pip-delete-this-directory.txt
|
|
38
|
+
|
|
39
|
+
# Unit test / coverage reports
|
|
40
|
+
htmlcov/
|
|
41
|
+
.tox/
|
|
42
|
+
.nox/
|
|
43
|
+
.coverage
|
|
44
|
+
.coverage.*
|
|
45
|
+
.cache
|
|
46
|
+
nosetests.xml
|
|
47
|
+
coverage.xml
|
|
48
|
+
*.cover
|
|
49
|
+
*.py.cover
|
|
50
|
+
.hypothesis/
|
|
51
|
+
.pytest_cache/
|
|
52
|
+
cover/
|
|
53
|
+
|
|
54
|
+
# Translations
|
|
55
|
+
*.mo
|
|
56
|
+
*.pot
|
|
57
|
+
|
|
58
|
+
# Django stuff:
|
|
59
|
+
*.log
|
|
60
|
+
local_settings.py
|
|
61
|
+
db.sqlite3
|
|
62
|
+
db.sqlite3-journal
|
|
63
|
+
|
|
64
|
+
# Flask stuff:
|
|
65
|
+
instance/
|
|
66
|
+
.webassets-cache
|
|
67
|
+
|
|
68
|
+
# Scrapy stuff:
|
|
69
|
+
.scrapy
|
|
70
|
+
|
|
71
|
+
# Sphinx documentation
|
|
72
|
+
docs/_build/
|
|
73
|
+
|
|
74
|
+
# PyBuilder
|
|
75
|
+
.pybuilder/
|
|
76
|
+
target/
|
|
77
|
+
|
|
78
|
+
# Jupyter Notebook
|
|
79
|
+
.ipynb_checkpoints
|
|
80
|
+
|
|
81
|
+
# IPython
|
|
82
|
+
profile_default/
|
|
83
|
+
ipython_config.py
|
|
84
|
+
|
|
85
|
+
# pyenv
|
|
86
|
+
# For a library or package, you might want to ignore these files since the code is
|
|
87
|
+
# intended to run in multiple environments; otherwise, check them in:
|
|
88
|
+
# .python-version
|
|
89
|
+
|
|
90
|
+
# pipenv
|
|
91
|
+
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
|
92
|
+
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
|
93
|
+
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
|
94
|
+
# install all needed dependencies.
|
|
95
|
+
# Pipfile.lock
|
|
96
|
+
|
|
97
|
+
# UV
|
|
98
|
+
# Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
|
|
99
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
100
|
+
# commonly ignored for libraries.
|
|
101
|
+
# uv.lock
|
|
102
|
+
|
|
103
|
+
# poetry
|
|
104
|
+
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
|
|
105
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
106
|
+
# commonly ignored for libraries.
|
|
107
|
+
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
|
|
108
|
+
# poetry.lock
|
|
109
|
+
# poetry.toml
|
|
110
|
+
|
|
111
|
+
# pdm
|
|
112
|
+
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
|
|
113
|
+
# pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
|
|
114
|
+
# https://pdm-project.org/en/latest/usage/project/#working-with-version-control
|
|
115
|
+
# pdm.lock
|
|
116
|
+
# pdm.toml
|
|
117
|
+
.pdm-python
|
|
118
|
+
.pdm-build/
|
|
119
|
+
|
|
120
|
+
# pixi
|
|
121
|
+
# Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
|
|
122
|
+
# pixi.lock
|
|
123
|
+
# Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
|
|
124
|
+
# in the .venv directory. It is recommended not to include this directory in version control.
|
|
125
|
+
.pixi
|
|
126
|
+
|
|
127
|
+
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
|
|
128
|
+
__pypackages__/
|
|
129
|
+
|
|
130
|
+
# Celery stuff
|
|
131
|
+
celerybeat-schedule
|
|
132
|
+
celerybeat.pid
|
|
133
|
+
|
|
134
|
+
# Redis
|
|
135
|
+
*.rdb
|
|
136
|
+
*.aof
|
|
137
|
+
*.pid
|
|
138
|
+
|
|
139
|
+
# RabbitMQ
|
|
140
|
+
mnesia/
|
|
141
|
+
rabbitmq/
|
|
142
|
+
rabbitmq-data/
|
|
143
|
+
|
|
144
|
+
# ActiveMQ
|
|
145
|
+
activemq-data/
|
|
146
|
+
|
|
147
|
+
# SageMath parsed files
|
|
148
|
+
*.sage.py
|
|
149
|
+
|
|
150
|
+
# Environments
|
|
151
|
+
.env
|
|
152
|
+
.envrc
|
|
153
|
+
.venv
|
|
154
|
+
env/
|
|
155
|
+
venv/
|
|
156
|
+
ENV/
|
|
157
|
+
env.bak/
|
|
158
|
+
venv.bak/
|
|
159
|
+
|
|
160
|
+
# Spyder project settings
|
|
161
|
+
.spyderproject
|
|
162
|
+
.spyproject
|
|
163
|
+
|
|
164
|
+
# Rope project settings
|
|
165
|
+
.ropeproject
|
|
166
|
+
|
|
167
|
+
# mkdocs documentation
|
|
168
|
+
/site
|
|
169
|
+
|
|
170
|
+
# mypy
|
|
171
|
+
.mypy_cache/
|
|
172
|
+
.dmypy.json
|
|
173
|
+
dmypy.json
|
|
174
|
+
|
|
175
|
+
# Pyre type checker
|
|
176
|
+
.pyre/
|
|
177
|
+
|
|
178
|
+
# pytype static type analyzer
|
|
179
|
+
.pytype/
|
|
180
|
+
|
|
181
|
+
# Cython debug symbols
|
|
182
|
+
cython_debug/
|
|
183
|
+
|
|
184
|
+
# PyCharm
|
|
185
|
+
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
|
|
186
|
+
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
|
187
|
+
# and can be added to the global gitignore or merged into this file. For a more nuclear
|
|
188
|
+
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
|
|
189
|
+
# .idea/
|
|
190
|
+
|
|
191
|
+
# Abstra
|
|
192
|
+
# Abstra is an AI-powered process automation framework.
|
|
193
|
+
# Ignore directories containing user credentials, local state, and settings.
|
|
194
|
+
# Learn more at https://abstra.io/docs
|
|
195
|
+
.abstra/
|
|
196
|
+
|
|
197
|
+
# Visual Studio Code
|
|
198
|
+
# Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
|
|
199
|
+
# that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
|
|
200
|
+
# and can be added to the global gitignore or merged into this file. However, if you prefer,
|
|
201
|
+
# you could uncomment the following to ignore the entire vscode folder
|
|
202
|
+
# .vscode/
|
|
203
|
+
# Temporary file for partial code execution
|
|
204
|
+
tempCodeRunnerFile.py
|
|
205
|
+
|
|
206
|
+
# primer-mcp generated output
|
|
207
|
+
primer/graph.html
|
|
208
|
+
|
|
209
|
+
# Ruff stuff:
|
|
210
|
+
.ruff_cache/
|
|
211
|
+
|
|
212
|
+
# PyPI configuration file
|
|
213
|
+
.pypirc
|
|
214
|
+
|
|
215
|
+
# Marimo
|
|
216
|
+
marimo/_static/
|
|
217
|
+
marimo/_lsp/
|
|
218
|
+
__marimo__/
|
|
219
|
+
|
|
220
|
+
# Streamlit
|
|
221
|
+
.streamlit/secrets.toml
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
3.13
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# primer-mcp
|
|
2
|
+
|
|
3
|
+
A Jira-lite MCP server that enforces planning-first workflows for AI-assisted development. Tickets are markdown files on the user's local disk. The AI agent is the interface.
|
|
4
|
+
|
|
5
|
+
## Project docs (read these first)
|
|
6
|
+
|
|
7
|
+
- `docs/planning.md` — goals, constraints, non-goals, success criteria
|
|
8
|
+
- `docs/architecture.md` — all key decisions, ticket schema, graph protocol, body templates
|
|
9
|
+
- `docs/epic-001.md` — prose descriptions of the stories; `primer/` is the live backlog
|
|
10
|
+
|
|
11
|
+
## Key conventions
|
|
12
|
+
|
|
13
|
+
- **Language:** Python, packaged with `uv`, distributed via `uvx`
|
|
14
|
+
- **Data store:** Markdown + YAML frontmatter in `primer/` (visible, not dot-hidden, and committed — this repo dogfoods its own store)
|
|
15
|
+
- **No provider-specific code** — server must be MCP-protocol-only, no Anthropic/OpenAI SDK calls
|
|
16
|
+
- **Ticket body templates** are defined in `docs/architecture.md` — follow them exactly when generating ticket files
|
|
17
|
+
- **Graph edges**: `blocked_by` is a base field on ALL ticket types, not just tasks. It is the only stored edge — "A blocks B" is recorded on B (ADR-004)
|
|
18
|
+
- **Two-phase completion:** `complete_task` then `verify_task` — do not collapse into one step
|
|
19
|
+
|
|
20
|
+
## Workflow gates (enforced by the server — never bypass)
|
|
21
|
+
|
|
22
|
+
1. Cannot create an ADR without a valid parent Epic
|
|
23
|
+
2. Cannot create a Task without a valid parent Story
|
|
24
|
+
|
|
25
|
+
Two-phase completion (`complete_task` then `verify_task`) is recommended and the tools will nudge you if you skip a step, but it is not enforced — `verify_task` proceeds from any pre-terminal state.
|
|
26
|
+
|
|
27
|
+
## Development workflow
|
|
28
|
+
|
|
29
|
+
- Dogfood wherever possible — plan and track this project's own work with primer-mcp's own tools, and fix what that exposes. If we don't trust our own process, why should anyone else?
|
|
30
|
+
- Always enter plan mode before implementing a new story
|
|
31
|
+
- Every story from ST-002 onward lands with its unit tests in the same PR — acceptance criteria are proven by tests, not deferred to ST-010
|
|
32
|
+
- No filler tests. Every test must verify a real behaviour or acceptance criterion and be able to fail for a real reason — never add tests for coverage's or quantity's sake
|
|
33
|
+
- Tasks must be completable in a single session (~3 files max)
|
|
34
|
+
- One PR per task
|
|
35
|
+
- When a commit is for a ticket, prefix the message with the ticket ID (`TK-030: Rename get_next_action...`). This closes the loop: `git log --grep TK-030` finds the commit, and `verified_evidence` on the ticket points back at the hash. Standalone chores (CLAUDE.md tweaks, typo fixes) need no prefix.
|
|
36
|
+
- Ask before committing and before pushing — the user reviews the working diff, not the PR page
|
|
37
|
+
- Improvements and simplifications wait until after v0 ships. This is a compact project that showcases the workflow, not an enterprise system; a heavier primer-mcp has no reason to exist when Jira already does
|
|
38
|
+
- Completion is two-phase: `complete_task` with notes, then `verify_task` with evidence. Both are recommended
|
|
39
|
+
- **Tickets hold what git cannot; they never restate it.** Intent before the work — `testable_outcome`, acceptance criteria, an ADR's rejected alternatives — has no other home. What happened, and how, is git's job. So keep ticket bodies at overview level: the goal, not the implementation. Evidence stays one line and points at the commit (`"218 passed, mypy clean — c4ac39f"`). Completion notes have two layers: the frontmatter `completed_notes` field is a terse one-liner for scanning; the `## Completion Notes` body section holds a fuller summary — approach taken, key changes, decisions made — the narrative that would otherwise vanish with the chat session. Duplicating git is what makes Jira miserable, and detail written before the work is what makes tickets lie: TK-007 listed the functions it would add, the real implementation added others, and `verified` is terminal so it says so permanently
|
|
40
|
+
- Detail is safe where the content describes a moment rather than a state, which is why ADRs are the exception: a rejected alternative stays true forever, and a reversal is a new ADR superseding the old one, not an edit
|
|
41
|
+
|
|
42
|
+
## Plagiarism policy
|
|
43
|
+
|
|
44
|
+
Do NOT read or reference `groundwork-mcp` or any similar existing repo. All design decisions must come from first principles. The architecture is fully documented in `docs/architecture.md`.
|
|
45
|
+
|
|
46
|
+
## Stack
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
mcp # MCP server SDK
|
|
50
|
+
pydantic # schema validation
|
|
51
|
+
python-frontmatter # markdown + YAML frontmatter parsing
|
|
52
|
+
pyyaml # direct YAML dumping (custom no-alias dumper, stable key order)
|
|
53
|
+
networkx # graph traversal and cycle detection
|
|
54
|
+
uv # packaging and distribution (dev pinned to Python 3.13, requires-python >=3.12)
|
|
55
|
+
pytest # unit tests (use tmp_path fixture, no filesystem mocking)
|
|
56
|
+
ruff # lint + format (dev)
|
|
57
|
+
mypy # type checking (dev)
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## Where things stand
|
|
61
|
+
|
|
62
|
+
**Start by running `uv run primer-mcp list-actionable`**, then:
|
|
63
|
+
|
|
64
|
+
1. Copy the command's entire output into your response as-is. The output
|
|
65
|
+
is already formatted for the user — do not rewrite, summarise, or
|
|
66
|
+
build your own table from it.
|
|
67
|
+
2. Below that output, add your recommendation for what to work on next
|
|
68
|
+
and why.
|
|
69
|
+
|
|
70
|
+
The live backlog is `primer/`; `docs/epic-001.md` keeps the prose descriptions.
|
|
71
|
+
Story IDs match across both — ST-007 means the query and graph tools story
|
|
72
|
+
everywhere.
|
|
73
|
+
|
|
74
|
+
Decisions live in `primer/adrs/` (ADR-001 to ADR-007) with the alternatives
|
|
75
|
+
that were rejected. Read those before reopening a settled question — several
|
|
76
|
+
were argued through at length and the reasoning is not in the code.
|
|
77
|
+
|
|
78
|
+
## primer-mcp
|
|
79
|
+
|
|
80
|
+
This project uses primer-mcp for planning-first development. Tickets are
|
|
81
|
+
markdown files under `primer/` — they are yours to read and edit. Prefer the
|
|
82
|
+
tools for creating and updating them: they allocate IDs, follow the templates
|
|
83
|
+
and guide the workflow. Hand-edit where the tools fall short.
|
|
84
|
+
|
|
85
|
+
- Plan before code. The recommended flow is Epic → ADR → Story → Task,
|
|
86
|
+
but the tools suggest rather than enforce — skip steps when it makes
|
|
87
|
+
sense for the work at hand.
|
|
88
|
+
- Unsure what to do next? Run `uv run primer-mcp list-actionable`.
|
|
89
|
+
- Completion is two-phase: `complete_task` with notes, then `verify_task`
|
|
90
|
+
with evidence (point at the commit, not the output). Both are
|
|
91
|
+
recommended — the tools will nudge you if you skip a step.
|
|
92
|
+
- After creating tickets, completing tasks, or verifying tasks, offer to
|
|
93
|
+
regenerate the project graph with `export_graph` so the user can see
|
|
94
|
+
the updated picture.
|
|
95
|
+
- Before committing, check whether any tickets completed or verified in
|
|
96
|
+
this session have completion notes that still reflect the actual work.
|
|
97
|
+
If the implementation evolved after the notes were written, update
|
|
98
|
+
both layers before staging: the frontmatter `completed_notes` (terse
|
|
99
|
+
one-liner) and the `## Completion Notes` body section (fuller summary
|
|
100
|
+
— approach taken, key changes, decisions made).
|
|
101
|
+
- When the user reports a bug or small fix, check for a standing bug-fix
|
|
102
|
+
story under the epic before creating a new story. Small fixes (1–2
|
|
103
|
+
tasks) go as tasks under that story; larger efforts (3+ tasks) get
|
|
104
|
+
their own story. If no bug-fix story exists yet, suggest creating one.
|
primer_mcp-0.1.0/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Ivan Lai
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,200 @@
|
|
|
1
|
+
Metadata-Version: 2.5
|
|
2
|
+
Name: primer-mcp
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: A Jira-lite MCP server that guides planning-first workflows for AI-assisted development — tickets as markdown files, your AI agent as the interface.
|
|
5
|
+
Project-URL: Homepage, https://github.com/ivanlai/primer-mcp
|
|
6
|
+
Project-URL: Repository, https://github.com/ivanlai/primer-mcp
|
|
7
|
+
Project-URL: Issues, https://github.com/ivanlai/primer-mcp/issues
|
|
8
|
+
Author: Ivan Lai
|
|
9
|
+
License: MIT License
|
|
10
|
+
|
|
11
|
+
Copyright (c) 2026 Ivan Lai
|
|
12
|
+
|
|
13
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
14
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
15
|
+
in the Software without restriction, including without limitation the rights
|
|
16
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
17
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
18
|
+
furnished to do so, subject to the following conditions:
|
|
19
|
+
|
|
20
|
+
The above copyright notice and this permission notice shall be included in all
|
|
21
|
+
copies or substantial portions of the Software.
|
|
22
|
+
|
|
23
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
24
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
25
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
26
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
27
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
28
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
29
|
+
SOFTWARE.
|
|
30
|
+
License-File: LICENSE
|
|
31
|
+
Keywords: ai-agents,markdown,mcp,planning,tickets
|
|
32
|
+
Classifier: Development Status :: 3 - Alpha
|
|
33
|
+
Classifier: Intended Audience :: Developers
|
|
34
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
35
|
+
Classifier: Programming Language :: Python :: 3
|
|
36
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
37
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
38
|
+
Classifier: Programming Language :: Python :: 3.14
|
|
39
|
+
Classifier: Topic :: Software Development
|
|
40
|
+
Requires-Python: >=3.12
|
|
41
|
+
Requires-Dist: mcp
|
|
42
|
+
Requires-Dist: networkx
|
|
43
|
+
Requires-Dist: pydantic
|
|
44
|
+
Requires-Dist: python-frontmatter
|
|
45
|
+
Requires-Dist: pyyaml
|
|
46
|
+
Description-Content-Type: text/markdown
|
|
47
|
+
|
|
48
|
+
# primer-mcp
|
|
49
|
+
|
|
50
|
+
> **Beta** — the core workflow is stable and tested, but the tool is new. Expect rough edges.
|
|
51
|
+
|
|
52
|
+
A Jira-lite MCP server that guides planning-first workflows for AI-assisted development — tickets as markdown files, your AI agent as the interface.
|
|
53
|
+
|
|
54
|
+
## Why
|
|
55
|
+
|
|
56
|
+
AI coding agents jump straight to implementation. primer-mcp makes them plan first: state why the work matters, record decisions, break it into stories and tasks, then complete and verify each one. The tickets are plain markdown with YAML frontmatter, committed alongside your code — no external service, no database, fully visible in your repo.
|
|
57
|
+
|
|
58
|
+
## Install
|
|
59
|
+
|
|
60
|
+
Requires Python 3.12+ and [uv](https://docs.astral.sh/uv/getting-started/installation/).
|
|
61
|
+
|
|
62
|
+
```bash
|
|
63
|
+
# Run directly (recommended for MCP)
|
|
64
|
+
uvx primer-mcp
|
|
65
|
+
|
|
66
|
+
# Or install permanently
|
|
67
|
+
uv tool install primer-mcp
|
|
68
|
+
|
|
69
|
+
# Update to latest
|
|
70
|
+
uv tool upgrade primer-mcp
|
|
71
|
+
|
|
72
|
+
# Uninstall
|
|
73
|
+
uv tool uninstall primer-mcp
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
## Quick start
|
|
77
|
+
|
|
78
|
+
Add to your MCP client config (e.g. Claude Code `settings.json`, Claude Desktop `claude_desktop_config.json`):
|
|
79
|
+
|
|
80
|
+
```json
|
|
81
|
+
{
|
|
82
|
+
"mcpServers": {
|
|
83
|
+
"primer-mcp": {
|
|
84
|
+
"command": "uvx",
|
|
85
|
+
"args": ["primer-mcp"]
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
}
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
Then ask your AI agent to plan some work. The recommended flow is:
|
|
92
|
+
|
|
93
|
+
```
|
|
94
|
+
init_project → plan_epic → record_adr → create_story → create_task
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
The tools suggest this order but don't block you from skipping steps — if the work is straightforward, go straight from epic to stories. You'll get a helpful nudge if the tools think you might want to record a decision first.
|
|
98
|
+
|
|
99
|
+
Once tasks exist, the execution cycle is:
|
|
100
|
+
|
|
101
|
+
```
|
|
102
|
+
start_task → complete_task (with notes) → verify_task (with evidence)
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
Not sure what to do next? `get_next_action` reads the current state and returns exactly one instruction.
|
|
106
|
+
|
|
107
|
+
## Tools
|
|
108
|
+
|
|
109
|
+
### Setup
|
|
110
|
+
|
|
111
|
+
| Tool | What it does |
|
|
112
|
+
|------|-------------|
|
|
113
|
+
| `init_project` | Create the `primer/` ticket store and add the workflow section to CLAUDE.md |
|
|
114
|
+
|
|
115
|
+
### Planning
|
|
116
|
+
|
|
117
|
+
| Tool | What it does |
|
|
118
|
+
|------|-------------|
|
|
119
|
+
| `plan_epic` | Create an epic — the top-level container for a body of work |
|
|
120
|
+
| `record_adr` | Record an architecture decision: context, decision, rejected alternatives, consequences |
|
|
121
|
+
| `create_story` | Create a story under an epic — a deliverable with acceptance criteria |
|
|
122
|
+
| `create_task` | Create a task under a story — a concrete unit of work with a testable outcome |
|
|
123
|
+
| `create_spike` | Create a spike — a timeboxed investigation to answer a question |
|
|
124
|
+
|
|
125
|
+
### Execution
|
|
126
|
+
|
|
127
|
+
| Tool | What it does |
|
|
128
|
+
|------|-------------|
|
|
129
|
+
| `start_task` | Move a task to in-progress |
|
|
130
|
+
| `complete_task` | Mark a task completed with notes on what was done |
|
|
131
|
+
| `verify_task` | Verify a completed task with evidence (point at the commit) |
|
|
132
|
+
| `complete_spike` | Close a spike with findings |
|
|
133
|
+
|
|
134
|
+
### Query
|
|
135
|
+
|
|
136
|
+
| Tool | What it does |
|
|
137
|
+
|------|-------------|
|
|
138
|
+
| `get_next_action` | Ask what to do next — returns exactly one instruction |
|
|
139
|
+
| `get_ticket` | Read a ticket by ID with its full body |
|
|
140
|
+
| `list_tickets` | List tickets, filterable by type or status |
|
|
141
|
+
| `update_ticket` | Amend a ticket's status, dependencies, body sections, or external refs |
|
|
142
|
+
|
|
143
|
+
### Export
|
|
144
|
+
|
|
145
|
+
| Tool | What it does |
|
|
146
|
+
|------|-------------|
|
|
147
|
+
| `export_graph` | Generate a self-contained HTML file visualising the project as an interactive graph |
|
|
148
|
+
|
|
149
|
+
## Prompts
|
|
150
|
+
|
|
151
|
+
| Prompt | What it does |
|
|
152
|
+
|--------|-------------|
|
|
153
|
+
| `plan_story` | Walk through a planning conversation before creating a story |
|
|
154
|
+
| `export_jira` | Export primer-mcp tickets to Jira via a Jira MCP server |
|
|
155
|
+
| `import_jira` | Import a Jira epic and its hierarchy into primer-mcp |
|
|
156
|
+
|
|
157
|
+
## CLAUDE.md snippet
|
|
158
|
+
|
|
159
|
+
`init_project` appends this to your project's CLAUDE.md automatically. If you prefer to add it manually:
|
|
160
|
+
|
|
161
|
+
```markdown
|
|
162
|
+
## primer-mcp
|
|
163
|
+
|
|
164
|
+
This project uses primer-mcp for planning-first development. Tickets are
|
|
165
|
+
markdown files under `primer/` — they are yours to read and edit. Prefer the
|
|
166
|
+
tools for creating and updating them: they allocate IDs, follow the templates
|
|
167
|
+
and guide the workflow. Hand-edit where the tools fall short.
|
|
168
|
+
|
|
169
|
+
- Plan before code. The recommended flow is Epic -> ADR -> Story -> Task,
|
|
170
|
+
but the tools suggest rather than enforce — skip steps when it makes
|
|
171
|
+
sense for the work at hand.
|
|
172
|
+
- Unsure what to do next? Call `get_next_action`.
|
|
173
|
+
- Completion is two-phase: `complete_task` with notes, then `verify_task`
|
|
174
|
+
with evidence (point at the commit, not the output). Both are
|
|
175
|
+
recommended — the tools will nudge you if you skip a step.
|
|
176
|
+
- After creating tickets, completing tasks, or verifying tasks, offer to
|
|
177
|
+
regenerate the project graph with `export_graph` so the user can see
|
|
178
|
+
the updated picture.
|
|
179
|
+
- When the user reports a bug or small fix, check for a standing bug-fix
|
|
180
|
+
story under the epic before creating a new story. Small fixes (1-2
|
|
181
|
+
tasks) go as tasks under that story; larger efforts (3+ tasks) get
|
|
182
|
+
their own story. If no bug-fix story exists yet, suggest creating one.
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
## Graduating to Jira
|
|
186
|
+
|
|
187
|
+
primer-mcp tickets map directly to Jira concepts (Epic, Story, Task, ADR). When a project outgrows local markdown files, use the `export_jira` prompt with any Jira MCP server to push tickets to Jira. The `external_ref` field on each ticket tracks the Jira key, so re-exports update existing issues instead of creating duplicates. `import_jira` goes the other direction.
|
|
188
|
+
|
|
189
|
+
## This repo dogfoods itself
|
|
190
|
+
|
|
191
|
+
The `primer/` directory is this project's own backlog, created with the tools in `src/` and committed deliberately — a tool that tells you to commit your ticket store should commit its own. It doubles as a worked example: browse it to see what a real store looks like before installing anything.
|
|
192
|
+
|
|
193
|
+
- `primer/adrs/` — why the design is what it is, including the alternatives that were rejected and why
|
|
194
|
+
- `primer/stories/` and `primer/tasks/` — what is done, what is next, and the evidence each completed task was verified against
|
|
195
|
+
|
|
196
|
+
**It is project management, not part of the package.** The wheel ships `src/primer_mcp` only, and `primer/` is excluded from the source distribution. When you install primer-mcp, `init_project` creates *your* `primer/` — this one never reaches your machine.
|
|
197
|
+
|
|
198
|
+
## License
|
|
199
|
+
|
|
200
|
+
MIT
|