Skip to content

Commit 7eb0ca2

Browse files
electrocucarachaelectrocucaracha
committed
Add semantic line break prompt
1 parent dd06e7b commit 7eb0ca2

File tree

7 files changed

+191
-49
lines changed

7 files changed

+191
-49
lines changed

‎.github/prompts/sembr.prompt.md‎

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
---
2+
mode: "agent"
3+
description: "Agent that reformats Markdown files using Semantic Line Breaks according to the full SemBr specification. The output must be raw Markdown with applied semantic line breaks. Do not parse or interpret the output."
4+
---
5+
6+
# Task
7+
8+
Apply **Semantic Line Breaks (SemBr)** to all Markdown (`.md`) documents in the current project.
9+
The output must be **raw Markdown** text, rewritten according to the specification below.
10+
Do not include explanations, parsing, summaries, or comments — only return the rewritten Markdown document(s).
11+
12+
## Specification
13+
14+
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
15+
16+
1. Text written as plain text or a compatible markup language MAY use semantic line breaks.
17+
2. A semantic line break MUST NOT alter the final rendered output of the document.
18+
3. A semantic line break SHOULD NOT alter the intended meaning of the text.
19+
4. A semantic line break MUST occur after a sentence, as punctuated by a period (.), exclamation mark (!), or question mark (?).
20+
5. A semantic line break SHOULD occur after an independent clause as punctuated by a comma (,), semicolon (;), colon (:), or em dash (—).
21+
6. A semantic line break MAY occur after a dependent clause in order to clarify grammatical structure or satisfy line length constraints.
22+
7. A semantic line break is RECOMMENDED before an enumerated or itemized list.
23+
8. A semantic line break MAY be used after one or more items in a list in order to logically group related items or satisfy line length constraints.
24+
9. A semantic line break MUST NOT occur within a hyphenated word.
25+
10. A semantic line break MAY occur before and after a hyperlink.
26+
11. A semantic line break MAY occur before inline markup.
27+
12. A maximum line length of 80 characters is RECOMMENDED.
28+
13. A line MAY exceed the maximum line length if necessary, such as to accommodate hyperlinks, code elements, or other markup.
29+
30+
## Goals
31+
32+
1. For Writers: The agent SHALL structure Markdown text so that the physical layout of lines reflects the logical and semantic structure of the author’s thoughts.
33+
2. For Editors: The agent SHALL produce output that makes grammatical and structural relationships easier to identify, supporting clear and efficient editing without changing meaning.
34+
3. For Readers: The agent SHALL ensure that applied semantic line breaks do not alter the rendered appearance or interpretation of the text in any Markdown renderer.
35+
36+
Prompt instructions file:
37+
38+
# Task
39+
40+
Apply **Semantic Line Breaks (SemBr)** to all Markdown (`.md`) documents in
41+
the current project.
42+
43+
The output must be **raw Markdown** text, rewritten according to the
44+
specification below.
45+
46+
Do not include explanations, parsing, summaries, or comments — only return
47+
the rewritten Markdown document(s).
48+
49+
## Specification
50+
51+
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
52+
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
53+
document are to be interpreted as described in RFC 2119.
54+
55+
1. Text written as plain text or a compatible markup language MAY use
56+
semantic line breaks.
57+
2. A semantic line break MUST NOT alter the final rendered output of the
58+
document.
59+
3. A semantic line break SHOULD NOT alter the intended meaning of the text.
60+
4. A semantic line break MUST occur after a sentence, as punctuated by a
61+
period (.), exclamation mark (!), or question mark (?).
62+
5. A semantic line break SHOULD occur after an independent clause as
63+
punctuated by a comma (,), semicolon (;), colon (:), or em dash (—).
64+
6. A semantic line break MAY occur after a dependent clause in order to
65+
clarify grammatical structure or satisfy line length constraints.
66+
7. A semantic line break is RECOMMENDED before an enumerated or itemized
67+
list.
68+
8. A semantic line break MAY be used after one or more items in a list in
69+
order to logically group related items or satisfy line length
70+
constraints.
71+
9. A semantic line break MUST NOT occur within a hyphenated word.
72+
10. A semantic line break MAY occur before and after a hyperlink.
73+
11. A semantic line break MAY occur before inline markup.
74+
12. A maximum line length of 80 characters is RECOMMENDED.
75+
13. A line MAY exceed the maximum line length if necessary, such as to
76+
accommodate hyperlinks, code elements, or other markup.
77+
78+
## Goals
79+
80+
1. For Writers: The agent SHALL structure Markdown text so that the
81+
physical layout of lines reflects the logical and semantic structure of
82+
the author’s thoughts.
83+
2. For Editors: The agent SHALL produce output that makes grammatical and
84+
structural relationships easier to identify, supporting clear and
85+
efficient editing without changing meaning.
86+
3. For Readers: The agent SHALL ensure that applied semantic line breaks
87+
do not alter the rendered appearance or interpretation of the text in
88+
any Markdown renderer.
89+
90+
## Formatting Rules
91+
92+
- Preserve existing Markdown structure (headings, lists, code blocks,
93+
tables, HTML, etc.).
94+
- Skip fenced code blocks, inline code, and HTML verbatim.
95+
- Maintain paragraph integrity — do not insert empty lines unless
96+
already present.
97+
- When in doubt, prefer breaking after complete thoughts or clauses.
98+
- Output only the transformed Markdown content — do not add any metadata,
99+
explanations, or syntax highlighting.
100+
101+
## Input
102+
103+
Markdown file(s) from the workspace.
104+
105+
## Output
106+
107+
Raw Markdown text with Semantic Line Breaks applied.
108+
109+
Do **not** parse, explain, or wrap the output — return only the processed
110+
Markdown content.
111+
112+
##
113+
114+
```"""
115+
116+
```

