@paroicms/site-generator-plugin/backend/prompts/initial-1-analysis.md

ParoiCMS Site Generator Plugin

You will be given a description of a website's structure. Your task is to **analyze** the website description, then you will generate three things:

1. A JSON object for website properties.
2. A Markdown bulleted list that represents the hierarchy of node types (routing documents, regular documents and parts) within the site.
3. A JSON object to describe each node type.

Here is the website description:

<user_message>
{{message}}
</user_message>

Notice: If the website description doesn't mention a _contact page_ and a _search page_, then append them by default as routing documents, children of the home page.

## Step 1 - Instructions for the website properties JSON

In the first step, you are tasked to write global properties of the website as a JSON object.

Provide the following website properties:

- language: The language used in <user_message>, as a two-letters code. This is the website language.
- title: The website title, in the _website language_.
- theme: A description (5-40 words) that can be used as a tooltip to explain the main theme and/or purpose of the website. Write it in the _website language_.

In the following, we will refer to the term **website language** when we need it.

## Step 2 - Instructions for the hierarchical bulleted list

For this second step, follow these instructions for creating the bullet list:

1. Carefully read and analyze the website description.
2. Identify the main documents and parts of the website.
3. Determine the hierarchical relationships between documents and parts.
4. Create a tree structure using a limited Markdown format to represent the website's tree structure.

Guidelines for creating the hierarchical bullet list:

- Write in English.
  - But, if the website description is not in English: do not translate book or post titles.
- Use a Markdown syntax. Indent with 2 spaces. Use indentation to show parent-child relationships between node types.
- Always start with the homepage, with key `home` at the top level.
- When you define an identifier for a node type name or a list name, use camel case and follow the identifier syntax of JavaScript.
  - Use `contactPage` as the default type name for contact page, and `searchPage` for the search page.
- Bullet point format for a _routing document_:
  - Start with a **bullet** (*).
  - Write the **type name** within backquotes.
  - End with `(routing document)`.
- Bullet point format for a list of _regular documents_:
  - Start with a **bullet** (*).
  - Write `"list of"`, and then the **type name** within backquotes.
  - End with `(regular documents)`.
- Bullet point format for a list of _parts_:
  - Start with a **bullet** (*).
  - Write `"list of"`, and then the **type name** within backquotes.
  - Append `(parts)`.
  - Add a coma, then write: `"list name:"` and append an identifier for the list name.
- Avoid recursivity. But if you can't avoid reusing a node type, then write its children only on the first occurence.
- On this task, do not focus on fields. If the website description provide fields then you will report them in the unused information. In particular, a collection of medias (a carousel, a slider, an image gallery, a slideshow, etc.) is a type of field.
- Don't try to provide a comment mechanism when the user requests a blog. Blog comments do not belong to the hierarchy of node types.
- NEVER ever reuse the same type name for 2 distinct node type. Pay particular attention to words spelled identically in the singular and plural. Each distinct node type must have a unique name through the whole tree structure.

Here are examples of correct outputs:

<correct_example>
- `home` (routing document)
  - `pages` (routing document)
    - list of `page` (regular documents)
</correct_example>

<correct_example>
- `home` (routing document)
  - `myPage1` (routing document)
  - `myPage2` (routing document)
</correct_example>

Here's an example of an incorrect output:

<incorrect_example>
- `home` (routing document)
  - `pages` (regular document)
    - list of `page` (regular documents)
</incorrect_example>

This incorrect example fails because the `pages` node type can't be a single regular document. Regular documents are always items in a list.

Here is another incorrect example:

<incorrect_example>
- `home` (routing document)
  - `species` (routing document)
    - list of `species` (regular documents)
</incorrect_example>

This incorrect example fails because the type name `species` is used for 2 different types. You can distinguish them by suffixing both the collection and the item types:

<correct_example>
- `home` (routing document)
  - `speciesColl` (routing document)
    - list of `speciesItem` (regular documents)
</correct_example>

Here's an example of correct output using parts, and with the default contact and search pages:

<correct_example>
- `home` (routing document)
  - list of `homeSection` (parts), list name: `homeSections`
  - `news` (routing document)
    - list of `post` (regular documents)
    - `tags` (routing document)
      - list of `tag` (regular documents)
  - `pages` (routing document)
    - list of `page` (regular documents)
      - list of `pageSection` (parts), list name: `pageSections`
  - `contactPage` (routing document)
  - `searchPage` (routing document)
</correct_example>

### Keep it simple

When you have a choice, keep it simple. If the user lets you invent the site's structure, limit the site's sections to **2 main entries**. For example, a “news” routing document with a list of articles and categories, and a list of pages on the site's theme. Plus the usual contact and search pages.

## Step 3 - Instructions for the dictionary JSON

In the third step, you are tasked to produce a JSON object that describes every node type and list of parts identified in the hierarchical markdown.

Guidelines for creating the dictionary JSON:

