frontend-ohmyhotel-plugin

Plugin frontend-ohmyhotel-plugin from marketplace ohmyhotelco in ohmyhotelco/hare-cc-plugins. Commands read from the repo's manifest — 8 days ago.

Skills (22)

• fo-analyze

  Analyze the V2 implementation(s) of a screen that the spec reuses — prepare a checkout of the monorepo (at the frozen commit, or at the head of the baseline branch under delta tracking), start legacy-analyzer on the PC and mobile route bodies, and write <screenDir>/analysis.json with permalinked beh

• fo-audit-codex

  Run an optional, advisory Codex audit of one stage's artifact for a screen (plan, gen, review, visual, e2e, contract, seo) through codex-auditor, recording the independent verdict and findings in docs/gates/<app>/<screen>/codex-audit.json. Use when a second opinion is wanted before approving a plan

• fo-clean-code

  Standalone code-quality audit of any path in the repo (a screen, a package module, a ui-kit folder) with quality-reviewer — the same eight dimensions fo-review uses, without a plan. Use for code the pipeline did not generate, or for a quick read before a PR.

• fo-contract

  Contract gate for one generated screen — checks it against the product repo's machine-checked rule lists (external URL contract, WebView contract, sensitive query keys, request conventions) and the telemetry events its spec names, one agent per list in parallel, and writes docs/gates/<app>/<screen>/

