Polish

docs/src/main/asciidoc/_attributes.adoc

@@ -16,7 +16,7 @@
 
 // project-specific attributes
 :core_path: {project-root}
-:plugins_path: {github-raw}/spring-cloud-contract-tools
+:plugins_path: {project-root}/spring-cloud-contract-tools
 :converters_path: {plugins_path}/spring-cloud-contract-converters
 :verifier_root_path: {core_path}/spring-cloud-contract-verifier
 :contract_spec_path: {core_path}/specs/spring-cloud-contract-spec-java

docs/src/main/asciidoc/_project-features-contract.adoc

@@ -190,7 +190,7 @@ include::{verifier_core_path}/src/test/resources/classpath/response.json[indent=
 ----
 ====
 
-When test or stub generation takes place, the contents of the `readFromFile.groovy` file is passed to the body
+When test or stub generation takes place, the contents of the `request.json` and `response.json` files are passed to the body
 of a request or a response. The name of the file needs to be a file with location
 relative to the folder in which the contract lays.
 

docs/src/main/asciidoc/_project-features-flows.adoc

@@ -352,7 +352,7 @@ methods to create request matchers, but you cannot use both approaches.
 
 On the consumer side, you can make the `resource.json` generated earlier in this section
 available on the classpath (by
-<<features-stub-runner-publishing-stubs-as-jars], for example). After that, you can create a stub that uses WireMock in a
+<<features-stub-runner-publishing-stubs-as-jars>>, for example). After that, you can create a stub that uses WireMock in a
 number of different ways, including by using
 `@AutoConfigureWireMock(stubs="classpath:resource.json")`, as described earlier in this
 document.

docs/src/main/asciidoc/index.adoc

@@ -1 +0,0 @@
-spring-cloud-contract.adoc