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.
Resume a paused flame-harness run based on pause_reason (rate_limit waits; manual_action confirms with user; error reports).
$ npx -y skills add tjdrhs90/flutter-flame-harness --skill flame-harness-resume --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/flame-harness-resumeContext preview
The summary Claude sees to decide when to auto-load this skill.
Resume a paused flame-harness run based on pause_reason (rate_limit waits; manual_action confirms with user; error reports).
name: flame-harness-resume description: Resume a paused flame-harness run based on pause_reason (rate_limit waits; manual_action confirms with user; error reports). argument-hint: "" allowed-tools: [Read, Write, Edit, Bash, AskUserQuestion, Skill]
Resume handler for the flutter-flame-harness pipeline. Reads `state.md`, branches on `pause_reason`, and re-dispatches the next phase skill when ready to continue.
All file schemas (`state.md`, `pipeline-log.md`) and state transition rules (including the requirement that `pause_reason` is cleared to `""` when `status` is restored to `running`) are defined in `docs/harness-protocol.md` — refer to §2 (state.md schema) and §7 (state transition rules) as the single source of truth. Do not redefine schemas here.
---
Read `docs/harness/state.md` per the schema in `docs/harness-protocol.md` §2. If `state.md` does not exist, abort with:
flame-harness-resume: nothing to resume — docs/harness/state.md not found. Run /flame-harness <idea> to start a new pipeline.
Extract:
If `status` is `running`:
flame-harness-resume: pipeline is already running (status: running, next_role: <next_role>). No resume needed.
If `status` is `completed`:
flame-harness-resume: pipeline is already completed. Nothing to resume.
---
`pause_reason: rate_limit` means the pipeline hit an API rate limit and paused automatically.
**Procedure:**
1. Print:
Pipeline paused due to rate limit (rate_limit). Checking whether the rate-limit window has passed...
2. Read `updated_at` from `state.md`. Calculate elapsed time since that timestamp using Bash (`date` command). If elapsed time is less than 60 seconds, print a warning:
Warning: only <N> seconds have elapsed since the pause. The rate-limit window may not have passed yet. Proceeding anyway — if another rate limit is hit, the pipeline will pause again.
3. Proceed to **Resume execution** below.
`pause_reason: manual_action` means the pipeline requires a manual step from the user before it can continue (e.g. **playing/approving the built game at the post-QA review gate**, completing App Store / Play Console submission steps, uploading a keystore, or configuring a device). The specific action is recorded in the `pause` event row of `pipeline-log.md`.
**Procedure:**
1. Read `docs/harness/pipeline-log.md` per `docs/harness-protocol.md` §6. Find the most recent `pause` event row to extract the details string describing what manual action was needed. If the log is unavailable, use a generic prompt.
2. Use **AskUserQuestion** to confirm the user has completed the required steps:
The pipeline was paused for a manual action. Last recorded reason: <details from pipeline-log, or "see docs/harness/pipeline-log.md"> Have you completed the required steps? (yes / no / describe what's pending)
3. If the user answers `no` or describes pending work:
flame-harness-resume: manual action not yet complete. Run /flame-harness-resume again
when ready.4. If the user answers `yes`:
`pause_reason: error` means the pipeline encountered an unrecoverable error in a phase skill.
**Procedure:**
1. Read `docs/harness/pipeline-log.md` per `docs/harness-protocol.md` §6. Find the most recent `error` event row to extract the error details.
2. Print a clear error report:
Pipeline paused due to an error.
Phase : <current_phase>
Next role : <next_role>
Error : <details from pipeline-log, or "see docs/harness/pipeline-log.md">
You must investigate and fix the error before resuming.
Common fixes:
- If it is a Flutter/Dart compile error, fix the code and run `flutter analyze`.
- If it is a missing file, create or restore it.
- If it is a credential error, check docs/harness/config.md and the credentials_dir.3. Use **AskUserQuestion**:
Have you resolved the error and are ready to retry? (yes / no)
4. If the user answers `no`:
flame-harness-resume: error not yet resolved. Run /flame-harness-resume again when fixed.
5. If the user answers `yes`:
If `pause_reason` is empty or an unrecognised value, print:
flame-harness-resume: unexpected pause_reason "<value>" in state.md. Expected one of: rate_limit, manual_action, error. Please inspect docs/harness/state.md manually and correct it before resuming.
Then abort without modifying any files.
---
Reached only after the appropriate branch above confirms it is safe to continue.
Per `docs/harness-protocol.md` §7 rule 4: when `status` is set back to `running`, `resume_attempts` must be incremented, and per §7 rule 8: `pause_reason` must be cleared to `""` by this skill.
Use **Edit** to update `docs/harness/state.md` with the following field changes (leave all other keys unchanged):
status: running pause_reason: "" resume_attempts: <previous_value + 1> updated_at: "<ISO-8601 UTC now>"
Both `status: running` and `pause_reason: ""` must be written in the same Edit call (atomic per `docs/harness-protocol.md` §7 rule 1).
Append one row to `docs/harness/pipeline-log.md` per the schema in `docs/harness-protocol.md` §6:
| <I
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.