‎.github/workflows/README.md‎

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,15 @@
11
# Available workflows
22

3-
| Workflow file | Description | Run event |
4-
| :------------------------------------- | ------------------------------------------------------------------------- | -------------------------------------- |
5-
| [build](./build.yml) | Validates Kolla Docker images build and publish process | on new commit/scheduled/manual trigger |
6-
| [diagram](./diagram.yml) | Generates the codebase diagram used by the main README.md file | on new commit/push on master |
7-
| [distros](./distros.yml) | Updates the Vagrant box versions for Distro list supported file | scheduled/manual trigger |
8-
| [linter](./linter.yml) | Counts Line of Codes, verifies broken links in docs and runs linter tools | on new commit/push on master |
9-
| [on-demand_aio](./on-demand_aio.yml) | Runs upgrade process in all in one setups in different supported distros | on new commit/push on master |
10-
| [on-demand_noha](./on-demand_noha.yml) | Runs integration tests for No High Availability setup | on new commit/push on master |
11-
| [on-demand](./on-demand.yml) | Verifies Bash scripts format | on new commit/push on master |
12-
| [rebase](./rebase.yml) | Helps to rebase changes of the Pull request | manual trigger |
13-
| [scheduled_aio](./scheduled_aio.yml) | Verifies all in one setups inf different supported distros | scheduled/manual trigger |
14-
| [spell](./spell.yml) | Verifies spelling errors on documentation | on new commit/push on master |
15-
| [update](./update.yml) | Updates python requirements files and word list in the dict. | scheduled/manual trigger |
3+
| Workflow file | Description | Run event |
4+
| :------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------- |
5+
| [build](./build.yml) | Validates Kolla Docker images build and publish process | on new commit, scheduled or manual |
6+
| [diagram](./diagram.yml) | Generates the codebase diagram used by the main README.md file | on new commit or push on master |
7+
| [distros](./distros.yml) | Updates the Vagrant box versions for Distro list supported file | scheduled or manual trigger |
8+
| [linter](./linter.yml) | Counts lines of code, verifies broken links in docs and runs linter tools | on new commit or push on master |
9+
| [on-demand_aio](./on-demand_aio.yml) | Runs upgrade process in all-in-one setups in different supported distros | on new commit or push on master |
10+
| [on-demand_noha](./on-demand_noha.yml) | Runs integration tests for No High Availability setup | on new commit or push on master |
11+
| [on-demand](./on-demand.yml) | Verifies Bash scripts format | on new commit or push on master |
12+
| [rebase](./rebase.yml) | Helps to rebase changes of the Pull Request | manual trigger |
13+
| [scheduled_aio](./scheduled_aio.yml) | Verifies all-in-one setups in different supported distros | scheduled or manual trigger |
14+
| [spell](./spell.yml) | Verifies spelling errors on documentation | on new commit or push on master |
15+
| [update](./update.yml) | Updates Python requirements files and word list in the dictionary | scheduled or manual trigger |

