diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index d686e0beb98f7..ba96b7ebd8e8d 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -33,7 +33,7 @@ repos:
       - id: search-and-replace
         files: '\.md$'
   - repo: https://github.com/google/pre-commit-tool-hooks
-    rev: b7dadde912123577a1b5d4bfa279ce51ed06ee49 # frozen: v1.2.0
+    rev: 26cc20f971cad7dee54e1fcccb960b4e19b2bdce # frozen: v1.2.1
     hooks:
       - id: check-copyright
         args:
@@ -78,6 +78,12 @@ repos:
           )$
       - id: check-google-doc-style
       - id: check-links
+        name: Check links in non-proposal files
+        exclude: ^proposals/.*$
+      - id: check-links
+        name: Check links in proposal files
+        args: ['--anchors-only']
+        files: ^proposals/.*$
       - id: markdown-toc
   - repo: https://github.com/codespell-project/codespell
     rev: 01da43d753cdff4ea7dff952b4f5317450af31e3 # frozen: v2.1.0
diff --git a/docs/design/expressions/as_expressions.md b/docs/design/expressions/as_expressions.md
index c775ed9e9077a..49ca6a71801d1 100644
--- a/docs/design/expressions/as_expressions.md
+++ b/docs/design/expressions/as_expressions.md
@@ -166,10 +166,11 @@ The expression `x as U` is rewritten to `x.(As(U).Convert)()`.
 
 ## Alternatives considered
 
