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.
Files changed (35) hide show
  1. primer_mcp-0.1.0/.github/workflows/ci.yml +23 -0
  2. primer_mcp-0.1.0/.gitignore +221 -0
  3. primer_mcp-0.1.0/.python-version +1 -0
  4. primer_mcp-0.1.0/CLAUDE.md +104 -0
  5. primer_mcp-0.1.0/LICENSE +21 -0
  6. primer_mcp-0.1.0/PKG-INFO +200 -0
  7. primer_mcp-0.1.0/README.md +153 -0
  8. primer_mcp-0.1.0/docs/architecture.md +289 -0
  9. primer_mcp-0.1.0/docs/epic-001.md +134 -0
  10. primer_mcp-0.1.0/docs/planning.md +42 -0
  11. primer_mcp-0.1.0/pyproject.toml +73 -0
  12. primer_mcp-0.1.0/src/primer_mcp/__init__.py +5 -0
  13. primer_mcp-0.1.0/src/primer_mcp/__main__.py +47 -0
  14. primer_mcp-0.1.0/src/primer_mcp/errors.py +17 -0
  15. primer_mcp-0.1.0/src/primer_mcp/export.py +395 -0
  16. primer_mcp-0.1.0/src/primer_mcp/graph.py +216 -0
  17. primer_mcp-0.1.0/src/primer_mcp/models.py +139 -0
  18. primer_mcp-0.1.0/src/primer_mcp/project.py +139 -0
  19. primer_mcp-0.1.0/src/primer_mcp/server.py +509 -0
  20. primer_mcp-0.1.0/src/primer_mcp/static/__init__.py +0 -0
  21. primer_mcp-0.1.0/src/primer_mcp/static/vis-network.min.js +34 -0
  22. primer_mcp-0.1.0/src/primer_mcp/storage.py +52 -0
  23. primer_mcp-0.1.0/src/primer_mcp/store.py +518 -0
  24. primer_mcp-0.1.0/src/primer_mcp/templates.py +93 -0
  25. primer_mcp-0.1.0/src/primer_mcp/tickets.py +514 -0
  26. primer_mcp-0.1.0/tests/conftest.py +11 -0
  27. primer_mcp-0.1.0/tests/test_export.py +262 -0
  28. primer_mcp-0.1.0/tests/test_graph.py +325 -0
  29. primer_mcp-0.1.0/tests/test_models.py +127 -0
  30. primer_mcp-0.1.0/tests/test_project.py +132 -0
  31. primer_mcp-0.1.0/tests/test_server.py +291 -0
  32. primer_mcp-0.1.0/tests/test_storage.py +105 -0
  33. primer_mcp-0.1.0/tests/test_store.py +592 -0
  34. primer_mcp-0.1.0/tests/test_tickets.py +755 -0
  35. 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.
@@ -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