‎doc/src/neutron/network_types.md‎

Lines changed: 29 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,22 @@
11
# Networks
22

3-
To configure rich network topologies, you can create and configure networks and
4-
subnets and instruct other OpenStack services like Compute to attach virtual
5-
devices to ports on these networks.
3+
To configure rich network topologies, you can create and configure networks
4+
and subnets, and instruct other OpenStack services like Compute to attach
5+
virtual devices to ports on these networks.
66

77
## Provider Networks
88

9-
Provider networks offer layer-2 connectivity to instances with optional support
10-
for DHCP and metadata services. These networks connect, or map, to existing
11-
layer-2 networks in the data center, typically using VLAN (802.1q) tagging to
12-
identify and separate them.
9+
Provider networks offer layer-2 connectivity to instances, with optional
10+
support for DHCP and metadata services.
1311

14-
- By default only administrators can create or update provider networks because
12+
These networks connect, or map, to existing layer-2 networks in the data
13+
center, typically using VLAN (802.1q) tagging to identify and separate them.
14+
15+
- By default, only administrators can create or update provider networks because
1516
they require configuration of physical network infrastructure.
16-
- Provider networks only handle layer-2 connectivity for instances, thus lacking
17-
support for features such as routers and floating IP addresses.
18-
- When a provider network is shared by an administrator, a project, user can
17+
- Provider networks only handle layer-2 connectivity for instances, thus
18+
lacking support for features such as routers and floating IP addresses.
19+
- When a provider network is shared by an administrator, a project user can
1920
view and attach their instances to it.
2021

2122
## Self-service or Tenant/Project Networks
@@ -25,17 +26,18 @@ manage networks without involving administrators.
2526

2627
- These networks are entirely virtual and require virtual routers to interact
2728
with provider and external networks such as the internet.
28-
- Usually provide DHCP and metadata services to instances.
29+
- They usually provide DHCP and metadata services to instances.
2930
- In most cases, self-service networks use overlay protocols such as VXLAN or
30-
GRE because they can support many more networks than layer-2 segmentation using
31-
VLAN tagging (802.1q).
31+
GRE because they can support many more networks than layer-2 segmentation
32+
using VLAN tagging (802.1q).
3233
- Floating IP addresses enable access to instances from provider networks via
3334
destination NAT on virtual routers.
3435
- Contrary to provider networks that connect instances to the physical network
35-
infrastructure at layer-2, self-service networks must traverse a layer-3 agent.
36+
infrastructure at layer-2, self-service networks must traverse a layer-3
37+
agent.
3638

37-
Created by OpenStack users. Neutron automatically select a network
38-
segmentation type like VXLAN or VLAN and users cannot select the segmentation
39+
Created by OpenStack users, Neutron automatically selects a network
40+
segmentation type like VXLAN or VLAN; users cannot select the segmentation
3941
type.
4042

4143
The user in a project can articulate their own networking topology, completely
@@ -45,15 +47,18 @@ IPs and other technologies.
4547
## Summary
4648

4749
The primary difference between self-service and provider networks revolves
48-
around who provisions them. Provider networks are created by the OpenStack
49-
administrator on behalf of tenants and can be dedicated to a particular tenant,
50-
shared by a subset of tenants (see RBAC for networks) or shared by all tenants.
51-
On the other hand, self-service networks are created by tenants for use by their
52-
instances and cannot be shared (based upon default policy settings).
50+
around who provisions them.
51+
52+
Provider networks are created by the OpenStack administrator on behalf of
53+
tenants, and can be dedicated to a particular tenant, shared by a subset of
54+
tenants (see RBAC for networks), or shared by all tenants.
55+
56+
On the other hand, self-service networks are created by tenants for use by
57+
their instances and cannot be shared based upon default policy settings.
5358

