Video 1 - Stop Vibe Coding: First Build an AI Harness for Android Apps | Ideation Skill & Agent - 1
In this video, we look at what happens when you ask an AI agent to build an Android app from a single vague prompt. Using a sample habit tracker app as the example, we see why this kind of prompt-first approach may produce something polished on the surface, but still lacks the clarity, boundaries, and control needed for real software development.
The main focus of this video is building a better ideation process for AI-assisted app development. Instead of jumping straight into coding, we create the foundation needed to guide the AI properly. That includes setting up a basic AI harness, creating a reusable product ideation skill, using that skill to run an ideation session for a habit tracker app, and then turning the conversation into a durable idea brief using a standard template.
When we start ideating for a product using AI agent, it is not advisable to get started with the direct creation of the skill and agent as a first attempt. Because it has not yet proven it's utility. So it is advisable to start with a prompt and work with it to get the work done. See how it behaves, see where it fails. Identify the failures it is making and use conversation with AI as a stepping stone to create the skills and agents.
In the video we had kicked off the ideation session with the bellow prompt.
You are helping me draft—not yet implement—a canonical repository-level
product-ideation skill.
Do not create, edit, move, or delete any files. Produce a proposal for me to
review as the product owner.
## Situation that earned the skill
When an agent receives an underspecified request to build an application, it
can produce a plausible default implementation while silently making product
choices that the creator has not made: the user, problem, behaviour, domain
rules, scope, and definition of success.
This skill should prevent that premature product scope. It must help a creator
discover the product before the agent treats any product direction as decided.
## Job of the proposed skill
Turn fuzzy creator intent into enough agreed product intent to create an Idea
Brief that a later product-definition step can convert into a PRD. The agent
manages the state of reasoning; it must never silently become the product owner.
## Non-negotiable behaviour
1. Begin from what is already known and show four visible states:
- Decided
- Open now
- Not yet specifiable / fog
- Out of scope
2. Ask only the next one to three questions that are meaningful now. Do not
present a static exhaustive questionnaire.
3. Work breadth-first before depth-first: establish target user, problem,
product promise, and core loop before technology, detailed behaviour, or
implementation questions.
4. Explain relevant options and trade-offs, but leave every material product
decision to me.
5. After each material decision, record the decision, my short rationale, and
its immediate consequence. Recalculate the decision space: expose newly
meaningful questions and retire invalid ones.
6. Treat persistence, sync, architecture, navigation, reminders, data schemas,
DI, and implementation plans as fog unless they become a genuinely necessary
product-boundary question. Do not write a PRD or architecture.
7. Stop once product intent and the V1 boundary are sufficient for a later PRD.
If something is still premature, explicitly defer it; never invent an answer.
8. Produce a durable Idea Brief with a decision log and an explicit handoff to
the later product-definition step.
## Canonical-harness constraints
- This should become a canonical repository skill only if its method recurs,
protects a repository-specific decision boundary, and produces an artifact
later work consumes. Do not claim that every useful prompt should become a
skill.
- The eventual canonical source belongs under `docs/aiagentharness/`. Claude- and
Codex-native project structures are thin adapters that invoke the canonical
method; they must not carry competing copies of its instructions.
- Keep project-specific acceptance criteria outside this generic skill. They
are separate gates on the resolved Idea Brief, not hidden product-selection
rules.
- Use the progressive-discovery ideas in this request as design input only. Do
not name, imitate, or claim to implement any external workflow or product.
## Your required response
Return an approval-ready proposal in exactly these sections:
1. **Why this is a canonical skill** — 100 words maximum; contrast it with a
one-off prompt using only the facts above.
2. **Naming and placement options** — recommend up to three kebab-case names
and one canonical `docs/aiagentharness/` location. Use `[PREFIX]` if a naming
prefix is still undecided; do not choose a prefix for me.
3. **Canonical / adapter boundary** — show the smallest possible file layout
and state what the canonical file owns versus what an adapter may contain.
4. **Proposed skill contract** — concise input, method, visible state,
guardrails, output, and stop condition.
5. **Draft SKILL.md content** — present the proposed content in a fenced code
block only. It must be concise, imperative, tool-agnostic, and suitable for
later adoption. Do not claim it has been written to disk.
6. **One illustrative dry run** — show the first two question rounds following
a deliberately vague request to build an app. Do not assume an app category,
choose answers for me, or invent a final product concept.
7. **Adoption checks** — list the exact decisions or evidence I must approve
before the proposal can become a repository file.
If the information above cannot support a decision, mark it explicitly as open
or fog. Never fill missing product decisions with plausible defaults.
The salient features of the prompt are
- Product-neutral — does not seed an app idea, user, or feature set; discovery must remain real.
- Proposal before implementation — asks for a reviewable skill draft, so the creator approves the method before it becomes harness code.
- Progressive questions (1–3 at a time) — avoids a static requirements questionnaire and keeps the conversation meaningful.
- Four visible decision states — distinguishes decided, open, fog, and out-of-scope items so uncertainty is never mistaken for a decision.
- Breadth before depth — resolves user, problem, promise, and core loop before technical detail, preventing false precision.
- Creator owns material choices — the agent explains trade-offs and facilitates; it never becomes the product owner.
- Decision provenance — records each decision, rationale, and consequence, so later agents do not reconstruct intent from chat memory.
- Explicit boundary — stops at an Idea Brief, before PRD, architecture, or implementation planning.
- Canonical-harness separation — keeps the method reusable and tool-neutral; Claude/Codex-specific files remain thin adapters.