SemText

Reference

Every tag, one table

All 115 elements across the SemText vocabulary, its extension families and NPL — the tag, the family it belongs to, and what it does in one sentence each. The grouped reference has the per-element pages; the editor opens any of them live.

Tag Family What it does
agent SemText You write name, bio, and instructions as plain children. The browser ignores this element; extraction turns it into one agent record. Use it when the document is addressed to or about an agent.
agent-kit-acceptance-criteria Agent Kit You author the criteria; the card renders them as a structured list. Point it at fixtures or an endpoint and it shows the cached snapshot with a last-refreshed stamp.
agent-kit-agent-persona Agent Kit The content you write inside is the record; the card frames it. One renderer serves both persona tags, parameterized by kind.
agent-kit-artifact Agent Kit You set the type and language and author the content; the card renders it as a cached specimen with a refresh stamp.
agent-kit-asset Agent Kit You point src at the asset, set its mime type and write the caption. The card renders the cached asset; the caption is the record.
agent-kit-board Agent Kit You author the columns and the ticket refs inside; the board renders the layout you wrote. It displays the cached state — it does not poll the tracker.
agent-kit-bug Agent Kit One renderer serves all six ticket tags, parameterized by type. The inner content you write is the record; the chrome adds the type and the cached state.
agent-kit-chatroom Agent Kit You author the messages; the card renders the transcript with a cached-snapshot stamp. Refresh is the CLI lane — the embed never fetches at read time.
agent-kit-cucumber Agent Kit You author the spec; the card displays the source verbatim in a cached card. Point it at fixtures for the snapshot stamp.
agent-kit-custom-assert Agent Kit You author the expr and expect pairs; the card renders them as a structured list from the cached snapshot.
agent-kit-cypress Agent Kit You author the spec; the card displays it verbatim with a last-refreshed stamp from the cached snapshot.
agent-kit-epic Agent Kit One renderer serves all six ticket tags, parameterized by type. The inner content you write is the record; the chrome adds the type and the cached state.
agent-kit-issue Agent Kit You set the key, state and labels and write the body; the card renders the cached ticket snapshot. It displays state — it never queries the tracker live.
agent-kit-organization Agent Kit One renderer serves both reference-card tags, parameterized by kind. The content you write inside is the record.
agent-kit-project Agent Kit One renderer serves both reference-card tags, parameterized by kind. The content you write inside is the record.
agent-kit-review Agent Kit You author the comments and set the verdict; the card renders the cached review. The verdict is data, not a live check.
agent-kit-sub-task Agent Kit One renderer serves all six ticket tags, parameterized by type. The inner content you write is the record; the chrome adds the type and the cached state.
agent-kit-task Agent Kit One renderer serves all six ticket tags, parameterized by type. The inner content you write is the record; the chrome adds the type and the cached state.
agent-kit-test-case Agent Kit You author the steps and what should happen; the card renders them as a structured list from the cached snapshot.
agent-kit-test-suite Agent Kit You author the rows — one per branch — and the card renders them from the cached snapshot with a refresh stamp.
agent-kit-ticket-ref Agent Kit You set the key, org and project; the ref renders as an inline card linking into the ticket family. It stays ordinary text with JavaScript off.
agent-kit-user-persona Agent Kit The content you write inside is the record; the card frames it, with an optional avatar. One renderer serves both persona tags.
agent-kit-user-story Agent Kit One renderer serves all six ticket tags, parameterized by type. The inner content you write is the record; the chrome adds the type and the cached state.
conclusion SemText You write it inside a sem-fact, after the statement. Flashcard views show it on the answer side; extraction pairs it with the statement.
highlight SemText You wrap the words to remember in a highlight child, or use [[double brackets]] as shorthand. Hiding them turns the passage into a self-test; showing them again reveals the answers.
incorrect-statement SemText You write it inside a sem-fact. Quiz views can offer it as a wrong answer choice; extraction keeps it labelled as false — never as a claim.
npl-agent NPL You write the agent's name, type, and rules as attributes and text. The page shows them as a tidy card. Machines can read the same fields back.
npl-artifact NPL Wrap the artifact's title and content in this element and the page adds a frame around them. The content itself is never changed.
npl-cot NPL Each step is listed in order, with the final answer at the end. The list uses a plain details box, so it works even with JavaScript off.
npl-critique NPL You write the subject, the strengths, the weaknesses, and the verdict. The element lays them out as a clean, labelled review card.
npl-declaration NPL It renders the version line of an NPL document, such as [email protected], as a banner at the top. Extended documents are marked the same way.
npl-directive NPL You write the instruction, and optionally a longer note, inside this element. The page shows it as a small chip the reader can spot while scanning.
npl-example NPL It exists to demonstrate the pattern, not to be used in real documents. Real elements replace it.
npl-flag NPL You give it a name and a value. The reader can click the row to apply the setting. If the name implies a number range, values outside it are flagged.
npl-flags NPL It wraps one or more npl-flag elements. You can add a short note above the rows to explain what they do.
npl-hormones NPL Each drive has a level from 0 to 100, drawn as a bar with an arrow showing whether it rose or fell. Notes explain what a bar means when it passes a set limit.
npl-intent NPL You write the goal, what is in and out of scope, the outcomes, and any assumptions. The element lays them out in a clear grid so a reader can check the plan at a glance.
npl-mindread NPL You write the subject, the signals (tone, patterns, things left unsaid), and the reading drawn from them. The result is clearly labelled as a guess, not a fact.
npl-mode NPL You write each mode as a child element. The main mode is marked so the reader knows which lens leads. This element only shows information; it changes nothing.
npl-mood NPL You write the mood in the mood attribute. Extra children can carry the tone, the context, and how the agent will approach work in this mood.
npl-poa NPL You write the tree, the reasoning with weights, and the option that was picked. The element shows all three parts; it never draws the tree for you.
npl-ref NPL You write the assessment, the improvements, the validation, and any eval notes. The element lays them out as a review card after the work.
npl-rubric NPL You write the criteria, their weights, and their scores. The total is shown as given, or worked out from the weights. Wrong or missing numbers are flagged, not hidden.
npl-section NPL Known section types get a matching header; unknown types get a warning style so a typo is easy to spot. The content stays plain text, so search and copy still work.
npl-thought NPL Each child is one thought with a type attribute, such as a question or a risk. The element shows them as a tidy list of bubbles.
npl-vos NPL You write each part of the state. The element shows them as labelled parts of one bracket. An optional collective part covers group personas.
sem-api-call SemText The definition card for an endpoint. You write the operation name, HTTP method and path, then one sem-api-param child per parameter or response field; the page shows a table and machines read the same fields back.
sem-api-param SemText The child of sem-api-call. The in attribute says where the parameter lives (query, body, header, or response for a returned field); required marks the ones the caller must send.
sem-audiences SemText You list each group here, then mark sections with an audience attribute. The reader picks their group and the page hides the rest. Nothing is deleted — machines still read the whole document.
sem-browser SemText It gives the document an address bar and a window frame, while everything inside stays real, working SemText. Use it when a page demonstrates a document rather than being one.
sem-changelog SemText You wrap the collection in sem-changelogs and write one entry per change inside, each with its date and a name. It stays ordinary readable text with JavaScript off.
sem-changelogs SemText You set the kind — added, changed, fixed, removed — on each entry, and the chrome labels the collection. The entries themselves are the record; nothing is invented.
sem-chronology SemText Each child is one event with a when date, an optional end date, and an optional status. You write the events in order; the element never sorts them. It can show the events as a timeline rail or as a plain list.
sem-code SemText The code is shown exactly as written — spacing included. You can mark the lines that matter, and the reader gets copy controls a plain code block cannot offer.
sem-data-join SemText You name the two sources and the key column. The joined result becomes a new data set that queries can use. Nothing shows on the page by itself — it only feeds queries.
sem-data-query SemText You write one query: pick columns, filter, sort, and limit. Joins are declared separately, and nothing can change the data. Readers see the results, and the query text stays visible.
sem-data-source SemText You either write the data inside the element or point at a file with source. Doing both is an error the element reports clearly. With JavaScript off, the data still reads as text.
sem-data-visualizer SemText You put one or more sem-data-source children inside, plus any joins and queries. The container owns the shared state: which data set and query are active. With JavaScript off it shows the data as plain tables.
sem-detail SemText This is the child of sem-details. Wrap the words to recall in a highlight, or use [[double brackets]]. Hiding them turns the passage into a memory exercise.
sem-details SemText Each sem-detail child is one passage. Readers hide or show the highlighted words to test themselves. This is a study aid — not a reveal box and not a tab set.
sem-enhanced-document SemText You wrap the whole document in it once. Inside, plain HTML and sem-* elements mix freely. Extraction reads everything inside the wrapper; the browser treats it as an ordinary container.
sem-eval SemText You author the cases as sections or prose inside; the container adds the chrome and label. It states what a good answer looks like — it does not run anything.
sem-event SemText You give it a when date, an optional until end date, and an optional status such as planned or done. Its place in the page is its place in time — the element does not sort events.
sem-fact SemText You write the statement, the conclusion drawn from it, and any incorrect-statement to warn against. The id is the token other text cites. It reads as plain sentences with JavaScript off.
sem-facts SemText You wrap sem-fact children in it and pick a view with view-as. The view only changes how the facts are shown — the facts themselves stay the same, and machines always read all of them.
sem-faq SemText The question child is the question; everything you write in the answer child is the answer. Machines extract both verbatim; the browser can show them as a Q and A pair.
sem-faqs SemText You wrap sem-faq children in it. The view only changes how the questions and answers are shown — the words stay the same.
sem-file-tree SemText You type the tree with box-drawing characters or plain indentation; with JavaScript on the same engine as sem-site-tree turns it into a browsable listing, and with JavaScript off the pre is the record.
sem-guard-rail SemText You give it a severity and a scope, and write the rule as the content. It renders as a labelled, warning-level item in the guard-rails list.
sem-guard-rails SemText You wrap sem-guard-rail children in it. The collection sorts nothing and invents nothing — the rails you wrote, in the order you wrote them.
sem-howto SemText The name child is the title; everything else inside is the guide. The container adds the chrome and label — you write the steps with the elements you already have.
sem-kb SemText There is no special structure to learn — headings, prose and the other elements all work as usual. The container frames the article with a labelled panel.
sem-md SemText You write tables, lists, and other Markdown inside the element. Readers see a formatted table or list; machines get the Markdown back unchanged. Made for content that is easier to write as Markdown than as HTML.
sem-mockup SemText You pick the mode — text or html — and put the mockup inside. It renders as a framed specimen; nothing inside it is interactive.
sem-note SemText Pick a variant — info, warning, tip, or danger — for the colour and label. The collapsed attribute hides the body behind a short teaser. It stays ordinary readable text with JavaScript off.
sem-option SemText The correct attribute marks the right choice. Readers pick an answer; machines read which option was correct.
sem-philosophy SemText You write the principles inside as prose or lists. The container gives them a labelled home so machines can find the project's stated principles.
sem-plan SemText You write the plan inside as sections or prose, with an optional status. The container keeps the reasoning with the work it produced.
sem-procedure SemText You write one sem-step per step, in the order they happen. Each step carries a status: done, current, todo, or blocked. There are no step numbers to maintain — position is the number.
sem-profile SemText You give it an id and a short label. Sections tagged with this id show or hide as the reader switches groups.
sem-progress SemText You give it a value and an optional label. The page draws a bar with the percentage. Values outside the range are clamped for display, and the raw value still reads as text without JavaScript.
sem-properties SemText You write one sem-property per pair. The grid renders with plain CSS, so it works with JavaScript off. Machines read the same pairs back.
sem-property SemText The key attribute is the term; the text inside is its meaning. Add role=definition when the value defines the key.
sem-question SemText You write the question and one or more sem-option children. It pairs with the quiz views of sem-facts. Works as plain markup with JavaScript off.
sem-reader SemText It is page furniture, not content — a document without it loses nothing a machine would read. Readers get focus mode, type size, colour scheme, print, and audience controls in one place.
sem-reference SemText You give it an id, a link, and a note. In the text, cite it with a plain link to the id. The element carries the fields a plain list item cannot.
sem-references SemText You wrap one sem-reference per source. Numbers come from position. With JavaScript off the list still reads as an ordinary numbered list.
sem-requirement SemText You write the requirement as the content and set kind, status and priority as attributes. Machines read it as one requirement record; readers see a labelled statement.
sem-reveal SemText You write the question as the summary and the answer as the body. It is a plain details box, so it works with JavaScript off. Use it for explanation — a sem-fact is for claims.
sem-rubric SemText You author the grid inside as a plain table or row prose — the container does not force a shape. Set max-score and the chrome shows the scale.
sem-runbook SemText You author the parts inside with the elements you already use; the container adds the chrome and a label. It reads as a document and extracts as one runbook record.
sem-site-tree SemText You nest bare node children with a path and optional label and kind. The same engine that reads sem-file-tree renders it, so both notations share one model.
sem-source SemText You put ordinary SemText inside. The reader sees the rendered result, then the exact source that produced it. Made for documents that teach the vocabulary.
sem-step SemText You write the instruction as the text and set status to done, current, todo, or blocked. Its place in the page is its order in the procedure.
sem-summary SemText Everything you put inside is the record. The container labels it as a summary so skimmers and machines both know what it is.
sem-table SemText You write a normal HTML table. Sorting and filtering only change what the reader sees; the markup stays the contract, so machines always read the same rows you wrote.
sem-tag-attr SemText The child of sem-tag-def. You write the attribute's name and type, add the required flag when it must be present, and the description text is what readers see in that row.
sem-tag-def SemText The definition card for a markup tag. You write the tag name and one sem-tag-attr child per attribute; the page shows a tidy table and machines read the same fields back. The reference pages use it, so the vocabulary documents itself.
sem-threat-model SemText You author them inside as sections or list prose; the container adds the chrome, label and scope. It frames the analysis — it does not check it.
sem-tldr SemText Whatever you put inside is the whole record — the element adds nothing and hides nothing. It renders as a set-apart block so the gist is visible at a glance.
sem-tsg SemText You write the problem and the resolution inside; the entry stays ordinary readable text with JavaScript off.
sem-tsgs SemText You wrap sem-tsg children in it. The collection is the record — the entries you wrote, in the order you wrote them.
sem-view SemText The name attribute labels the tab; the content inside is that view of the subject. With JavaScript off every view shows, each under its name.
sem-views SemText You wrap sem-view children and name each one. Readers switch by click, keyboard, or link. The content is never moved or rewritten — only which view shows changes.
sem-workflow SemText You write one sem-step per step, like a procedure, plus a duration for the whole run. Each step can carry a gate and check, and an if-no that says what to do when the check fails.
semext-annotate SemText Extensions The embed renders the cached threads snapshot; it is the one embed of the family with a live anonymous read. Visitors pin comments on the page and the embed shows them in place.
semext-docptr SemText Extensions The snapshot mirrors the pointer registry so a page can cite a source location durably — the card survives line drift until a CLI refresh re-snapshots it.
semext-media-prompt SemText Extensions The record is the prompt you write; the output region beside it is filled by the refresh CLI, not the element. The element never fetches and never generates — it only reports the region's state.
semext-sig-logs SemText Extensions The log lines you author are the record; the chrome builds an Open in SigNoz anchor from the query, range and env you set. The snapshot is refreshed by the CLI, never fetched at read time.
semext-sig-metrics SemText Extensions The metrics table you author is the record; the chrome adds the deep link from your query parameters. Nothing is fetched when the page is read.
semext-sig-synthetic-monitor SemText Extensions You author the monitor's expected definition; the card mirrors it and links to SigNoz. Running monitors is a service surface this element deliberately does not touch.
semext-sig-traces SemText Extensions The trace list you author is the record; the chrome adds the Open in SigNoz anchor. The embed is cached and link-only — no client queries.
semext-styleguide-theme SemText Extensions The card shows the theme name, key color swatches and a type sample, plus a link to preview the theme CSS at the src you set. Refresh is the CLI lane.
semext-styleguide-themes SemText Extensions It renders a summary line over its semext-styleguide-theme children. The snapshots are refreshed by the CLI, not at read time.
statement SemText You write the statement as the child of a sem-fact. Its pair, the conclusion, draws the takeaway. Plain text, no attributes needed.