/house-conventions

name: house-conventions
description: Use before writing any code, spec, or store asset on a Mobify Studio app — loads the relevant House Knowledge Base pack(s) so output matches the studio's established conventions instead of generic defaults. Every IC invokes this first; execs invoke it when their document names a platform, version, library, or store surface.

House conventions

The plugin ships a House Knowledge Base under `knowledge/` mined from our internal shipped apps. This skill is how an agent loads the right pack before working, so what it produces looks like the studio's other apps — same architecture, same monetization patterns, same store hygiene.

When to use

Invoke this **before** the first edit/spec on any ticket, sprint, or asset. It costs one read and prevents a whole class of "this doesn't match how we build" rework.

Procedure

1. Identify what you're about to do and load the matching pack(s). The packs live at **`${CLAUDE_PLUGIN_ROOT}/knowledge/<pack>.md`**. If `CLAUDE_PLUGIN_ROOT` is not set in your environment, glob for `**/knowledge/stack-defaults.md` inside the plugin install and read the packs from that directory. If you genuinely cannot locate the packs, **STOP and report a blocker** — do not silently proceed on generic defaults; that is exactly the failure this skill exists to prevent.

| You are about to… | Read | |---|---| | Pick stack / versions / libraries | `stack-defaults.md` | | Write or review iOS code | `ios-conventions.md` (+ `stack-defaults.md`) | | Write or review Android code | `android-conventions.md` (+ `stack-defaults.md`) | | Add ads, IAP, or a paywall | `monetization.md` | | Add analytics / events / KPIs | `analytics.md` | | Prepare store assets / submission | `aso.md` | | Set up git, CI, signing, releases | `git-workflow.md` | | Write a vision, PRD, or backlog | **No pack — the shape lives in `prd-builder` / `requirements-intake`, not here.** Read `stack-defaults.md` only where the document names a platform, version or library; otherwise this skill has nothing for you and you are done in one line. |

2. Treat the pack as the **floor**. Follow it unless the project's own `docs/` (architecture, engineering principles, `CLAUDE.md`) explicitly overrides a specific rule — a project may be stricter, never sloppier.

**Tier:** default to the **Flagship** rules in each pack. If the project declares itself a *utility* app (in its `docs/` or `CLAUDE.md`), apply the **Utility** branch where a pack defines one (e.g. ad-first monetization, leaner stack) — see `knowledge/README.md` §Tiers.

2a. **Load only what the project has.** Read `docs/02-team-roster.md` (tier, product type, platforms) before the pack. Do not produce a section for a platform, role or capability the project does not have — no Android stack section on an iOS-only app, no "consult tech-lead about capacity" with one active IC. **Skip it explicitly, never silently:** write `N/A: <section> — <reason> per docs/02-team-roster.md`. A silent skip and a forgotten section look identical to every reader afterwards.

3. If the pack and the project docs **conflict**, the project docs win for that project, but write one line to your per-run fragment (`docs/daily/<today>-<role>-<ticket>.md`) noting the divergence so the `tech-manager` can decide whether the KB or the project is wrong.

**No ticket?** A spec-writing exec has none, and that used to make this rule unfollowable for exactly the roles whose divergences are largest. Use `docs/daily/<today>-<role>-spec.md` — same directory, so the standup collects it with everything else.

4. If you discover a genuinely new, reusable convention while working, add a `LEARNING:` line to that same fragment so `/app-learn` can fold it back into the KB after ship.

5. **If you just wrote to a file OUTSIDE a leased worktree — a spec, the SRS, the PRD, the backlog, an ADR/PDR/DDR, anything in the shared tree — commit it before you report done or hand off.** `ic-workflow`'s branch-and-commit discipline is written for IC roles working inside a worktree; it says nothing about the execs, `tech-lead`, `cpo`, and every other role that edits `docs/` directly on the shared tree, and until this line existed nothing did. The failure is not hypothetical: a `cpo` wrote a new requirement into the SRS/PRD and created a board ticket, a `tech-lead` wrote the impl spec and handed off — neither committed — and the next command that cut a fresh worktree for the developer (`git worktree add`, which snapshots the last COMMIT, not the live working directory) produced a worktree missing both edits entirely. The developer correctly `BLOCKED`, reporting a ticket and impl spec that "did not exist," because from git's point of view they didn't yet. `git add <the files you touched> && git commit -m "..."` — explicit paths, same rule `ic-workflow` gives ICs, for the same reason: a blanket `git add -A` from a shared-tree role risks staging someone else's in-flight work.

6. **Read what your role names, not the whole tree.** `ic-workflow`'s input contract already scopes a developer to exactly three things — the ticket row, the PRD/impl-spec sections it points to, and its own subtree — for a reason: a role that re-reads the full PRD, every prior standup, and every sibling ticket "to be safe" burns budget on context it was never going to use and makes the next context-window compaction more likely mid-ticket. Read the pack this skill names, the doc your input contract names, and nothing wider unless a specific question sends you looking for it. This is not a license to skip house-conventions or defect-hunting's own required reads — it is the same discipline pointed at everything *else*: a role file that grew barnacles ("also skim the last five standups") over time is exactly the kind of accretion this rule exists to refuse.

Ant