> ## Documentation Index
> Fetch the complete documentation index at: https://labs.prompthon.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Article Guidelines

<div className="not-prose my-4 rounded-md border border-gray-200 bg-gray-50 p-2 text-sm dark:border-gray-800 dark:bg-gray-900/40">
  <div className="mb-2 px-1 text-xs font-semibold uppercase tracking-wide text-gray-500 dark:text-gray-400">Need help?</div>

  <div className="flex flex-wrap gap-2">
    <a className="inline-flex items-center gap-2 rounded-md border border-gray-200 bg-white px-3 py-1.5 font-medium text-gray-700 no-underline shadow-sm hover:border-gray-300 hover:bg-gray-50 dark:border-gray-800 dark:bg-gray-950/60 dark:text-gray-200 dark:hover:bg-gray-900" href="https://discord.gg/sDE2HhGTg4" target="_blank" rel="noreferrer">
      <Icon icon="discord" iconType="brands" size={14} />

      <span>Ask in Discord</span>
    </a>

    <a className="inline-flex items-center gap-2 rounded-md border border-gray-200 bg-white px-3 py-1.5 font-medium text-gray-700 no-underline shadow-sm hover:border-gray-300 hover:bg-gray-50 dark:border-gray-800 dark:bg-gray-950/60 dark:text-gray-200 dark:hover:bg-gray-900" href="https://github.com/Prompthon-IO/agent-systems-handbook/issues/new/choose" target="_blank" rel="noreferrer">
      <Icon icon="github" iconType="brands" size={14} />

      <span>Open a GitHub issue</span>
    </a>

    <a className="inline-flex items-center gap-2 rounded-md border border-gray-200 bg-white px-3 py-1.5 font-medium text-gray-700 no-underline shadow-sm hover:border-gray-300 hover:bg-gray-50 dark:border-gray-800 dark:bg-gray-950/60 dark:text-gray-200 dark:hover:bg-gray-900" href="https://github.com/Prompthon-IO/agent-systems-handbook/blob/main/SUPPORT.md" target="_blank" rel="noreferrer">
      <Icon icon="life-ring" size={14} />

      <span>Support guide</span>
    </a>
  </div>
</div>

Lab articles are durable handbook pages. They turn a useful signal, question, or
research thread into a structured explanation that future learners can use
without following the original conversation.

Use this contribution type when the output should become a long-lived page about
a concept, pattern, system, ecosystem area, or case study. A lab article is not a
chat transcript, quick note, or loose source roundup. It should help a reader
understand the topic, why it matters, how to reason about it, and where to go
next.

## Where articles belong

| Lane            | What it covers                                                             | Example topics                                                         |
| --------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| `foundations/`  | Core concepts and first-principles explanations.                           | what an agent is, agent systems, agents vs. workflows                  |
| `patterns/`     | Reusable design patterns that show up across many agent systems.           | memory and retrieval, planning and reflection, runtime building blocks |
| `systems/`      | System-level architecture, infrastructure, protocols, and evaluation.      | context engineering, interoperability, observability                   |
| `ecosystem/`    | Tools, frameworks, platforms, and the surrounding agent builder landscape. | agent frameworks, low-code builders, platform comparisons              |
| `case-studies/` | Applied examples that explain how agent systems work in real scenarios.    | deep research agents, customer support agents                          |

Choose the lane by topic, not by the source chapter that inspired the draft.

## Issue and review flow

Create a GitHub issue before drafting the article. Use the `Content Proposal`
form and choose `Lab article` or `Major revision to an existing lab page`.

The core team reviews the issue first. They may approve the scope, ask for
changes, or decline the proposal. After the issue is approved or acknowledged,
the contributor can fork the repository and make the change.

The core team then reviews the pull request separately. They may approve it,
request revisions, or decline the PR. If the issue or PR is declined, the
contributor can still keep their fork and reuse the work outside this repository.

## Required shape

Every article should follow:

* the metadata contract in [metadata-schema.mdx](/publications/metadata-schema)
* the structure in [Article Template](/contributor-kit/templates/article-template)

Required sections:

* `Summary`
* `Why It Matters`
* `Mental Model`
* `Architecture Diagram`
* `Tool Landscape`
* `Tradeoffs`
* `Citations`
* `Reading Extensions`
* `Update Log`

## Working rules

* Write in repo-native English.
* Use source inputs for concepts and citations, not as prose to preserve.
* Keep diagrams simple and repo-owned.
* Link to related lab pages so the article is part of the larger map.
* Keep the page durable. If a claim is likely to age fast, either verify it or
  write it in non-time-sensitive language.

## Completion standard

An article is ready for review when it:

* fits the lane cleanly
* follows the metadata and section template
* cites its main sources
* avoids copied upstream teaching flow
* includes at least one useful internal reading link