Update writers-playbook.md

* - prism overview article

* Update overview.md

* Update overview.md

* - cleaning up prism introduction article

* - need to add related links

* - add prism helpers

* Update introduction.md

* - add images/gifs to the prism introduction

* - update gif for mocking

articles/billing/overview.md

@@ -1,43 +1,43 @@
-# Personal Billing Overview 
-
-![Billing Overview](https://github.com/stoplightio/docs/blob/develop/assets/images/billing.png?raw=true)
-
-## Platform Plans 
-
-### Open Source
-- Price: Free 
-- Features: 
-    - API Modeling 
-    - Documentation 
-    - Mocking
-    - Testing 
-
-### Developer 
-- Price: $9/month 
-- Features:
-    - Unlimited Private Projects 
-    - Coming Soon: Github Integration 
-
-## Documentation Plans 
-
-### Basic 
-- Price: Free 
-- Features: 
-    - Unlimited Visits 
-    - Publish to .docs.stoplight.io 
-    - Docs & OpenAPI Editors 
-
-### Essential 
-- Price: $79/month 
-- Features: 
-    - Publish to your Domain (1 domain)
-    - Theming 
-    - Build History & Instant Rollbacks 
-
-### Standard 
-- Price: $179/month 
-- Features:
-    - Publish to your Domain (10 domains)
-    - Custom CSS
-    - White Label 
-    - Basic Auth & Auth0 Integration 
+# Personal Billing Overview 
+
+![Billing Overview](https://github.com/stoplightio/docs/blob/develop/assets/images/billing.png?raw=true)
+
+## Platform Plans 
+
+### Open Source
+- Price: Free 
+- Features: 
+    - API Modeling 
+    - Documentation 
+    - Mocking
+    - Testing 
+
+### Developer 
+- Price: $9/month 
+- Features:
+    - Unlimited Private Projects 
+    - Coming Soon: Github Integration 
+
+## Documentation Plans 
+
+### Basic 
+- Price: Free 
+- Features: 
+    - Unlimited Visits 
+    - Publish to .docs.stoplight.io 
+    - Docs & OpenAPI Editors 
+
+### Essential 
+- Price: $79/month 
+- Features: 
+    - Publish to your Domain (1 domain)
+    - Theming 
+    - Build History & Instant Rollbacks 
+
+### Standard 
+- Price: $179/month 
+- Features:
+    - Publish to your Domain (10 domains)
+    - Custom CSS
+    - White Label 
+    - Basic Auth & Auth0 Integration 

articles/getting-started/permissions-overview.md

@@ -0,0 +1,36 @@
+# Permissions & Governance Overview 
+
+## Organizations 
+
+| **Organization Actions**        | **Guest** | **Member** | **Administrator** | **Owner** |
+|---------------------------------|:-----------:|:------------:|:-------------------:|:-----------:|
+| Read Public Projects            |     X     |      X     |         X         |     X     |
+| View Organization Collaborators |           |      X     |         X         |     X     |
+| View Organization Teams         |           |      X     |         X         |     X     |
+| Create Projects                 |           |      X     |         X         |     X     |
+| Read Private Projects           |           |      X     |         X         |     X     |
+| Write Projects                  |           |            |         X         |     X     |
+| Manage Collaborators            |           |            |         X         |     X     |
+| Manage Teams                    |           |            |         X         |     X     |
+| Manage Organization Settings    |           |            |                   |     X     |
+| Manage Organization Billing     |           |            |                   |     X     |
+| Delete Organization             |           |            |                   |     X     |
+
+## Teams 
+
+|      **Team Actions**     | **Member** | **Administrator** | **Owner** |
+|-------------------------|:------------:|:-------------------:|:-----------:|
+| View Team Collaborators   | X          | X                 | X         |
+| Add Team to Projects      | X          | X                 | X         |
+| Manage Team Collaborators |            | X                 | X         |
+| Manage Team Settings      |            | X                 | X         |
+| Delete Team               |            |                   | X         |
+
+## Projects 
+
+| **Project Actions**          | **Read** | **Write** | **Administrator** |
+|------------------------------|:--------:|:---------:|:-----------------:|
+| Read Project                 | X        | X         | X                 |
+| Write Project                |          | X         | X                 |
+| Manage Project Collaborators |          |           | X                 |
+| Delete Project               |          |           | X                 |

articles/getting-started/writers-playbook.md

@@ -0,0 +1,43 @@
+# Technical Writer Playbook 
+
+Documenting an API is crucial to its success but can be extremely time consuming. Here at Stoplight, we believe documentation should be beautiful, clean, and robust while maintaining a streamlined turnaround time. We’ve created a holistic documentation tool, Hubs, to address some of the problems our users were facing including:
+ 
+- Documenting Endpoints 
+- Testing Endpoints 
+- Creating Non-Reference Documentation 
+- Managing Content
+- External and Internal Referencing 
+- Design and Style 
+
+
+## Documenting Endpoints 
+The most key component to API Documentation are its endpoints. To that end, we created a reference builder that allows you to [“power pages”](/documentation/referencing-other-data-sources) with your specification as you see fit. When you power a page or subpage with your specification, the endpoints are automatically documented and styled for legibility and aesthetic design. 
+
+## Testing Endpoints 
+Testing endpoints is a valuable tool for anyone who wants to consumer your API. Users want to know that your API functions properly before they commit to using it. To address this problem, we created [“Try it Out,” an HTTP Request Maker](/modeling/modeling-with-openapi/sending-http-requests). Try it Out allows you to send HTTP Requests to your API to test out its endpoints under any number of different conditions. You can customize Try it Out with security schemes, variables, headers, queries, and it even generates code in various programming languages. 
+
+## Creating Non-Reference Documentation 
+Great documentation is more than just API endpoints. Guides, tutorials, and other supplemental information enhance your users experience by providing them with all the information they need to access your API and your product. We broadened Hubs scope to accomodate all product documentation needs. You can easily build out your content within [Blocks](/documentation/blocks), a number of flexible content structures that can house a number of different forms of content including markdown, images, code snippets, and much more. 
+
+## Managing Content 
+Organizing a complex APIs endpoints and supplemental information can be a challenging task. Some specification can have hundreds of endpoints with supplemental information throughout. To assist with organizing content, we created an overview of all your pages, subpages, and their connections called “Table of Contents”. With a bird’s eye view of your content, you can easily organize and manage your content through drag drop functionality. 
+
+## External and Internal Referencing 
+To accomodate a larger variety of writing workflows, we expanded the capabilities of [Powering a Page](/documentation/referencing-other-data-sources) to allow for more files internally and externally to be referenced. You can now easily reference specification, Markdown, YAML, JSON, and Scenario files from within a Project or externally located. 
+
+## Design and Style 
+We wanted to create a new, beautiful, minimalistic, efficient design for less design-oriented individuals while allowing for customization. Hubs was designed to be display your documentation in a neat, efficient structure designed specifically for displaying the real beauty, your API. On the other hand, we didn’t want to stifle the creativity that goes into documentation design so we added in [theming](/documentation/design/theming) and [custom CSS](/documentation/design/custom-css). We also made it easier to add navigation, different kinds of content, and a more robust search. 
+
+---
+Related Links 
+- [Documentation with Hubs](/documentation/introduction)
+- [Routing](/documentation/getting-started/routing)
+- [Headers](/documentation/getting-started/header-footer)
+- [Pages](/documentation/getting-started/pages)
+- [Subpages](/documentation/getting-started/subpages)
+- [Blocks](/documentation/blocks)
+- [Referencing Other Data Sources](/documentation/referencing-other-data-sources)
+- [Publishing](/documentation/publishing)
+- [Theming](/documentation/design/theming)
+- [Custom CSS](/documentation/design/custom-css)
+

articles/hubs/custom-css.md

@@ -0,0 +1,46 @@
+# Custom CSS
+
+![Applying Custom CSS](https://github.com/stoplightio/docs/blob/develop/assets/gifs/hubs-custom-css.gif?raw=true)
+
+## What 
+
+Want to add some style and flair to your documentation? Add your own custom CSS to enhance your Hub’s look and feel. Below are some of the classes you can modify: 
+
+```
+.Hub
+  .HubHeader
+    .HubHeader-section
+      .HubHeaderItem.is-active
+        .HubHeaderItem-name
+  .HubMain
+    .HubSidebar-overlay
+    .HubSidebar-wrapper
+      .HubSidebar
+        .HubSidebar-inner
+      .HubBranding
+    .HubPage-wrapper
+      .HubPage
+        .HubPage-inner
+          .HubPage-content
+            .HubPageCrumbs
+              .HubPageCrumb 
+            .HubPageBody 
+              .HubBlock
+            .HubPageFooter
+```
+
+## How
+
+1. Select the Hub you wish to modify 
+2. Select the **Design View**
+3. Click on **Theme** in the top toolbar 
+4. Select **Custom CSS** in the bottom left 
+5. Input CSS in the text area at the bottom of the page 
+6. Input CSS in the generated **theme** file (optional)
+7. In publishing, check the **Custom CSS** box under **Advanced** to apply the Custom CSS to that Hub when published
+
+>After accessing Custom CSS, a **theme** file will be generated under Documentation in the file explorer. After making changes to your CSS, make sure to save the **theme** file. 
+
+---
+**Related Articles**
+- [Theming](/documentation/design/theming)

articles/hubs/themes.md

@@ -21,10 +21,13 @@ Texture applies a texture to your header.
 ## How
 1. Select the **Hub** you wish to modify
 2. Select the **Design View** 
-3. Click on **Settings** at the top of the screen 
-4. Select **Theme** in the sidebar 
-5. Select a pre-selected color or choose your own color with the eyedropper 
-6. Select a texture 
-
+3. Click on **Theme** at the top of the screen 
+4. Select a pre-selected color or choose your own color with the eyedropper 
+5. Select a texture 
+
+---
+
+**Related Links**
+- [Custom CSS](/documentation/design/custom-css)
 
 

articles/hubs/variables.md

@@ -0,0 +1,40 @@
+# Variables in Hubs 
+
+## What 
+
+Inputting variables in API documentation whenever you consume them can quickly become a tedious time sink. The same pain point applies to people consuming your documentation. Inputting an API key everytime you want to send HTTP Requests to test endpoints is time better spent elsewhere.  Stoplight removes this obstacle by storing variables in your local browser. Once you input a variable, it populates the rest of your docs, no duplication, no problems. 
+
+## How
+
+You can specify variables in your docs by adding them at the specification level or directly into Hubs. 
+
+### Modeling Method 
+
+![Security Scheme in Specification](https://github.com/stoplightio/docs/blob/develop/assets/images/hubs-variables-modeling.png?raw=true)
+
+1. Select the modeling file you wish to modify 
+2. Create a new **security scheme** 
+    1. Input a **key** (required, must be unique in this specification) 
+    2. Select a **type** of security scheme 
+    3. Select a location for the security scheme under **in**
+    4. Input a **name** 
+3. Reference the specification in your Hub
+
+---
+
+### Hubs Method 
+
+![Adding variables to HTTP Request Maker](https://github.com/stoplightio/docs/blob/develop/assets/images/hubs-variables-tryitout.png?raw=true)
+
+1. Select the Hub you wish to modify 
+2. Create a **HTTP Request Maker** block 
+3. Select the **Headers** tab 
+4. Click **Add Header** 
+5. Input a **header name**
+6. Input a **header value** 
+
+***
+
+**Related**
+
+* [Security Schemes Overview](/modeling/modeling-with-openapi/security-schemes)

articles/prism/introduction.md

@@ -0,0 +1,61 @@
+# Introduction
+
+Prism is a proxy and API server toolkit that helps you test, mock, validate, and orchestrate your online applications. We rebuilt Prism from the ground up to be performant, powerful, and programmable while still being practical. Prism enables teams to work in parallel and iterate faster with less errors. The Stoplight Platform integrates tightly with Prism to generate test coverage of your API automatically, build tests visually, and create mock and contract servers instantly.
+
+Prism has first class support for the OpenAPI Specification (aka OAS) and Stoplight Scenarios. OAS is machine readable documentation of your API that Prism can read and understand. Scenarios tell Prism how to orchestrate your API. When you use them together you can easily assert, transform, and validate your API against your OAS. Prism also allows your front-end team to work in tandem with your back-end team. While the back-end team implements your API, your front-end teams can implement against a mock server that can return static examples, dynamic data, or replay actual traffic from your API.
+
+![Prism Overivew](https://github.com/stoplightio/docs/blob/develop/assets/images/prism-introduction-help.png?raw=true)
+
+## Features
+
+* Act as a mock server, routing incoming requests to example responses, or dynamically generating examples on the fly
+* Act as a transformation layer, manipulating incoming requests and outgoing responses
+* Act as a validation layer, validating incoming requests, and outgoing responses
+* Contract test your APIs
+* Extend existing APIs with new endpoints or capabilities
+* Act as a system-wide proxy, blocking traffic to particular websites or endpoints
+
+## Conduct vs Serve
+
+Conduct and Serve are important concepts to understand when using Prism.
+
+* Conduct is an isolated scenario run. You tell Prism what scenarios you want to run, give it an environment to run against, and Prism will generate a report of the run
+
+* Serving, on the other hand, is a long running instance of Prism that applies scenarios to HTTP traffic
+
+### Conduct Use Cases
+
+1.  Debugging your API implementation or specification
+2.  Integrating with your CI/CD Environment: Catch bugs before they get to your actual API Consumers
+3.  Webhooks: Generate your OAS from code, automatically upload it to Stoplight
+
+![Prism Conduct](https://github.com/stoplightio/docs/blob/develop/assets/gifs/prism-introduction-conduct.gif?raw=true)
+
+### Serve Use Cases
+
+1.  Mocking back one or more specifications: Useful to help teams work in parallel and simplify testing dependencies.
+2.  Validating live traffic between your client/backend.
+3.  Your API, your workflow, your Prism. Prism is very flexible. You can easily create an instance that will record your API traffic, save it to S3, and then create another instance that will replay that API traffic.
+
+![Mock Server](https://github.com/stoplightio/docs/blob/develop/assets/gifs/prism-introduction-mock.gif?raw=true)
+
+### Stoplight Prism Helpers
+
+The [Prism Helpers](https://next.stoplight.io/stoplight/prism) project is a collection of scenarios, specifications, and Prism instances that illustrate how to use Prism effectively. Please go [here](https://community.stoplight.io) and let us know what you would like to see.
+
+---
+
+**Related Articles**
+
+* [Javascript Runtime Refrence](/runtime.md)
+* [Passing Data Between Steps](/testing/getting-started/passing-data-between-steps)
+* [Running Tests In Stoplight](/testing/running-tests/in-stoplight)
+* [Running Tests in the Terminal](/testing/running-tests/in-the-terminal)
+* [Running Tests Triggered by URL](/testing/running-tests/triggering-by-url)
+* [Using Variables Overview](/testing/using-variables/overview)
+* [$$.env (Environment)](/testing/using-variables/environment)
+* [$.ctx(Context)](/testing/using-variables/context)
+* [Sending HTTP Requests](/testing/sending-http-requests/overview)
+* [Referencing other Scenarios](/testing/referencing-other-scenarios/overview)
+* [Contract Testing](/testing/leveraging-openapi/contract-testing)
+* [Integrating in Continuous Integration](/testing/continuous-integration/overview)

articles/prism/overview.md

@@ -1,61 +0,0 @@
-# Mocking with Prism 
-
-Prism is a performant, dependency free server, built specifically to work with web APIs. 
-
-### Features 
-- Act as a mock server, routing incoming requests to example repsonses, or dynamically generating examples on the fly. 
-- Act as a transformation layer, manipulating incoming requests and outgoing responses. 
-- Act as a validation layer, validating incoming requests and outgoing responses. 
-- Contract test your APIs, given an OAS(Swagger 2) file. 
-- Log all or a subset of traffic to configurable locations. 
-- Extend existing APIs with new endpoints or capabilites. 
-- Act as a system-wide proxy, blocking traffic to particular websites or endpoints. 
-
-### Simplicity Redefined 
-Run it anywhere. It runs on OS X, Windows, and Linux, with no external dependencies. It is a single, self-contained binary file, that you can easily run from your terminal with a single command.  
-
-## Getting Started 
-
-#### macOS and Linux 
-
-```# Install Prism 
-curl https://raw.githubusercontent.com/stoplightio/prism/master.install.sh | sh
-```
-
-#### Windows 
-Download the appropriate binary from [here](https://github.com/stoplightio/prism/releases). Unzip the binary file, then navigate in your terminal to the folder where you extracted Prism. 
-
-### Run a Simple Mock Server 
-Prism understands OAS(Swagger 2), so let's get started by spinning up a quick mock server for the popular Petstore API. To do this, run the following command in your terminal: 
-
-```# os x / linux
-prism run --mock --list --spec http://petstore.swagger.io/v2/swagger.json
-
-# windows 
-path/to/prism.exe run --mock --list --spec http://petstore.swagger.io/v2/swagger.json
-```
-
-Here, you are using the "run" command to run a server based on the spec file passed in via the --spec argument. The spec location can be the filepath to a file on your computer, or the URL to a publicly hosted file. The mock argument tells Prism to mock all incoming requests, instead of forwarding them to the API host described in the spec file. The list argument is a convenience, and tells Prism to print out the endpoints in the spec on startup. 
-
-Prism starts on port 4010 by default - try visiting ```http://localhost:4010/v2/pet/findByStatus``` in your browser. This is one of the endpoints described in the petstore spec you passed in. You'll notice that it returns an error about a required query string parameter "status". This is the automatic request validation at work! The swagger spec specifies that a query string parameter names "status" is required for this endpoint so Prism simulates a 400 response for you. Reload the page with a query string parameter, and you will see the dynamically generated mock response ```http://localhost:4010/v2/pet/findByStatus?status=available```.
-
-Tada! With a single command you have started a validating, dynamically mocking version of the Swagger petstore API. 
-
-### Run some Contract Tests
-
-Prism consumes OAS(Swagger 2) files. OAS provides the contract for your API. If your OAS file contains the x-tests extension (generated automatically if you use the Stoplight app to manage your OAS and tests) then you can run tests with Prism.
-
-Check out [this specification](https://goo.gl/jniYmw). If you scroll past all the regular OAS properties, you will notice a ```x-tests``` extension near the bottom of the file. Inside of that property, we have a few test cases defined. This OAS file, along with its tests, is managed in the Stoplight app (we export our API from within the app to produce this file). 
-
-#### To Run the Contract Tests 
-```
-# os x / linux 
-prism test --spec https://goo.gl/jniYmw
-
-# windows
-path/to/prism.exe test --spec https://goo.gl/jniYmw
-```
-
-You should see some nice output to your terminal detailing the tests and assertions that are run. These tests take our OAS contract and apply it to your API. They act as a sort of sync manager. 
-
-> If a test fails, it means one of two things - your API is broken or, our OAS contract is out of date / incorrect