docs: fix formatting that breaks docs.github.com publishing

The docs/ content is synced to docs.github.com (via github/docs-internal),
where it must meet that platform's style rules. Two recurring issues were
being reintroduced and fixed by hand on every sync:

* Unordered lists must use asterisks (*) not hyphens (-) on docs.github.com.
  Converted prose bullets in features/fleet-mode.md, features/hooks.md, and
  hooks/post-tool-use.md (code blocks and frontmatter left untouched).
* Every table cell must have a value. Filled the empty AZURE_TOKEN_CREDENTIALS
  Example cell in setup/azure-managed-identity.md with ManagedIdentityCredential
  (matches the row's description and this page's Azure scenario).

Note: intentionally-blank cells that represent structure (optional 'Required'
columns in property tables, section-grouping rows in troubleshooting/
compatibility.md, and the corner cell of the setup/scaling.md comparison
matrix) were left as-is.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: sunbrye

docs/features/fleet-mode.md

@@ -8,18 +8,18 @@ Fleet mode is useful when the work can be decomposed before execution and each u
 
 Good fits include:
 
-- Multi-file refactors where each worker owns a file, package, or language SDK.
-- Batch reviews where each worker checks a separate diff, module, or alert group.
-- Parallel research across independent repositories, services, or feature areas.
-- Documentation refreshes where each worker owns a page or topic.
-- Migration tasks where each worker can validate its own slice and report back.
+* Multi-file refactors where each worker owns a file, package, or language SDK.
+* Batch reviews where each worker checks a separate diff, module, or alert group.
+* Parallel research across independent repositories, services, or feature areas.
+* Documentation refreshes where each worker owns a page or topic.
+* Migration tasks where each worker can validate its own slice and report back.
 
 Avoid fleet mode for:
 
-- Sequential tasks where step 2 needs the concrete output from step 1.
-- Tightly coupled edits where workers would contend for the same files.
-- Small tasks that one synchronous sub-agent or the parent agent can finish quickly.
-- Tasks that require continuous shared reasoning rather than clear ownership.
+* Sequential tasks where step 2 needs the concrete output from step 1.
+* Tightly coupled edits where workers would contend for the same files.
+* Small tasks that one synchronous sub-agent or the parent agent can finish quickly.
+* Tasks that require continuous shared reasoning rather than clear ownership.
 
 Fleet mode works best when the parent session can create clear units of work, assign one owner per unit, and define what each worker must return.
 
@@ -321,29 +321,29 @@ Keep plugin-provided sub-agent types narrow and descriptive so the orchestrator
 
 ## Best practices
 
-- Decompose the work into independent units before starting fleet mode.
-- Minimize dependencies between todos; dependencies reduce parallelism.
-- Give each todo a durable ID, a clear title, and a complete description.
-- Make each sub-agent own exactly one todo at a time.
-- Use background sub-agents for truly parallel work.
-- Use synchronous sub-agent calls for serialized steps or validation gates.
-- Provide each sub-agent with complete context; sub-agents are stateless across calls.
-- Include file paths, commands, expected outputs, and constraints in each worker prompt.
-- Do not dispatch a single background sub-agent; prefer a synchronous call or batch multiple workers in parallel.
-- Avoid assigning overlapping files to different workers unless the parent agent will reconcile conflicts explicitly.
-- Require every worker to report what it changed, how it validated the change, and what remains blocked.
-- Have the parent agent verify the combined result after workers finish.
+* Decompose the work into independent units before starting fleet mode.
+* Minimize dependencies between todos; dependencies reduce parallelism.
+* Give each todo a durable ID, a clear title, and a complete description.
+* Make each sub-agent own exactly one todo at a time.
+* Use background sub-agents for truly parallel work.
+* Use synchronous sub-agent calls for serialized steps or validation gates.
+* Provide each sub-agent with complete context; sub-agents are stateless across calls.
+* Include file paths, commands, expected outputs, and constraints in each worker prompt.
+* Do not dispatch a single background sub-agent; prefer a synchronous call or batch multiple workers in parallel.
+* Avoid assigning overlapping files to different workers unless the parent agent will reconcile conflicts explicitly.
+* Require every worker to report what it changed, how it validated the change, and what remains blocked.
+* Have the parent agent verify the combined result after workers finish.
 
 ## Limitations and open questions
 
