원클릭으로
claude-code-app-studio
claude-code-app-studio에는 cenconq25에서 수집한 skills 73개가 있으며, 저장소 수준 직업 범위와 사이트 내 skill 상세 페이지를 제공합니다.
이 저장소의 skills
Brownfield onboarding for an existing mobile-app codebase. Audits PRDs, ADRs, stories, UX specs, and architecture docs for compatibility with this template's review skills, classifies gaps by impact, and produces a numbered migration plan. Use when joining a project mid-flight or upgrading from an older template version.
Creates an Architecture Decision Record (ADR) documenting a significant technical decision — its context, alternatives, decision, consequences, and PRD requirements addressed. Every major mobile-architecture choice should have an ADR. Framework-version-aware: cross-references the framework reference docs to flag knowledge-cutoff risk.
Validates the architecture against all PRDs. Builds a traceability matrix from PRD requirements to ADRs, identifies coverage gaps, detects cross-ADR conflicts, and produces a PASS/CONCERNS/FAIL verdict. Run after Required ADRs are written; rerun whenever PRDs change. Read-only — never edits files.
Audits app assets for naming conventions, file size budgets, format standards, app icon completeness, splash screens, and store-listing imagery. Identifies orphans (asset on disk but never referenced) and missing references (referenced but missing).
Generates per-asset visual specifications and AI-generation prompts from PRDs and the design bible. Produces structured spec files and updates a master asset manifest. Use after design bible is approved and a UX spec or PRD identifies assets to produce. Output: design/assets/<asset>.md plus design/assets/manifest.md.
Analyze pricing tiers, paywall configs, A/B test variants, and feature-flag values for outliers, broken funnels, dominant variants, and monetization imbalance. Use after editing pricing, paywall copy, or any growth-experiment config.
Guided ideation for a mobile app — from a blank page (or a single hint) to a structured concept doc covering target user, core job-to-be-done, MVP scope, and primary metric. Use when starting a new app or when an existing pitch needs to be tightened into a concept.
Author a structured bug report from a description, OR analyze code/logs to derive likely bugs. Captures reproduction steps, severity, device matrix, expected vs actual, and attachments. Use after a manual QA failure or when the user describes a defect.
Read all open bugs, re-evaluate priority and severity, surface systemic trends, and assign each to a sprint or backlog. Run at sprint start or when the open bug count grows beyond comfort.
Auto-generate a changelog from git commits, sprint data, and design docs. Produces both internal (engineering-facing) and user-facing (release-notes) versions for a given release window.
Architectural and quality review of one or more files. Verifies coding standards, SOLID, testability, mobile anti-patterns, and ADR compliance. Use after /dev-story and before /story-done.
Read-only audit that scans all PRDs against the entity registry and detects cross-doc inconsistencies — same entity with different values, same configurable value with different defaults, same formula with different variables. Use when multiple PRDs are in flight to catch drift before /review-all-prds runs.
Audits PRD-specified content counts (screens, copy strings, images, supported locales, push categories, onboarding steps) against what is actually implemented. Identifies what is planned vs. what is built. Read-only.
Section-by-section authoring of the master architecture doc for the app. Reads all PRDs, systems index, existing ADRs, and the framework reference docs to produce a complete blueprint and a Required ADR list. Framework-version-aware: flags knowledge gaps and validates against the pinned framework. Run after /review-all-prds passes.
Produces a flat, immediately-actionable rules sheet — do this, never do that, per system and per layer — extracted from accepted ADRs, technical preferences, and framework reference docs. More directly usable than ADRs for day-to-day implementation. Run after /architecture-review passes.
Translates approved PRDs and architecture into epics — one epic per architectural module or major system. Each epic captures scope, governing ADRs, framework risk, and untraced requirements. Run after /architecture-review passes; do NOT decompose into stories — run /create-stories per epic afterward.
Decomposes a single epic into implementable story files. Each story embeds its TR-ID, governing ADR, acceptance criteria, story type, and test-evidence path. Run after /create-epics for each epic, in dependency order. Stories are what developers pick up — epics are what architects define.
Prepare a day-one patch for launch. Scopes, prioritizes, implements, and QA-gates a focused patch addressing issues found between gold master and public launch. Treats the patch as a mini-sprint with its own QA gate and rollback plan.
Section-by-section authoring of the Design Bible — the visual identity spec that gates all visual production. Defines tokens for color, type, space, radius, elevation, motion, plus app icon and splash spec. Run after /brainstorm and before /map-systems or any UX work.
Reviews any design document — concept doc, design bible, flow spec, or other architecture-adjacent design artefact — for completeness, internal consistency, and implementability. Detects PRDs and routes them to /prd-review. Use this when the doc is NOT a PRD; for PRD validation, use /prd-review directly.
Section-by-section authoring of a Product Requirements Doc for a single mobile-app system. Reads concept, systems index, dependencies, and registry; walks the user through each PRD section collaboratively; writes incrementally to file. Use when starting a new PRD or filling gaps in an existing one.
Read a story file and implement it end-to-end. Loads PRD requirement, governing ADR, control manifest, and routes to the right framework specialist (RN/Flutter/iOS/Android). Use when a story has passed /story-readiness and is ready to be built.
Estimates effort for a story, batch of stories, or epic by analyzing complexity, dependencies, historical velocity, and risk factors. Produces a structured estimate with confidence levels. Use before sprint planning or when sizing a new request.
Extracts patterns from existing source code into a structured system.md file — naming, state shape, navigation pattern, error handling, and component composition. Used as the first step inside /reverse-document and on its own when the team wants to capture undocumented conventions in a brownfield project.
Validate readiness to advance between development phases. Synthesizes QA, perf, security, asset, balance, and localization verdicts into a single PASS/CONCERNS/FAIL with specific blockers and required artifacts. Use when asking 'are we ready to advance?'.
Analyzes the project's current state and the user's question, then recommends the single best next skill or step. Use when the user says 'what should I do next', 'I'm stuck', or 'I don't know where to go'.
Emergency fix workflow that bypasses normal sprint process while keeping a full audit trail. Creates the hotfix branch, tracks approvals, ensures backport to main, and produces release-store-ready notes. Use only for production-impacting S1 bugs or critical store-rejection issues.
Full launch readiness across departments: code, content, store listings, marketing, community, infra, legal, privacy (ATT, Data Safety), accessibility, and sign-offs. Run before every public launch.
Full localization pipeline: scan for hardcoded strings, extract to string tables, validate translations, RTL test, locale QA, voiceover/audio localization, string freeze enforcement, and coverage reporting.
Decomposes the app concept into discrete systems, maps dependencies, prioritizes design order by upstream-first, and writes the systems index. Use after /brainstorm and /setup-framework, before authoring any individual PRD.
Comprehensive milestone progress review — feature completeness, quality metrics, risk assessment, and go/no-go recommendation. Use at milestone checkpoints (alpha, beta, RC) or when evaluating readiness for a milestone deadline.
Generates a contextual onboarding doc for a new contributor based on their role (engineer, designer, PM, QA, etc.). Summarizes app concept, architecture, conventions, current sprint, and the contributor's likely first tasks. Use when bringing someone new onto the project or when a contributor switches roles.
Generate user-facing patch notes from git history, sprint data, and the internal changelog. Translates engineering language into clear, store-appropriate user communication. Respects App Store / Play Store character limits.
Structured performance profiling: cold/warm start, frame time, memory, network, app size, battery. Identifies bottlenecks against budgets, recommends optimizations with priority. Use during Polish or before a release.
PRD-specific validation gate: checks required PRD sections, TR-ID requirement IDs, GIVEN-WHEN-THEN acceptance criteria, dependency-graph bidirectionality, and traceability readiness for engineering hand-off. Use ONLY for PRDs (`design/prd/*.md`); for any other design doc, use /design-review. Run in a fresh session — never the same session that wrote the PRD.
Read-only audit that classifies the project's current stage (concept / design / architecture / sprint / beta / live-ops), identifies missing artifacts, and recommends the next sensible skill. Use when the user asks 'where are we', 'what stage are we in', or after pulling an unfamiliar branch.
When a PRD is changed, scans all ADRs, dependent PRDs, stories, and the traceability index to identify what is now potentially stale. Produces a change-impact report and walks the user through resolving each downstream artifact. Use immediately after editing a PRD that other artifacts reference.
Rapid prototyping workflow that deliberately skips standards to validate a risky concept fast. Produces throwaway code and a structured prototype report. Use to retire the riskiest assumption from /brainstorm before committing to architecture, or to validate a novel mechanic before adding to the sprint.
Generate a QA test plan for a sprint or feature. Reads PRDs and stories, classifies stories by test type (Logic/Integration/Visual/UI/Config), and produces a plan covering automated tests, manual cases, smoke scope, device matrix, and sign-off rules. Run before sprint kickoff or when starting a major feature.
Lightweight design spec for small changes — copy tweaks, single-screen polish, parameter adjustments — when a full PRD is overkill. Produces a Quick Design Spec that embeds directly into a story file. Use when a change is too small to justify a new PRD section but still needs a written spec for traceability.