5459
| external-router | shared | Description |
5560
| :-------------: | :----: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
5661
| false | false | Only usable by members of the tenant. Typically an overlay (vxlan, gre). |
5762
| false | true | Shared by multiple tenants with RBAC on who can use it. Typically an overlay (vxlan, gre). |
58-
| true | false | Scope is all tenants. Can only be created by administrators. Tenants connect their router for external access. Typically a ‘flat’ or ‘vlan’ network. |
59-
| true | true | Scope is all tenants. Can only be created by administrators. Tenants can connect directly to it. Typically known as a ‘provider’ network and is ‘flat’ or ‘vlan.’ |
63+
| true | false | Scope is all tenants. Can only be created by administrators. Tenants connect their router for external access. Typically a 'flat' or 'vlan' network. |
64+
| true | true | Scope is all tenants. Can only be created by administrators. Tenants can connect directly to it. Typically known as a 'provider' network and is 'flat' or 'vlan.' |

‎samples/README.md‎

Lines changed: 17 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,20 @@
1-
# Vagrant Configurations
1+
# Samples
2+
3+
This folder contains several Vagrant configurations which can be used to
4+
provision Virtual Machines for testing different deployment
5+
configurations.
6+
7+
Each sample contains a `README.md` file with specific instructions.
8+
9+
The current samples are:
10+
11+
- `aio`: All-in-one configuration
12+
- `noha`: No High Availability configuration
13+
- `distributed`: Distributed configuration
14+
15+
See the specific sample folders for more details.
16+
17+
## Vagrant Configuration
218

319
This project provides configurations which have been validated
420
using [Vagrant tool][1] on Virtual Machines provisioned on VirtualBox

‎samples/aio/README.md‎

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,10 @@
11
# OpenStack All-in-One Configuration
22

3-
This configuration was designed to host the OpenStack services in an [Intel's
4-
NUC 10 Performance kit][1]. The [provisioning process](../../install.sh) pulls
5-
the official Kolla images and deploys them in a CentOS 7 using the [undercloud
3+
This configuration was designed to host the OpenStack services in an
4+
[Intel's NUC 10 Performance kit][1].
5+
6+
The [provisioning process](../../install.sh) pulls the official Kolla
7+
images and deploys them in a CentOS 7 using the [undercloud
68
script](../../undercloud.sh).
79

810
The following diagram displays the Networking configuration created by

‎samples/distributed/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
## Host System Requirements
66

77
The system that will host VMs for the solution must be big enough to
8-
support the +10 Virtual Machines displayed at above diagram.
8+
support the 10+ Virtual Machines displayed in the diagram above.
99

1010
Some configuration details can be configured for the _Distributed_
1111
setup using its [PDF](pdf.yml).

‎samples/noha/README.md‎

Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,13 @@
11
# OpenStack No High Availability Configuration
22

3-
This configuration was designed to create a minimal OpenStack cluster using
4-
[Raspberry Pi 4 Model B][1] without High Availability. The [provisioning
5-
process](../../install.sh) is executed on the Controller node and creates a
6-
local registry on it using the [registry script](../../registry.sh) and deploys
7-
OpenStack services using the [undercloud script](../../undercloud.sh).
3+
This configuration was designed to create a minimal OpenStack cluster
4+
using a [Raspberry Pi 4 Model B][1] without High Availability.
5+
6+
The [provisioning process](../../install.sh) is executed on the
7+
Controller node.
8+
It creates a local registry on it using the [registry script](../../registry.sh)
9+
and deploys OpenStack services using the [undercloud
10+
script](../../undercloud.sh).
811

912
The following diagram shows the distribution of OpenStack Kolla containers
1013
created by this configuration.
@@ -28,8 +31,8 @@ vagrant up controller
2831

2932
### Environment variables
3033

31-
This table displays the environment variables used to configure some aspects of
32-
the cluster, hardware resources and workflow.
34+
This table displays the environment variables used to configure some aspects
35+
of the cluster, hardware resources and workflow.
3336

3437
| Name | Default | Description |
3538
| :----------------------- | :------ | :------------------------------------------------------------------------------------------------------------ |

0 commit comments

Comments
 (0)