When talking about requirements, you have multiple types of requirements. User stories often capture a combination of functional requirements (inputs, outputs, behaviors) and user characteristics (goals, desires, objectives of users of the software). But there are other things that are important to consider when capturing requirements - design constraints and quality attributes come to mind.
The difference is that things like design constraints and quality attributes live on throughout the design and maintenance of a system. With functionality, you implement the functionality once and you have it (barring a regression). However, you need to take care to always work within your design constraints and ensure the system has the quality attributes.
In your particular example, I would consider the use of a particular style guide part of the usability of the software system, and usability is a quality attribute. Your requirement to adhere to a specific style guide is a good requirement - it's cohesive, complete, likely to be consistent, atomic, current, clear, and so on.
There's no one right way to handle this.
The first thing that you need to do is to capture and control your guidance. For example, for a style guide, make sure it's available to your team. For performance requirements, put a table that relates functions to timing. For availability, fault tolerance, and disaster recovery, have a plan and test the plan by forcing the system into low availbility or failure modes to ensure the goals are met. A wiki with approrpiate change protection and revision history may be sufficient, or a more rigorous configuration management system may be required.
Tying these other requirements to your product may be as simple as developing test plans (there are JIRA test management plugins - Zephyr, TestFLO) that are executed against your documented standards. I wouldn't recommend putting your design constraints and quality attributes as standard JIRA tickets, since they don't follow the standard lifecycle of a user story, bug, or task. They need to be in a form that is searchable, referenceable, and persistent.
The last step is education - make sure that your development team is aware of the standards or these persistent requirements and how to design and do developer testing against them.