Publish project files as shareable artifacts with the `kortix artifacts` CLI. Create editable Markdown docs that can be exported as PDF, or HTML pages for decks, dashboards, mockups, and tools; manage versions and share them with project members, selected people, or link holders.
Share work from the project's Drive as artifacts with the `kortix artifacts` CLI: a `doc` (a Markdown file people read and edit in place, exportable as PDF) or an `html` page (a slide deck, dashboard, mockup, tool or app). The files stay plain files in Drive; every save is a version from the Drive history; people open artifacts in the Kortix app under Artifacts and share them with the project, chosen people, or anyone with a link. Load when the user asks for a doc, report, write-up, plan, proposal, spec, decision record, comparison, deck, slides, presentation, dashboard, tracker, mockup, tool, page, or anything meant to be read, kept or shared; when a reply would run past a screen of structured content; or when the user names an artifact or an artifact link.
Run score Not tested
See how to installThis skill turns ordinary files in a project’s Files into artifacts that are easier to view and share. Use a Markdown doc for text-focused plans, specifications, and reports. Use an html page for slides, dashboards, mockups, or tools that need layout, charts, or interaction. With the kortix artifacts CLI, you can publish new artifacts, save changes to an existing one, list and view artifacts, share them, and inspect or restore versions. Each save creates a version in Files history, and artifacts can be opened from Artifacts in the app.
Use it when a plan or comparison is too long for a chat reply and needs to be revisited, edited, or shared with a team. Short answers and code changes do not need an artifact. When revising an existing artifact, save to that same artifact.
The kortix artifacts CLI needs write access to Files, and publishing or sharing also involves artifact permissions. New artifacts are private by default; sharing with the project or selected people must be set explicitly. Anyone can open a public link without logging in, so check before making one public. Do not publish secrets, tokens, or customer data.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 28, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Before you write one, read references/design.md (the page contract and the
design method). For any diagram, read references/diagrams.md.
</overview>
Answer in chat when the answer is a few sentences, a quick fact, or a short list. A code change belongs in the repository, not in an artifact.
Change the existing artifact when the user asks to revise, extend or fix one.
Never publish a second copy (see <update>).
</when>
Choose the treatment (utilitarian, UI or editorial) from
references/design.md.
2. Gather real content first. Get real numbers with units and dates, real
names of things, the user's own terms. Never use lorem ipsum. If data is
missing, the page says so.
3. Plan. For html, write the token plan (colors, type roles, a layout
line) as the :root block before anything else. For a doc, write the
heading outline first.
4. Write it once, well. Lead with the answer. Follow the fundamentals in
references/design.md.
5. Name it. Give it a --title and a one-sentence --description (rules
below).
6. Publish, look once, fix once. See "Check once" in
references/design.md. No loops.
7. Hand it over. Call show with the app link (url) and the name
(title): the chat shows the artifact itself, and the user opens it beside
the chat. End your reply with one line on what the
artifact shows. Never paste its content into the chat. Mention the design
in at most one plain sentence.
</method>
| Wrong | Right |
|---|---|
Docs search migration: hosted vendor → Postgres FTS | Docs search migration |
Q3 Report – churn, revenue and retention | Q3 churn report |
Dashboard | Support queue health |
Pass the name with --title. The doc's own # heading may say more.
--description, one sentence: the gallery shows it
under the title.# <Name>, then the recommendation or the decision asked for in the
first paragraph: what to do, by when, and what it costs in time or risk.- [ ]) the reader can tick in the doc.Write it for a reader who decides without asking you a question. Revise the same artifact as the plan changes: its history keeps every earlier version. </planning>
<types> | Type | For | The file | |---|---|---| | `doc` | specs, reports, memos, plans | a **Markdown** file (`report.md`). Kortix renders and styles it; people edit it in place and export it as PDF. | | `html` | decks, dashboards, mockups, tools | an **HTML** file, or a folder with `index.html` and its assets. Served exactly as written. |kortix artifacts types <type> prints the format rules and a starter.
doc: one # Title, then headings, paragraphs, bold, italic,
code, links, bulleted, numbered and task lists (- [ ]), quotes, code
blocks, tables, ```mermaid diagrams, images and videos (files in media/ next to
index.md, referenced relatively), ---. No HTML layout, CSS or scripts.
Need charts or layout? Make an html artifact.
html: a complete page, served exactly as written: write the <!doctype>,
the viewport meta and the <title> yourself. It runs sandboxed (no cookies;
storage may throw; no access to Kortix). Its images, data and scripts sit in
the same folder and load by relative path. Load libraries from a CDN at a
pinned version (Chart.js for charts, Reveal.js for decks). It must work from
400 px to a large screen and in light and dark. The full contract is in
references/design.md.
</types>
kortix artifacts publish report.md --title "Q3 churn report" # uploads to your Artifacts folder in Drive
kortix artifacts publish ./deck # a folder with index.html
kortix artifacts add /Company/Plans/roadmap # shares a folder already in Drive (index.md or index.html)
A .md file is a doc; anything else is html. The command prints the artifact
id, its path in Drive and its app link. Hand it over with show (the app link
as url) and one line on what it shows. Never paste the content into the chat.
A new artifact is private: the person who runs this session (and you) can
see it. Share it when the user asks. "Share it with the team", "something the
team can review" or "for everyone on the project" each mean
--visibility project; pass it on the first publish. Named people mean
--with. Only an explicit "public" or "anyone with the link" means public:
kortix artifacts share <id> --visibility project # every project member
kortix artifacts share <id> --with ada@example.com # chosen people (private)
kortix artifacts share <id> --visibility public # anyone with the link
Ask before public: a public link works without a login. Never publish
secrets, tokens or customer data.
</publish>
kortix artifacts pull <id> ./work # prints the entry_version
# edit ./work/<file>
kortix artifacts publish ./work/<file> --id <id> --base-version <entry_version>
--base-version refuses the save (exit 3, version_conflict) when someone
saved after you pulled, for example a person editing the doc: pull again,
merge, save. kortix artifacts versions <id> lists every save from the Drive
history; restore <id> <version-id> writes one back as a new save.
kortix artifacts rm <id> stops sharing; the files stay in Drive.
If the request also asks to share ("so the team can review it"), share the
artifact you saved: kortix artifacts share <id> --visibility project.
</update>
Add --json for machine-readable output. Permissions (a role's, and for an
agent its kortix_permissions in kortix.yaml):
| Permission | Lets you |
|---|---|
project.artifact.read | list, open, read versions and files |
project.artifact.write | publish, add, save, restore; rename and share your own |
project.artifact.manage | rename, share or stop sharing anyone's |
project.artifact.public | give an artifact a public link |
Saving also needs write access to the folder in Drive. A refused public link
answers 403 public_link_forbidden: share with the project instead and tell
the user.
</commands>
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review Slack access requests against Okta role and team information, then prepare narrowly scoped GitHub or AWS IAM permissions. Apply changes only after an eligible person's approval and record the grant, reasoning, approver, and timestamp.
Research companies and people before outreach or meetings. Combines business profiles, recent news, hiring signals, and key contacts into a sourced brief with talking points and suggested questions, adding relationship history when CRM data is connected.
Review daily Google Ads and Meta Ads results for budget pacing, declining performance, and unusual activity. Get prioritized findings with supporting numbers and concrete recommendations for a marketing team to assess and carry out.
Automate website tasks such as navigating pages, filling forms, clicking buttons, taking screenshots, and extracting data. The skill also supports web app testing, with specialized guides for Electron desktop apps, Slack, and cloud browsers.
Process emailed vendor invoices by extracting details, comparing them with purchase orders and invoice history, and recording duplicates, overcharges, or missing orders. Summarize results in Slack for human review; payment approval and execution remain with people.
Guide changes to Kortix billing code, admin controls, and pricing screens. Explain how plans, trials, enterprise contracts, and access exceptions should work, where pricing is defined, and which audited routes must handle account changes.