diff --git a/ci/dictionary.txt b/ci/dictionary.txt
index 75c55973..ecf6430b 100644
--- a/ci/dictionary.txt
+++ b/ci/dictionary.txt
@@ -542,6 +542,7 @@ UnsafeCell
 unsafety
 unsized
 unsynchronized
+Unyank
 URIs
 UsefulType
 username
diff --git a/src/ch14-02-publishing-to-crates-io.md b/src/ch14-02-publishing-to-crates-io.md
index e28e28ec..64885d05 100644
--- a/src/ch14-02-publishing-to-crates-io.md
+++ b/src/ch14-02-publishing-to-crates-io.md
@@ -253,7 +253,9 @@ the `art` crate</span>
 
 In cases where there are many nested modules, re-exporting the types at the top
 level with `pub use` can make a significant difference in the experience of
-people who use the crate.
+people who use the crate. Another common use of `pub use` is to re-export
+definitions of a dependency in the current crate to make that crate's
+definitions part of your crate’s public API.
 
 Creating a useful public API structure is more of an art than a science, and
 you can iterate to find the API that works best for your users. Choosing `pub
@@ -436,10 +438,14 @@ yank means that all projects with a *Cargo.lock* will not break, and any future
 
 To yank a version of a crate, in the directory of the crate that you’ve
 previously published, run `cargo yank` and specify which version you want to
-yank:
+yank. For example, if we've published a crate named `guessing_game` version
+1.0.1 and we want to yank it, in the project directory for `guessing_game` we'd
+run:
 
 ```console
 $ cargo yank --vers 1.0.1
+    Updating crates.io index
+        Yank guessing_game:1.0.1
 ```
 
 By adding `--undo` to the command, you can also undo a yank and allow projects
@@ -447,6 +453,8 @@ to start depending on a version again:
 
 ```console
 $ cargo yank --vers 1.0.1 --undo
+    Updating crates.io index
+      Unyank guessing_game_:1.0.1
 ```
 
 A yank *does not* delete any code. It cannot, for example, delete accidentally
diff --git a/src/ch14-03-cargo-workspaces.md b/src/ch14-03-cargo-workspaces.md
index a7e42aaf..942d61b4 100644
--- a/src/ch14-03-cargo-workspaces.md
+++ b/src/ch14-03-cargo-workspaces.md
@@ -24,11 +24,10 @@ $ cd add
 ```
 
 Next, in the *add* directory, we create the *Cargo.toml* file that will
-configure the entire workspace. This file won’t have a `[package]` section or
-the metadata we’ve seen in other *Cargo.toml* files. Instead, it will start
-with a `[workspace]` section that will allow us to add members to the workspace
-by specifying the path to the package with our binary crate; in this case,
-that path is *adder*:
+configure the entire workspace. This file won’t have a `[package]` section.
+Instead, it will start with a `[workspace]` section that will allow us to add
+members to the workspace by specifying the path to the package with our binary
+crate; in this case, that path is *adder*:
 
 <span class="filename">Filename: Cargo.toml</span>