Breakdown Feature Implementation
Turn a Feature PRD into a detailed Markdown implementation plan aligned with Epoch-style monorepo layout, including architecture diagrams—without jumping straight to code.
Overview
breakdown-feature-implementation is an agent skill most often used in Build (also Validate when a PRD is ready) that produces detailed feature implementation plans in Markdown for Epoch-style monorepos from a Feature PRD
Install
npx skills add https://github.com/github/awesome-copilot --skill breakdown-feature-implementationWhat is this skill?
- Outputs Markdown implementation plan to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`
- Epoch monorepo layout: `apps/`, `services/`, `packages/` for front-end and back-end paths
- Per-feature sections: Goal, Requirements, Technical Considerations with Mermaid system architecture
- Explicit rule: do not write production code in output except pseudocode when needed
- Frames work as large-scale SaaS-grade, high-touch feature delivery from a Feature PRD
- Output path pattern: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`
- Monorepo roots: apps/, services/, packages/
Adoption & trust: 8.8k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a Feature PRD but no ordered, repo-aware implementation plan that spans frontend and backend in a monorepo.
Who is it for?
Indie teams shipping SaaS in a monorepo who want PRD-driven plans with explicit file paths and architecture before implementation.
Skip if: Single-file scripts, throwaway prototypes with no PRD, or teams that already have an approved spec and only need ticket-level tasks.
When should I use this skill?
You have a Feature PRD and need a comprehensive implementation plan in Markdown following Epoch monorepo structure without writing feature code.
What do I get? / Deliverables
A saved implementation-plan.md with goals, requirements, technical considerations, and a Mermaid architecture diagram ready for engineering breakdown and coding tasks.
- implementation-plan.md with Goal, Requirements, Technical Considerations
- Mermaid system architecture diagram
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Planning artifacts sit at the handoff from scoped requirements into build execution; canonical shelf is Build → pm because output is an implementation plan for engineering. The skill explicitly targets PRD-to-plan workflows, monorepo folder conventions, and Mermaid architecture—not coding or testing execution.
Where it fits
Convert an approved Feature PRD into a technical plan to sanity-check scope before committing sprint capacity.
Produce the canonical implementation-plan.md under the epic/feature doc path for the team to execute against.
Capture system architecture in Mermaid for onboarding collaborators on a new cross-app feature.
How it compares
Use instead of freeform chat planning when you need a fixed doc path, monorepo structure, and no-code plan output.
Common Questions / FAQ
Who is breakdown-feature-implementation for?
Builders and tech leads in Epoch-like monorepos who need agent help turning PRDs into implementation plans for full-stack features.
When should I use breakdown-feature-implementation?
In Validate once a Feature PRD is drafted, and in Build before coding when you need `/docs/ways-of-work/plan/.../implementation-plan.md` with architecture diagrams.
Is breakdown-feature-implementation safe to install?
It prompts documentation and planning only; review the Security Audits panel on this Prism page and treat PRD content as sensitive if it includes unreleased product details.
SKILL.md
READMESKILL.md - Breakdown Feature Implementation
# Feature Implementation Plan Prompt ## Goal Act as an industry-veteran software engineer responsible for crafting high-touch features for large-scale SaaS companies. Excel at creating detailed technical implementation plans for features based on a Feature PRD. Review the provided context and output a thorough, comprehensive implementation plan. **Note:** Do NOT write code in output unless it's pseudocode for technical situations. ## Output Format The output should be a complete implementation plan in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`. ### File System Folder and file structure for both front-end and back-end repositories following Epoch's monorepo structure: ``` apps/ [app-name]/ services/ [service-name]/ packages/ [package-name]/ ``` ### Implementation Plan For each feature: #### Goal Feature goal described (3-5 sentences) #### Requirements - Detailed feature requirements (bulleted list) - Implementation plan specifics #### Technical Considerations ##### System Architecture Overview Create a comprehensive system architecture diagram using Mermaid that shows how this feature integrates into the overall system. The diagram should include: - **Frontend Layer**: User interface components, state management, and client-side logic - **API Layer**: tRPC endpoints, authentication middleware, input validation, and request routing - **Business Logic Layer**: Service classes, business rules, workflow orchestration, and event handling - **Data Layer**: Database interactions, caching mechanisms, and external API integrations - **Infrastructure Layer**: Docker containers, background services, and deployment components Use subgraphs to organize these layers clearly. Show the data flow between layers with labeled arrows indicating request/response patterns, data transformations, and event flows. Include any feature-specific components, services, or data structures that are unique to this implementation. - **Technology Stack Selection**: Document choice rationale for each layer ``` - **Technology Stack Selection**: Document choice rationale for each layer - **Integration Points**: Define clear boundaries and communication protocols - **Deployment Architecture**: Docker containerization strategy - **Scalability Considerations**: Horizontal and vertical scaling approaches ##### Database Schema Design Create an entity-relationship diagram using Mermaid showing the feature's data model: - **Table Specifications**: Detailed field definitions with types and constraints - **Indexing Strategy**: Performance-critical indexes and their rationale - **Foreign Key Relationships**: Data integrity and referential constraints - **Database Migration Strategy**: Version control and deployment approach ##### API Design - Endpoints with full specifications - Request/response formats with TypeScript types - Authentication and authorization with Stack Auth - Error handling strategies and status codes - Rate limiting and caching strategies ##### Frontend Architecture ###### Component Hierarchy Documentation The component structure will leverage the `shadcn/ui` library for a consistent and accessible foundation. **Layout Structure:** ``` Recipe Library Page ├── Header Section (shadcn: Card) │ ├── Title (shadcn: Typography `h1`) │ ├── Add Recipe Button (shadcn: Button with DropdownMenu) │ │ ├── Manual Entry (DropdownMenuItem) │ │ ├── Import from URL (DropdownMenuItem) │ │ └── Import from PDF (DropdownMenuItem) │ └── Search Input (shadcn: Input with icon) ├── Main Content Area (flex container) │ ├── Filter Sidebar (aside) │ │ ├── Filter Title (shadcn: Typography `h4`) │ │ ├── Category Filters (shadcn: Checkbox group) │ │ ├── Cuisine Filters (shadcn: Checkbox group) │ │ └── Dif