Clean up buildpack-author concepts and how-to

Signed-off-by: Natalie Arellano <[email protected]>

Author: Natalie Arellano

content/docs/for-buildpack-authors/concepts/buildpack-group.md

@@ -1,12 +1,13 @@
 +++
-title="Buildpack Group"
-weight=3
-summary="A buildpack group is a list of specific buildpacks composed together in an order such that the list is suitable for building an application. Because buildpacks are modular and reusable, a buildpack group is what allows you to connect multiple modular buildpacks together."
+title="What is a buildpack group?"
+weight=2
 +++
 
-## What is a buildpack group?
+A buildpack group is a list of individual buildpacks that are designged to work together to build an application.
 
-{{< param "summary" >}}
+<!--more-->
+
+Buildpack groups allow you to connect multiple modular buildpacks together, making buildpacks modular and re-usable.
 
 For example, you might have a buildpack that installs Java and a buildpack that uses Maven to build your application. These two buildpacks can be combined into a group to implement higher-level functionality, specifically that the first one will install Java and the second will use Java to run Maven, which is a Java build tool.
 

content/docs/for-buildpack-authors/concepts/caching-strategies.md

@@ -1,6 +1,6 @@
 +++
-title="Caching strategies"
-weight=1
+title="What caching strategies are available to buildpacks?"
+weight=4
 summary="Learn strategies for caching layers at build-time for future re-use."
 +++
 

content/docs/for-buildpack-authors/concepts/lifecycle-phases.md

@@ -1,12 +1,14 @@
 +++
-title="Lifecycle phases"
-weight=2
+title="What is the lifecycle?"
+weight=1
 +++
 
-There are five phases to a buildpacks build.
+The lifecycle is a binary responsible for orchestrating buildpacks.
 
 <!--more-->
 
+There are five phases to a buildpacks build.
+
 We work through a full example of building a "hello world" NodeJs web application.  
 
 In the example we run `pack` on the NodeJS application to produce an application image.  We assume that we have a NodeJS buildpack, `registry.fake/buildpacks/nodejs:latest`, that is decomposed into buildpacks that help with the build.  We expand each of the buildpacks phases to explain the process.  Throughout the example we take a production-level view of their operation.  For example, our assumed NodeJS buildpack will be described to create different build, cache and launch layers in a manner similar to how a real NodeJS buildpack would operate.

content/docs/for-buildpack-authors/concepts/targets.md

@@ -1,9 +1,11 @@
 +++
-title="Targets"
-weight=4
+title="What are targets?"
+weight=3
 +++
 
-The concept of "targets" is used to identify compatibility between buildpacks and base images.
+The concept of `targets` is used to identify compatibility between buildpacks and base images.
+
+<!--more-->
 
 Target data includes:
 * Operating system name (e.g., "linux")

content/docs/for-buildpack-authors/how-to/write-buildpacks/_index.md

@@ -1,6 +1,5 @@
 +++
 title="Write buildpacks"
 weight=1
-
 include_summaries=true
 +++

content/docs/for-buildpack-authors/how-to/write-buildpacks/add-sbom.md

@@ -1,11 +1,13 @@
 +++
-title="Adding Bill-of-Materials"
+title="Provide a Software Bill-of-Materials"
 weight=409
 +++
 
 Buildpacks can provide a [Software `Bill-of-Materials`](https://en.wikipedia.org/wiki/Software_bill_of_materials) (SBOM)
 to describe the dependencies that they provide.
 
+<!--more-->
+
 There are three supported ways to report SBOM data.
 You'll need to choose to use one or more of [CycloneDX](https://cyclonedx.org/), [SPDX](https://spdx.dev/) or [Syft](https://github.com/anchore/syft).
 The SBOM format you choose to use is likely to be the format accepted by the SBOM scanner (eg: [`syft cli`](https://github.com/anchore/syft)) you might choose to use.

content/docs/for-buildpack-authors/how-to/write-buildpacks/specify-launch-processes.md

@@ -5,6 +5,8 @@ weight=406
 
 One of the benefits of buildpacks is that they are multi-process - an image can have multiple entrypoints for each operational mode.
 
+<!--more-->
+
 Let's see how this works. We will specify a process type that allows a debugger to attach to our application.
 
 To enable running the debug process, we'll need to have our buildpack define a "process type" for the worker.

content/docs/for-buildpack-authors/how-to/write-extensions/_index.md

@@ -1,6 +1,5 @@
 +++
 title="Write extensions"
 weight=2
-
 include_summaries=true
 +++

content/docs/for-buildpack-authors/how-to/write-extensions/guidance.md

@@ -3,6 +3,9 @@ title="Guidance for extension authors"
 weight=1
 +++
 
+If you haven't already, check out our [tutorial](/docs/for-buildpack-authors/tutorials/basic-extension) on extensions,
+then come here for the finer points.
+
 <!--more-->
 
 ## During detect