oauth-init 0.7.0 → 0.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,68 @@
1
+ # Title
2
+
3
+ ![banner](assets/text_wordmark_dark.png)
4
+
5
+ ![GitHub Created At](https://img.shields.io/github/created-at/RichardLitt/standard-readme?color=bright-green&style=flat-square)
6
+ ![GitHub contributors](https://img.shields.io/github/contributors/RichardLitt/standard-readme?color=bright-green&style=flat-square)
7
+ [![license](https://img.shields.io/github/license/RichardLitt/standard-readme.svg?color=bright-green&style=flat-square)](LICENSE)
8
+ [![standard-readme compliant](https://img.shields.io/badge/readme%20style-standard-brightgreen.svg?style=flat-square)](https://github.com/RichardLitt/standard-readme)
9
+
10
+ This is an example file with maximal choices selected.
11
+
12
+ This is a long description.
13
+
14
+ ## Table of Contents
15
+
16
+ - [Security](#security)
17
+ - [Background](#background)
18
+ - [Install](#install)
19
+ - [Usage](#usage)
20
+ - [API](#api)
21
+ - [Contributing](#contributing)
22
+ - [License](#license)
23
+
24
+ ## Security
25
+
26
+ ### Any optional sections
27
+
28
+ ## Background
29
+
30
+ ### Any optional sections
31
+
32
+ ## Install
33
+
34
+ This module depends upon a knowledge of [Markdown]().
35
+
36
+ ```
37
+ ```
38
+
39
+ ### Any optional sections
40
+
41
+ ## Usage
42
+
43
+ ```
44
+ ```
45
+
46
+ Note: The `license` badge image link at the top of this file should be updated with the correct `:user` and `:repo`.
47
+
48
+ ### Any optional sections
49
+
50
+ ## API
51
+
52
+ ### Any optional sections
53
+
54
+ ## More optional sections
55
+
56
+ ## Contributing
57
+
58
+ See [the contributing file](CONTRIBUTING.md)!
59
+
60
+ PRs accepted.
61
+
62
+ Small note: If editing the Readme, please conform to the [standard-readme](https://github.com/RichardLitt/standard-readme) specification.
63
+
64
+ ### Any optional sections
65
+
66
+ ## License
67
+
68
+ [MIT © Richard McRichface.](../LICENSE)
@@ -0,0 +1,21 @@
1
+ # Title
2
+
3
+ This is an example file with default selections.
4
+
5
+ ## Install
6
+
7
+ ```
8
+ ```
9
+
10
+ ## Usage
11
+
12
+ ```
13
+ ```
14
+
15
+ ## Contributing
16
+
17
+ PRs accepted.
18
+
19
+ ## License
20
+
21
+ MIT © Richard McRichface
@@ -0,0 +1,242 @@
1
+ # Standard README Specification
2
+
3
+ > Source: [Standard Readme](https://github.com/RichardLitt/standard-readme) by Richard Litt
4
+
5
+ A compliant README must satisfy all the requirements listed below.
6
+
7
+ > Note: Standard Readme is designed for open source libraries. Although it's [historically](README.md#background) made for Node and npm projects, it also applies to libraries in other languages and package managers.
8
+
9
+ **Requirements:**
10
+ - Be called README (with capitalization) and have a specific extension depending on its format (`.md` for Markdown, `.org` for Org Mode Markup syntax, `.html` for HTML, ...)
11
+ - If the project supports i18n, the file must be named accordingly: `README.de.md`, where `de` is the BCP 47 Language tag. For naming, prioritize non-regional subtags for languages. If there is only one README and the language is not English, then a different language in the text is permissible without needing to specify the BCP tag: e.g., `README.md` can be in German if there is no `README.md` in another language. Where there are multiple languages, `README.md` is reserved for English.
12
+ - Be a valid file in the selected format (Markdown, Org Mode, HTML, ...).
13
+ - Sections must appear in order given below. Optional sections may be omitted.
14
+ - Sections must have the titles listed below, unless otherwise specified. If the README is in another language, the titles must be translated into that language.
15
+ - Must not contain broken links.
16
+ - If there are code examples, they should be linted in the same way as the code is linted in the rest of the project.
17
+
18
+ ## Table of Contents
19
+
20
+ _Note: This is only a navigation guide for the specification, and does not define or mandate terms for any specification-compliant documents._
21
+
22
+ - [Sections](#sections)
23
+ - [Title](#title)
24
+ - [Banner](#banner)
25
+ - [Badges](#badges)
26
+ - [Short Description](#short-description)
27
+ - [Long Description](#long-description)
28
+ - [Table of Contents](#table-of-contents-1)
29
+ - [Security](#security)
30
+ - [Background](#background)
31
+ - [Install](#install)
32
+ - [Usage](#usage)
33
+ - [Extra Sections](#extra-sections)
34
+ - [API](#api)
35
+ - [Maintainers](#maintainers)
36
+ - [Thanks](#thanks)
37
+ - [Contributing](#contributing)
38
+ - [License](#license)
39
+ - [Definitions](#definitions)
40
+
41
+ ## Sections
42
+
43
+ ### Title
44
+ **Status:** Required.
45
+
46
+ **Requirements:**
47
+ - Title must match repository, folder and package manager names - or it may have another, relevant title with the repository, folder, and package manager title next to it in italics and in parentheses. For instance:
48
+
49
+ ```markdown
50
+ # Standard Readme Style _(standard-readme)_
51
+ ```
52
+
53
+ If any of the folder, repository, or package manager names do not match, there must be a note in the [Long Description](#long-description) explaining why.
54
+
55
+ **Suggestions:**
56
+ - Should be self-evident.
57
+
58
+ ### Banner
59
+ **Status:** Optional.
60
+
61
+ **Requirements:**
62
+ - Must not have its own title.
63
+ - Must link to local image in current repository.
64
+ - Must appear directly after the title.
65
+
66
+ ### Badges
67
+ **Status:** Optional.
68
+
69
+ **Requirements:**
70
+ - Must not have its own title.
71
+ - Must be newline delimited.
72
+
73
+ **Suggestions:**
74
+ - Use http://shields.io or a similar service to create and host the images.
75
+ - Add the [Standard Readme badge](https://github.com/RichardLitt/standard-readme#badge).
76
+
77
+ ### Short Description
78
+ **Status:** Required.
79
+
80
+ **Requirements:**
81
+ - Must not have its own title.
82
+ - Must be less than 120 characters.
83
+ - Must not start with `> `
84
+ - Must be on its own line.
85
+ - Must match the description in the packager manager's `description` field.
86
+ - Must match GitHub's description (if on GitHub).
87
+
88
+ **Suggestions:**
89
+ - Use [gh-description](https://github.com/RichardLitt/gh-description) to set and get GitHub description.
90
+ - Use `npm show . description` to show the description from a local [npm](https://npmjs.com) package.
91
+
92
+ ### Long Description
93
+ **Status:** Optional.
94
+
95
+ **Requirements:**
96
+ - Must not have its own title.
97
+ - If any of the folder, repository, or package manager names do not match, there must be a note here as to why. See [Title section](#title).
98
+
99
+ **Suggestions:**
100
+ - If too long, consider moving to the [Background](#background) section.
101
+ - Cover the main reasons for building the repository.
102
+ - "This should describe your module in broad terms,
103
+ generally in just a few paragraphs; more detail of the module's
104
+ routines or methods, lengthy code examples, or other in-depth
105
+ material should be given in subsequent sections.
106
+
107
+ Ideally, someone who's slightly familiar with your module should be
108
+ able to refresh their memory without hitting "page down". As your
109
+ reader continues through the document, they should receive a
110
+ progressively greater amount of knowledge."
111
+
112
+ ~ [Kirrily "Skud" Robert, perlmodstyle](http://perldoc.perl.org/perlmodstyle.html)
113
+
114
+ ### Table of Contents
115
+ **Status:** Required; optional for READMEs shorter than 100 lines.
116
+
117
+ **Requirements:**
118
+ - Must link to all sections in the file.
119
+ - Must start with the next section; do not include the title or Table of Contents headings.
120
+ - Must be at least one-depth: must capture all level two headings (e.g.: Markdown's `##` or Org Mode's `**` or HTML's `<h2>` and so on).
121
+
122
+ **Suggestions:**
123
+ - May capture third and fourth depth headings. If it is a long ToC, these are optional.
124
+
125
+ ### Security
126
+ **Status**: Optional.
127
+
128
+ **Requirements:**
129
+ - May go here if it is important to highlight security concerns. Otherwise, it should be in [Extra Sections](#extra-sections).
130
+
131
+ ### Background
132
+ **Status:** Optional.
133
+
134
+ **Requirements:**
135
+ - Cover motivation.
136
+ - Cover abstract dependencies.
137
+ - Cover intellectual provenance: A `See Also` section is also fitting.
138
+
139
+ ### Install
140
+ **Status:** Required by default, optional for [documentation repositories](#definitions).
141
+
142
+ **Requirements:**
143
+ - Code block illustrating how to install.
144
+
145
+ **Subsections:**
146
+ - `Dependencies`. Required if there are unusual dependencies or dependencies that must be manually installed.
147
+
148
+ **Suggestions:**
149
+ - Link to prerequisite sites for programming language: [npmjs](https://npmjs.com), [godocs](https://godoc.org), etc.
150
+ - Include any system-specific information needed for installation.
151
+ - An `Updating` section would be useful for most packages, if there are multiple versions which the user may interface with.
152
+
153
+ ### Usage
154
+ **Status:** Required by default, optional for [documentation repositories](#definitions).
155
+
156
+ **Requirements:**
157
+ - Code block illustrating common usage.
158
+ - If CLI compatible, code block indicating common usage.
159
+ - If importable, code block indicating both import functionality and usage.
160
+
161
+ **Subsections:**
162
+ - `CLI`. Required if CLI functionality exists.
163
+
164
+ **Suggestions:**
165
+ - Cover basic choices that may affect usage: for instance, if JavaScript, cover promises/callbacks, ES6 here.
166
+ - If relevant, point to a runnable file for the usage code.
167
+
168
+ ### Extra Sections
169
+ **Status**: Optional.
170
+
171
+ **Requirements:**
172
+ - None.
173
+
174
+ **Suggestions:**
175
+ - This should not be called `Extra Sections`. This is a space for 0 or more sections to be included, each of which must have their own titles.
176
+ - This should contain any other sections that are relevant, placed after [Usage](#usage) and before [API](#api).
177
+ - Specifically, the [Security](#security) section should be here if it wasn't important enough to be placed above.
178
+
179
+ ### API
180
+ **Status:** Optional.
181
+
182
+ **Requirements:**
183
+ - Describe exported functions and objects.
184
+
185
+ **Suggestions:**
186
+ - Describe signatures, return types, callbacks, and events.
187
+ - Cover types covered where not obvious.
188
+ - Describe caveats.
189
+ - If using an external API generator (like go-doc, js-doc, or so on), point to an external `API.md` file. This can be the only item in the section, if present.
190
+
191
+ ### Maintainer(s)
192
+ **Status**: Optional.
193
+
194
+ **Requirements:**
195
+ - Must be called `Maintainer` or `Maintainers`.
196
+ - List maintainer(s) for a repository, along with one way of contacting them (e.g. GitHub link or email).
197
+
198
+ **Suggestions:**
199
+ - This should be a small list of people in charge of the repo. This should not be everyone with access rights, such as an entire organization, but the people who should be pinged and who are in charge of the direction and maintenance of the repository.
200
+ - Listing past maintainers is good for attribution, and kind.
201
+
202
+ ### Thanks
203
+ **Status**: Optional.
204
+
205
+ **Requirements:**
206
+ - Must be called `Thanks`, `Credits` or `Acknowledgements`.
207
+
208
+ **Suggestions:**
209
+ - State anyone or anything that significantly helped with the development of your project.
210
+ - State public contact hyper-links if applicable.
211
+
212
+ ### Contributing
213
+ **Status**: Required.
214
+
215
+ **Requirements:**
216
+ - State where users can ask questions.
217
+ - State whether PRs are accepted.
218
+ - List any requirements for contributing; for instance, having a sign-off on commits.
219
+
220
+ **Suggestions:**
221
+ - Link to a CONTRIBUTING file -- if there is one.
222
+ - Be as friendly as possible.
223
+ - Link to the GitHub issues.
224
+ - Link to a Code of Conduct. A CoC is often in the Contributing section or document, or set elsewhere for an entire organization, so it may not be necessary to include the entire file in each repository. However, it is highly recommended to always link to the code, wherever it lives.
225
+ - A subsection for listing contributors is also welcome here.
226
+
227
+ ### License
228
+ **Status:** Required.
229
+
230
+ **Requirements:**
231
+ - State license full name or identifier, as listed on the [SPDX](https://spdx.org/licenses/) license list. For unlicensed repositories, add `UNLICENSED`. For more details, add `SEE LICENSE IN <filename>` and link to the license file. (These requirements were adapted from [npm](https://docs.npmjs.com/files/package.json#license)).
232
+ - State license owner.
233
+ - Must be last section.
234
+
235
+ **Suggestions:**
236
+ - Link to longer License file in local repository.
237
+
238
+ ## Definitions
239
+
240
+ _These definitions are provided to clarify any terms used above._
241
+
242
+ - **Documentation repositories**: Repositories without any functional code. For instance, [RichardLitt/knowledge](https://github.com/RichardLitt/knowledge).
@@ -0,0 +1,17 @@
1
+ # Section Checklist by Project Type
2
+
3
+ Quick reference for which sections to include based on project type.
4
+
5
+ | Section | OSS | Personal | Internal | Config |
6
+ |---------|-----|----------|----------|--------|
7
+ | Name/Description | Yes | Yes | Yes | Yes |
8
+ | Badges | Yes | Optional | No | No |
9
+ | Installation | Yes | Yes | Yes | No |
10
+ | Usage/Examples | Yes | Yes | Yes | Brief |
11
+ | What's Here | No | No | No | Yes |
12
+ | How to Extend | No | No | Optional | Yes |
13
+ | Contributing | Yes | Optional | Yes | No |
14
+ | License | Yes | Optional | No | No |
15
+ | Architecture | Optional | No | Yes | No |
16
+ | Gotchas/Notes | Optional | Optional | Yes | Yes |
17
+ | Last Reviewed | No | No | Optional | Yes |
@@ -0,0 +1,13 @@
1
+ # README Style Guide
2
+
3
+ ## Common Mistakes
4
+
5
+ - **No install steps** - Never assume setup is obvious
6
+ - **No examples** - Show, don't just tell
7
+ - **Wall of text** - Use headers, tables, lists
8
+ - **Stale content** - Add "last reviewed" date
9
+ - **Generic tone** - Write for YOUR audience
10
+
11
+ ## Prose Quality
12
+
13
+ For general writing advice — clear prose, Strunk's rules, and AI patterns to avoid — use the `writing-clearly-and-concisely` skill.
@@ -0,0 +1,106 @@
1
+ # Internal/Work Project README Template
2
+
3
+ Use this template for team codebases, services, and internal tools.
4
+ Focus on onboarding new team members and operational knowledge.
5
+
6
+ ---
7
+
8
+ # [Service/Project Name]
9
+
10
+ [One-line description of what this service does]
11
+
12
+ **Team**: [Team name or slack channel]
13
+ **On-call**: [Rotation or contact info]
14
+
15
+ ## Overview
16
+
17
+ [2-3 sentences on what this does, why it exists, and where it fits in the system architecture.]
18
+
19
+ ### Dependencies
20
+
21
+ - **Upstream**: [Services this depends on]
22
+ - **Downstream**: [Services that depend on this]
23
+
24
+ ## Local Development Setup
25
+
26
+ ### Prerequisites
27
+
28
+ - [Required tool 1 with version]
29
+ - [Required tool 2]
30
+ - Access to [internal system/VPN/etc]
31
+
32
+ ### Environment Variables
33
+
34
+ | Variable | Description | Where to get it |
35
+ |----------|-------------|-----------------|
36
+ | `DATABASE_URL` | [Description] | [1Password/Vault/etc] |
37
+ | `API_KEY` | [Description] | [Where to find] |
38
+
39
+ ### Running Locally
40
+
41
+ ```bash
42
+ [Step-by-step commands to get running]
43
+ ```
44
+
45
+ ### Running Tests
46
+
47
+ ```bash
48
+ [Test commands]
49
+ ```
50
+
51
+ ## Architecture
52
+
53
+ [Brief description of system design. Link to architecture diagrams if they exist.]
54
+
55
+ ```
56
+ [Simple ASCII diagram if helpful]
57
+ ```
58
+
59
+ ### Key Files
60
+
61
+ | Path | Purpose |
62
+ |------|---------|
63
+ | `src/[important-file]` | [What it does] |
64
+ | `config/` | [Configuration files] |
65
+
66
+ ## Deployment
67
+
68
+ [How to deploy, or link to deployment docs]
69
+
70
+ ### Environments
71
+
72
+ | Environment | URL | Notes |
73
+ |-------------|-----|-------|
74
+ | Development | [URL] | [Notes] |
75
+ | Staging | [URL] | [Notes] |
76
+ | Production | [URL] | [Notes] |
77
+
78
+ ## Runbooks
79
+
80
+ ### [Common Task 1]
81
+
82
+ ```bash
83
+ [Commands or steps]
84
+ ```
85
+
86
+ ### [Common Task 2]
87
+
88
+ [Steps]
89
+
90
+ ## Troubleshooting
91
+
92
+ ### [Common Problem 1]
93
+
94
+ **Symptom**: [What you see]
95
+ **Cause**: [Why it happens]
96
+ **Fix**: [How to resolve]
97
+
98
+ ## Contributing
99
+
100
+ [Link to team contribution guidelines or PR process]
101
+
102
+ ## Related Docs
103
+
104
+ - [Link to design doc]
105
+ - [Link to API docs]
106
+ - [Link to monitoring dashboard]
@@ -0,0 +1,77 @@
1
+ # Open Source Project README Template
2
+
3
+ Use this template for projects intended for public use and contribution.
4
+
5
+ ---
6
+
7
+ # [Project Name]
8
+
9
+ [One-line description of what this project does]
10
+
11
+ [![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
12
+ [![Build Status](https://img.shields.io/github/actions/workflow/status/[user]/[repo]/ci.yml)](https://github.com/[user]/[repo]/actions)
13
+ [![npm version](https://img.shields.io/npm/v/[package-name])](https://www.npmjs.com/package/[package-name])
14
+
15
+ ## About
16
+
17
+ [2-3 sentences explaining what problem this solves and why someone would use it. Include what makes it different from alternatives if relevant.]
18
+
19
+ ## Features
20
+
21
+ - [Key feature 1]
22
+ - [Key feature 2]
23
+ - [Key feature 3]
24
+
25
+ ## Installation
26
+
27
+ ```bash
28
+ [package manager install command]
29
+ ```
30
+
31
+ ### Requirements
32
+
33
+ - [Runtime requirement, e.g., Node.js >= 18]
34
+ - [Other dependencies if any]
35
+
36
+ ## Usage
37
+
38
+ ```[language]
39
+ [Minimal working example showing the most common use case]
40
+ ```
41
+
42
+ ### More Examples
43
+
44
+ [Link to examples directory or additional code samples]
45
+
46
+ ## Documentation
47
+
48
+ [Link to full docs if they exist separately, or expand this section]
49
+
50
+ ## Contributing
51
+
52
+ Contributions are welcome! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
53
+
54
+ ### Development Setup
55
+
56
+ ```bash
57
+ [Commands to clone and set up for development]
58
+ ```
59
+
60
+ ### Running Tests
61
+
62
+ ```bash
63
+ [Test command]
64
+ ```
65
+
66
+ ## Roadmap
67
+
68
+ - [ ] [Planned feature 1]
69
+ - [ ] [Planned feature 2]
70
+
71
+ ## Acknowledgments
72
+
73
+ - [Credit to inspirations, contributors, or dependencies worth highlighting]
74
+
75
+ ## License
76
+
77
+ [Project name] is licensed under the [License name] license. See the [`LICENSE`](LICENSE) file for more information.
@@ -0,0 +1,51 @@
1
+ # Personal Project README Template
2
+
3
+ Use this template for side projects, portfolio pieces, and experiments.
4
+ Balance between documenting for future-you and showcasing for others.
5
+
6
+ ---
7
+
8
+ # [Project Name]
9
+
10
+ [One-line description]
11
+
12
+ [Screenshot or demo GIF if visual]
13
+
14
+ ## What This Does
15
+
16
+ [2-3 sentences explaining what it does and why you built it. Be specific about the problem it solves for you.]
17
+
18
+ ## Demo
19
+
20
+ [Link to live demo, video, or screenshots]
21
+
22
+ ## Tech Stack
23
+
24
+ - **[Category]**: [Technology] - [brief why you chose it]
25
+ - **[Category]**: [Technology]
26
+
27
+ ## Getting Started
28
+
29
+ ```bash
30
+ [Clone and run commands]
31
+ ```
32
+
33
+ ## How It Works
34
+
35
+ [Brief explanation of the interesting parts - architecture, algorithms, or techniques worth noting. This is useful for portfolio viewers and future-you.]
36
+
37
+ ## What I Learned
38
+
39
+ [Key takeaways from building this. Good for portfolios and personal reference.]
40
+
41
+ - [Learning 1]
42
+ - [Learning 2]
43
+
44
+ ## Future Ideas
45
+
46
+ - [ ] [Thing you might add]
47
+ - [ ] [Improvement you're considering]
48
+
49
+ ## License
50
+
51
+ [License if you want one, or just "Personal project" if not sharing]
@@ -0,0 +1,71 @@
1
+ # Config Directory README Template
2
+
3
+ Use this template for XDG config directories, dotfiles, script folders,
4
+ and any local directory you'll return to later wondering "what is this?"
5
+
6
+ The audience is future-you, probably confused.
7
+
8
+ ---
9
+
10
+ # [Tool/Directory Name] Config
11
+
12
+ > Last reviewed: [YYYY-MM-DD]
13
+
14
+ [One sentence: what this directory configures and why you have custom config]
15
+
16
+ ## What's Here
17
+
18
+ | Path | Purpose |
19
+ |------|---------|
20
+ | `[file-or-dir]` | [What it does] |
21
+ | `[file-or-dir]` | [What it does] |
22
+ | `[file-or-dir]` | [What it does] |
23
+
24
+ ### [Subdirectory 1] (if complex enough to warrant detail)
25
+
26
+ [Brief explanation of what's in this subdirectory]
27
+
28
+ ### [Subdirectory 2]
29
+
30
+ [Brief explanation]
31
+
32
+ ## Why This Setup
33
+
34
+ [1-2 paragraphs explaining your philosophy or goals for this config. What problems were you solving? What workflow are you optimizing for?]
35
+
36
+ ## How to Extend
37
+
38
+ ### Adding a new [thing]
39
+
40
+ 1. [Step 1]
41
+ 2. [Step 2]
42
+ 3. [Step 3]
43
+
44
+ ### Adding a new [other thing]
45
+
46
+ 1. [Steps]
47
+
48
+ ## Dependencies
49
+
50
+ [What needs to be installed for this config to work]
51
+
52
+ ```bash
53
+ [Install commands if applicable]
54
+ ```
55
+
56
+ ## Gotchas
57
+
58
+ - [Thing that will confuse future-you]
59
+ - [Non-obvious behavior]
60
+ - [Files that shouldn't be edited directly]
61
+ - [Order dependencies or load sequences]
62
+
63
+ ## Sync/Backup
64
+
65
+ [How this config is backed up or synced across machines, if applicable]
66
+
67
+ ## Related
68
+
69
+ - [Link to tool's official docs]
70
+ - [Link to your dotfiles repo if this is part of it]
71
+ - [Other relevant resources]