--   [Do not distinguish between safe and unsafe casts](/docs/proposals/p0845.md#merge-as-and-assume_as)
--   [Do not distinguish between `as` and implicit conversions](/docs/proposals/p0845.md#as-only-performs-implicit-conversions)
--   [Allow `iN as bool`](/docs/proposals/p0845.md#integer-to-bool-conversions)
--   [Disallow `bool as iN`](/docs/proposals/p0845.md#bool-to-integer-conversions)
+-   [Allow `as` to perform some unsafe conversions](/proposals/p0845.md#allow-as-to-perform-some-unsafe-conversions)
+-   [Allow `as` to perform two's complement truncation](/proposals/p0845.md#allow-as-to-perform-twos-complement-truncation)
+-   [`as` only performs implicit conversions](/proposals/p0845.md#as-only-performs-implicit-conversions)
+-   [Integer to bool conversions](/proposals/p0845.md#integer-to-bool-conversions)
+-   [Bool to integer conversions](/proposals/p0845.md#bool-to-integer-conversions)
 
 ## References
 
diff --git a/docs/design/expressions/implicit_conversions.md b/docs/design/expressions/implicit_conversions.md
index 460829e973cac..fff36c2745b51 100644
--- a/docs/design/expressions/implicit_conversions.md
+++ b/docs/design/expressions/implicit_conversions.md
@@ -281,10 +281,10 @@ types.
 
 ## Alternatives considered
 
--   [Provide lossy and non-semantics-preserving implicit conversions from C++](/docs/proposals/p0820.md#c-conversions)
--   [Provide no implicit conversions](/docs/proposals/p0820.md#no-conversions)
--   [Provide no extensibility](/docs/proposals/p0820.md#no-extensibility)
--   [Apply implicit conversions transitively](/docs/proposals/p0820.md#transitivity)
+-   [Provide lossy and non-semantics-preserving implicit conversions from C++](/proposals/p0820.md#c-conversions)
+-   [Provide no implicit conversions](/proposals/p0820.md#no-conversions)
+-   [Provide no extensibility](/proposals/p0820.md#no-extensibility)
+-   [Apply implicit conversions transitively](/proposals/p0820.md#transitivity)
 
 ## References
 
diff --git a/docs/design/generics/appendix-coherence.md b/docs/design/generics/appendix-coherence.md
index 8d50e239bcdf0..475a794de867f 100644
--- a/docs/design/generics/appendix-coherence.md
+++ b/docs/design/generics/appendix-coherence.md
@@ -46,8 +46,8 @@ These last two cases are highlighted as concerns in Rust in
 Since Carbon is bundling interface implementations into types, for the
 convenience and expressiveness that provides, we satisfy those use cases by
 giving the user control over the type of a value. This means having facilities
-for defining new [compatible types](terminology#compatible-types) with different
-interface implementations, and casting between those types as needed.
+for defining new [compatible types](terminology.md#compatible-types) with
+different interface implementations, and casting between those types as needed.
 
 ## The "Hashtable Problem"
 
@@ -213,9 +213,9 @@ This has some downsides:
     type.
 
 As a result, this doesn't make sense as the default behavior for Carbon based on
-its [goals](/project/goals.md). That being said, this could be a feature added
-later as opt-in behavior to either allow users to reduce code size or support
-use cases that require dynamic dispatch.
+its [goals](/docs/project/goals.md). That being said, this could be a feature
+added later as opt-in behavior to either allow users to reduce code size or
+support use cases that require dynamic dispatch.
 
 ### Rejected variation: manual conflict resolution
 
diff --git a/docs/design/generics/details.md b/docs/design/generics/details.md
index bcce9dee81122..3afc52a28e376 100644
--- a/docs/design/generics/details.md
+++ b/docs/design/generics/details.md
@@ -2099,7 +2099,7 @@ class DynamicArray(T:! Type) {
 ```
 
 For context, see
-["Interface type parameters and associated types" in the generics terminology document](terminology.md#interface-type-parameters-versus-associated-types).
+["Interface type parameters and associated types" in the generics terminology document](terminology.md#interface-type-parameters-and-associated-types).
 
 **Comparison with other languages:** Both
 [Rust](https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#specifying-placeholder-types-in-trait-definitions-with-associated-types)
@@ -2149,7 +2149,7 @@ interface at most once.
 If instead you want a family of related interfaces, one per possible value of a
 type parameter, multiple of which could be implemented for a single type, you
 would use
-[parameterized interfaces](terminology.md#interface-type-parameters-versus-associated-types).
+[parameterized interfaces](terminology.md#interface-type-parameters-and-associated-types).
 To write a parameterized version of the stack interface, instead of using
 associated types, write a parameter list after the name of the interface instead
 of the associated type declaration:
diff --git a/docs/design/lexical_conventions/numeric_literals.md b/docs/design/lexical_conventions/numeric_literals.md
index adc3a82e8a03a..2065a44f76833 100644
--- a/docs/design/lexical_conventions/numeric_literals.md
+++ b/docs/design/lexical_conventions/numeric_literals.md
@@ -121,7 +121,7 @@ The design provides a syntax that is deliberately close to that used both by C++
 and many other languages, so it should feel familiar to developers. However, it
 selects a reasonably minimal subset of the syntaxes. This minimal approach
 provides benefits directly in line with the goal that Carbon code should be
-[easy to read, understand, and write](../docs/project/goals.md#code-that-is-easy-to-read-understand-and-write):
+[easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write):
 
 -   Reduces unnecessary choices for programmers.
 -   Simplifies the syntax rules of the language.
diff --git a/docs/design/lexical_conventions/whitespace.md b/docs/design/lexical_conventions/whitespace.md
index 7ad83c7396c6b..d4fc48d3101e4 100644
--- a/docs/design/lexical_conventions/whitespace.md
+++ b/docs/design/lexical_conventions/whitespace.md
@@ -21,7 +21,8 @@ The exact lexical form of Carbon whitespace has not yet been settled. However,
 Carbon will follow lexical conventions for whitespace based on
 [Unicode Annex #31](https://unicode.org/reports/tr31/). TODO: Update this once
 the precise rules are decided; see the
-[Unicode source files](/proposals/p0142.md#characters-in-identifiers) proposal.
+[Unicode source files](/proposals/p0142.md#characters-in-identifiers-and-whitespace)
+proposal.
 
 Unicode Annex #31 suggests selecting whitespace characters based on the
 characters with Unicode property `Pattern_White_Space`, which is currently these
diff --git a/docs/design/lexical_conventions/words.md b/docs/design/lexical_conventions/words.md
index d61e8899c5201..716339c9fd948 100644
--- a/docs/design/lexical_conventions/words.md
+++ b/docs/design/lexical_conventions/words.md
@@ -26,7 +26,8 @@ The exact lexical form of words has not yet been settled. However, Carbon will
 follow lexical conventions for identifiers based on
 [Unicode Annex #31](https://unicode.org/reports/tr31/). TODO: Update this once
 the precise rules are decided; see the
-[Unicode source files](/proposals/p0142.md#characters-in-identifiers) proposal.
+[Unicode source files](/proposals/p0142.md#characters-in-identifiers-and-whitespace)
+proposal.
 
 ## Keywords
 
diff --git a/docs/project/code_review.md b/docs/project/code_review.md
index 5ab87c07b1e84..d238b64ff71c2 100644
--- a/docs/project/code_review.md
+++ b/docs/project/code_review.md
@@ -423,7 +423,7 @@ early on:
 
 1. Bring another person into the review to help address the specific issue.
    Typically they should at least be a code owner, and may usefully be a
-   [Carbon lead](groups.md#carbon-leads-1).
+   [Carbon lead](groups.md#carbon-leads).
 
 2. Ask the specific question in a broader forum, such as Discord, in order to
    get a broad set of perspectives on a particular area or issue.
diff --git a/docs/project/contribution_tools.md b/docs/project/contribution_tools.md
index 22038a0d41ac9..6257a984e29bf 100644
--- a/docs/project/contribution_tools.md
+++ b/docs/project/contribution_tools.md
@@ -285,8 +285,8 @@ the PR and proposal file for a new proposal. It's documented in
 
 #### pr_comments.py
 
-[pr_comments.py](/github/pr_comments.py) is a helper for scanning comments in
-GitHub. It's particularly intended to help find threads which need to be
+[pr_comments.py](/github_tools/pr_comments.py) is a helper for scanning comments
+in GitHub. It's particularly intended to help find threads which need to be
 resolved.
 
 Options can be seen with `-h`. A couple key options to be aware of are:
diff --git a/docs/project/design_style_guide.md b/docs/project/design_style_guide.md
index 3c83b42c5f9de..90ee4e46e4bf7 100644
--- a/docs/project/design_style_guide.md
+++ b/docs/project/design_style_guide.md
@@ -30,7 +30,7 @@ conventions for the language design, where they have been established.
 ## General
 
 The language design documentation follows the
-[style conventions](/CONTRIBUTING.html#google-docs-and-markdown) for Carbon
+[style conventions](/CONTRIBUTING.md#google-docs-and-markdown) for Carbon
 documentation.
 
 ## Linking
@@ -42,7 +42,7 @@ documentation.
 -   Links to specific sections of a proposal should link to the repository copy
     of the proposal file, using the section title or other appropriate link
     text. For example,
-    `[Painting details](/docs/proposals/p0123.md#painting-details)`
+    `[Painting details](/proposals/p0123.md#painting-details)`
 
 ## Document structure
 
@@ -75,7 +75,7 @@ that were considered, along with references to the proposals in which those
 designs were discussed. For example:
 
 ```md
--   [Paint widgets from bottom to top](/docs/proposals/p0123.md#alternatives-considered).
+-   [Paint widgets from bottom to top](/proposals/p0123.md#alternatives-considered).
 ```
 
 ### References
diff --git a/docs/project/groups.md b/docs/project/groups.md
index c3b41d7242f01..ee05080ab6602 100644
--- a/docs/project/groups.md
+++ b/docs/project/groups.md
@@ -23,7 +23,7 @@ We use a mix of:
 -   [GitHub organization](https://github.com/orgs/carbon-language/people)
     -   [GitHub team: Contributors with label access](https://github.com/orgs/carbon-language/teams/contributors-with-label-access):
         Mirrors the GitHub organization for write access.
-        [Manually updated](/github/update_label_access.py).
+        [Manually updated](/github_tools/update_label_access.py).
 -   [Discord access](https://discord.com/app)
 -   [Google group](https://groups.google.com/g/carbon-lang-contributors): Grants
     Google Drive access.
diff --git a/docs/project/principles/low_context_sensitivity.md b/docs/project/principles/low_context_sensitivity.md
index 92883a808dbe1..3e99e414aafe0 100644
--- a/docs/project/principles/low_context_sensitivity.md
+++ b/docs/project/principles/low_context_sensitivity.md
@@ -153,13 +153,13 @@ in Carbon that reflect applications of this principle:
 -   Carbon doesn't provide an analogy to C++'s
     [`using namespace`](https://en.cppreference.com/w/cpp/language/namespace#Using-directives)
     or a
-    ["wildcard imports" mechanisms](/docs/design/code_and_name_organization/#broader-imports-either-all-names-or-arbitrary-code)
+    ["wildcard imports" mechanisms](/proposals/p0107.md#broader-imports-either-all-names-or-arbitrary-code)
     that merge the names from one namespace into another. Either would introduce
     ambiguity in where a name is coming from, making the code more
     context-sensitive.
 
 -   Carbon doesn't support large blocks of code
-    [inside a namespace declaration](/docs/design/code_and_name_organization/#scoped-namespaces),
+    [inside a namespace declaration](/proposals/p0107.md#scoped-namespaces),
     where the reader would have to search for the beginning of the block to see
     what namespace applies.
 
diff --git a/docs/project/principles/one_way.md b/docs/project/principles/one_way.md
index 36e7399b4491f..49da7fe135c98 100644
--- a/docs/project/principles/one_way.md
+++ b/docs/project/principles/one_way.md
@@ -104,7 +104,7 @@ benefits, typically as a matter of convenience for either a common use-case or a
 particularly complex and important use-case. Some examples of why and where this
 occurs are:
 
--   For [performance](/docs/projects/goals.md#performance-critical-software), it
+-   For [performance](/docs/project/goals.md#performance-critical-software), it
     may at times be necessary to provide a specialized syntax that better
     supports optimization than a generic syntax.
 -   For
diff --git a/docs/project/pull_request_workflow.md b/docs/project/pull_request_workflow.md
index 59dce4ff1b0a2..30dcdfbfc405e 100644
--- a/docs/project/pull_request_workflow.md
+++ b/docs/project/pull_request_workflow.md
@@ -134,8 +134,7 @@ We suggest a specific workflow to address this:
     ```
 
     And create a pull request for it using the
-    [`gh`](/docs/project/contribution_tools.md#github_commandline_interface)
-    tool:
+    [`gh`](/docs/project/contribution_tools.md#gh-cli) tool:
 
     ```shell
     gh pr create
diff --git a/executable_semantics/README.md b/executable_semantics/README.md
index bf2000ff3c5c3..6a48b061188d4 100644
--- a/executable_semantics/README.md
+++ b/executable_semantics/README.md
@@ -24,8 +24,8 @@ considered definitive.
 
 The parser is implemented using the flex and bison parser generator tools.
 
--   [`syntax.lpp`](syntax/syntax.lpp) the lexer specification
--   [`syntax.ypp`](syntax/syntax.ypp) the grammar
+-   [`lexer.lpp`](syntax/lexer.lpp) the lexer specification
+-   [`parser.ypp`](syntax/parser.ypp) the grammar
 
 The parser translates program text into an abstract syntax tree (AST), defined
 in the [ast](ast/) subdirectory. The `UnimplementedExpression` node type can be
@@ -35,8 +35,8 @@ handling of the `UNIMPL_EXAMPLE` token for an example of how this is done, and
 see [`unimplemented_example_test.cpp`](syntax/unimplemented_example_test.cpp)
 for an example of how to test it.
 
-The [type checker](interpreter/typecheck.h) defines what it means for an AST to
-be a valid program. The type checker prints an error and exits if the AST is
+The [type checker](interpreter/type_checker.h) defines what it means for an AST
+to be a valid program. The type checker prints an error and exits if the AST is
 invalid.
 
 The parser and type checker together specify the static (compile-time)