-- Fleet mode is exposed through generated session RPC bindings and is marked experimental in several SDKs.
-- The SQL todos pattern is the canonical coordination model in the runtime guidance, but whether it is a stable extensibility contract for SDK consumers is still an open question.
-- `subagentStart` and `subagentStop` are runtime hook names; this branch exposes sub-agent lifecycle to SDK consumers through the generic session event stream, not dedicated hook callbacks.
-- Plugin sub-agent registration is configured at the runtime layer through `--plugin-dir`; no SDK-level plugin registration helper was verified on this branch.
-- Java native typed bindings for `session.fleet.start` were not found in the Java SDK source on this branch.
-- Fleet mode does not remove the need for parent-agent review. Parallel workers can produce inconsistent assumptions that the orchestrator must reconcile.
+* Fleet mode is exposed through generated session RPC bindings and is marked experimental in several SDKs.
+* The SQL todos pattern is the canonical coordination model in the runtime guidance, but whether it is a stable extensibility contract for SDK consumers is still an open question.
+* `subagentStart` and `subagentStop` are runtime hook names; this branch exposes sub-agent lifecycle to SDK consumers through the generic session event stream, not dedicated hook callbacks.
+* Plugin sub-agent registration is configured at the runtime layer through `--plugin-dir`; no SDK-level plugin registration helper was verified on this branch.
+* Java native typed bindings for `session.fleet.start` were not found in the Java SDK source on this branch.
+* Fleet mode does not remove the need for parent-agent review. Parallel workers can produce inconsistent assumptions that the orchestrator must reconcile.
 
 ## See also
 
-- [Custom agents and sub-agent orchestration](custom-agents.md)
-- [Hooks](hooks.md)
+* [Custom agents and sub-agent orchestration](custom-agents.md)
+* [Hooks](hooks.md)

docs/features/hooks.md

@@ -1051,16 +1051,16 @@ const session = await client.createSession({
 
 For full type definitions, input/output field tables, and additional examples for every hook, see the API reference:
 
-- [Hooks Overview](../hooks/hooks-overview.md)
-- [Pre-Tool Use](../hooks/pre-tool-use.md)
-- [Post-Tool Use](../hooks/post-tool-use.md)
-- [User Prompt Submitted](../hooks/user-prompt-submitted.md)
-- [Session Lifecycle](../hooks/session-lifecycle.md)
-- [Error Handling](../hooks/error-handling.md)
+* [Hooks Overview](../hooks/hooks-overview.md)
+* [Pre-Tool Use](../hooks/pre-tool-use.md)
+* [Post-Tool Use](../hooks/post-tool-use.md)
+* [User Prompt Submitted](../hooks/user-prompt-submitted.md)
+* [Session Lifecycle](../hooks/session-lifecycle.md)
+* [Error Handling](../hooks/error-handling.md)
 
 ## See also
 
-- [Getting Started](../getting-started.md)
-- [Custom Agents & Sub-Agent Orchestration](./custom-agents.md)
-- [Streaming Session Events](./streaming-events.md)
-- [Debugging Guide](../troubleshooting/debugging.md)
+* [Getting Started](../getting-started.md)
+* [Custom Agents & Sub-Agent Orchestration](./custom-agents.md)
+* [Streaming Session Events](./streaming-events.md)
+* [Debugging Guide](../troubleshooting/debugging.md)

docs/hooks/post-tool-use.md

@@ -2,10 +2,10 @@
 
 The `onPostToolUse` hook is called **after** a tool executes **successfully**. Use it to:
 
-- Transform or filter tool results
-- Log tool execution for auditing
-- Add context based on results
-- Suppress results from the conversation
+* Transform or filter tool results
+* Log tool execution for auditing
+* Add context based on results
+* Suppress results from the conversation
 
 > **Failure variant** — `onPostToolUse` only fires for successful tool executions. To observe **failed** tool calls, register `onPostToolUseFailure` (`on_post_tool_use_failure` in Python, `OnPostToolUseFailure` in Go/.NET, `on_post_tool_use_failure` in Rust). The handler receives `{ sessionId, toolName, toolArgs, error, timestamp, workingDirectory }` — the `error` field is a string extracted from the tool's failure result — and may return `{ additionalContext: string }` to inject extra guidance for the model (e.g. retry hints). See the [hooks overview](./hooks-overview.md) for the full list.
 > <a id="failure-variant"></a>
@@ -507,6 +507,6 @@ const session = await client.createSession({
 
 ## See also
 
-- [Hooks Overview](./README.md)
-- [Pre-Tool Use Hook](./pre-tool-use.md)
-- [Error Handling Hook](./error-handling.md)
+* [Hooks Overview](./README.md)
+* [Pre-Tool Use Hook](./pre-tool-use.md)
+* [Error Handling Hook](./error-handling.md)

docs/setup/azure-managed-identity.md

@@ -233,7 +233,7 @@ await client.stop();
 
 | Variable | Description | Example |
 |----------|-------------|---------|
-| `AZURE_TOKEN_CREDENTIALS` | When running in **Azure**, set it to `ManagedIdentityCredential`. When running **locally**, set it to either `dev` or a developer tool credential name, such as `AzureCliCredential`. | |
+| `AZURE_TOKEN_CREDENTIALS` | When running in **Azure**, set it to `ManagedIdentityCredential`. When running **locally**, set it to either `dev` or a developer tool credential name, such as `AzureCliCredential`. | `ManagedIdentityCredential` |
 | `FOUNDRY_RESOURCE_URL` | Your Microsoft Foundry resource URL | `https://<my-resource>.openai.azure.com` |
 
 No API key environment variable is needed—authentication is handled by `DefaultAzureCredential`, which automatically supports: