Commit 2f192085 authored by Jan Reimes's avatar Jan Reimes
Browse files

style(skills): standardize metadata formatting and improve readability 

- Updated SKILL.md files across various 3GPP skills to unify metadata format.
- Changed description and related fields to a consistent structure.
- Enhanced readability by adjusting list formatting in workflow.md and README.md.
parent 82b2fe01

.config/skills/3gpp/3gpp-basics/SKILL.md

+3 −9
Original line number Diff line number Diff line 
---

name: 3gpp-basics

description: General 3GPP organization overview, partnerships, scope, and fundamental concepts. Use when working with 3GPP data structures, understanding 3GPP hierarchy, or needing context about 3GPP as an organization.

related: 

  - 3gpp-working-groups

  - 3gpp-meetings

  - 3gpp-tdocs

  - 3gpp-portal-authentication

---

______________________________________________________________________



## name: 3gpp-basics description: General 3GPP organization overview, partnerships, scope, and fundamental concepts. Use when working with 3GPP data structures, understanding 3GPP hierarchy, or needing context about 3GPP as an organization. metadata: related: [3gpp-working-groups, 3gpp-meetings, 3gpp-tdocs, 3gpp-portal-authentication]



# 3GPP Basics

.config/skills/3gpp/3gpp-change-request/SKILL.md

+55 −63
Original line number Diff line number Diff line 
---

name: 3gpp-change-request

description: Change Request procedure, workflow, status tracking, CR database, and step-by-step instructions. Use when working with 3GPP Change Requests to modify specifications, understanding CR lifecycle, or querying CR status.

related:

  - 3gpp-specifications

  - 3gpp-basics

  - 3gpp-working-groups

  - 3gpp-tdocs

  - 3gpp-portal-authentication

  - 3gpp-releases

---

______________________________________________________________________



## name: 3gpp-change-request description: Change Request procedure, workflow, status tracking, CR database, and step-by-step instructions. Use when working with 3GPP Change Requests to modify specifications, understanding CR lifecycle, or querying CR status. metadata: related: [3gpp-specifications, 3gpp-basics, 3gpp-working-groups, 3gpp-tdocs, 3gpp-portal-authentication, 3gpp-releases]



# 3GPP Change Requests - Reference
@@ -31,17 +23,17 @@ A CR is a **temporary document** (tdoc) to a meeting which specifies in precise 
Three main reasons for creating a CR:



1. **Add a new feature** to a Release still under development

2. **Correct / clarify / enhance** an existing feature in a Release still under development

3. **Correct an error** in a spec which is functionally frozen

1. **Correct / clarify / enhance** an existing feature in a Release still under development

1. **Correct an error** in a spec which is functionally frozen



## CR Development and Approval



### Submission Process



1. **WG Level**: Any 3GPP member organization can propose a CR to the Working Group responsible for the spec

2. **WG Agreement**: WG discusses and agrees CR is valid and required

3. **TSG Approval**: WG presents CR to parent TSG plenary for final approval

4. **MCC Incorporation**: After TSG approval, 3GPP Support Team (MCC) incorporates CR into new spec version

1. **WG Agreement**: WG discusses and agrees CR is valid and required

1. **TSG Approval**: WG presents CR to parent TSG plenary for final approval

1. **MCC Incorporation**: After TSG approval, 3GPP Support Team (MCC) incorporates CR into new spec version



### CR Status Meanings
@@ -110,24 +102,24 @@ Each spec maintains a history box listing all CRs that have been approved for th 
**Key Sections:**



1. Header (meeting details, WG document number)

2. Spec number, CR number

3. CR revision number (for revised CRs only)

4. Current version

5. Title

6. Source to WG

7. Source to TSG

8. Work item code

9. Date

10. Category

11. Release

12. Consequences if not approved

13. Clauses affected

14. Other specs affected

15. Other comments

16. CR revision history

17. Filename convention

18. Body of CR

19. Other considerations

1. Spec number, CR number

1. CR revision number (for revised CRs only)

1. Current version

1. Title

1. Source to WG

1. Source to TSG

1. Work item code

1. Date

1. Category

1. Release

1. Consequences if not approved

1. Clauses affected

1. Other specs affected

1. Other comments

1. CR revision history

1. Filename convention

1. Body of CR

1. Other considerations



## CR Categories
@@ -175,25 +167,25 @@ Each CR must be associated with a **Work Item (WI) code**: 
## CR Submission Checklist



1. [ ] Unique_ID value from Work Item

2. [ ] TDoc number of Work Item Description (WID) document

3. [ ] Name of rapporteur for TS/TR (or contact coords for TR)

4. [ ] Target date from WID (approval date)

5. [ ] Source to WG (responsible 3GPP member)

6. [ ] Source to TSG (if presented directly to TSG)

7. [ ] Work item code (from WI list)

8. [ ] Release (one only)

9. [ ] Category (TEI for technical enhancements)

10. [ ] Title (descriptive, not redundant)

11. [ ] Reason for change

12. [ ] Summary of changes

13. [ ] Consequences if not approved

14. [ ] Clauses affected (list individually)

15. [ ] Other specs affected

16. [ ] Other comments (optional)

17. [ ] Date (format: yyyy-MM-dd)

18. [ ] Release (Rel-4, Rel-5, etc.)

19. [ ] (U)SIM - ME/UE - Radio Access Network - Core Network checkboxes

20. [ ] UICC field (change to (U)SIM or ISIM)

1. [ ] TDoc number of Work Item Description (WID) document

1. [ ] Name of rapporteur for TS/TR (or contact coords for TR)

1. [ ] Target date from WID (approval date)

1. [ ] Source to WG (responsible 3GPP member)

1. [ ] Source to TSG (if presented directly to TSG)

1. [ ] Work item code (from WI list)

1. [ ] Release (one only)

1. [ ] Category (TEI for technical enhancements)

1. [ ] Title (descriptive, not redundant)

1. [ ] Reason for change

1. [ ] Summary of changes

1. [ ] Consequences if not approved

1. [ ] Clauses affected (list individually)

1. [ ] Other specs affected

1. [ ] Other comments (optional)

1. [ ] Date (format: yyyy-MM-dd)

1. [ ] Release (Rel-4, Rel-5, etc.)

1. [ ] (U)SIM - ME/UE - Radio Access Network - Core Network checkboxes

1. [ ] UICC field (change to (U)SIM or ISIM)



### CR Revision History
@@ -257,20 +249,20 @@ New spec version becomes available 
## Common Pitfalls



1. **Multiple Releases**: One spec may be maintained in multiple Releases

2. **Parallel CRs**: Need separate CRs for each Release with same WI code

3. **Editorial Changes**: Use "dot-one" versions, not full CRs

4. **Wrong Release**: Can't use Release 6 WI code for Release 4 spec

5. **Out-of-date Specs**: Writing CR to old version that's been updated

1. **Parallel CRs**: Need separate CRs for each Release with same WI code

1. **Editorial Changes**: Use "dot-one" versions, not full CRs

1. **Wrong Release**: Can't use Release 6 WI code for Release 4 spec

1. **Out-of-date Specs**: Writing CR to old version that's been updated



## Best Practices



1. **Always use WI codes** from official list

2. **Check spec version** before writing CR (is it in Release 4, Release 5, or current?)

3. **Target correct Release**: Each CR should target only one Release (unless mirror CR)

4. **Use proper categories**: TEI for technical enhancements, F for correctives

5. **Mirror CR requirements**: Include mirror CRs for all affected Releases if maintaining parallel versions

6. **Document revisions**: Use CR revision history field for tracking changes

7. **Format dates correctly**: Use `yyyy-MM-DD` format

1. **Check spec version** before writing CR (is it in Release 4, Release 5, or current?)

1. **Target correct Release**: Each CR should target only one Release (unless mirror CR)

1. **Use proper categories**: TEI for technical enhancements, F for correctives

1. **Mirror CR requirements**: Include mirror CRs for all affected Releases if maintaining parallel versions

1. **Document revisions**: Use CR revision history field for tracking changes

1. **Format dates correctly**: Use `yyyy-MM-DD` format



## Cross-References

.config/skills/3gpp/3gpp-change-request/workflow.md

+3 −3
Original line number Diff line number Diff line
@@ -84,9 +84,9 @@ Essential fields for CR submission: 
## Common Pitfalls



1. **Wrong Release**: Can't use Rel-6 WI code for Rel-4 spec

2. **Missing mirrors**: Need separate CR for each Release if spec is in multiple

3. **Out-of-date base**: Writing CR against old version that's been updated

4. **Wrong category**: Use TEI for enhancements, F for corrections

1. **Missing mirrors**: Need separate CR for each Release if spec is in multiple

1. **Out-of-date base**: Writing CR against old version that's been updated

1. **Wrong category**: Use TEI for enhancements, F for corrections



## See Also

.config/skills/3gpp/3gpp-meetings/SKILL.md

+21 −27
Original line number Diff line number Diff line 
---

name: 3gpp-meetings

description: Meeting structure, naming conventions, quarterly plenaries, and meeting pages. Use when parsing 3GPP meeting data, understanding meeting schedules, or working with meeting metadata from 3GPP portal.

related: 

  - 3gpp-basics

  - 3gpp-working-groups

  - 3gpp-tdocs

  - 3gpp-portal-authentication

---

______________________________________________________________________



## name: 3gpp-meetings description: Meeting structure, naming conventions, quarterly plenaries, and meeting pages. Use when parsing 3GPP meeting data, understanding meeting schedules, or working with meeting metadata from 3GPP portal. metadata: related: [3gpp-basics, 3gpp-working-groups, 3gpp-tdocs, 3gpp-portal-authentication]



# 3GPP Meetings
@@ -92,12 +86,12 @@ Each meeting list page contains an HTML table with the following columns: 
### Columns



1. **Meeting** - Short name (link to meeting details)

