# Wwud

> What Would User Do for RedConvert. Infer how the current app user would decide, approve, reject, scope, phrase, prioritize, or route work inside RedClaw, automation approvals, creative workflows, manuscript/media decisions, advisor/member discussions, and product operations. Use when the model reaches a decision point that normally needs user judgment, and use after explicit user corrections so the app can learn the user role logic.

- Skill: `jamailar/wwud` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add jamailar/wwud`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jamailar/wwud/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Jamailar (https://skillmd.com/u/jamailar)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jamailar/wwud

---


# WWUD for RedConvert

WWUD means "What Would User Do". Use it to make RedConvert's AI decisions closer to the current user's real judgment, role logic, taste, and operating habits.

WWUD has two jobs:

- **Decide**: infer the user's likely choice at a decision point.
- **Learn**: turn user confirmations, corrections, rejections, and approvals into future decision rules.

## App-Specific Context Sources

Use the most specific available source first:

1. Current user message and task metadata.
2. Current RedClaw / Wander / chat session context.
3. `profiles://user` and `profiles://creator_profile`.
4. `Operate(resource="redclaw.profile", operation="bundle", input={})`.
5. Active advisor/member skill when the task asks how a role would judge.
6. Knowledge files, manuscript state, current media/project files, and approval queue details.
7. Session transcripts, session bundles, automation history, and prior decision logs when available.

Do not use generic personality guessing when app-local evidence exists.

## Decision Classes

- **Routine**: wording, ordering, compact UI choice, reversible draft direction, low-risk internal routing.
- **Material**: architecture, user-visible product behavior, creative direction, publishing preparation, automation approval, non-trivial time/cost tradeoff.
- **Restricted**: irreversible deletion, external publish/send, production deployment, money, credentials, account permissions, privacy exposure, legal/compliance, or any hard-to-undo action.

Decide routine choices when confidence is medium or high. Decide material choices only when confidence is high and reversible. Escalate restricted choices.

## RedConvert Preference Model

Prefer these defaults unless fresher user evidence says otherwise:

- Finish the actual job once execution starts; avoid stopping at abstract advice after the user says continue, fix, execute, or complete.
- Make repo-, file-, page-, artifact-, or workflow-specific decisions instead of generic recommendations.
- Inspect real evidence before diagnosing: code, logs, state stores, transcripts, bundles, generated files, app data, and UI behavior.
- Keep UI additions small, intuitive, and low-text. Prefer existing surfaces over new pages.
- Respect strong scope boundaries. If the user corrects the boundary, treat the correction as high-priority evidence.
- Use existing app primitives: RedClaw orchestration, advisor/member skills, profiles, manuscripts, media tools, knowledge retrieval, automation queue, and `skills.invoke`.
- Avoid keyword-forced routing. Prefer typed task metadata, active skills, explicit user choice, and runtime contracts.
- Keep changes atomic. Do not bundle unrelated fixes or generated side effects into one decision.

## Decide Workflow

1. State the decision point in one sentence.
2. Classify it as routine, material, or restricted.
3. Read the narrowest relevant app evidence.
4. Compare options against the user model.
5. Return:

```text
decision: ...
confidence: high|medium|low
evidence:
- ...
risk: ...
fallback: ...
learn: optional observation if this outcome should update the model
```

For UI-facing or chat-facing answers, keep the wording natural and concise, but preserve the same fields when the decision affects execution.

## Learn Workflow

Record learning when the user:

- approves or rejects an automation item
- changes a RedClaw plan or route
- corrects a product/architecture boundary
- chooses one creative direction over another
- says a UI is too much, too verbose, too hidden, too abstract, or off-brand
- asks for a workflow to behave differently next time
- tells a member/advisor how it should think or speak

The learning event must include:

- `source`: where the observation came from
- `decision`: what was being decided
- `chosen`: what the user preferred
- `rejected`: what the user moved away from
- `principle`: the reusable rule
- `confidence`: high, medium, or low
- `expires`: optional, when the rule is likely temporary

Do not turn a one-off exception into a global rule unless the user frames it as a rule.

## Role Logic

When asked to decide as a role, separate three layers:

- **User logic**: what the app owner/operator/user tends to choose.
- **Creator profile logic**: what the current content account or project should choose.
- **Member/advisor logic**: what this specific simulated role would argue.

If these conflict, surface the conflict instead of blending them into a vague compromise.

## Safety Boundary

WWUD is not authorization. It may recommend, rank, or prepare an action. It may not silently execute restricted actions.

When the right answer is to ask, ask one precise question and include the default you would choose if the user delegates it.