flame-harness-admob
Phase 7 — analyze the game, decide a rewarded-ad strategy, guide manual AdMob ad-unit creation, and inject google_mobile_ads + ATT/UMP consent code.
Phase 1 — discover Flame game concepts from store charts/competitors, propose 2-3 options, query the user, and record the chosen concept.
$ npx -y skills add tjdrhs90/flutter-flame-harness --skill flame-harness-research --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/flame-harness-researchContext preview
The summary Claude sees to decide when to auto-load this skill.
Phase 1 — discover Flame game concepts from store charts/competitors, propose 2-3 options, query the user, and record the chosen concept.
name: flame-harness-research description: Phase 1 — discover Flame game concepts from store charts/competitors, propose 2-3 options, query the user, and record the chosen concept. argument-hint: "" allowed-tools: [Agent, Read, Write, Edit, WebFetch, WebSearch, AskUserQuestion, Bash]
Phase 1 of the flutter-flame-harness pipeline. Reads the user's raw idea from `config.md`, performs market research if needed, proposes 2-3 concrete game concepts, queries the user via AskUserQuestion to pick one, checks it for App Store guideline 4.3 clone risk, then writes the research spec and advances the pipeline state.
All file schemas (`config.md`, `state.md`, `pipeline-log.md`) are defined in `docs/harness-protocol.md` — refer to that document as the single source of truth. Do not redefine schemas here.
---
Read `docs/harness/config.md` and extract:
the harness without an idea, in which case you will generate ideas from scratch in the Discovery step). When `app_idea` is blank, the Discovery and "Propose & query" steps run exactly as normal but driven purely by market research and creative reasoning with no seed concept; the resulting proposals are presented via AskUserQuestion for the user to pick — the AI does not select automatically **unless `auto_idea: true`**, in which case the "Propose & query" step auto-scores and selects the best concept with no user prompt (see that section).
**skip the Discovery and "Propose & query" steps entirely**. Jump directly to Clone avoidance, then Output. Even when skipping discovery you must still write the research spec.
steps auto-decide instead of calling AskUserQuestion: the skill scores its own generated concepts, selects the best, and auto-revises any clone — running fully hands-off with no user input. Has no effect when `skip_research: true` (the idea is already taken verbatim — nothing to select).
If `config.md` does not exist, abort with: `flame-harness-research: docs/harness/config.md not found — run the orchestrator to bootstrap first.`
---
> Skip this section when `skip_research: true`.
Goal: understand the current mobile game landscape so the proposals are grounded in real market data.
Use WebSearch and/or WebFetch to fetch the current top-grossing and top-free charts for mobile games on Google Play and the App Store. Search queries to use:
For each chart, extract at least 10 titles and their genre/mechanic (e.g. idle clicker, hyper-casual runner, match-3, tower defense, merge).
For the genre most aligned with `app_idea` (if provided), or the top 2 genres by chart frequency, fetch the store pages of 3-5 representative titles via WebFetch. Record for each:
Use WebSearch to look for "hypercasual game trends 2026" and "mobile game genre growth 2026". Extract 2-3 specific trend signals (e.g. "merge mechanics growing 40% YoY", "offline-playable games rising") to inform your proposals.
---
Synthesise your Discovery findings (and `app_idea` if provided) into exactly **2-3 concrete game concept proposals**. Each proposal must include:
| Field | Description | |---|---| | Title | Working title | | Tagline | One sentence (≤ 15 words) describing the core loop | | Core mechanic | What the player does every 10–30 seconds | | Differentiator | One thing that makes it distinct from existing top charts | | Flame suitability | Why Flutter/Flame is a good fit (≤ 2 sentences) | | Monetisation hook | How AdMob ads fit naturally (interstitial / rewarded / banner) |
Present the proposals in a numbered list that is easy to read.
Then branch on `auto_idea`:
Use **AskUserQuestion** to ask the user to pick one or refine:
Which concept would you like to build? Reply with the number (1, 2, or 3), or describe a variation. If you are happy with one as-is, just type its number.
Wait for the user's response. If the user types a number, set the chosen concept to that proposal. If the user describes a variation, merge their input with the closest base proposal and confirm the merged concept with a follow-up AskUserQuestion before proceeding:
Got it. I'll build: <merged concept summary>. Is this correct? (yes / describe further)
Repeat until the user confirms.
Do **not** call AskUserQuestion. Score each of the 2-3 proposals against these weighted criteria and present a short scoring table:
| Criterion | Weight | |---|---| | Market fit | 30% | | Differentiation / clone-safety | 25% | | Flame suitability | 20% | | Monetisation fit | 15% | | MVP scope feasibility | 10% |
Score each criterion 0–10, multiply by its weight, and sum to a weighted total per proposal. Render the table (one row per proposal, one column per criterion, plus a Total column), then **select the proposal with the highest total** as the chosen concept. Print the choice and a one-line rationale, e.g. `Auto-selected: <title> (total 8.4/10) — strongest market fit with a clone-safe twist.` Then proceed to Clone avoidance. Do not query the user.
---
App Store guideline **4.3** prohibits apps that are copies of existing apps ("clone avoida
A Claude Code plugin that takes a Flutter/Flame game from raw idea all the way to the app stores.
Phase 7 — analyze the game, decide a rewarded-ad strategy, guide manual AdMob ad-unit creation, and inject google_mobile_ads + ATT/UMP consent code.
Phase 8 — bootstrap signing credentials, generate fastlane config from templates, and build + upload signed IPA (TestFlight) and AAB (internal track).
Phase 4 — propose verifiable completion criteria and mandatory hard gates; reach AGREED (1-pass default, multi-round negotiation in --strict).
Phase 3 — define the Flutter design_tokens.dart spec (palette, typography, spacing), the game's art/visual concept, and the asset/audio sourcing plan.
Phase 6 — skeptical QA. Run the game, watch it, then judge against the contract. Default = functional check; --strict adds quality and edge-case passes.
Phase 5 — build the Flame game in 3 gated sub-phases (core loop → systems+components → UI+content), then self-evaluate against the contract.