- Use JSON syntax.
- Keys: each key is the name of a node type or the name of a list of parts.
- If the same type is reused several times, then write only one entry in this dictionnary.
- Values contains the properties. For a node type, provide the following properties:
  - confidence: Your confidence level for the accuracy of this node type (0.0-1.0).
  - kind: Can be `routingDocument`, `regularDocument`, `part`.
  - entryPage: A Boolean indicating whether this is one of the very few first pages the visitor lands on (optional, routing document only).
  - taxonomy: A boolean to indicate if this is a taxonomy (optional, routing document only).
  - temporal: A boolean to indicate if there is a temporal nature for this type of node (optional, regular document only).
  - jsonLdType (optional, document only): The schema.org type for JSON-LD structured data. Use PascalCase values. Allowed values: `"Article"` for blog posts or news articles, `"BlogPosting"` for blog posts specifically, `"Product"` for product pages, `"AboutPage"` for about pages, `"ContactPage"` for contact pages, `"ProfilePage"` for author/profile pages, `"CollectionPage"` for category/tag pages etc., `"SearchResultsPage"` for search pages. Omit for other or generic pages.
  - label: A label of the node type, in the _website language_.
  - description: A description (5-40 words) for describing the purpose and theme of the node type. Write it in the _website language_.
  - prompt: This is an optional property. If there is an information to process later about this node type (a description of fields), then write it here. Keep is short, and in English.
- For a list type (only for part list, never for document list), provide the following properties:
  - confidence: Your confidence level for the accuracy of this node type (0.0-1.0).
  - kind: Must be `partList`.
  - label: A label of the list type, in the _website language_.
  - description: A description (5-40 words) for describing the purpose and theme of the list type. Write it in the _website language_.

Here is an example of expected output:

<correct_example>
{
  "home": {
    "confidence": 1,
    "kind": "routingDocument",
    "entryPage": true,
    "label": "Home page",
    "description": "This is the home page of the website."
  },
  "homeSections": {
    "confidence": 0.9,
    "kind": "partList",
    "label": "Sections",
    "description": "This list contains the main sections of the home page."
  },
  "homeSection": {
    "confidence": 0.7,
    "kind": "part",
    "label": "Section",
    "description": "A home section is a sub-part of the home page."
  },
  "pages": {
    "confidence": 0.9,
    "kind": "routingDocument",
    "label": "Pages",
    "description": "This is the document for grouping all pages."
  },
  "page": {
    "confidence": 0.9,
    "kind": "regularDocument",
    "temporal": false,
    "label": "Page",
    "description": "..."
  },
  "pageSections": {
    "confidence": 0.9,
    "kind": "partList",
    "label": "Sections",
    "description": "..."
  },
  "pageSection": {
    "confidence": 0.8,
    "kind": "part",
    "label": "Section",
    "description": "..."
  }
}
</correct_example>

Here is how to specify posts with a "tags" taxonomy:

<correct_example>
{
  "news": {
    "confidence": 1,
    "kind": "routingDocument",
    "entryPage": true,
    "label": "News",
    "description": "This is the blog section of the website. The news document contains all the topical posts."
  },
  "post": {
    "confidence": 0.8,
    "kind": "regularDocument",
    "temporal": true,
    "jsonLdType": "Article",
    "label": "Post",
    "description": "A topical post about the subject of the website whatever it is.",
    "prompt": "Add a labeling field using the tags taxonomy (allow multiple tags)"
  },
  "tags": {
    "confidence": 0.9,
    "kind": "routingDocument",
    "taxonomy": true,
    "label": "Tags",
    "description": "Tags taxonomy for post documents."
  },
  "tag": {
    "confidence": 0.9,
    "kind": "regularDocument",
    "temporal": false,
    "label": "Tag",
    "description": "A tag is a term in the tags taxonomy."
  }
}
</correct_example>

Note the `prompt` property in the `post` type: in this way, tags can be assigned to a post.

# Producing outputs

Before providing your final answer, use the scratchpad to organize your thoughts and plan the structure:

<scratchpad>
[Use this space to analyze the website description, identify node types, and plan the hierarchy]
</scratchpad>

Once you have organized your thoughts, provide the JSON for website properties (step 1) within <website_properties_json> tags.

Then, provide the mardown representing the website tree structure (step 2) within <hierarchical_md> tags.

Provide the node types properties (step 3) within <dictionary_json> tags.

Also, write a short explanation of your choices regarding the 3 steps, within <explanation_md> tags. Write the explanation in markdown and in the website description language. Your explanation message will be shown to the end-user as a message in a chat. The user will also see the website structure and its properties, so don't repeat descriptions, don't describe choices when they're obvious. Be as succinct as possible. If there is nothing valuable to say, then let this tag empty.

Finally, extract and rephrase within <unused_information_md> tags the information from the site description that you weren't able to use in the previous elements, in the form of a short prompt, in markdown format. Do not invent anything. Do not imagine anything. If you used every valuable information, then let this tag empty.

Do not include any other explanation or commentary outside these tags.