菜单
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 and exec agent invokes this first.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when pointing the team at an EXISTING, already-built app instead of a blank project — detects the stack, reverse-engineers the as-built architecture, and classifies remediation work as safe-to-auto-fix vs risky-needs-approval. Triggered by /app-onboard, /app-audit, and by /app-run when it detects a non-empty app directory.
Use to actually launch multiple developer agents in parallel via the subagent tool (Task/Agent), given a sprint plan and board. Triggers from /app-build or when the tech-manager says "spawn the pod". Encapsulates the rules for safe concurrent agent execution.
Use to produce the technical architecture doc and engineering principles for a mobile app. Used primarily by the CTO agent. Triggers on "design the architecture", "pick the stack", or as part of /app-plan.
Use to construct a complete Product Requirements Document for a mobile app from a vision file. Used primarily by the CPO agent. Triggers on requests to "write the PRD", "spec out the product", or as part of /app-plan.
Use at the very start of a new app project to convert a one-line idea or rough brief into a structured requirements document the CEO/CPO/CTO agents can act on. Triggers when the user says "build an app", "I have an idea for an app", or kicks off /app-init with a fuzzy prompt.
Use to convert the backlog into a runnable sprint with parallel ticket assignment and dependency tracking. Used primarily by the tech-manager. Triggers on "plan the sprint", "what does the pod do next", or as part of /app-build.
| 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 and exec agent invokes this first. |
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.
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.
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 |
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.
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>-<agent>-<ticket>.md) noting the
divergence so the tech-manager can decide whether the KB or the project is wrong.
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.
