Wit

Unified “whatifthen” framework for early-stage product thinking, requirement clarification, and decision review. Use when a user has a new idea, feature requ...

Security Scan

The skill is an instruction-only facilitation framework for product thinking; its files, instructions, and requirements are consistent with that purpose and it does not request credentials, install code, or perform external I/O.

Purpose & Capability

The name and description match the included SKILL.md and reference documents: this is a conversational facilitation framework. There are no unexpected environment variables, binaries, or config paths declared that would be unrelated to a guidance/facilitation skill.

Instruction Scope

All runtime instructions are guidance for conversational flow and output formatting. The SKILL.md and reference files only instruct the agent to ask questions and produce a structured note; they do not tell the agent to read system files, call external endpoints, or access environment variables beyond the skill's own reference documents.

Install Mechanism

There is no install spec and no code to execute. This instruction-only skill does not download or install binaries, so it has a minimal installation surface.

Credentials

The skill declares no required environment variables, credentials, or config paths. That is proportionate to a purely facilitation/templating skill.

Persistence & Privilege

always is false and there are no instructions to modify other skills, system settings, or to persist credentials. The skill is therefore not requesting elevated or permanent privileges.

Assessment

This skill appears to be a purely instructional facilitation framework and is internally consistent with its stated purpose. Risks are low because it: (a) has no install actions or code, (b) asks for no secrets or system access, and (c) only contains guidance and templates. Before installing, you may still want to: (1) confirm you trust the publisher (owner ID and no homepage are provided), (2) avoid providing sensitive or confidential data during sessions driven by any third-party skill, and (3) if you enable autonomous agent behaviors on your platform, review what other skills or systems the agent can access—autonomous invocation is platform-default and increases blast radius only when combined with access to credentials or installable code (not present here).

WIT stands for whatifthen.

Use WIT to move from vague idea to practical decision in two phases:

1. Break the problem open — verify the problem is real, specific, observed, and worth solving.
2. Make the decision — narrow scope, choose what to do now, define what not to do, and commit to the next step.

What WIT is for

WIT is for cases where the user does not need instant solutioning yet. Use it when the job is to:

• sharpen the problem before planning
• challenge the current framing
• separate observed facts from story
• reduce scope to a narrow wedge
• force a decision instead of endless exploration

When to stay in WIT

Stay in WIT when the user needs:

• discovery before planning
• sharper problem definition
• separation of observations from assumptions
• a narrower initial wedge
• a decision memo rather than brainstorming sprawl

When to exit WIT

Exit WIT once the following are clear enough:

• the problem and target user
• the narrowest wedge
• the main assumption or uncertainty
• the decision for this round
• the next concrete action

Once these are clear, stop probing and hand off to planning, execution, or review.

Facilitation style

• Ask one strong question at a time unless the user explicitly wants a compact batch.
• Prefer concrete wording over abstract strategy language.
• Push for examples, current behavior, and specific moments.
• Challenge broad or inflated scope early.
• If the user names a feature, test whether the real need is larger, smaller, or different.
• Convert ambiguity into explicit assumptions.
• Convert discussion into a decision before ending.

Operating rules

• Do not jump to solutioning before clarifying the problem.
• Separate observations, inferences, and assumptions.
• Prefer a narrow, concrete initial scope over a broad “platform” answer.
• Force an explicit not doing list.
• Name the current status quo before proposing a replacement.
• Ask what would make this worth doing now, not someday.
• For integration / consolidation / rewrite / merge-notes requests, do not jump straight into execution if the decision target is still unclear. First ask what this work is meant to serve: reframing, scope reduction, PRD drafting, roadmap choice, or another concrete decision.
• Stop expanding once enough information exists to make a practical decision.
• If the user is still in discovery mode, stay longer in Phase 1.
• If the user is clearly choosing among options, move faster into Phase 2.
• Do not end with only questions; end with a structured synthesis.

Default conversation sequence

Phase 1 — Break the problem open

Establish:

• who has the problem
• what they do today
• what is observed vs assumed
• what framing may be wrong or too narrow
• what the narrowest wedge is
• which assumption most needs validation

Phase 2 — Make the decision

Establish:

• whether this is worth doing now
• the smallest version worth shipping or testing
• explicit non-goals
• what decision must be made now
• the next concrete action and owner

Decision states

End with one of these states:

• Do now — worth acting on immediately
• Test first — worth a narrow validation step before committing
• Do later — real idea, not current priority
• Do not do — weak problem, wrong timing, or wrong wedge

Required output

Produce a structured note with these sections:

1. Problem definition
2. Target user and specific scenario
3. Status quo today
4. Observations vs assumptions
5. Framing check
6. Narrowest wedge
7. Decision for this round
8. Not doing now
9. Next step

If the user asks only for discussion, still summarize the above briefly before ending.

References

Read these as needed:

• references/framework.md — full question framework and facilitation sequence
• references/evidence-basis.md — why this framework is structured this way
• references/output-template.md — output format
• references/examples.md — example uses