Generative Development Framework
GDF.ai
  • Intro to GDF-FSE
    • Generative AI, Large Language Models, ChatGPT?
    • Knowledge Areas
    • Access a Chat Based LLM
    • Why GDF?
    • Expectations
  • Limitations
  • Prompting
    • Prompt Patterns
    • Prompt Context
    • Prompt Stores
    • Prompt Operators
    • Prompt Chaining
  • Security
    • Protecting Data
    • Protecting Application Security
    • Protecting Intellectual Property
    • Protection Stores
    • AI Security Assessments and Penetration Testing
    • Social Engineering Testing with AI
  • Subject Knowledge Areas
    • Ideation
      • Identifying a Problem Statement
      • Plan and Prioritize Features
      • Develop User Stories
      • Requirement Gathering
      • Ideation Prompting
      • Ideation Template
    • Specification
      • Specifying Languages
      • Specifying Libraries
      • Specifying Project Structures
      • Specify Schemas
      • Specifying Elements
      • Specifying API Specs
    • Generation
      • Generating UI Elements
      • Generating Mock Data
      • Generating Schemas
      • Generating Parsers
      • Generating Databases
      • Generate Functions
      • Generate APIs
      • Generate Diagrams
      • Generating Documentation
    • Transformation
      • Converting Languages
      • Converting Libraries
    • Replacement
      • Replacing Functions
      • Replacing Data Types
    • Integration
      • Connecting UI Components
      • Connecting UI to Backend
      • Connecting Multiple Services Together
      • Connecting Cloud Infrastructure (AWS)
    • Separation
      • Abstraction
      • Model View Controller (MVC)
    • Consolidation
      • Combining UI Elements
      • Deduplicating Code Fragments
    • Templating
      • Layouts
      • Schemas
      • Project Structures
      • Content Management Systems
    • Visualization
      • General Styling
      • Visual Referencing
      • Visual Variations
    • Verification
      • Test Classes
      • Logging and Monitoring
      • Automated Testing
      • Synthetic Monitoring
    • Implementation
      • Infrastructure
      • DevOps / Deployment
    • Optimization
      • General Optimization
      • Performance Monitoring
      • Code Review
  • Guidance
    • Business Process
    • Regulatory Guidance
  • Generative Pipelines
  • Troubleshooting
    • Client Side Troubleshooting
    • Server Side Troubleshooting
    • Troubleshooting with AI
    • Documentation
    • Infrastructure Engineering
  • Terminology
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. Subject Knowledge Areas
  2. Specification

Specifying Project Structures

Building out projects structures using AI

Project strcutures are the files and folders that make up your application. The importance of your model knowing your project structure, gives your responses context that ensure prompts from any of the knowledge areas align to the project structure you are working with.

Once you have your language and libraries established, you will want to define your project structure and store it as a prompt store.

In the context of a Next.js application, there are a few common project structures that you can use, depending on your needs. One common structure is to organize your application by feature, with each feature having its own folder. Within each feature folder, you can have sub-folders for components, pages, and utilities. Here's an example:

├── components
│   ├── Button.js
│   ├── Card.js
│   └── ...
├── features
│   ├── auth
│   │   ├── components
│   │   ├── pages
│   │   └── utils
│   ├── profile
│   │   ├── components
│   │   ├── pages
│   │   └── utils
│   └── ...
├── pages
│   ├── index.js
│   ├── _app.js
│   └── ...
├── public
│   ├── images
│   ├── favicon.ico
│   └── ...
├── utils
│   ├── api.js
│   ├── auth.js
│   └── ...
├── .env.local
├── .gitignore
├── next.config.js
├── package.json
├── README.md
└── yarn.lock

In this structure, the components folder contains reusable components that can be used across features. The features folder contains the main functionality of the application, with each feature having its own folder. Each feature folder has a components folder for feature-specific components, a pages folder for feature-specific pages, and a utils folder for feature-specific utility functions.

The pages folder contains the top-level pages of the application, such as the homepage and any other static pages. The _app.js file is used to initialize the application and can be used to set up things like global styles or state providers.

The public folder contains any static assets that should be served directly by the server, such as images or favicon.ico.

The utils folder contains utility functions that can be used across features.

The .env.local file contains environment variables that are specific to the local development environment.

The next.config.js file is used to configure Next.js, such as setting up webpack or configuring plugins.

Here's an example of how you could structure your markdown prompt store based on this project structure:

prompt
remember this project structure:

- components
  - Button.js
  - Card.js
  - ...
- features
  - auth
    - components
    - pages
    - utils
      - auth.js
    - ...
  - profile
    - components
    - pages
    - utils
      - profile.js
    - ...
  - ...
- pages
  - index.js
  - _app.js
  - ...
- public
  - images
  - favicon.ico
  - ...
- utils
  - api.js
  - auth.js
  - ...
- .env.local
- .gitignore
- next.config.js
- package.json
- README.md
- yarn.lock

This way, when your model receives a prompt that references a component or utility function, it can look for it in the appropriate folder based on the project structure.

PreviousSpecifying LibrariesNextSpecify Schemas

Last updated 3 months ago

Was this helpful?