• fo-cutover

  Maintain and check the big-bang cutover ledger for an app — computed items (every screen's gates pass and are current, rule lists populated), list items (external URL and native app contract entries confirmed, frozen-monorepo hotfixes re-applied), manual items with owners and evidence (integrated QA

• fo-debug

  Debug a failing test, gate or runtime error on a screen with the debugger agent — reproduce, one hypothesis at a time with evidence, fix the confirmed cause with a regression test, escalate after three refuted hypotheses. Use when fo-verify, fo-e2e or a dev run fails for a reason the evidence does n

• fo-e2e

  E2E gate for one generated screen — realizes the plan's test scenarios (TS ids from the spec snapshot) as Playwright specs, runs them against the mock-first dev server through the harness, and writes docs/gates/<app>/<screen>/e2e.json with per-scenario results and trace paths. Use after fo-visual.

• fo-extract

  Extract the shared-package candidates found by fo-analyze (framework-free logic still inside V2 route bodies) into packages/shared-* with TDD, one package-extractor per candidate in sequence, after the user confirms the candidate list and how PC/mobile divergence is reconciled. Use between fo-analyz

• fo-figma

  Record a screen's Figma frames (state × viewport node ids) in docs/figma-manifest.json through the Figma MCP and export them to PNG with bin/fo-figma-export when FIGMA_TOKEN is set, so fo-plan can cite them and fo-visual can compare against them. Use before fo-plan on screens that have a design.

• fo-fix

  Apply approved finding clusters from the last fo-review (or a failed gate's report — verify, visual, e2e, contract, seo) to a generated screen through the fo-fix-run workflow, one review-fixer per cluster in sequence, then re-run fo-verify. Use after fo-review approves clusters or when a gate report

• fo-gen

  Generate one screen from its approved implementation plan through the fo-gen-run workflow (foundation → api-tdd → component-tdd → page-tdd → integration, TDD with recorded evidence), resume a stopped run, or apply a delta plan to an existing screen. Use after fo-plan is approved; follow with fo-veri

• fo-init

  Initialize frontend-ohmyhotel-plugin for the current repository — detect the app layout, write .claude/frontend-ohmyhotel-plugin.json, scaffold the product-rule files (docs/adr, docs/rules/*.json), the gate evidence tree and specs/MANIFEST.md, and point the repo CLAUDE.md at the rules. Run once per

• fo-plan

  Plan one screen of an app from its spec snapshot (+ Figma frames, legacy analysis, product rule lists) into implementation-plan.json and a draft <Screen>.spec.md, or — when a plan exists and the spec changed or the legacy analysis moved past it — produce delta-plan.json. Ends with the plan summary a

• fo-progress

  Show an app's screen × gate matrix — spec version, plan state and open approvals, generation stages, each gate's result with staleness against the current tree hash, deferred review clusters — and the next command per screen; computed by fo-progress-report. Use any time to see where every screen sta

• fo-review

  Review a generated screen with four reviewers in parallel (spec compliance, code quality, test quality, security) through the fo-review-run workflow, merge their findings into file clusters, write docs/gates/<app>/<screen>/review.json, and ask which clusters to fix. Use after fo-verify (or any faile

• fo-security

  Standalone client-side security audit of any path (screen, package, route modules, telemetry) with security-auditor — XSS sinks, token handling, secrets, sensitive query keys against the repo's rule list, open redirects, SSR exposure, headers. Read-only. Use before cutover on shared modules and on a

• fo-seo

  SEO gate for one generated screen — checks head meta against the meta template, canonical and hreflang, sitemap/robots host rules, structured data and slug lists against the SEO spec snapshot (config.seo.specRef), one agent per aspect in parallel, and writes docs/gates/<app>/<screen>/seo.json. Use a

• fo-shared

  Shared conventions for every frontend-ohmyhotel-plugin agent and skill — config lookup, state and evidence files, locks, reporting format. Preloaded into agents through their `skills:` frontmatter; not meant to be invoked by hand.

• fo-spec-sync

  Import a planning-spec attachment (Jira zip or extracted folder) into specs/<screen>/ as an immutable snapshot, update specs/MANIFEST.md (ticket, version, status, sha256, content hash, date), and report which screens now have a plan older than their spec. Use when the planning team delivers a new or

• fo-test-review

  Standalone test-quality audit of any test path (Vitest or Playwright) with test-reviewer — assertions, Testing Library usage, async, structure and anchors, coverage, timing, anti-patterns — without a plan. Use for tests the pipeline did not generate, or before accepting a test PR.

• fo-verify

  Run the technical gate for one generated screen — route typegen + tsc, the API package's own tsc/vitest for additions, eslint, the screen's vitest suite, the i18n key-coverage spec, and the e2e-layout check (every e2e/ file in the fixed tree, no tracked run output) — through the deterministic fo-ver

• fo-visual

  Visual gate for one generated screen — captures every planned state at each configured viewport × language through a Playwright spec, checks breakage (overflow, console errors, broken images, clipped text, DS responsive boundary), compares captures with their Figma frames where frames exist, and wri

Subagents (19)

• codex-auditor

  Obtains an independent Codex audit of one stage's artifact for a screen — gathers only the artifacts and sources of truth (never Claude's reasoning), runs headless `codex exec`, parses the verdict and findings into docs/gates/<app>/<screen>/codex-audit.json carrying earlier adjudications forward. Ad

• contract-verifier

  Checks one screen against one machine-checked rule list from the product repo (externalUrls, webviewContract, sensitiveQueryKeys, requestConventions) or against the telemetry events the spec names, by reading the generated code and running the matching probe; reports every finding with severity and

• debugger

  Systematic debugger for a failing test, gate or runtime error in a screen — reproduces, forms one hypothesis at a time with the evidence that would confirm or refute it, tests it, fixes the confirmed cause with a regression test, and stops to report after three refuted hypotheses instead of guessing

• delta-modifier

  Applies a delta-plan.json to an already-generated screen — targeted add/modify/remove on the existing files, TDD for behavioral changes and direct edits for structural ones — preserving fixes accumulated since generation, then merges the delta into implementation-plan.json with planVersion + 1.

• e2e-test-runner

  Realizes a screen's planned test scenarios (TS ids from the spec snapshot) as Playwright specs under <app.dir>/e2e/screens/<screen>/, runs them against the mock-first dev server through the harness, and reports per-scenario results with trace paths. Writes specs and the e2e report only.

• figma-extractor

  Resolves a screen's Figma frames (state × viewport) from the design file through the Figma MCP, records their node ids in docs/figma-manifest.json, and reports which planned states have no frame; the PNG export itself is done by bin/fo-figma-export with a token. Writes the manifest and, with a token

• foundation-generator

  Builds the non-TDD foundation for one screen from its implementation plan — types, zod schemas, MSW factories/fixtures/handlers — and, once per app, the Vitest+MSW test infra, the Playwright harness, the i18n key-coverage spec and the form adapters over the design system. Writes the foundation stage

• implementation-planner

  Turns one screen's planning-spec snapshot, its Figma frames, its legacy analysis (when the screen reimplements a V2 route) and the product rule lists into implementation-plan.json plus a draft <Screen>.spec.md; in delta mode compares the new spec and/or the updated legacy analysis against the existi

• integration-generator

  Wires a generated screen into the app — React Router v7 route modules in routesDir, i18n keys appended to every language's flat resource file (with machine-translated values listed for review), the MSW global handler aggregate — then runs the full check (typegen, tsc, vitest, build) and records it i

• legacy-analyzer

  Reads the V2 implementation(s) of a screen from the monorepo archive at a given commit (PC and mobile route bodies, hooks, services) and writes analysis.json — behaviors, API calls with field sources, copy sources, failure paths, navigation/storage/state surfaces, the PC-vs-mobile differences, and s

• package-extractor

  Moves one shared-package candidate (framework-free logic found by the legacy analysis inside V2 route bodies) into the matching packages/shared-* module with TDD, reconciling PC/mobile divergence as the plan or the user decided, and keeps the package's own export surface. Writes package code and tes

• quality-reviewer

  Read-only reviewer that judges a generated screen's code quality across eight dimensions — single responsibility, consistent patterns, no literal copy, error handling, TypeScript strictness, repo conventions (design system only, package hooks, useT, no client store, route-module shape, SSR safety, d

• review-fixer

  Fixes one approved cluster of review or gate findings on a generated screen — TDD for behavioral changes (test first, red, green, mutation check), direct edits for mechanical ones, Playwright trace reading for E2E failures — then runs the affected checks and reports what changed with evidence. Edits

• security-auditor

  Read-only audit of a generated screen (and its package additions) for client-side security — XSS sinks, token handling, secrets in client code, sensitive data in logs/storage/URLs (incl. the repo's sensitive query keys), open redirects, SSR data exposure, config/headers — reporting every finding wit

• seo-verifier

  Checks one aspect of a screen's SEO against the SEO spec snapshot in the product repo (head meta vs the meta template, canonical and hreflang, sitemap/robots host rules, structured data, slug lists) by rendering the routes through the harness and reading the output; reports every finding with severi

• spec-reviewer

  Read-only reviewer that compares a generated screen against its planning spec snapshot (FR/BR/AC/TS), the implementation plan and the Figma frames listed in it, across five dimensions, and reports every finding with severity and confidence for the fo-review merge stage.

• tdd-cycle-runner

  Runs one TDD stage (api-tdd, component-tdd or page-tdd) for a screen — writes failing tests from the plan with spec anchors, runs them red, implements the minimum, runs them green, mutation-checks each behavior, and records every run as evidence in generation-state.json.

• test-reviewer

  Read-only reviewer of a generated screen's Vitest and Playwright tests — assertion quality, Testing Library usage, async patterns, structure and spec anchors (followed into the spec snapshot), coverage breadth, timing, anti-patterns — reporting every finding with severity and confidence for the fo-r

• visual-verifier

  Visual gate worker for one screen — in `capture` mode writes and runs a Playwright spec that renders every planned state at each configured viewport × language and records breakage (overflow, console errors, broken images, clipped text); in `compare` mode judges one rendered capture against its Figm

Similar plugins