메뉴
Add a new top-level renderer screen to Anvil and wire it into routing, navigation, and the existing workspace-gated shell.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | add-view |
| description | Add a new top-level renderer screen to Anvil and wire it into routing, navigation, and the existing workspace-gated shell. |
Use this skill when you are creating a new screen or major route in the React renderer.
Top-level screens are usually *View.tsx files under src/renderer/components/<feature>/.
Examples:
src/renderer/components/repos/ReposView.tsxsrc/renderer/components/chat/ChatView.tsxsrc/renderer/components/security/SecurityView.tsxsrc/renderer/components/docs/DocsView.tsx*View.tsx file inside the appropriate feature folder under src/renderer/components/.src/renderer/App.tsx.<Route /> in src/renderer/App.tsx.NavItem entry in src/renderer/components/layout/Sidebar.tsx.guard(...) pattern in App.tsx.WorkspaceGate.HashRouter.ErrorBoundary.WorkspaceGate.ROLE_FEATURES from src/shared/types.Use existing route definitions in src/renderer/App.tsx as the template instead of inventing a new routing pattern.
Choose the narrowest integration:
WorkspaceContextwindow.anvil API and follow the full cross-process workflow from add-featuresrc/renderer/components/.src/renderer/components/layout/ and nearby feature folders.src/renderer/App.tsxsrc/renderer/components/layout/Shell.tsxsrc/renderer/components/layout/Sidebar.tsxsrc/renderer/contexts/WorkspaceContext.tsxpnpm lint after adding or wiring a screen.pnpm test and, when relevant, pnpm build.pnpm dev to confirm route access, role gating, and workspace behavior.Standard workflow for adding a new Anvil feature that spans shared contracts, IPC, preload, services, persistence, and renderer UI.
Process model, data flow, and feature placement guide for Anvil so agents can modify the right layer with minimal thrash.
Use for Azure cost analysis, right-sizing, FinOps, SKU selection, reserved instances, and detecting over-engineering. Grounded in Well-Architected Cost Optimisation pillar.
Use when designing a new Azure workload from scratch. Covers gold-standard architecture patterns, Landing Zones, service selection, IaC, observability, and DR. Avoids over-engineering.
Use when evaluating migration of existing systems to Azure. Covers lift-and-shift vs rearchitect decisions, the 5 Rs, phased migration planning, and Azure Migrate tooling.
Use for Azure architecture review, service selection, design decisions, and Well-Architected Framework guidance. Interactive consultant that challenges assumptions and cites Microsoft docs.