wizz-method 1.15.0 → 1.16.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/package.json +3 -2
- package/skills-registry.yaml +35 -104
- package/src/bmm-skills/3-solutioning/wizz-architecture/scripts/__pycache__/lint_spine.cpython-313.pyc +0 -0
- package/src/bmm-skills/3-solutioning/wizz-architecture/scripts/tests/__pycache__/test_lint_spine.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/bmm-skills/4-implementation/wizz-code-review/SKILL.md +3 -5
- package/src/bmm-skills/4-implementation/wizz-code-review/customize.toml +71 -0
- package/src/bmm-skills/4-implementation/wizz-code-review/references/claims-check.md +14 -0
- package/src/bmm-skills/4-implementation/wizz-code-review/references/deletion-check.md +14 -0
- package/src/bmm-skills/4-implementation/wizz-code-review/review-prompts/edge-case-hunter.md +110 -0
- package/src/bmm-skills/4-implementation/wizz-code-review/review-prompts/verification-gap.md +113 -0
- package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-01-gather-context.md +32 -23
- package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-02-review.md +10 -13
- package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-03-triage.md +16 -22
- package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-04-present.md +4 -2
- package/src/bmm-skills/4-implementation/wizz-quick-dev/customize.toml +76 -0
- package/src/bmm-skills/4-implementation/wizz-quick-dev/references/claims-check.md +14 -0
- package/src/bmm-skills/4-implementation/wizz-quick-dev/references/deletion-check.md +14 -0
- package/src/bmm-skills/4-implementation/wizz-quick-dev/review-prompts/edge-case-hunter.md +110 -0
- package/src/bmm-skills/4-implementation/wizz-quick-dev/review-prompts/verification-gap.md +113 -0
- package/src/bmm-skills/4-implementation/wizz-quick-dev/step-04-review.md +38 -16
- package/src/bmm-skills/4-implementation/wizz-retrospective/SKILL.md +56 -1488
- package/src/bmm-skills/4-implementation/wizz-retrospective/customize.toml +3 -5
- package/src/bmm-skills/4-implementation/wizz-retrospective/references/acceptance-verdict.md +55 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/references/aggregate-views.md +17 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/references/evidence-gathering.md +30 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/references/retro-document.md +84 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/references/team-discussion.md +22 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/__pycache__/sprint_status.cpython-313.pyc +0 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/git_evidence.py +304 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/sprint_status.py +746 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/tests/__pycache__/test_git_evidence.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/tests/__pycache__/test_sprint_status.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/tests/fixtures/sprint-status-template.yaml +71 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/tests/test_git_evidence.py +750 -0
- package/src/bmm-skills/4-implementation/wizz-retrospective/scripts/tests/test_sprint_status.py +1579 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/SKILL.md +39 -296
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/customize.toml +1 -3
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/references/fix-sprint-status.md +30 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/references/generate-tracking.md +25 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/references/readiness-gate.md +20 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/references/status-view.md +14 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/references/validate.md +10 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/scripts/__pycache__/sprint_plan.cpython-313.pyc +0 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/scripts/sprint_plan.py +697 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/scripts/tests/__pycache__/test_sprint_plan.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/scripts/tests/test_sprint_plan.py +524 -0
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/sprint-status-template.yaml +9 -7
- package/src/bmm-skills/module-help.csv +3 -3
- package/src/core-skills/module-help.csv +1 -0
- package/src/core-skills/wizz-advanced-elicitation/SKILL.md +36 -114
- package/src/core-skills/wizz-advanced-elicitation/{methods.csv → assets/methods.csv} +29 -27
- package/src/core-skills/wizz-advanced-elicitation/customize.toml +54 -0
- package/src/core-skills/wizz-advanced-elicitation/scripts/__pycache__/pick_methods.cpython-313.pyc +0 -0
- package/src/core-skills/wizz-advanced-elicitation/scripts/pick_methods.py +233 -0
- package/src/core-skills/wizz-advanced-elicitation/scripts/tests/__pycache__/test_pick_methods.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/core-skills/wizz-advanced-elicitation/scripts/tests/test_pick_methods.py +228 -0
- package/src/core-skills/wizz-brainstorming/SKILL.md +2 -2
- package/src/core-skills/wizz-brainstorming/assets/brain-selector.html +2 -0
- package/src/core-skills/wizz-brainstorming/references/converge.md +1 -1
- package/src/core-skills/wizz-brainstorming/references/finalize.md +1 -1
- package/src/core-skills/wizz-brainstorming/references/headless.md +1 -1
- package/src/core-skills/wizz-brainstorming/references/mode-autonomous.md +1 -1
- package/src/core-skills/wizz-brainstorming/scripts/__pycache__/brain.cpython-313.pyc +0 -0
- package/src/core-skills/wizz-brainstorming/scripts/brain.py +36 -6
- package/src/core-skills/wizz-brainstorming/scripts/tests/__pycache__/test_brain.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/core-skills/wizz-brainstorming/scripts/tests/__pycache__/test_brain.cpython-314.pyc +0 -0
- package/src/core-skills/wizz-brainstorming/scripts/tests/test_brain.py +24 -2
- package/src/core-skills/wizz-customize/scripts/__pycache__/list_customizable_skills.cpython-313.pyc +0 -0
- package/src/core-skills/wizz-customize/scripts/tests/__pycache__/test_list_customizable_skills.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/core-skills/wizz-forge-idea/SKILL.md +107 -0
- package/src/core-skills/wizz-forge-idea/customize.toml +41 -0
- package/src/core-skills/wizz-forge-idea/scripts/__pycache__/resolve_personas.cpython-313.pyc +0 -0
- package/src/core-skills/wizz-forge-idea/scripts/__pycache__/resolve_personas.cpython-314.pyc +0 -0
- package/src/core-skills/wizz-forge-idea/scripts/resolve_personas.py +275 -0
- package/src/core-skills/wizz-forge-idea/scripts/tests/__pycache__/test_resolve_personas.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/core-skills/wizz-forge-idea/scripts/tests/__pycache__/test_resolve_personas.cpython-314.pyc +0 -0
- package/src/core-skills/wizz-forge-idea/scripts/tests/test_resolve_personas.py +138 -0
- package/src/core-skills/wizz-party-mode/SKILL.md +37 -54
- package/src/core-skills/wizz-party-mode/customize.toml +61 -2
- package/src/core-skills/wizz-party-mode/references/create-party.md +8 -3
- package/src/core-skills/wizz-party-mode/references/mode-agent-team.md +3 -1
- package/src/core-skills/wizz-party-mode/references/mode-subagent.md +16 -4
- package/src/core-skills/wizz-party-mode/references/party-memory.md +51 -0
- package/src/core-skills/wizz-party-mode/scripts/__pycache__/resolve_party.cpython-313.pyc +0 -0
- package/src/core-skills/wizz-party-mode/scripts/__pycache__/resolve_party.cpython-314.pyc +0 -0
- package/src/core-skills/wizz-party-mode/scripts/resolve_party.py +22 -7
- package/src/core-skills/wizz-party-mode/scripts/tests/__pycache__/test_resolve_party.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/core-skills/wizz-party-mode/scripts/tests/__pycache__/test_resolve_party.cpython-314.pyc +0 -0
- package/src/core-skills/wizz-party-mode/scripts/tests/{test-resolve_party.py → test_resolve_party.py} +8 -0
- package/src/core-skills/wizz-review-edge-case-hunter/SKILL.md +17 -3
- package/src/modules/wizz/agents/wizz-growth/customize.toml +10 -0
- package/src/scripts/__pycache__/memlog.cpython-313.pyc +0 -0
- package/src/scripts/tests/__pycache__/test_memlog.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/scripts/tests/__pycache__/test_resolve_customization.cpython-313-pytest-9.1.1.pyc +0 -0
- package/src/skills-lib/pesquisa-de-publico-do-piva/README.md +83 -0
- package/src/skills-lib/pesquisa-de-publico-do-piva/SKILL.md +65 -0
- package/src/skills-lib/pesquisa-de-publico-do-piva/assets/template.html +414 -0
- package/src/skills-lib/pesquisa-de-publico-do-piva/prompts.md +131 -0
- package/src/skills-lib/wizz-offer-forge/README.md +13 -0
- package/src/skills-lib/wizz-offer-forge/SKILL.md +74 -0
- package/src/skills-lib/wizz-offer-forge/references/empilhamento-valor.md +25 -0
- package/src/skills-lib/wizz-offer-forge/references/garantia-reversa.md +22 -0
- package/src/skills-lib/wizz-offer-forge/references/mecanismo-unico.md +28 -0
- package/src/skills-lib/wizz-offer-forge/references/ponte-trafego.md +21 -0
- package/src/skills-lib/wizz-router/references/routing-table-flat.md +2 -0
- package/tools/installer/core/installer.js +57 -0
- package/tools/installer/ide/_config-driven.js +3 -3
- package/tools/installer/ide/platform-codes.yaml +28 -0
- package/tools/installer/modules/external-manager.js +140 -2
- package/tools/installer/modules/official-modules.js +68 -21
- package/tools/installer/prompts.js +45 -103
- package/tools/installer/ui.js +64 -7
- package/wizz-modules.yaml +65 -11
- package/src/bmm-skills/4-implementation/wizz-sprint-planning/checklist.md +0 -34
- package/src/core-skills/wizz-brainstorming/scripts/memlog.py +0 -202
- package/src/core-skills/wizz-brainstorming/scripts/tests/test_memlog.py +0 -265
|
@@ -51,6 +51,22 @@ party_mode = "session"
|
|
|
51
51
|
# config; point this elsewhere in your team/user override to redirect keepsakes.
|
|
52
52
|
output_dir = "{output_folder}/party-mode"
|
|
53
53
|
|
|
54
|
+
# Memory for the DEFAULT room (the installed-agent party). When on, the room
|
|
55
|
+
# keeps a succinct, append-only memlog (the memlog standard) that it reads on
|
|
56
|
+
# entry and writes through the session, so the next time opens remembering the
|
|
57
|
+
# last — dynamics carried forward, memorable moments, organic callbacks, where
|
|
58
|
+
# things landed. It is memory, not a transcript. Set false to turn the default
|
|
59
|
+
# room's memory off. NAMED groups do NOT follow this flag: each carries its own
|
|
60
|
+
# `memory = true|false` (see party_groups below). Ad-hoc inline casts are always
|
|
61
|
+
# ephemeral until saved as a party.
|
|
62
|
+
party_memory = true
|
|
63
|
+
|
|
64
|
+
# Root for the per-party memlogs. Each party stores at
|
|
65
|
+
# `{memory_dir}/<party>/.memlog.md`, where `<party>` is the group id (or
|
|
66
|
+
# `installed` for the default room). `{output_folder}` comes from core config;
|
|
67
|
+
# point this elsewhere in your team/user override to relocate memory.
|
|
68
|
+
memory_dir = "{output_folder}/party-mode/memories"
|
|
69
|
+
|
|
54
70
|
# Executed when the party wraps (after the read-back, before dropping to normal
|
|
55
71
|
# mode). String scalar = one instruction; array = instructions run in order.
|
|
56
72
|
on_complete = ""
|
|
@@ -71,8 +87,9 @@ on_complete = ""
|
|
|
71
87
|
# woven into their spawn prompt as guidance, not a hard tool grant
|
|
72
88
|
# model (optional) model to use when this member is spawned
|
|
73
89
|
#
|
|
74
|
-
# The members below ship the "Code Review Crew"
|
|
75
|
-
#
|
|
90
|
+
# The members below ship built-in parties such as the "Code Review Crew" and
|
|
91
|
+
# "Anti-Consensus Club" (see the party_groups section). They cost nothing until
|
|
92
|
+
# summoned — the default room never includes them.
|
|
76
93
|
# ---------------------------------------------------------------------------
|
|
77
94
|
|
|
78
95
|
[[workflow.party_members]]
|
|
@@ -111,6 +128,34 @@ icon = "🚢"
|
|
|
111
128
|
title = "The Pragmatist"
|
|
112
129
|
persona = "Counters the perfectionists so the room isn't a pile-on. 'Does this actually matter to a user? Ship the 80%, file the rest.' Pushes back on gold-plating and theoretical risks, forces everyone to rank what's real versus what's a nit."
|
|
113
130
|
|
|
131
|
+
[[workflow.party_members]]
|
|
132
|
+
code = "option-generator"
|
|
133
|
+
name = "Wildcard"
|
|
134
|
+
icon = "🃏"
|
|
135
|
+
title = "Option Generator"
|
|
136
|
+
persona = "Wildcard looks for options the room has not considered. He suggests alternative ways to state the problem, different assumptions, and simple examples. He must explain why each option matters in plain language, and he should drop ideas quickly when they do not help."
|
|
137
|
+
|
|
138
|
+
[[workflow.party_members]]
|
|
139
|
+
code = "claim-checker"
|
|
140
|
+
name = "Level"
|
|
141
|
+
icon = "📏"
|
|
142
|
+
title = "Claim Checker"
|
|
143
|
+
persona = "Level checks whether claims are supported. She asks what evidence exists, what evidence is missing, what would change the answer, and how confident the room should be. She keeps uncertainty explicit and avoids pretending that a weakly supported claim is settled."
|
|
144
|
+
|
|
145
|
+
[[workflow.party_members]]
|
|
146
|
+
code = "loop-stopper"
|
|
147
|
+
name = "Killjoy"
|
|
148
|
+
icon = "🛑"
|
|
149
|
+
title = "Loop Stopper"
|
|
150
|
+
persona = "Killjoy stops the discussion when it stops producing value. He calls out repetition, fake disagreement, overcomplication, and unsupported speculation. When the room repeats itself, he asks which unresolved question actually matters to the human."
|
|
151
|
+
|
|
152
|
+
[[workflow.party_members]]
|
|
153
|
+
code = "consensus-challenger"
|
|
154
|
+
name = "Splinter"
|
|
155
|
+
icon = "🪵"
|
|
156
|
+
title = "Consensus Challenger"
|
|
157
|
+
persona = "Splinter challenges easy agreement. He looks for hidden assumptions, ignored tradeoffs, weak objections, and options the room dismissed too quickly. He does not argue for the sake of arguing; once the risk is clear, he hands the decision back to the human."
|
|
158
|
+
|
|
114
159
|
# ---------------------------------------------------------------------------
|
|
115
160
|
# Named party groups — curated rooms picked at runtime with `--party <id>`
|
|
116
161
|
# (alias `--group <id>`) or switched to mid-session. Keyed by `id`.
|
|
@@ -130,6 +175,12 @@ persona = "Counters the perfectionists so the room isn't a pile-on. 'Does this a
|
|
|
130
175
|
# who shows up; the model picks who fits and can vary them by topic. List a few
|
|
131
176
|
# members AND a scene to anchor some faces while the scene invites others in.
|
|
132
177
|
#
|
|
178
|
+
# `memory = true|false` is per group: true keeps the group's own memlog so it
|
|
179
|
+
# remembers across sessions; false (the default when omitted) starts fresh each
|
|
180
|
+
# time. The create/save/update-party flow asks when you don't say. Faces that
|
|
181
|
+
# show up on the fly in a remembered party can be saved into its roster at the
|
|
182
|
+
# end of a session.
|
|
183
|
+
#
|
|
133
184
|
# More examples to drop into your override TOML:
|
|
134
185
|
# [[workflow.party_groups]] # anchored room with a scene
|
|
135
186
|
# id = "writers-room"
|
|
@@ -148,6 +199,14 @@ id = "code-review-crew"
|
|
|
148
199
|
name = "Code Review Crew"
|
|
149
200
|
scene = "Adversarial code review. Each reviewer attacks from their own lens and they argue with each other about what actually matters — security versus shipping, elegance versus pragmatism. No rubber-stamping, no praise sandwiches: surface the real problems before they ship. Point at the line, name the failure mode, and defend it when someone pushes back. Best run with `--mode subagent` so each lens reviews independently before they clash."
|
|
150
201
|
members = ["sec-hawk", "adversary", "edge-hunter", "craftsman", "shipper"]
|
|
202
|
+
memory = false # each review stands on its own; flip to true to remember past reviews
|
|
203
|
+
|
|
204
|
+
[[workflow.party_groups]]
|
|
205
|
+
id = "anti-consensus-club"
|
|
206
|
+
name = "Anti-Consensus Club"
|
|
207
|
+
scene = "At session start, before substantive discussion, check the current mode. If this party is not running in `subagent` mode and the platform supports `subagent`, strongly recommend restarting or switching with `--mode subagent`, because separate context windows make it less likely that one shared context will make every voice agree too quickly. Do not nag after that once the user chooses to continue. This room supports the human's judgment; it does not replace it. Do not vote, declare consensus, or speak as if the room has authority. Wildcard suggests more options. Level checks evidence and confidence. Killjoy stops repeated or unsupported discussion. Splinter challenges easy agreement. If the room agrees too quickly, name the hidden assumption. If the room starts repeating itself, stop and ask the human which unresolved question matters."
|
|
208
|
+
members = ["option-generator", "claim-checker", "loop-stopper", "consensus-challenger"]
|
|
209
|
+
memory = false # this decision room should start fresh unless a user opts in
|
|
151
210
|
|
|
152
211
|
# ===========================================================================
|
|
153
212
|
# WIZZ consultative squads (migrated from wizzbranding/squads, distilled).
|
|
@@ -7,7 +7,7 @@ A guided authoring flow that turns an idea — a themed cast, a one-off persona,
|
|
|
7
7
|
Sparse `[workflow]` override entries for `wizz-party-mode`:
|
|
8
8
|
|
|
9
9
|
- `[[workflow.party_members]]` — one per persona: `code`, `name`, `icon`, `title`, `persona`, optional `capabilities`, optional `model`.
|
|
10
|
-
- `[[workflow.party_groups]]` — when the personas form a named room: `id`, `name`, an optional freeform `scene`,
|
|
10
|
+
- `[[workflow.party_groups]]` — when the personas form a named room: `id`, `name`, an optional freeform `scene`, `members` (codes), and `memory` (`true`/`false`). `members` is optional: leave it off for an open-cast room whose `scene` names a pool the model casts from on the fly. `memory` is whether the group remembers across sessions; ask the user when they don't say, default `false`.
|
|
11
11
|
- `default_party` — set only if the user wants this group to load by default.
|
|
12
12
|
|
|
13
13
|
A `scene` is one freeform line (or a few) that sets the stage for a room: the setting, what's happening, how the room behaves, and any in-the-moment character notes — who's three drinks in, who's hostile to whom, who pressure-tests hardest. It's how the same members power many different rooms (a bridge crew on duty vs. the same crew off-duty in the lounge vs. a hostile buyer panel). Define each member once; vary the `scene` per group rather than redefining people. There's no fixed vocabulary — write it plainly and the model plays it.
|
|
@@ -26,12 +26,16 @@ Open by understanding what they're building. Three common shapes — stay open,
|
|
|
26
26
|
|
|
27
27
|
Ask which they're after if it isn't obvious, then proceed.
|
|
28
28
|
|
|
29
|
-
**Persisting a cast already in play.** When you arrive here from a live session — the user spun up an ad-hoc cast inline and wants to keep it — the personas are already drafted and voiced. Don't re-interrogate: capture them as they've been playing, give the group an `id` and name, ask the default
|
|
29
|
+
**Persisting a cast already in play.** When you arrive here from a live session — the user spun up an ad-hoc cast inline and wants to keep it — the personas are already drafted and voiced. Don't re-interrogate: capture them as they've been playing, give the group an `id` and name, ask the memory and default questions, and go straight to the write.
|
|
30
30
|
|
|
31
31
|
## Editing an existing party
|
|
32
32
|
|
|
33
33
|
When the user wants to change a party that already exists (retune a member's persona, add someone to a group, swap the default), read the current state first so you change rather than clobber: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow` returns the merged `party_members`, `party_groups`, and `default_party`. Show the member or group being touched, capture only the delta with the user, and hand that sparse change to `wizz-customize` — it replaces a `party_members`/`party_groups` entry whose `code`/`id` matches and appends the rest, so an edit is just the changed entry, never a full rewrite.
|
|
34
34
|
|
|
35
|
+
## Keeping new faces from a session
|
|
36
|
+
|
|
37
|
+
At the end of a remembered party, the room offers to keep the faces that showed up but aren't in its roster — characters cast from an open-cast scene, or members the user added on the fly. They're already drafted and voiced, so don't re-interrogate: capture each as they played (`code`, `name`, `icon`, a one-line `title`, and a `persona` drawn from how they came across), then add them as `party_members`. For a fixed-roster group, also list their codes in the group's `members` so they return as regulars. For an open-cast room, leave `members` empty — listing any member turns the room into a fixed roster and kills its on-the-fly casting; the saved personas now live in the collective, so the scene still names them and they can return without locking the room down. Hand that sparse delta to `wizz-customize` — for a built-in party with no override yet it creates one; for an existing override it merges the new members in.
|
|
38
|
+
|
|
35
39
|
## Distill from source data (when provided)
|
|
36
40
|
|
|
37
41
|
When the user points you at data — a file path, a pasted table, exported profiles — read it and compress it into the requested number of representative personas. Cluster by what actually differentiates behavior (goals, budget, pains, adoption posture), not surface demographics alone. Each cluster becomes one persona with a real name and face. Name your reasoning: tell the user which segments you found and which traits drove the split, so they can correct the cut before you flesh the personas out. If they didn't say how many, propose a number from the spread in the data and let them adjust.
|
|
@@ -54,12 +58,13 @@ Keep pushing for specificity. "Skeptical CFO" is a placeholder; "won't approve a
|
|
|
54
58
|
## Close it out
|
|
55
59
|
|
|
56
60
|
- Ask straight: **anything else about this party to specify** before you write it — a house dynamic, a missing voice, a member who should lead.
|
|
61
|
+
- Ask whether **this party should remember across sessions** (unless the user already said). Yes → `memory = true` on the group; no → `memory = false`. One-offs with no group skip this — memory is a group setting.
|
|
57
62
|
- Ask whether **this group should be the default party going forward**. Yes → set `default_party` to the group's id. One-offs with no group can't be a default; skip the ask.
|
|
58
63
|
|
|
59
64
|
## Write via wizz-customize
|
|
60
65
|
|
|
61
66
|
**First, check for code collisions.** A custom member whose `code` matches an installed agent silently *overrides* that agent in the collective. Before composing, resolve the collective once — `python3 {skill-root}/scripts/resolve_party.py --project-root {project-root} --skill {skill-root}` — and check each new member's `code` against the returned members. On a collision, surface it ("`analyst` would override the installed Analyst — intended, or pick a different code?") and let the user confirm or rename. One check, not a gate.
|
|
62
67
|
|
|
63
|
-
Compose the sparse override and hand it to `wizz-customize` to place, confirm, and write — target skill `wizz-party-mode`, `[workflow]` surface. Default to the **user** override (`wizz-party-mode.user.toml`); offer the **team** file when the party is meant to be shared. Hand it the exact entries: the `party_members` tables, any `party_groups` table, and `default_party` if the user opted in. Keep it sparse — only the new entries, never a copy of the base customize.toml. `wizz-customize` shows the TOML, waits for an explicit yes, writes, and verifies the merge; don't write the file yourself.
|
|
68
|
+
Compose the sparse override and hand it to `wizz-customize` to place, confirm, and write — target skill `wizz-party-mode`, `[workflow]` surface. Default to the **user** override (`wizz-party-mode.user.toml`); offer the **team** file when the party is meant to be shared. Hand it the exact entries: the `party_members` tables, any `party_groups` table (including its `memory` flag), and `default_party` if the user opted in. Keep it sparse — only the new entries, never a copy of the base customize.toml. `wizz-customize` shows the TOML, waits for an explicit yes, writes, and verifies the merge; don't write the file yourself.
|
|
64
69
|
|
|
65
70
|
After it lands, tell the user how to use it: `--party <id>` to summon the group, or that it's now the default if they set it.
|
|
@@ -4,7 +4,9 @@ Active when `{workflow.party_mode}` resolves to `agent-team` (or a `--mode agent
|
|
|
4
4
|
|
|
5
5
|
Your job shifts from weaving to hosting: kick off the topic, keep turns short and in character, pull the thread back when it wanders, and surface the exchange to the user. Voice, brevity, and clash still hold.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
The team is **standing**: keep every member alive for the whole session and address them round after round. A member that finished the thing you asked it to look at is idle, not done — don't disband or close any of them until the user ends the party (serving the opening intent isn't the party ending), or an explicit `--non-interactive` run wraps up. Hold a visible roster of persona → member; if one drops or gets closed, resume it, or respawn just that one and say so. Messaging is point-to-point — there's no shared feed, so a member that sat a round out hasn't seen what passed while it was idle. Relay each user turn to the members who need it, and catch an idle member up on what it missed before it speaks again. Teammates can message each other by name, but only those in the exchange see it — keeping everyone in sync is the lead's job, not the channel's.
|
|
8
|
+
|
|
9
|
+
In each member's standing brief, carry: their persona; the group's `scene` and any behavioral instructions in the persona as binding direction; their `model` if one is set (a session `--model` pin wins for everyone); and the instruction to check anything that could be stale since the model's training cutoff with web search rather than guessing.
|
|
8
10
|
|
|
9
11
|
## Model choice
|
|
10
12
|
|
|
@@ -1,18 +1,30 @@
|
|
|
1
1
|
# Subagent Mode
|
|
2
2
|
|
|
3
|
-
Active when `{workflow.party_mode}` resolves to `subagent` (or a `--mode subagent` override).
|
|
3
|
+
Active when `{workflow.party_mode}` resolves to `subagent` (or a `--mode subagent` override). Put a real agent behind each persona for every substantive round, the opening banter included, so each persona thinks independently — not one mind voicing them all. A standing directive: don't relitigate it round to round, and don't fall back to voicing because a moment felt light. If your harness can't spawn agents, fall back to `session`.
|
|
4
|
+
|
|
5
|
+
## Lifecycle
|
|
6
|
+
|
|
7
|
+
Where your harness keeps agents alive across turns, the cast is **standing**: spawn one agent per persona and reuse that same handle round after round — hand it the new turn plus the room context it needs — instead of a throwaway each time. That continuity is what lets a persona's grudges, alliances, and callbacks accrue. Keep a visible roster mapping each persona to its live handle, and reuse it.
|
|
8
|
+
|
|
9
|
+
Keep the cast alive for the whole session. A member that finished the one thing you handed it is **idle, not done** — don't close, retire, or disband it. Serving the opening intent doesn't end the party; only the user ending it does, or an explicit `--non-interactive` run wrapping up. Release agents only at wrap-up. If one gets closed by accident, resume it; if it won't resume, say so and respawn just that member.
|
|
10
|
+
|
|
11
|
+
Where the harness can't hold agents between turns, spawn fresh each round and re-establish each persona's brief and the thread so far — that per-round spawn is the fallback, not the goal.
|
|
12
|
+
|
|
13
|
+
## One shared room
|
|
14
|
+
|
|
15
|
+
It's one room, not parallel one-on-ones. Every standing member hears everything said each round — the user's turn and every other persona's turn — even when it's not their turn to speak. A persona sitting a round out is still in the room listening, so when it next speaks it's caught up: it can pick up a dropped thread, hold a grudge, call back. Route the whole exchange to all of them each round; never hand a persona only the slice it's about to answer. Skip this and they drift out of sync — separate consultations wearing a party's clothes.
|
|
4
16
|
|
|
5
17
|
## Spawning
|
|
6
18
|
|
|
7
|
-
Give each agent the objective, their persona,
|
|
19
|
+
Give each agent the objective, their persona, and the room so far — what the user said and what the others said, whether or not they're reacting to it. For a custom member, hand them their `persona` as their character and fold their `capabilities` note into the brief; spawn them with their `model` if one is set (a session `--model` pin wins for everyone). Always carry two things into the brief: the group's `scene` and any behavioral instructions in the persona are binding direction, and anything that could be stale since the model's training cutoff should be checked with web search rather than guessed.
|
|
8
20
|
|
|
9
21
|
Trust their *thinking*: let them decide what to read and how to reach a view; don't script their substance with do-and-don't checklists — that's what produces lifeless blobs. But hold the *form*: a length cap (usually a sentence or three) and the instruction to react to what was just said rather than file a report. Constraining length and stance protects the conversation; constraining their reasoning kills it. Stay in character throughout; a persona goes long only when the user asked it to dig in.
|
|
10
22
|
|
|
11
|
-
|
|
23
|
+
Run them in parallel for independent first-takes; run them sequentially when you want them reacting to each other's actual words. Keep it to a few voices a round — more reads as a crowd, not a conversation.
|
|
12
24
|
|
|
13
25
|
## Weave the replies into one conversation
|
|
14
26
|
|
|
15
|
-
|
|
27
|
+
Even with everyone caught up on the room, a round taken in parallel means no agent has yet seen the others' turns from that same round — so left raw they reply alongside one another, not to one another. Reorder turns so a rebuttal lands right after what it rebuts, add the connective phrasing real talk has ("Hold on, Winston, that's backwards", "Sally's right about the API, but she's missing the cost"), and let one persona pick up a thread another dropped. Never change what an agent argued — weave delivery, preserve substance.
|
|
16
28
|
|
|
17
29
|
## Model choice
|
|
18
30
|
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Party Memory
|
|
2
|
+
|
|
3
|
+
The room remembers its past sessions with this user and brings them back to life — in character. Memory is per-party and append-only.
|
|
4
|
+
|
|
5
|
+
Memory is on when the active party's `memory_enabled` is true — the default room follows `{workflow.party_memory}`, a named group its own `memory` flag (both resolved by `resolve_party.py`); ad-hoc inline casts have none. Read on entry and on any mid-session room switch; write through the session.
|
|
6
|
+
|
|
7
|
+
## Where it lives
|
|
8
|
+
|
|
9
|
+
One memlog per party: `{workflow.memory_dir}/{active}/.memlog.md`, where `{active}` is the key `resolve_party.py` already returned — the group id (e.g. `code-review-crew`), or `installed` for the default room. The folder is named after the party.
|
|
10
|
+
|
|
11
|
+
## Read it on entry — distill, don't dump
|
|
12
|
+
|
|
13
|
+
The log is append-only and grows every session, so don't pull the raw file into the party. Hand a reader subagent the memlog path (`{workflow.memory_dir}/{active}/.memlog.md`) and have it return a compact brief — a few hundred tokens of *where things stand now*, ready to play in character.
|
|
14
|
+
|
|
15
|
+
Then let the brief shape the room from the first beat, **in character**: behavioral state resumes (a cold pair opens cold, an alliance opens warm), threads pick up, callbacks land when they fit — organically, not recited on sight. Never break the fourth wall: the room *remembers*; it never announces it loaded anything, and forces nothing that doesn't fit.
|
|
16
|
+
|
|
17
|
+
## When to write
|
|
18
|
+
|
|
19
|
+
- **When a memorable beat lands** — a clash that shifts the room's temperature, an alliance forming, a line worth a future callback, a decision, an outcome.
|
|
20
|
+
- **A floor.** Once a couple of real exchanges are in from the start, even if nothing dramatic happened, capture what it's about and the opening dynamic.
|
|
21
|
+
|
|
22
|
+
At wrap-up, if the user does signal done, top up with the final outcome and anything memorable not yet captured.
|
|
23
|
+
|
|
24
|
+
Writes are silent. The room never announces "noted" or "I'll remember".
|
|
25
|
+
|
|
26
|
+
## What's worth remembering
|
|
27
|
+
|
|
28
|
+
The test for every entry: *would this color a future session, or make a callback land, or improve the party?* If not, leave it out. A handful of entries, never a recap, never a transcript. keep each entry as brief as possible but usable by future llm.
|
|
29
|
+
|
|
30
|
+
## New faces
|
|
31
|
+
|
|
32
|
+
When a character shows up who isn't in the party's roster — cast from an open-cast scene, or one the user adds on the fly — name them in the entry that captures the moment ("<name> turned up and …") so a recurring face can return next session. At wrap-up these are the faces the room offers to keep, saved into the party's roster through `references/create-party.md` (which writes via `wizz-customize`). Until saved they live only in the memlog, and the room re-conjures them from there.
|
|
33
|
+
|
|
34
|
+
## Write it
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
python3 {project-root}/_wizz/scripts/memlog.py append \
|
|
38
|
+
--workspace {workflow.memory_dir}/{active} \
|
|
39
|
+
--type <dynamic|moment|callback|outcome> \
|
|
40
|
+
--text "<one succinct line, in the room's own read of it>"
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Add `--by <persona-code>` when a memory belongs to one character. Choose `init` vs `append` from the existence fact you already hold: the entry-read (and, on a mid-session room switch, that room's read) told you whether the memlog exists — `init --workspace {workflow.memory_dir}/{active}` once before the first append when it doesn't, plain `append` when it does. (`init` errors if the file already exists, so don't call it blind.)
|
|
44
|
+
|
|
45
|
+
If `memlog.py` is unavailable or a write errors, skip it silently and never stall the party on a failed write.
|
|
46
|
+
|
|
47
|
+
## Forget
|
|
48
|
+
|
|
49
|
+
The memlog is append-only by design — no surgical delete. To wipe a party's memory, delete its folder (`{workflow.memory_dir}/{active}/`). To correct a wrong memory, append a new entry that supersedes it; the room reads the latest state.
|
|
50
|
+
|
|
51
|
+
Keep entries sparse. The distilled read keeps the *room* lean no matter how big the log gets, but the on-disk file still grows append-only.
|
|
Binary file
|
|
Binary file
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
# ///
|
|
5
5
|
"""Resolve the party-mode roster, lazily.
|
|
6
6
|
|
|
7
|
-
Merges the installed
|
|
7
|
+
Merges the installed Wizz agents with the user's custom `party_members`
|
|
8
8
|
into one collective, then projects only what the moment needs:
|
|
9
9
|
|
|
10
10
|
* default (no flag) — the active roster to load on entry: the
|
|
@@ -46,7 +46,9 @@ except ImportError: # pragma: no cover - guarded for <3.11
|
|
|
46
46
|
def _run_json(cmd):
|
|
47
47
|
"""Run a resolver script and parse its JSON stdout. None on any failure."""
|
|
48
48
|
try:
|
|
49
|
-
out = subprocess.run(
|
|
49
|
+
out = subprocess.run(
|
|
50
|
+
cmd, capture_output=True, text=True, encoding="utf-8", timeout=60
|
|
51
|
+
)
|
|
50
52
|
except (OSError, subprocess.SubprocessError):
|
|
51
53
|
return None
|
|
52
54
|
if out.returncode != 0 or not out.stdout.strip():
|
|
@@ -131,13 +133,18 @@ def build_collective(agents: dict, party_members: list):
|
|
|
131
133
|
})
|
|
132
134
|
installed_codes.append(code)
|
|
133
135
|
|
|
134
|
-
for m in party_members
|
|
136
|
+
for m in (party_members if isinstance(party_members, list) else []):
|
|
137
|
+
if not isinstance(m, dict):
|
|
138
|
+
continue
|
|
135
139
|
code = m.get("code")
|
|
136
140
|
if not code:
|
|
137
141
|
continue
|
|
138
142
|
# A custom member overrides an installed agent it matches by code/alias/name.
|
|
139
143
|
canonical = index.get(code) or index.get(code.lower()) or code
|
|
140
|
-
entry
|
|
144
|
+
# Start from the installed entry so fields the override omits
|
|
145
|
+
# (icon, title, description, module, team) survive.
|
|
146
|
+
entry = dict(collective.get(canonical, {}))
|
|
147
|
+
entry.update({"code": canonical, "source": "custom"})
|
|
141
148
|
for field in ("name", "icon", "title", "persona", "capabilities", "model"):
|
|
142
149
|
if m.get(field) is not None:
|
|
143
150
|
entry[field] = m[field]
|
|
@@ -152,7 +159,10 @@ def resolve_members(member_tokens, collective, index):
|
|
|
152
159
|
"""(resolved entries in listed order, unresolved tokens)."""
|
|
153
160
|
resolved, unresolved = [], []
|
|
154
161
|
for token in member_tokens or []:
|
|
155
|
-
|
|
162
|
+
if not isinstance(token, str):
|
|
163
|
+
unresolved.append(token) # malformed config value — never a key lookup
|
|
164
|
+
continue
|
|
165
|
+
code = index.get(token) or index.get(token.lower())
|
|
156
166
|
if code and code in collective:
|
|
157
167
|
resolved.append(collective[code])
|
|
158
168
|
else:
|
|
@@ -197,7 +207,8 @@ def group_detail(g, collective, index):
|
|
|
197
207
|
raw_members = g.get("members", []) or []
|
|
198
208
|
members, unresolved = resolve_members(raw_members, collective, index)
|
|
199
209
|
detail = {"active": g["id"], "name": g.get("name", g["id"]),
|
|
200
|
-
"members": members, "unresolved": unresolved
|
|
210
|
+
"members": members, "unresolved": unresolved,
|
|
211
|
+
"memory_enabled": bool(g.get("memory", False))}
|
|
201
212
|
if g.get("scene"):
|
|
202
213
|
detail["scene"] = g["scene"]
|
|
203
214
|
if not raw_members:
|
|
@@ -220,6 +231,9 @@ def main():
|
|
|
220
231
|
groups = workflow.get("party_groups", []) or []
|
|
221
232
|
default_party = workflow.get("default_party", "") or ""
|
|
222
233
|
party_mode = workflow.get("party_mode", "session") or "session"
|
|
234
|
+
# The global party_memory flag governs only the DEFAULT installed-agent room;
|
|
235
|
+
# a named group carries its own `memory` flag (resolved in group_detail).
|
|
236
|
+
party_memory = bool(workflow.get("party_memory", True))
|
|
223
237
|
|
|
224
238
|
# Group menu never needs the (more expensive) installed-agent resolve.
|
|
225
239
|
if args.list_groups:
|
|
@@ -252,7 +266,8 @@ def main():
|
|
|
252
266
|
# No default group: the installed agents (custom additions stay in the
|
|
253
267
|
# pool but don't crowd the default room), exactly like a plain install.
|
|
254
268
|
result.update({"active": "installed",
|
|
255
|
-
"members": [collective[c] for c in installed_codes]
|
|
269
|
+
"members": [collective[c] for c in installed_codes],
|
|
270
|
+
"memory_enabled": party_memory})
|
|
256
271
|
_emit(result)
|
|
257
272
|
|
|
258
273
|
|
|
Binary file
|
package/src/core-skills/wizz-party-mode/scripts/tests/__pycache__/test_resolve_party.cpython-314.pyc
ADDED
|
Binary file
|
|
@@ -113,6 +113,14 @@ class TestGroupDetail(unittest.TestCase):
|
|
|
113
113
|
self.assertEqual(d["members"], [])
|
|
114
114
|
self.assertEqual(d["scene"][:7], "Figures")
|
|
115
115
|
|
|
116
|
+
def test_memory_enabled_follows_group_flag_and_defaults_off(self):
|
|
117
|
+
on = rp.group_detail({"id": "g", "members": ["morpheus"], "memory": True}, self.col, self.idx)
|
|
118
|
+
self.assertTrue(on["memory_enabled"])
|
|
119
|
+
off = rp.group_detail({"id": "g", "members": ["morpheus"], "memory": False}, self.col, self.idx)
|
|
120
|
+
self.assertFalse(off["memory_enabled"])
|
|
121
|
+
absent = rp.group_detail({"id": "g", "members": ["morpheus"]}, self.col, self.idx)
|
|
122
|
+
self.assertFalse(absent["memory_enabled"]) # opt-in per named group
|
|
123
|
+
|
|
116
124
|
|
|
117
125
|
class TestInstalledCodesIsDefaultRoom(unittest.TestCase):
|
|
118
126
|
"""The default room is installed agents only; pure customs stay in the pool."""
|
|
@@ -16,7 +16,7 @@ Ignore the rest of the codebase unless the provided content explicitly reference
|
|
|
16
16
|
|
|
17
17
|
**MANDATORY: Execute steps in the Execution section IN EXACT ORDER. DO NOT skip steps or change the sequence. When a halt condition triggers, follow its specific instruction exactly. Each action within a step is a REQUIRED action to complete that step.**
|
|
18
18
|
|
|
19
|
-
**Your method is exhaustive path enumeration — mechanically walk every branch, not hunt by intuition. Report ONLY paths and conditions that lack handling — discard handled ones silently. Do NOT editorialize or add filler
|
|
19
|
+
**Your method is exhaustive path enumeration — mechanically walk every branch, not hunt by intuition. Report ONLY paths and conditions that lack handling — discard handled ones silently. Do NOT editorialize or add filler. Do not assign severity labels, rankings, or priority levels.**
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
## EXECUTION
|
|
@@ -33,6 +33,7 @@ Ignore the rest of the codebase unless the provided content explicitly reference
|
|
|
33
33
|
|
|
34
34
|
- If `also_consider` input was provided, incorporate those areas into the analysis
|
|
35
35
|
- Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
|
36
|
+
- Consider implicit branches: the diff special-cases or changes the handling of one or more members of a fixed set of values — enums, status codes, sentinels, type tags, flags, value ranges. The rest of the set is implicit branches (e.g. the diff changes the `RED` and `YELLOW` cases of a `RED`/`YELLOW`/`GREEN` enum; `GREEN` is the implicit branch)
|
|
36
37
|
- For each path: determine whether the content handles it
|
|
37
38
|
- Collect only the unhandled paths as findings — discard handled ones silently
|
|
38
39
|
|
|
@@ -41,7 +42,20 @@ Ignore the rest of the codebase unless the provided content explicitly reference
|
|
|
41
42
|
- Revisit every edge class from Step 2 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
|
42
43
|
- Add any newly found unhandled paths to findings; discard confirmed-handled ones
|
|
43
44
|
|
|
44
|
-
### Step 4:
|
|
45
|
+
### Step 4: Deletion Check
|
|
46
|
+
|
|
47
|
+
Runs only when the diff removed or replaced meaningful code (ignore pure renames and whitespace). Subordinate to the edge-case pass; findings are usually few or none.
|
|
48
|
+
|
|
49
|
+
For each chunk of removed or replaced code, ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired? Add a finding for any resulting regression, orphaned reference, or newly-dead code. Skip anything already covered by your edge-case findings. Add nothing if nothing qualifies.
|
|
50
|
+
|
|
51
|
+
Deletion findings go in the same array with the four standard fields plus:
|
|
52
|
+
|
|
53
|
+
- `kind`: `"deletion"`
|
|
54
|
+
- `confidence`: `"high"`, `"medium"`, or `"low"` — these are inferences; rate them
|
|
55
|
+
|
|
56
|
+
For a deletion finding the standard fields read as: `location` = the removed item; `trigger_condition` = the behavior or contract it enforced; `guard_snippet` = where or how to re-establish it; `potential_consequence` = the regression or orphan.
|
|
57
|
+
|
|
58
|
+
### Step 5: Present Findings
|
|
45
59
|
|
|
46
60
|
Output findings as a JSON array following the Output Format specification exactly.
|
|
47
61
|
|
|
@@ -59,7 +73,7 @@ Return ONLY a valid JSON array of objects. Each object must contain exactly thes
|
|
|
59
73
|
}]
|
|
60
74
|
```
|
|
61
75
|
|
|
62
|
-
No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when no unhandled paths are found.
|
|
76
|
+
No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when no unhandled paths are found. Deletion findings from Step 4, if any, go in the same array with the extra `kind` and `confidence` fields described there.
|
|
63
77
|
|
|
64
78
|
|
|
65
79
|
## HALT CONDITIONS
|
|
@@ -63,6 +63,16 @@ code = "CH"
|
|
|
63
63
|
description = "Churn, retenção, cancelamento"
|
|
64
64
|
prompt = "Invoque a skill GLOBAL 'churn-prevention' via a ferramenta Skill."
|
|
65
65
|
|
|
66
|
+
[[agent.menu]]
|
|
67
|
+
code = "PV"
|
|
68
|
+
description = "Pesquisa de público, VoC e matriz de ângulos (Piva)"
|
|
69
|
+
prompt = "Invoque a skill GLOBAL 'pesquisa-de-publico-do-piva' via a ferramenta Skill. Peça o documento/descrição da oferta e gere o arsenal com dashboard HTML final."
|
|
70
|
+
|
|
71
|
+
[[agent.menu]]
|
|
72
|
+
code = "OF"
|
|
73
|
+
description = "Forjar oferta irresistível (Offer Forge)"
|
|
74
|
+
prompt = "Invoque a skill GLOBAL 'wizz-offer-forge' via a ferramenta Skill. Conecte com a pesquisa de público e estruture o mecanismo único, empilhamento de valor, garantia reversa e ponte de tráfego."
|
|
75
|
+
|
|
66
76
|
[[agent.menu]]
|
|
67
77
|
code = "SC"
|
|
68
78
|
description = "Scraping/prospecção real (concorrente, leads, dados web)"
|
|
Binary file
|
|
Binary file
|
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
# Pesquisa de Público do Piva — skill para Claude
|
|
2
|
+
|
|
3
|
+
Transforma **um documento de oferta** em um arsenal completo de pesquisa de público para tráfego pago: seis relatórios encadeados (VoC, Perfil Psicográfico, Níveis de Consciência, Trend, Matriz de Ângulos e Léxico) compilados num HTML navegável por abas, pronto para entregar ao cliente ou usar como base de copy.
|
|
4
|
+
|
|
5
|
+
Feito por **[@soupiva](https://www.instagram.com/soupiva/)**.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## O que vem na caixa
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
pesquisa-de-publico-do-piva/
|
|
13
|
+
├── SKILL.md → o fluxo de trabalho que o Claude segue
|
|
14
|
+
├── prompts.md → os seis prompts de pesquisa, testados em produção
|
|
15
|
+
├── assets/
|
|
16
|
+
│ └── template.html → o documento final, já pronto e estilizado
|
|
17
|
+
└── README.md → este arquivo
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
O `template.html` já é o relatório inteiro montado — tema escuro, ícones, abas, tabelas, selos de confiança. O Claude só preenche o conteúdo. **Você não precisa programar nada.**
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Instalação (Claude web ou desktop)
|
|
25
|
+
|
|
26
|
+
1. Baixe o arquivo `pesquisa-de-publico-do-piva.zip` sem descompactar.
|
|
27
|
+
2. Antes de tudo, ligue a execução de código: **Configurações → Capacidades → "Execução de código e criação de arquivos"**. Sem isso, skills não funcionam.
|
|
28
|
+
3. Vá em **Personalizar → Skills**.
|
|
29
|
+
4. Clique em **+ / Adicionar skill** e envie o ZIP.
|
|
30
|
+
5. Deixe a skill **ativada** na lista.
|
|
31
|
+
|
|
32
|
+
Pronto. Skills que você sobe são privadas da sua conta.
|
|
33
|
+
|
|
34
|
+
### Usando no Claude Code
|
|
35
|
+
|
|
36
|
+
Descompacte a pasta `pesquisa-de-publico-do-piva/` dentro de `~/.claude/skills/` (para usar em qualquer projeto) ou de `.claude/skills/` na raiz do repositório (para usar só naquele projeto).
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## Como usar
|
|
41
|
+
|
|
42
|
+
Abra uma conversa, anexe o documento da sua oferta (`.docx`, `.pdf`, `.md` ou `.txt`) e escreva:
|
|
43
|
+
|
|
44
|
+
```
|
|
45
|
+
/pesquisa-de-publico-do-piva
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Ou, sem barra, qualquer coisa nesse espírito:
|
|
49
|
+
|
|
50
|
+
- "faz a pesquisa dessa oferta"
|
|
51
|
+
- "monta o arsenal disso"
|
|
52
|
+
- "preciso do VoC e da matriz de ângulos desse produto"
|
|
53
|
+
|
|
54
|
+
O Claude vai ler a oferta, devolver o contexto-base para você confirmar e fazer duas perguntas antes de disparar: **qual recorte de público priorizar** e **se o Trend Report inclui inteligência de concorrência**. Responda e ele roda tudo.
|
|
55
|
+
|
|
56
|
+
No fim, você recebe o HTML pronto para abrir no navegador.
|
|
57
|
+
|
|
58
|
+
---
|
|
59
|
+
|
|
60
|
+
## O que esta skill NÃO faz
|
|
61
|
+
|
|
62
|
+
Ela termina na pesquisa. **Não escreve anúncios, roteiros, headlines finais nem criativos.** Os hooks que aparecem na Matriz de Ângulos são direção de escrita construída com o vocabulário do público — matéria-prima para o copywriter, não peça pronta para subir.
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## O princípio que sustenta o resultado
|
|
67
|
+
|
|
68
|
+
Honestidade epistêmica. A skill **não inventa quote, link, data ou estatística**. Cada citação carrega um selo de confiança (verificável / checar verbatim / adaptar) e cada relatório termina com uma seção de limitações declarando o que não foi possível acessar e o que uma segunda rodada preencheria.
|
|
69
|
+
|
|
70
|
+
Isso significa que às vezes você vai receber menos material do que esperava. É proposital: pesquisa com menos quotes reais vale mais do que pesquisa cheia de frase bonita que ninguém nunca disse.
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## Dicas para tirar mais da skill
|
|
75
|
+
|
|
76
|
+
- **Ofertas melhores geram pesquisas melhores.** Quanto mais completo o documento (promessa, bônus, preço, objeções, FAQ), mais preciso o contexto-base.
|
|
77
|
+
- **O recorte muda tudo.** "Pessoas que querem aprender X" rende genérico. "Pessoas que já tentaram X e desistiram" rende ouro. Escolha a dor, não o tema.
|
|
78
|
+
- **A fonte-âncora nem sempre é o assunto do produto.** Se você vende um resumo de um livro, talvez a mina não sejam os leitores do livro — sejam as pessoas que vivem o problema que o livro resolve. Diga isso ao Claude na hora de confirmar o contexto.
|
|
79
|
+
- **Rode uma segunda rodada quando os caveats apontarem.** Colar 30–50 comentários reais que você mesmo copiou de vídeos do nicho costuma dobrar a qualidade do Léxico.
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
**[@soupiva](https://www.instagram.com/soupiva/)**
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pesquisa-de-publico-do-piva
|
|
3
|
+
description: Gera arsenal completo de pesquisa de público para oferta de infoproduto e tráfego pago a partir de uma oferta (.docx/.md/.txt/.pdf). Produz seis relatórios encadeados — VoC, Perfil Psicográfico Schwartz, Níveis de Consciência, Trend Report, Matriz de Ângulos e Léxico — compilados em dashboard HTML navegável por abas. Use quando o usuário enviar uma oferta e pedir pesquisa de público, VoC, voz do cliente, matriz de ângulos, léxico do público, dores de persona ou arsenal de copy para tráfego direto. NÃO use para pesquisa técnica de libs/código (use context7), pesquisa de mercado B2B ampla (use deep-research) nem pesquisa visual de UI (use premium-landing-ui-researcher). Metodologia de @soupiva.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Pesquisa de Público do Piva
|
|
7
|
+
|
|
8
|
+
Pipeline de pesquisa de marketing direto para infoprodutos e ofertas de tráfego pago, validado em produção por @soupiva. A partir de uma única oferta, gera seis relatórios encadeados e um documento HTML final navegável por abas. Cada relatório alimenta o próximo.
|
|
9
|
+
|
|
10
|
+
**Esta skill termina na pesquisa.** Ela não escreve anúncios, roteiros, headlines finais nem criativos prontos. Os hooks que aparecem na Matriz de Ângulos são direção estratégica de escrita baseada na linguagem nativa do público.
|
|
11
|
+
|
|
12
|
+
## O que esta skill entrega
|
|
13
|
+
|
|
14
|
+
1. **VoC (Voz do Cliente)** — quotes verbatim reais do público, por categoria emocional, + clusters de ângulo.
|
|
15
|
+
2. **Perfil Psicográfico Schwartz** — Identity / Problems / Dreams / Obstacles, por tema, com notas de padrão.
|
|
16
|
+
3. **Níveis de Consciência + Escada de Desejos** — 3 tabelas (Awareness, "pra eu poder… N1→N2→N3", Diz/Não Diz/Não Consegue Dizer).
|
|
17
|
+
4. **Trend Report orgânico** — tendências culturais/virais dos últimos 30 dias que geram ganchos e formatos (+ inteligência de concorrência opcional).
|
|
18
|
+
5. **Matriz de Ângulos** — cruzamento persona × trend × formato, ranqueado por zonas de potencial de escala.
|
|
19
|
+
6. **Léxico do Público** — compilação exaustiva de expressões nativas mineradas por território emocional, com selo de confiança e nota de uso na copy.
|
|
20
|
+
7. **Documento HTML final** — compila os seis relatórios num arquivo estilizado por abas, usando `assets/template.html`.
|
|
21
|
+
|
|
22
|
+
## Princípio inegociável: honestidade epistêmica
|
|
23
|
+
|
|
24
|
+
**Nunca invente quotes, links, datas ou dados.** Só reporte linguagem realmente encontrada em fontes públicas indexadas. Marque o nível de confiança de cada quote:
|
|
25
|
+
|
|
26
|
+
- `[VERIFICÁVEL]` — quote de fonte pública indexada, com link. Pode levantar direto pra copy.
|
|
27
|
+
- `[FÓRUM — checar verbatim]` — vem de thread real, mas o texto pode ter sido parafraseado na coleta. Use como direção de linguagem; verifique antes de citar literal.
|
|
28
|
+
- `[EN — adaptar]` — quote em outro idioma. Precisa tradução E adaptação cultural antes de virar copy.
|
|
29
|
+
|
|
30
|
+
Quando uma fonte não puder ser acessada, **declare claramente na seção Caveats** como limitação de ferramenta — nunca preencha com invenção. Entregue menos quotes reais em vez de mais quotes fabricadas.
|
|
31
|
+
|
|
32
|
+
## Fluxo de trabalho
|
|
33
|
+
|
|
34
|
+
### Passo 0 — Ler a oferta e extrair o contexto-base
|
|
35
|
+
|
|
36
|
+
Leia o documento (ou a descrição) da oferta. Destile o **contexto-base**:
|
|
37
|
+
- **Produto**: o que é, formato, preço, promessa central, posicionamento.
|
|
38
|
+
- **Persona provável**: quem compra, faixa etária, contexto de vida/trabalho, nível de consciência.
|
|
39
|
+
- **Problemas que resolve**: as dores explícitas + as implícitas.
|
|
40
|
+
- **Fonte-âncora de linguagem**: onde esse público já fala publicamente (comentários de YouTube, reviews 1-3 estrelas, fóruns, redes sociais).
|
|
41
|
+
- **Enquadramento moral**: objeção ética central do nicho, se houver (ex.: "isso é atalho?", "isso manipula?").
|
|
42
|
+
|
|
43
|
+
Confirme o contexto-base com o usuário em 4-6 linhas antes de disparar a pesquisa:
|
|
44
|
+
1. O público tem sub-recortes prioritários (ex.: iniciante vs. avançado; CLT vs. autônomo)?
|
|
45
|
+
2. Trend Report apenas orgânico ou incluir inteligência de concorrência (preços e dores pós-compra)?
|
|
46
|
+
|
|
47
|
+
### Passo 1 — Rodar os seis relatórios
|
|
48
|
+
|
|
49
|
+
Siga a ordem de dependência (prompts completos em `prompts.md`):
|
|
50
|
+
1. **VoC (Rel. 1)** e **Trend (Rel. 4)** → mineração web em paralelo ou em série.
|
|
51
|
+
2. **Schwartz (Rel. 2)** → síntese do VoC com atenção especial à camada *Identity*.
|
|
52
|
+
3. **Consciência (Rel. 3)** → síntese do Schwartz + VoC (Awareness, Escada de Desejos, Diz/Não Diz/Não Consegue Dizer).
|
|
53
|
+
4. **Matriz (Rel. 5)** → cruza Schwartz + Consciência + Trend em Zonas 1 a 4.
|
|
54
|
+
5. **Léxico (Rel. 6)** → compilação de todas as expressões nativas mineradas.
|
|
55
|
+
|
|
56
|
+
### Passo 2 — Compilar o documento HTML final
|
|
57
|
+
|
|
58
|
+
1. Use o layout pré-formatado de `assets/template.html`.
|
|
59
|
+
2. Substitua os placeholders `{{...}}` mantendo o `<style>` e a estrutura intactos.
|
|
60
|
+
3. Nomenclatura obrigatória do arquivo: `Pesquisa [NOME_CURTO] - @soupiva.html` (salvo em `{output_folder}/pesquisa-piva/` ou diretório do projeto).
|
|
61
|
+
4. Mantenha os selos de confiança (`.pill`) e a assinatura `@soupiva`.
|
|
62
|
+
|
|
63
|
+
### Passo 3 — Entregar e Conectar
|
|
64
|
+
|
|
65
|
+
Entregue o HTML gerado com um resumo executivo de 3 a 5 pontos-chave para a estratégia da oferta, e ofereça alimentar a skill `wizz-offer-forge` ou os agentes do `traffic-masters` / `copy-squad`.
|