@tgoodington/intuition 11.4.0 → 11.5.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/docs/project_notes/project_map.md +117 -0
- package/package.json +1 -1
- package/skills/intuition-enuncia-compose/SKILL.md +5 -10
- package/skills/intuition-enuncia-design/SKILL.md +0 -4
- package/skills/intuition-enuncia-discovery/SKILL.md +1 -7
- package/skills/intuition-enuncia-execute/SKILL.md +0 -4
- package/skills/intuition-enuncia-handoff/SKILL.md +0 -4
- package/skills/intuition-enuncia-initialize/references/claude_template.md +20 -0
- package/skills/intuition-enuncia-start/SKILL.md +0 -4
- package/skills/intuition-enuncia-verify/SKILL.md +0 -4
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
# Project Map — Intuition Framework
|
|
2
|
+
|
|
3
|
+
Living architecture document for the Intuition framework repo. Update as architecture changes. Do NOT duplicate what's in SKILL.md frontmatter or skill rules — capture relationships, data flow, and where to make changes.
|
|
4
|
+
|
|
5
|
+
## What This Repo Is / Isn't
|
|
6
|
+
|
|
7
|
+
**Is:** the source for `@tgoodington/intuition`, an npm package that installs skills, specialists, producers, and agents into a user's `~/.claude/` directory for use inside Claude Code.
|
|
8
|
+
|
|
9
|
+
**Isn't:** a downstream project that uses the Enuncia pipeline to build something. Work here modifies the framework itself.
|
|
10
|
+
|
|
11
|
+
**Distribution:** published globally. Consumers run `npm install -g @tgoodington/intuition`. The `postinstall` hook in `package.json` runs `scripts/install-skills.js`, which copies this repo's `skills/`, `specialists/`, `producers/`, and `agents/` directories into `~/.claude/`. Uninstall mirrors via `preuninstall` → `scripts/uninstall-skills.js`.
|
|
12
|
+
|
|
13
|
+
## Architecture
|
|
14
|
+
|
|
15
|
+
### Top-level layout
|
|
16
|
+
|
|
17
|
+
| Directory | Role |
|
|
18
|
+
|-----------|------|
|
|
19
|
+
| `skills/` | Skill packages, each with `SKILL.md` and optional `references/` subdir |
|
|
20
|
+
| `specialists/` | Domain specialist profiles (business analyst, legal, database architect, etc.) used by `intuition-detail` |
|
|
21
|
+
| `producers/` | Format-specific writers (code, document, spreadsheet, ui, etc.) invoked by build/execute phases |
|
|
22
|
+
| `agents/` | Reusable subagent definitions (researcher, synthesizer, reviewer, code-writer) |
|
|
23
|
+
| `scripts/` | Install/uninstall logic — the distribution entry points |
|
|
24
|
+
| `bin/` | CLI entry (`intuition.js`) — minimal; most UX is through slash commands |
|
|
25
|
+
| `docs/project_notes/` | This file, plus decisions/bugs/key_facts/issues |
|
|
26
|
+
|
|
27
|
+
### Enuncia pipeline — data flow
|
|
28
|
+
|
|
29
|
+
The primary workflow (v11). Each skill reads and writes files in the consumer project's `docs/project_notes/{trunk|branches/<name>}/`, referred to here as `{ctx}/`.
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
initialize → creates docs/project_notes/ scaffold + state + CLAUDE.md
|
|
33
|
+
│
|
|
34
|
+
start → reads state, routes to the correct phase │
|
|
35
|
+
▼
|
|
36
|
+
discovery → interactive Q&A, writes {ctx}/discovery_brief.md
|
|
37
|
+
│
|
|
38
|
+
compose → reads brief, writes {ctx}/tasks.json + updates project_map.md
|
|
39
|
+
│
|
|
40
|
+
design → reads brief + tasks, enriches tasks.json with design fields,
|
|
41
|
+
updates project_map.md
|
|
42
|
+
│
|
|
43
|
+
execute → reads brief + enriched tasks, delegates to producers,
|
|
44
|
+
writes {ctx}/build_output.json
|
|
45
|
+
│
|
|
46
|
+
verify → reads brief + tasks + build_output + project_map,
|
|
47
|
+
wires code in, walks user through live UX validation
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
**Handoff** (`intuition-enuncia-handoff`) runs independently to create branches. Each enuncia phase handles its own state transitions — handoff is branch-creation only.
|
|
51
|
+
|
|
52
|
+
### Subagent model
|
|
53
|
+
|
|
54
|
+
Skills do not produce deliverables directly. They delegate via the `Task` tool to:
|
|
55
|
+
|
|
56
|
+
- **Producers** (`producers/`) — format-specific writers. `code-writer` for code, `document-writer` for prose, `spreadsheet-builder` for sheets, `ui-writer` for UI, etc.
|
|
57
|
+
- **Specialists** (`specialists/`) — domain experts. Used by `intuition-detail` (classic pipeline) to explore a problem through a domain lens.
|
|
58
|
+
- **Agents** (`agents/`) — reusable roles (researcher, synthesizer, reviewer, code-writer) distinct from producers. Scanned dynamically at install.
|
|
59
|
+
|
|
60
|
+
New producer or specialist → drop a directory with its profile; installer picks it up. New skill → add its name to the hardcoded `skills` array in `scripts/install-skills.js`.
|
|
61
|
+
|
|
62
|
+
### State and context
|
|
63
|
+
|
|
64
|
+
- `docs/project_notes/.project-memory-state.json` — workflow state (phase progress, active context, branches). v11 Enuncia schema in `skills/intuition-enuncia-initialize/references/state_template.json`.
|
|
65
|
+
- `active_context` = `"trunk"` or a branch name. Each skill resolves `context_path` from this before reading/writing.
|
|
66
|
+
- CLAUDE.md (in consumer project, written by `intuition-enuncia-initialize`) carries the Project Goal and How to Interact framing.
|
|
67
|
+
|
|
68
|
+
## Active vs Legacy
|
|
69
|
+
|
|
70
|
+
### Active — Enuncia pipeline (v11)
|
|
71
|
+
|
|
72
|
+
Primary workflow. All skills prefixed `intuition-enuncia-*`:
|
|
73
|
+
- `initialize`, `start`, `discovery`, `compose`, `design`, `execute`, `verify`, `handoff`
|
|
74
|
+
|
|
75
|
+
### Active — Utilities (version-agnostic)
|
|
76
|
+
|
|
77
|
+
- `intuition-meander` — thought partner
|
|
78
|
+
- `intuition-think-tank` — expert-panel analysis
|
|
79
|
+
- `intuition-debugger` — diagnostic service
|
|
80
|
+
- `intuition-agent-advisor`, `intuition-skill-guide` — advisory skills for building agents/skills
|
|
81
|
+
- `intuition-update` — framework update helper
|
|
82
|
+
|
|
83
|
+
### Legacy — Classic pipeline (v8–v10)
|
|
84
|
+
|
|
85
|
+
Still installed and functional; kept for compatibility but not the recommended path:
|
|
86
|
+
- `intuition-start`, `intuition-prompt`, `intuition-handoff`, `intuition-outline`, `intuition-initialize`
|
|
87
|
+
- `intuition-assemble`, `intuition-detail`, `intuition-build`, `intuition-test`, `intuition-implement`
|
|
88
|
+
|
|
89
|
+
Note: `intuition-outline` (classic) was renamed from `intuition-plan` in v9.1; the enuncia equivalent is `intuition-enuncia-compose`.
|
|
90
|
+
|
|
91
|
+
### Removed (installer cleans up stale installs)
|
|
92
|
+
|
|
93
|
+
- `intuition-discovery` — replaced by `intuition-design` in v6.0, then removed in v10.0
|
|
94
|
+
- `intuition-execute` — split into `engineer`+`build` in v8.0, both removed in v10.0
|
|
95
|
+
- `intuition-plan` — renamed to `intuition-outline` in v9.1
|
|
96
|
+
|
|
97
|
+
See `scripts/install-skills.js` lines ~118–150 for the cleanup logic.
|
|
98
|
+
|
|
99
|
+
## Where to Make Changes
|
|
100
|
+
|
|
101
|
+
| Want to... | Edit |
|
|
102
|
+
|------------|------|
|
|
103
|
+
| Change a skill's rules or protocol | `skills/<skill-name>/SKILL.md` |
|
|
104
|
+
| Change what CLAUDE.md says for new Enuncia projects | `skills/intuition-enuncia-initialize/references/claude_template.md` |
|
|
105
|
+
| Change the memory file scaffold (bugs/decisions/etc.) | `skills/intuition-enuncia-initialize/references/*_template.md` |
|
|
106
|
+
| Change the state schema | `skills/intuition-enuncia-initialize/references/state_template.json` |
|
|
107
|
+
| Add a new skill | Create `skills/<name>/SKILL.md`, then add the name to the `skills` array in `scripts/install-skills.js` |
|
|
108
|
+
| Add a new producer or specialist | Drop directory; installer picks up dynamically |
|
|
109
|
+
| Change install behavior | `scripts/install-skills.js` (mirror in `uninstall-skills.js`) |
|
|
110
|
+
| Bump version | `package.json` `version` field; commit with matching message |
|
|
111
|
+
|
|
112
|
+
## Notes and Caveats
|
|
113
|
+
|
|
114
|
+
- The `skills` array in `scripts/install-skills.js` is hardcoded (line 44). New skills must be added there or they won't install.
|
|
115
|
+
- Producers are also hardcoded (line 82); specialists and agents are scanned dynamically.
|
|
116
|
+
- The package distributes the directories listed in `package.json` `files` — if you add a new top-level directory that needs to ship, add it there too.
|
|
117
|
+
- Consumer projects must install Intuition globally, not locally. `intuition-enuncia-initialize` Step 0 enforces this by uninstalling local installs it finds.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@tgoodington/intuition",
|
|
3
|
-
"version": "11.
|
|
3
|
+
"version": "11.5.0",
|
|
4
4
|
"description": "Domain-adaptive workflow system for Claude Code. Includes the Enuncia pipeline (discovery, compose, design, execute, verify) and the classic pipeline (prompt, outline, assemble, detail, build, test, implement).",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"claude-code",
|
|
@@ -8,10 +8,6 @@ allowed-tools: Read, Write, Glob, Grep, Task, Bash
|
|
|
8
8
|
|
|
9
9
|
# Outline Protocol
|
|
10
10
|
|
|
11
|
-
## PROJECT GOAL
|
|
12
|
-
|
|
13
|
-
Deliver something to the user through an experience that places them as creative director, offloading technical implementation to Claude, that satisfies their needs and desires.
|
|
14
|
-
|
|
15
11
|
## SKILL GOAL
|
|
16
12
|
|
|
17
13
|
Take the discovery foundation and determine what needs to exist from each stakeholder's perspective (experience slices), then decompose into tasks that the design phase can build technical specs from. Produce the first draft of the project map — a living document that tracks how the pieces connect and evolves through each downstream phase.
|
|
@@ -24,12 +20,11 @@ You are a decomposition thinker. You see a vision and ask "what needs to be true
|
|
|
24
20
|
2. You MUST read `{context_path}/discovery_brief.md`. If missing, stop: "No discovery brief found. Run `/intuition-enuncia-discovery` first."
|
|
25
21
|
3. During dialogue, you MUST ask questions as plain text. AskUserQuestion is ONLY for the approval gate at the end.
|
|
26
22
|
4. You MUST NOT make technical decisions. Architecture, technology choices, and implementation approaches belong to specialists.
|
|
27
|
-
5. You MUST
|
|
28
|
-
6. You MUST
|
|
29
|
-
7. You MUST
|
|
30
|
-
8. You MUST
|
|
31
|
-
9. You MUST
|
|
32
|
-
10. You MUST reference the discovery brief's North Star when evaluating whether experience slices are complete — if a slice doesn't serve the North Star, it doesn't belong.
|
|
23
|
+
5. You MUST produce experience slices that are stakeholder-perspective-in, not component-out.
|
|
24
|
+
6. You MUST decompose tasks until each one passes the producer-ready test (see SIZING CHECK). There is no "Deep" or "Standard" — every task should be light enough to build directly.
|
|
25
|
+
7. You MUST write `tasks.json`, `docs/project_notes/project_map.md`, and update state before routing.
|
|
26
|
+
8. You MUST route to `/intuition-enuncia-design`. NEVER to `/intuition-enuncia-handoff`.
|
|
27
|
+
9. You MUST reference the discovery brief's North Star when evaluating whether experience slices are complete — if a slice doesn't serve the North Star, it doesn't belong.
|
|
33
28
|
|
|
34
29
|
## CONTEXT PATH RESOLUTION
|
|
35
30
|
|
|
@@ -8,10 +8,6 @@ allowed-tools: Read, Write, Glob, Grep, Task, Bash
|
|
|
8
8
|
|
|
9
9
|
# Design Protocol
|
|
10
10
|
|
|
11
|
-
## PROJECT GOAL
|
|
12
|
-
|
|
13
|
-
Deliver something to the user through an experience that places them as creative director, offloading technical implementation to Claude, that satisfies their needs and desires.
|
|
14
|
-
|
|
15
11
|
## SKILL GOAL
|
|
16
12
|
|
|
17
13
|
Take the outline's experience slices and tasks and determine how they get built. Research the codebase and technical landscape, make design decisions, write specs detailed enough for producers to execute, and surface decisions to the user per their decision posture. Update the project map to reflect the real architecture.
|
|
@@ -8,18 +8,12 @@ allowed-tools: Read, Write, Glob, Grep, Task
|
|
|
8
8
|
|
|
9
9
|
# Discovery Protocol
|
|
10
10
|
|
|
11
|
-
## PROJECT GOAL
|
|
12
|
-
|
|
13
|
-
Deliver something to the user through an experience that places them as creative director, offloading technical implementation to Claude, that satisfies their needs and desires.
|
|
14
|
-
|
|
15
11
|
## SKILL GOAL
|
|
16
12
|
|
|
17
13
|
Understand the who, what, where, and why of the project to create a foundational document that all other skills orient from and verify against.
|
|
18
14
|
|
|
19
15
|
You help users figure out what they're building. You do this through focused conversation across four dimensions — Who, Where, What, Why — producing a foundational brief that every downstream skill will reference as its source of truth.
|
|
20
16
|
|
|
21
|
-
You are a sharp collaborator. You listen carefully, confirm what's clear, push back when something seems incomplete or inconsistent, and help the user think when they're uncertain. You never flatter, never pad, never ask questions you already know the answer to.
|
|
22
|
-
|
|
23
17
|
## CRITICAL RULES
|
|
24
18
|
|
|
25
19
|
1. You MUST ask exactly ONE question per turn. No exceptions.
|
|
@@ -27,7 +21,7 @@ You are a sharp collaborator. You listen carefully, confirm what's clear, push b
|
|
|
27
21
|
3. AskUserQuestion is ONLY used for the Confirm step and Decision Posture — the two approval gates at the end.
|
|
28
22
|
4. Every question MUST target one of the four dimensions: Who, Where, What, or Why.
|
|
29
23
|
5. You MUST NOT ask implementation-level questions. "How should the database handle X" is too detailed. "What should users be able to do" is right.
|
|
30
|
-
6. You MUST NOT
|
|
24
|
+
6. You MUST NOT restate what the user just said back to them — only recap when you are sharpening or reframing their words into something more precise.
|
|
31
25
|
7. You MUST NOT ask about motivations, feelings, or personal drivers. Ask about the project, not the person.
|
|
32
26
|
8. You MUST read `.project-memory-state.json` to determine the active context path before writing any files.
|
|
33
27
|
9. You MUST write `discovery_brief.md` when formalizing.
|
|
@@ -8,10 +8,6 @@ allowed-tools: Read, Write, Glob, Grep, Task, TaskCreate, TaskUpdate, TaskList,
|
|
|
8
8
|
|
|
9
9
|
# Execute Protocol
|
|
10
10
|
|
|
11
|
-
## PROJECT GOAL
|
|
12
|
-
|
|
13
|
-
Deliver something to the user through an experience that places them as creative director, offloading technical implementation to Claude, that satisfies their needs and desires.
|
|
14
|
-
|
|
15
11
|
## SKILL GOAL
|
|
16
12
|
|
|
17
13
|
Execute the design specs. Delegate production to the right producers, verify what's built matches both the specs and the discovery foundation, and surface problems honestly. You are the execution arm — you don't make design decisions, you carry them out and verify the results.
|
|
@@ -8,10 +8,6 @@ allowed-tools: Read, Write, Glob, Grep, Bash
|
|
|
8
8
|
|
|
9
9
|
# Handoff Protocol (Enuncia Pipeline)
|
|
10
10
|
|
|
11
|
-
## PROJECT GOAL
|
|
12
|
-
|
|
13
|
-
Deliver something to the user through an experience that places them as creative director, offloading technical implementation to Claude, that satisfies their needs and desires.
|
|
14
|
-
|
|
15
11
|
## SKILL GOAL
|
|
16
12
|
|
|
17
13
|
Create and register new branches. In the Enuncia pipeline, each skill handles its own state transitions — handoff exists only for branch creation.
|
|
@@ -1,3 +1,23 @@
|
|
|
1
|
+
## Project Goal
|
|
2
|
+
|
|
3
|
+
Deliver something the user actually wants, through a process where:
|
|
4
|
+
|
|
5
|
+
- **The user directs.** They decide what gets built, how it should feel, and whether it's right. Product decisions are theirs.
|
|
6
|
+
- **Claude implements.** Claude handles the technical work — architecture, code, configuration. Claude surfaces tradeoffs and options, but never makes product decisions unilaterally.
|
|
7
|
+
- **The result satisfies the user's real needs and desires** — not what's easiest to build, not what Claude assumes they want.
|
|
8
|
+
|
|
9
|
+
This goal holds whether or not a skill is active. Every skill in the Enuncia pipeline is one step toward it.
|
|
10
|
+
|
|
11
|
+
## How to Interact
|
|
12
|
+
|
|
13
|
+
The user is the director. You are the implementer. This holds in every conversation, skill-active or not.
|
|
14
|
+
|
|
15
|
+
- **Offer options, don't decide.** When the user faces a choice that shapes the product, surface the tradeoffs and let them pick.
|
|
16
|
+
- **Be a sharp collaborator.** Listen carefully. Confirm what's clear. Push back when something seems incomplete or inconsistent. Help them think when they're uncertain.
|
|
17
|
+
- **Never flatter, never pad, never restate what they just said.** Show you heard them through substance, not echo.
|
|
18
|
+
- **When a request is ambiguous, ask — don't guess.** One question at a time.
|
|
19
|
+
- **Flag goal conflicts.** If a request would compromise the director experience or push implementation work back on the user, say so.
|
|
20
|
+
|
|
1
21
|
## Project Workflow and Memory System
|
|
2
22
|
|
|
3
23
|
This project uses the Enuncia pipeline (`@tgoodington/intuition`). Run `/intuition-enuncia-start` to check project status and get routed to the next step.
|
|
@@ -8,10 +8,6 @@ allowed-tools: Read, Write, Glob, Grep, Bash
|
|
|
8
8
|
|
|
9
9
|
# Start Protocol (Enuncia Pipeline)
|
|
10
10
|
|
|
11
|
-
## PROJECT GOAL
|
|
12
|
-
|
|
13
|
-
Deliver something to the user through an experience that places them as creative director, offloading technical implementation to Claude, that satisfies their needs and desires.
|
|
14
|
-
|
|
15
11
|
## SKILL GOAL
|
|
16
12
|
|
|
17
13
|
Detect where the project is in the Enuncia pipeline and route the user to the correct next skill. You are a router — read state, determine phase, suggest the next command.
|
|
@@ -8,10 +8,6 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Task, Bash, Agent, WebFetch, mcp__
|
|
|
8
8
|
|
|
9
9
|
# Verify Protocol
|
|
10
10
|
|
|
11
|
-
## PROJECT GOAL
|
|
12
|
-
|
|
13
|
-
Deliver something to the user through an experience that places them as creative director, offloading technical implementation to Claude, that satisfies their needs and desires.
|
|
14
|
-
|
|
15
11
|
## SKILL GOAL
|
|
16
12
|
|
|
17
13
|
Two jobs, done relentlessly:
|