| name | deepretaste |
| description | Detect product intent, run SOTA-2026 deepresearch with a capacity-bound parallel or hive budget, define ICPs, and bootstrap or propose/apply taste.md, taste.vision, and ICP artifacts. Use when the user invokes /deepretaste or asks to retaste a product from intent and customer research. |
| argument-hint | ["product/context",{"mode":"research|bootstrap|proposal|apply"}] |
| disable-model-invocation | true |
/deepretaste
Run the intent-to-ICP-to-taste workflow for:
$ARGUMENTS
/deepretaste is the high-governance entrypoint for turning an early product
idea or existing repo into a customer-aligned operating kernel.
It is not an independent write path around /defineicp. It orchestrates:
/deepresearch for current and stable evidence
/hive only when role-based judgment, blackboard state, dissent, and
synthesis improve the result
/tastebootstrap when taste.md or taste.vision are missing
/defineicp for existing-kernel ICP-to-taste proposal or apply semantics
/deepresearch remains the general-purpose research engine for architecture,
debugging, benchmarks, provider behavior, market work, product strategy, and
other non-taste investigations. /deepretaste uses /deepresearch only when
the research is feeding intent, ICP, or taste-kernel decisions.
For bootstrap or apply modes that mutate files, /opusworkflow is the default
outer route and /deepretaste is the inner contract. Direct /deepretaste
invocation remains valid, but it must inherit the Claude/Opus planner-reviewer
plus MiniMax-M2.7-highspeed executor policy before mutation.
outer_route: opusworkflow
inner_contract: deepretaste
Non-Negotiable Contract
- Do not read
.env, .env.*, .claude/*.local.json, secrets/**,
credential files, private customer memory seeds, production logs, private
connector exports, or raw external report bodies unless the user explicitly
approves the exact source.
- Do not claim "SOTA 2026", "state of the art", "best current practice", or
"research-backed" unless the claim is backed by a current source ledger or is
labeled as a stable foundation.
- Use the current
minmaxing temporal anchor injected by hooks, or run
bash scripts/time-anchor.sh text, before any SOTA 2026, current market,
competitor, workflow, model, tooling, or benchmark claim. Record the anchor
date and live-source access dates in the evidence ledger.
- Treat
MAX_PARALLEL_AGENTS, Codex max_threads, and hardware capacity as
ceilings, not quotas. More lanes are useful only when they reduce
decision-relevant uncertainty.
- The main agent remains the supervisor. Subagent, hive, worker, or external
report summaries are claims until parent verification proves them.
- Existing
taste.md and taste.vision are protected kernel files. Do not
overwrite them from /deepretaste.
- If taste files already exist, route all taste mutation through
/defineicp
semantics: proposal-first, exact apply approval, backups, hashes,
changed-line trace, protected-kernel checklist, validation, and rollback.
- If taste files are missing, route kernel creation through
/tastebootstrap
semantics: explicit intent intake, 10 kernel questions or equivalent supplied
answers, both taste files written as a pair, ICP artifact written, and
validation.
- Block apply when product scope is ambiguous or the approved proposal does not
name the same product scope.
- Run inline
/introspect pre-plan before freezing the retaste plan,
/introspect pre-apply before file mutation, and /introspect pre-closeout
before final confidence.
Mode Selection
research: detect intent, research ICPs, list evidence gaps. No taste patch.
bootstrap: only for missing taste files. Create taste.md,
taste.vision, and ICP artifacts using /tastebootstrap semantics.
proposal: default for existing kernels. Produce ICP artifacts and taste
patch proposal using /defineicp semantics. No file mutation.
apply: only after explicit approval of an exact proposal id and product
scope. Use /defineicp apply semantics.
If mode is missing, choose:
bootstrap when either taste file is missing and product intent is explicit
enough
proposal when both taste files exist
research when product scope or intent is ambiguous
Phase 0: Intent And Kernel Gate
Read safe local truth surfaces first:
taste.md when present
taste.vision when present
SPEC.md when present
.minimaxing/state/CURRENT.md as stale-prone continuity only
README.md, product docs, package manifests, app routes, or public docs
needed to identify the product
Detect and record:
{
"product_scope": {
"scope_type": "repo|feature|vertical|distribution|unknown",
"product": "...",
"source_evidence": ["user prompt", "README.md", "..."],
"confidence": "high|medium|low",
"ambiguities": [],
"apply_allowed": false
},
"intent_detection": {
"developer_intent": "...",
"product_intent": "...",
"route_decision": "research|bootstrap|proposal|apply|blocked",
"confidence": "high|medium|low"
},
"taste_state": {
"taste_md_exists": true,
"taste_vision_exists": true,
"existing_kernel": true
}
}
apply_allowed is true only when scope confidence is high and explicit approval
names the same product scope and proposal id.
Phase 1: Route Arbitration
Use this boundary:
| Need | Route |
|---|
Missing taste.md or taste.vision | /tastebootstrap semantics via /deepretaste bootstrap |
| Existing taste plus ICP discovery or customer tailoring | /defineicp semantics via /deepretaste proposal/apply |
| One-week real usage stress test | /icpweek |
| Current architecture, debugging, benchmark, provider, market, or product research that will not mutate taste | /deepresearch |
| Role-based judgment with dissent and synthesis | /hive |
| Disjoint implementation packets | /parallel or /workflow |
/deepretaste must declare which route it is orchestrating and why. Route
confusion blocks file mutation.
Phase 2: SOTA-2026 DeepResearch Plan
Before the first search wave or synthesis, write:
## DeepRetaste Research Plan
- Product Scope:
- Taste State:
- Route Decision:
- Candidate ICPs:
- SOTA Claim Policy:
- Research Branches:
- Effective Parallel/Hive Budget:
- Source Classes:
- Stop Condition:
Compute:
effective_deepretaste_budget = min(
MAX_PARALLEL_AGENTS,
codex_max_threads,
hardware_recommended_ceiling,
distinct_research_lenses_or_hive_roles,
supervisor_synthesis_capacity,
verifier_capacity
)
Good default lenses:
Intent Scout: product category, workflow, product maturity, constraints.
ICP/JTBD Scout: primary job, urgency, buyer/user distinction, triggers.
Market/Current Practice Scout: current 2026 sources and competitor norms.
UX/Product Fit Scout: adoption friction, trust signals, experience promise.
Technical/Ops Scout: integration, data, reliability, security, support.
Skeptic: false ICP, overbroad segment, fake SOTA, kernel overwrite risk.
Use /hive only when the role map needs a visible blackboard, dissent/conflict
log, and synthesis. If using hive, the run must include queen/supervisor,
role map, blackboard claims, dissent log, synthesis, and verification evidence.
Maintain:
## Source Ledger
- Cited:
- Reviewed But Not Cited:
- Rejected / Quarantined:
- Conflicts:
## Claim Ledger
| Claim | Label | Evidence | Taste Impact |
| --- | --- | --- | --- |
Allowed labels:
current-source-backed
stable-source-backed
repo-derived
user-stated
inference
assumption
unknown
Only current-source-backed, stable-source-backed, repo-derived, or
user-stated claims may directly drive taste text. Inferences and assumptions
may drive questions, provisional wording, or blocked status only.
Phase 3: ICP Synthesis
Produce:
- Primary ICP
- Secondary ICPs only when materially distinct
- Anti-ICP / disqualified segments
- Buyer vs end user distinction
- Job-to-be-done
- Trigger events
- Pain points and desired outcomes
- Current workaround or competitor
- Buying criteria, objections, and proof needed
- Usage frequency and channel
- Technical context and implementation constraints
- Adoption risks
- What the product should optimize for
- What the product should avoid
- Missing evidence and validation questions
Reject generic persona fluff. "Developers who want better tools" is not an ICP
unless it includes a concrete job, urgency, context, trigger, constraints,
disqualifiers, and validation path.
Phase 4: Kernel Output
Fresh Bootstrap
Allowed only when taste.md or taste.vision are missing.
Use the /tastebootstrap structure and ensure:
- the 10 kernel questions are answered directly or by clear user/repo evidence
taste.md contains required frontmatter and sections
taste.vision contains required frontmatter and sections
.taste/deepretaste/{run_id}/icp.json records the ICP synthesis
- if one taste file already existed, backup it and preserve compatible content
RETASTE_BOOTSTRAPPED is returned only after validation passes
Existing-Kernel Proposal
Default when both taste files exist.
Use /defineicp proposal semantics and produce:
- ICP artifact under
.taste/deepretaste/{run_id}/icp.json
- taste patch proposal for
taste.md and taste.vision
- changed-line trace
- protected-kernel checklist
- what not to change
- rollback plan
- validation commands
Stop with:
RETASTE_PROPOSED
Apply
Allowed only when all are true:
- both taste files exist
- product scope confidence is high
- user approval names the exact proposal id
- approval names
taste.md, taste.vision, and the ICP artifact
- current file hashes match the proposal preconditions
/introspect pre-apply has no unresolved blockers
Use /defineicp apply semantics:
- Re-read both taste files.
- Create backups under
.taste/deepretaste/{run_id}/backups/.
- Record pre-change hashes.
- Write both taste files as one unit.
- Validate both files.
- Restore both from backups if validation fails.
- Record post-change hashes, commands, and rollback path.
Return RETASTE_APPLIED only when verification passes.
Artifact Contract
Every non-trivial run should write a sanitized artifact:
.taste/deepretaste/{run_id}/deepretaste-run.json
Required top-level fields:
artifact_type: "deepretaste-run"
run_id
mode
status
product_scope
intent_detection
taste_state
routing
research
parallel_decision
icp
kernel_output or taste_evolution
taste_mutation
verification
introspection
Status values:
RETASTE_RESEARCHED
RETASTE_DRAFTED_LOW_CONFIDENCE
RETASTE_PROPOSED
RETASTE_WAITING_FOR_APPLY_APPROVAL
RETASTE_BOOTSTRAPPED
RETASTE_APPLIED
RETASTE_BLOCKED
Output
## DeepRetaste Result
- Status:
- Product Scope:
- Route:
- Taste State:
- Effective parallel/hive budget:
- ICP:
- Kernel action:
- Artifacts:
- Verification:
- Confidence:
- Blockers or next approval needed:
Anti-Patterns
- Replacing
/defineicp with a second taste-mutation workflow.
- Calling generic web search "SOTA 2026 deepresearch."
- Filling every agent lane because the ceiling is 10.
- Using hive without blackboard, dissent, and verification.
- Applying taste changes from ambiguous product intent.
- Treating worker or subagent summaries as verified truth.
- Bootstrapping over an existing kernel.