---
name: wecode-ai/wiki-submit-skill
source: https://app.decimal.ai/s/wecode-ai-wiki-submit-skill@3/SKILL.md
source_sha256: fc99bcab62cc
---

# Wiki Submit Skill

This skill provides a simple command-line tool to submit wiki documentation pages to the Wegent backend.

## Page paths

A page is identified by its `--path`: `index`, `architecture/backend`, `modules/indexing`.
Lowercase, `/`-separated, no file extension, at most 4 folders deep. Two paths may not
differ only by case — the projection matches them case-insensitively, so they would
collapse into one page.

**Keep a path stable across runs.** It is what lets an unchanged page keep its place,
its links and its search index. Changing it republishes the page as a deletion plus an
insertion, so reword titles freely and move paths rarely.

Send a page's **complete content** every time. There is no patch format; what you send
replaces the page.

A section that holds pages needs a page of its own. If you submit
`architecture/backend`, also submit `architecture` with an overview of that section.
Write `index` as the wiki overview.

Link to another wiki page by its complete page path without an extension, for example
`[Backend](architecture/backend)`. Do not use `./architecture/backend.md` or a URL: wiki
pages are not files served at those locations.

Anything submitted is part of the version; there is no scratch page or draft namespace.
Remove an accidental page before completing the run.

## Usage

### Submit a page from a markdown file

```bash
node wiki_submit.js submit \
  --generation-id 123 \
  --path architecture/backend \
  --title "Backend Architecture" \
  --file /path/to/page.md
```

### Submit page content directly

Note the `$'...'` quoting: in a plain double-quoted string `\n` stays a backslash and
an `n`, and the page arrives as one long line. For anything beyond a few lines, write
the markdown to a file and use `--file`.

```bash
node wiki_submit.js submit \
  --generation-id 123 \
  --path index \
  --title "Overview" \
  --content $'# Overview\n\nYour markdown content here...'
```

### Read what a page currently says

Only your own generation is readable, which in an incremental run is a complete copy
of the published wiki — so this is how you see a page before revising it.

```bash
node wiki_submit.js read --generation-id 123 --path architecture/backend > current.md
```

Exits 0 with no output when the page does not exist yet. In an incremental run that
means the page is new.

### Remove pages that no longer have a subject

Only meaningful in an incremental run, where your version starts as a copy of the
published wiki and not writing a page therefore does *not* remove it.

```bash
node wiki_submit.js remove \
  --generation-id 123 \
  --path modules/legacy-sync \
  --path guides/old-setup
```

### Complete the wiki generation

Report the commit you documented, so the next run knows what has already been covered.

```bash
node wiki_submit.js complete \
  --generation-id 123 \
  --head-commit "$(git rev-parse HEAD)" \
  --structure-order index,quickstart,architecture,modules
```

`--structure-order` controls the order readers see. Put `index` first and arrange the
remaining paths so the wiki reads from overview to detail. Unlisted paths are appended.

The response says whether the version was published. A completed version can still be
refused when it is unexpectedly smaller than the published wiki. If publication is
refused, write the missing pages and run `complete` again.

The response may also report Mermaid diagrams that do not render after a successful
publication. Rewrite the named pages at the same paths and run `complete` again so the
corrected version is republished.

### Mark generation as failed

```bash
node wiki_submit.js fail \
  --generation-id 123 \
  --error-message "Failed to analyze repository structure"
```

## Section types

`--type` defaults to `chapter` and can be left out. The legacy wiki used it to group
pages; a code wiki organises them by path instead.

Accepted values: `overview`, `architecture`, `module`, `api`, `guide`, `deep`, `chapter`.

## Authentication

The authorization token is **automatically obtained** from the `TASK_INFO.auth_token` environment variable when running inside an executor container. You don't need to specify it manually.

## Environment Variables

The following environment variables are automatically available in executor containers:

- `TASK_API_DOMAIN`: Backend API domain (e.g., `http://wegent-backend:8000`). The endpoint is automatically built as `{TASK_API_DOMAIN}/api/internal/wiki/generations/contents`
- `TASK_INFO`: Contains `auth_token` for API authentication

Optional override:
- `WIKI_ENDPOINT`: Full API endpoint URL (overrides auto-built endpoint from TASK_API_DOMAIN)