murmur8 4.7.0 → 4.7.1
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 +9 -5
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
# murmur8
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
AI coding tools can be a black box. You describe what you want, magic happens, and code appears. If it's wrong, you describe it again and hope for better. There's no process, no trail, no shared understanding of why decisions were made.
|
|
4
4
|
|
|
5
|
-
murmur8 is different.
|
|
5
|
+
murmur8 is different. Agents Alex, Cass, Nigel, and Codey run a structured, documented pipeline — the kind a good engineering team would run naturally. Each agent produces real, readable artefacts: a feature spec, user stories, a test plan, an implementation. You can read every one of them, understand the reasoning, and step in at any point. It's not magic. It's a repeatable process that happens to move very fast.
|
|
6
6
|
|
|
7
|
-
Like a murmuration of starlings, the agents move together — each one responding to what came before
|
|
7
|
+
Like a murmuration of starlings, the agents move together — each one responding to what came before and building upon it.
|
|
8
8
|
|
|
9
9
|
## The Workflow
|
|
10
10
|
|
|
@@ -12,7 +12,7 @@ Like a murmuration of starlings, the agents move together — each one respondin
|
|
|
12
12
|
|
|
13
13
|
Every feature starts with intent. If you're setting up a new project, murmur8 will walk you through creating a system specification interactively — Alex asks questions, you answer, and together you produce a document that grounds everything that follows. If a feature spec doesn't exist yet, the same thing happens at the feature level.
|
|
14
14
|
|
|
15
|
-
You can also trigger this explicitly with `--interactive
|
|
15
|
+
You can also trigger this explicitly with `--interactive` flag. This is useful when an idea is still fuzzy, you can have a conversation with Alex until the shape of the feature becomes clear. The spec that comes out the other side is yours to review and approve before anything else runs.
|
|
16
16
|
|
|
17
17
|
### The pipeline runs
|
|
18
18
|
|
|
@@ -24,10 +24,14 @@ At every handoff, the agent writes a summary of what it did, what it decided, an
|
|
|
24
24
|
|
|
25
25
|
The first run won't always land exactly right. Requirements shift, something was misunderstood, or the implementation reveals a gap in the spec. That's normal.
|
|
26
26
|
|
|
27
|
-
`/refine-feature` reopens the conversation. Alex reads what was built,
|
|
27
|
+
`/refine-feature` reopens the conversation. You can discuss with Alex whats not right, provide error logs, or user feedback. Alex reads what was built, and describes what needs to change, and proposes an updated spec diff for your approval. From there Cass updates only the affected stories, Nigel updates only the affected tests, and Codey reimplements. The pipeline pauses before Codey runs — you always see the full picture of what's changing before any code is touched.
|
|
28
28
|
|
|
29
29
|
Every refinement is linked to the run it came from, so the history of a feature — original intent, what changed, and why — is always traceable.
|
|
30
30
|
|
|
31
|
+
### Turning it up to 11
|
|
32
|
+
|
|
33
|
+
If you using the skill with Claude Code or Github Copilot, or via an npx command, you can run multiple of these pipelines at the same time, working independantly on features in parallel. The pipeline look at whats required and work out how multiple fetaures can be delivered at the same time withough Nigel 1, 2, and 3 treading on each others toes in the code base. The pipeline runs EXACTLY the same way... just mutiple of them at the same time!
|
|
34
|
+
|
|
31
35
|
## Quick Start
|
|
32
36
|
|
|
33
37
|
**Inside Claude Code or Copilot CLI:**
|