2. **Start Date** - Meeting start date

3. **End Date** - Meeting end date (if multi-day)

4. **Location** - Physical location

5. **Status** - Meeting status (e.g., "Upcoming", "Held")

6. **Files** - Link to TDoc FTP directory (CRITICAL for TDoc crawling)

7. **Registration** - Registration deadline

1. **Start Date** - Meeting start date

1. **End Date** - Meeting end date (if multi-day)

1. **Location** - Physical location

1. **Status** - Meeting status (e.g., "Upcoming", "Held")

1. **Files** - Link to TDoc FTP directory (CRITICAL for TDoc crawling)

1. **Registration** - Registration deadline



### Files Column - Critical for TDoc Crawling
@@ -126,8 +120,8 @@ Meeting dates in the portal tables are in various formats: 
### Registration Process



1. **Registration Deadline**: Usually 2-3 weeks before meeting

2. **Check-in**: On-site registration at venue

3. **Meeting Documents Templates**: Available from 3GPP portal

1. **Check-in**: On-site registration at venue

1. **Meeting Documents Templates**: Available from 3GPP portal



**Resources:**
@@ -155,26 +149,26 @@ The 3GPP Meeting Calendar is available on the 3GU Portal: 
## Common Mistakes



1. **Using meeting name for database lookups** - Always use `meeting_id` integer

2. **Parsing date strings directly** - Normalize to ISO format first

3. **Skipping empty Files column** - Don't attempt crawl, skip meeting

4. **Year format changes** - Early years use different conventions

1. **Parsing date strings directly** - Normalize to ISO format first

1. **Skipping empty Files column** - Don't attempt crawl, skip meeting

1. **Year format changes** - Early years use different conventions



## Best Practices



### When Working with Meeting Data



1. **Use meeting_id Integer**: Primary key for database operations

2. **Do NOT parse meeting names**: Use for display only

3. **Check Files column**: Before attempting TDoc crawl

4. **Normalize dates**: Store as ISO format in database

5. **Handle empty Files column**: Skip meeting if no TDocs available

1. **Do NOT parse meeting names**: Use for display only

1. **Check Files column**: Before attempting TDoc crawl

1. **Normalize dates**: Store as ISO format in database

1. **Handle empty Files column**: Skip meeting if no TDocs available



### Common Pitfalls



1. **Parsing meeting names**: Different formats (e.g., `SA4#134` vs `SA4-e`) cannot be reliably parsed

2. **Date format inconsistency**: Multiple formats in portal tables

3. **Empty Files column**: Don't attempt TDoc crawl for meetings without files

4. **Year format changes**: Early years use different conventions

1. **Date format inconsistency**: Multiple formats in portal tables

1. **Empty Files column**: Don't attempt TDoc crawl for meetings without files

1. **Year format changes**: Early years use different conventions



## Resources

.config/skills/3gpp/3gpp-portal-authentication/SKILL.md

+9 −15
Original line number Diff line number Diff line 
---

name: 3gpp-portal-authentication

description: EOL authentication, AJAX login patterns, 3GPP portal data fetching, and session management. Use when accessing protected 3GPP portal resources that require EOL login, fetching TDoc metadata, or working with 3GPP portal APIs.

related: 

  - 3gpp-tdocs

  - 3gpp-meetings

  - 3gpp-specifications

  - 3gpp-change-request

---

______________________________________________________________________



## name: 3gpp-portal-authentication description: EOL authentication, AJAX login patterns, 3GPP portal data fetching, and session management. Use when accessing protected 3GPP portal resources that require EOL login, fetching TDoc metadata, or working with 3GPP portal APIs. metadata: related: [3gpp-tdocs, 3gpp-meetings, 3gpp-specifications, 3gpp-change-request]



# 3GPP Portal Authentication
@@ -50,8 +44,8 @@ The 3GPP portal uses JavaScript-based AJAX login via `LoginEOL.ashx` endpoint. 
### Login Process



1. **Session Establishment**: Visit login page to establish session cookies

2. **AJAX Request**: POST to `LoginEOL.ashx` with credentials

3. **Session Validation**: Parse JSON response for authentication status

1. **AJAX Request**: POST to `LoginEOL.ashx` with credentials

1. **Session Validation**: Parse JSON response for authentication status



### Code Pattern
@@ -277,10 +271,10 @@ response = session.get("https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/RAN1_98/Docs/R1 
## Best Practices



1. **Check authentication requirement** before attempting protected operations

2. **Use session context** to maintain authentication state

3. **Handle auth failures** gracefully with clear error messages

4. **Don't cache credentials** in code or environment files

5. **Use environment variables** (`EOL_USERNAME`, `EOL_PASSWORD`) for credentials

1. **Use session context** to maintain authentication state

1. **Handle auth failures** gracefully with clear error messages

1. **Don't cache credentials** in code or environment files

1. **Use environment variables** (`EOL_USERNAME`, `EOL_PASSWORD`) for credentials



## Cross-References