@xcraftmind/mastermind 0.25.0 → 0.26.0
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.
- package/README.md +3 -3
- package/package.json +8 -8
- package/share/commands/api-shape-explorer.md +107 -0
package/README.md
CHANGED
|
@@ -30,7 +30,7 @@ mastermind init # scaffold .mastermind/, build the index, d
|
|
|
30
30
|
echo ".mastermind/" >> .gitignore # index + local specs are local state
|
|
31
31
|
```
|
|
32
32
|
|
|
33
|
-
`init` builds the index and drafts `CONTEXT.md` from your code via `claude -p` (pass `--no-claude` or `--no-index` to skip). It also installs the workflow subagents
|
|
33
|
+
`init` builds the index and drafts `CONTEXT.md` from your code via `claude -p` (pass `--no-claude` or `--no-index` to skip). It also installs the workflow subagents, skills, and slash commands into `~/.claude/` so the full pipeline (planner / critic / executor / auditor) is available, not just the codegraph (`--no-global` to skip). Re-run `mastermind index .` to refresh, or `mastermind watch` to keep it live.
|
|
34
34
|
|
|
35
35
|
**3. Register with Claude Code** — once, globally:
|
|
36
36
|
|
|
@@ -53,11 +53,11 @@ Three pieces — the split is the part that trips people up:
|
|
|
53
53
|
| | Scope | Lives in | How often |
|
|
54
54
|
|---|---|---|---|
|
|
55
55
|
| **Index** — `init` + `index` | **per project** | `.mastermind/mmcg.db` in each repo | once per repo, refresh with `index` / `watch` |
|
|
56
|
-
| **Workflow** — subagents
|
|
56
|
+
| **Workflow** — subagents, skills, commands | global | `~/.claude/{agents,skills,commands}/` | installed + refreshed by `init` |
|
|
57
57
|
| **MCP registration** — `setup claude` | once | `~/.claude/.mcp.json` | once for all projects |
|
|
58
58
|
|
|
59
59
|
- **The index is always per-project.** Run `mastermind init` in *every* repo you want indexed. `doctor` reporting `index database not found` just means you haven't done this in the current directory yet (the exact situation if you run `doctor` from `/tmp` or a fresh shell).
|
|
60
|
-
- **The workflow installs globally on `init`** — subagents +
|
|
60
|
+
- **The workflow installs globally on `init`** — subagents, skills + slash commands land in `~/.claude/{agents,skills,commands}/`, overwriting Mastermind's own files to keep them current (`--no-global` to skip). Ships with the npm package; cargo installs use the plugin marketplace instead.
|
|
61
61
|
- **The MCP registration is usually once, globally.** The global entry launches `mastermind serve` from whichever project you open in Claude Code, so it picks up *that* project's `.mastermind/mmcg.db` automatically. You do **not** re-run `setup claude` per repo.
|
|
62
62
|
- Use **per-project registration** only if you want the MCP config committed with the repo and version-pinned: `mastermind setup claude --project . --write-mcp` writes `./.mcp.json` with `command: "./node_modules/.bin/mastermind"` (pair it with a project-local install — see below).
|
|
63
63
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@xcraftmind/mastermind",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.26.0",
|
|
4
4
|
"description": "Mastermind workflow CLI + mmcg codegraph for AI coding agents — verify-spec / audit-spec gates, MCP server, multi-language tree-sitter indexer (Python, TypeScript, JavaScript, Rust, C#, Go, Java, PHP, C/C++). Prebuilt native binaries via optional platform packages — no Rust toolchain required.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "xcraftmind",
|
|
@@ -38,12 +38,12 @@
|
|
|
38
38
|
"mastermind"
|
|
39
39
|
],
|
|
40
40
|
"optionalDependencies": {
|
|
41
|
-
"@xcraftmind/mmcg-darwin-arm64": "0.
|
|
42
|
-
"@xcraftmind/mmcg-darwin-x64": "0.
|
|
43
|
-
"@xcraftmind/mmcg-linux-x64-gnu": "0.
|
|
44
|
-
"@xcraftmind/mmcg-linux-arm64-gnu": "0.
|
|
45
|
-
"@xcraftmind/mmcg-linux-x64-musl": "0.
|
|
46
|
-
"@xcraftmind/mmcg-linux-arm64-musl": "0.
|
|
47
|
-
"@xcraftmind/mmcg-win32-x64-msvc": "0.
|
|
41
|
+
"@xcraftmind/mmcg-darwin-arm64": "0.26.0",
|
|
42
|
+
"@xcraftmind/mmcg-darwin-x64": "0.26.0",
|
|
43
|
+
"@xcraftmind/mmcg-linux-x64-gnu": "0.26.0",
|
|
44
|
+
"@xcraftmind/mmcg-linux-arm64-gnu": "0.26.0",
|
|
45
|
+
"@xcraftmind/mmcg-linux-x64-musl": "0.26.0",
|
|
46
|
+
"@xcraftmind/mmcg-linux-arm64-musl": "0.26.0",
|
|
47
|
+
"@xcraftmind/mmcg-win32-x64-msvc": "0.26.0"
|
|
48
48
|
}
|
|
49
49
|
}
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: api-shape-explorer
|
|
3
|
+
description: Generate three radically different API/interface shapes for the same problem so you can compare tradeoffs before committing. Use when you're about to design a new module, service boundary, or public API and want to avoid anchoring on the first idea.
|
|
4
|
+
metadata:
|
|
5
|
+
version: 0.1.0
|
|
6
|
+
authors:
|
|
7
|
+
- mastermind
|
|
8
|
+
tags:
|
|
9
|
+
- workflow
|
|
10
|
+
- design
|
|
11
|
+
role: user
|
|
12
|
+
variables:
|
|
13
|
+
- name: PROBLEM
|
|
14
|
+
required: true
|
|
15
|
+
description: What the API needs to do. Concrete use cases, not abstract goals.
|
|
16
|
+
- name: CONSTRAINTS
|
|
17
|
+
required: false
|
|
18
|
+
description: Hard constraints — language, framework, latency, compatibility.
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
# API Shape Explorer
|
|
22
|
+
|
|
23
|
+
A user prompt that asks the model to generate three meaningfully different interface designs for the same problem, with tradeoffs. The goal is to force a comparison before you anchor on the first shape that comes to mind.
|
|
24
|
+
|
|
25
|
+
## When to use
|
|
26
|
+
|
|
27
|
+
- Designing a new module's public API
|
|
28
|
+
- Choosing between an SDK shape, a CLI shape, and a config-file shape
|
|
29
|
+
- Service boundary discussions — "should this be one endpoint or three?"
|
|
30
|
+
- Before writing a design doc, to populate the "alternatives considered" section
|
|
31
|
+
- Do NOT use this for implementation — use it only at the interface-design stage
|
|
32
|
+
|
|
33
|
+
## Variables
|
|
34
|
+
|
|
35
|
+
| Name | Required | Description |
|
|
36
|
+
|---|---|---|
|
|
37
|
+
| `PROBLEM` | yes | What the API needs to do. Concrete use cases beat abstract goals. |
|
|
38
|
+
| `CONSTRAINTS` | no | Hard constraints — language, framework, latency targets, compatibility requirements. |
|
|
39
|
+
|
|
40
|
+
## Prompt
|
|
41
|
+
|
|
42
|
+
```text
|
|
43
|
+
I'm designing an API/interface for the following problem. Before I commit to one shape, I want to see three meaningfully different options.
|
|
44
|
+
|
|
45
|
+
PROBLEM:
|
|
46
|
+
{{PROBLEM}}
|
|
47
|
+
|
|
48
|
+
{{#if CONSTRAINTS}}
|
|
49
|
+
CONSTRAINTS:
|
|
50
|
+
{{CONSTRAINTS}}
|
|
51
|
+
{{/if}}
|
|
52
|
+
|
|
53
|
+
Generate exactly three interface designs. They must be *qualitatively* different — not three variations of the same idea. Examples of "qualitatively different": object-oriented vs. functional vs. data-pipeline; sync vs. async vs. streaming; one big call vs. many small calls vs. configuration-driven.
|
|
54
|
+
|
|
55
|
+
For each, give me:
|
|
56
|
+
|
|
57
|
+
## Option <N>: <short name>
|
|
58
|
+
|
|
59
|
+
**Shape:** A code snippet showing how a caller would actually use it. 10-20 lines, realistic.
|
|
60
|
+
|
|
61
|
+
**Mental model:** One sentence describing how a user has to think about this API to use it correctly.
|
|
62
|
+
|
|
63
|
+
**Strengths:**
|
|
64
|
+
- <thing 1>
|
|
65
|
+
- <thing 2>
|
|
66
|
+
|
|
67
|
+
**Weaknesses:**
|
|
68
|
+
- <thing 1>
|
|
69
|
+
- <thing 2>
|
|
70
|
+
|
|
71
|
+
**Best when:** <one sentence on the situation this is the right shape for>
|
|
72
|
+
|
|
73
|
+
After the three options, give me a short comparison:
|
|
74
|
+
|
|
75
|
+
## Comparison
|
|
76
|
+
|
|
77
|
+
| Dimension | Option 1 | Option 2 | Option 3 |
|
|
78
|
+
|---|---|---|---|
|
|
79
|
+
| Learning curve | low / medium / high | … | … |
|
|
80
|
+
| Composability | … | … | … |
|
|
81
|
+
| Testability | … | … | … |
|
|
82
|
+
| Extensibility | … | … | … |
|
|
83
|
+
|
|
84
|
+
End with one paragraph: "If forced to pick one without more information, I'd choose Option X because…"
|
|
85
|
+
|
|
86
|
+
Do not hedge. Do not say "all three have merit." Pick one and defend it.
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## Example invocation
|
|
90
|
+
|
|
91
|
+
```text
|
|
92
|
+
I'm designing an API/interface for the following problem. Before I commit to one shape, I want to see three meaningfully different options.
|
|
93
|
+
|
|
94
|
+
PROBLEM:
|
|
95
|
+
A library that retries flaky operations. Used in Python services. Needs to support: exponential backoff, max attempts, retry only on specific exception types, callback on retry, async and sync code paths. Typical caller wraps a single function call.
|
|
96
|
+
|
|
97
|
+
CONSTRAINTS:
|
|
98
|
+
- Python 3.11+, no external runtime deps
|
|
99
|
+
- Must work in both sync and async code (one library, not two)
|
|
100
|
+
- Should be debuggable — users have to be able to see *why* a retry happened
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
## Notes
|
|
104
|
+
|
|
105
|
+
- The prompt deliberately forbids "all three are good" answers. Forcing a pick exposes which dimensions matter most to the model.
|
|
106
|
+
- Re-run with the same `PROBLEM` and a slightly different `CONSTRAINTS` to see how the recommendation shifts. That's often where the real insight is.
|
|
107
|
+
- Works well with Opus. Sonnet tends to make the three options closer to each other than they should be.
|