vibecodeagent 0.0.0-stage → 0.1.65

package/dist/resources/skills/builtin/kerja-agentik/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: kerja-agentik
+description: Use on every task from start to finish — the agentic working loop. Write code, then actually run and test it before claiming anything; debug to the root cause, not the symptom; and when information is missing or uncertain, verify with `WebSearch` or the codebase instead of inventing it.
+---
+
+# Working agentically
+
+Two disciplines separate an agent from an autocomplete: it **runs what it
+writes**, and it **checks what it claims**. Everything below is one of those two.
+
+## The loop: write → run → test → fix
+
+Code that has never executed is a draft, no matter how confident it reads.
+
+1. **Plan first when the task has more than one step.** Use `TodoWrite`, one
+   item per independently verifiable outcome — not "improve X" but "X passes
+   test Y". Mark items done only when verified, never when written.
+2. **Write the smallest piece that can be executed**, then execute it with
+   `Bash` — the real command, the real output. Building the whole feature
+   before the first run means the first error arrives with ten suspects.
+3. **Test it, and prove the test can fail.** Break the code on purpose and
+   watch the test go red, then restore it and watch green. A test that passes
+   on its first run has proven nothing — it may be asserting something that was
+   never in doubt. Every bug you fix gets a test: the receipt of the fix.
+4. **Test the contract, not the mechanism.** Assert what a caller can observe —
+   return values, thrown errors, files written. And pair every upper bound with
+   a lower one: `length < 10` passes when the length is zero.
+5. **Re-run the full relevant suite before saying done.** Your change passing
+   its own test while breaking a neighbour's is the most common last-minute lie.
+
+## When it fails: debug to the root, not the symptom
+
+A patch that makes the symptom disappear without explaining it moves the bug
+somewhere less visible.
+
+- Reproduce first — a command or input that fails **every time**. Without it
+  you cannot tell a fix from a coincidence. "Fails only sometimes" is itself a
+  clue: suspect ordering, caching, clocks, leftover state.
+- Narrow by halving, not by reading: simplest input? fails before or after this
+  line (log it, do not assume)? does the previous commit fail?
+- Ask "why" until the answer stops moving: crash → value is `undefined` → field
+  optional → caller never sets it → **two call sites disagree about the
+  shape**. That last one is the bug; fixing the crash alone leaves it alive.
+- Read the actual error message, all of it. The line you skimmed past usually
+  names the file and the reason.
+
+## Claims need evidence
+
+- "Done" means: this command was run, this was its exit code, these tests are
+  green — and you cite them. If you wrote code but did not run it, say exactly
+  that: "written, not yet run".
+- Report failures verbatim. A test that fails is a finding to show, not to
+  smooth over. Saying "everything works" when one thing does not costs more
+  trust than the failure itself.
+- Numbers beat adjectives: "startup 1.2s → 0.4s" can be re-checked; "much
+  faster" cannot.
+
+## When you do not know: look it up, do not make it up
+
+An invented API costs the user a debugging session and their trust. An honest
+lookup costs one tool call. Recognise the moment before the hallucination:
+
+- **About this codebase** — a function you have not opened, a config key you
+  half-remember: `Grep` and `Read` the actual files. Memory of a codebase is a
+  hypothesis; the file is the truth.
+- **About a library or API** — a method signature, an option name, behaviour
+  that differs between versions: check the version actually installed
+  (lockfile, `node_modules`) first, then `WebSearch` for that exact version
+  and `WebFetch` the documentation page. Quote what you found, with the URL.
+- **An unfamiliar error message** — `WebSearch` it verbatim, in quotes, before
+  theorising about it.
+- **Anything recent** — releases, deprecations, pricing, news, or anything
+  after your training data: `WebSearch`, always. Your memory of the current
+  state of the world is guaranteed stale.
+
+Never invent a function signature, config key, CLI flag, URL, or version
+number. Confidence is not a source.
+
+And when the search fails or the tool is unavailable: **say "I could not
+verify this"** and mark the assumption clearly. An answer with a named gap is
+useful; a guess dressed as an answer is a trap you set for the user.
+
+### Researching, not just looking up
+
+One query answers one fact. Anything carrying a "why", a version, a comparison,
+or a date needs a sweep — and a sweep is three or four queries in a single
+`WebSearch` call, not three calls and not one query.
+
+**Vary the angle, not the wording.** Rephrasing the same idea hits the same part
+of the index three times and buys nothing. Genuinely different angles: the exact
+error string in quotes; the official term the vendor uses; the words a frustrated
+user would type; the negative case ("X not working after Y"); the question dated
+("X 2026"). Send them together.
+
+**Cross-check before you commit.** One source is a claim; two independent sources
+are a fact. Prefer primary sources — the vendor's changelog, the RFC, the
+repository — over anyone summarising them. Results name the indexes that found
+them: a URL two independent indexes returned is a stronger signal than one. When
+results carry dates, the newest wins for anything that changes (versions, prices,
+APIs) and loses for anything that does not (concepts, history).
+
+**When sources contradict each other, say so.** Do not quietly pick the one you
+prefer. Name both, name their dates, and name the one you are acting on and why —
+usually the more recent, more official, or more specific. A contradiction you
+report is useful; one you hide becomes the user's bug.
+
+**Stop when the next query stops changing your answer.** Two sources agreeing is
+enough; a third confirming the same thing is a wasted call. Stop also when the
+sweep keeps returning the same few pages — the index has told you what it has,
+and the next step is `WebFetch` on the best of them, not another query.
+
+**Read the coverage line.** It says which indexes answered and which did not.
+Thin coverage means your search was narrow or an index was down — it is not
+evidence that the answer does not exist. Widen the angles or fetch a page
+directly. And if a search fails outright, that is a tooling failure, not a
+finding: fall back to the rule above and say you could not verify it. Never let a
+failed search turn into a confident guess.

package/dist/resources/skills/builtin/pdf-maker/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: pdf-maker
+description: Use when the user wants a PDF — a printable report, invoice, certificate, handout, or any document that must look identical on every device — or asks to export Markdown or HTML to PDF. Covers DokumenTulis's Chromium rendering, raw HTML with CSS for layout and page breaks, and checking PDFs with DokumenValidasi.
+---
+
+# PDF documents
+
+`DokumenTulis` renders PDFs with Chromium's full layout engine on A4 pages: real fonts, tables, code blocks and page breaks. Never try to produce a PDF with Write or a shell script — the result will not open.
+
+## The call
+
+```
+DokumenTulis { "path": "out/invoice-0042.pdf", "isi": "# Invoice 0042\n\n..." }
+```
+
+Relative paths resolve against the session's working directory.
+
+## Markdown or HTML?
+
+**Markdown** (the default) covers most documents: headings, paragraphs, bold, italic, links, bulleted and numbered lists, block quotes, tables and code blocks, styled by a clean built-in print stylesheet. Prefer it.
+
+**`"html": true`** when layout matters — invoices, certificates, letterheads, multi-column pages. You write a complete HTML document and control everything with CSS:
+
+- page size and margins: `@page { size: A4; margin: 18mm 16mm; }`
+- page breaks: `<div style="break-after: page"></div>`, and `break-inside: avoid` on table rows or cards that must not split
+- landscape pages: `@page { size: A4 landscape; }`
+- images: embed them as `data:` URIs; remote URLs are not guaranteed to load
+- fonts: use common system font stacks; web fonts are not guaranteed to load
+
+Scripts do not run to build the page — lay it out with HTML and CSS only.
+
+## Writing a good PDF
+
+1. Decide the page structure before writing: title block, sections, tables, totals.
+2. Keep tables narrow enough for a portrait page, or switch the page to landscape.
+3. Put totals and key figures where a printed page will show them, not after a page break.
+4. Write in the user's language.
+
+## After writing
+
+The result ends with a validation verdict, including the page count and how much text the pages contain:
+
+- `Validated: it opens cleanly (N page(s), M characters of text)` — done. The PDF is attached to your reply automatically.
+- A warning that pages have **no extractable text** means the content came out as images; search and copy-paste will not work. That is expected only for image-only documents.
+- `VALIDATION FAILED` — fix the input and write it again in the same turn.
+
+For a PDF made any other way, or one a user says is broken, run `DokumenValidasi` on it. It detects truncated files, missing headers, unparseable structure, password protection, and pages without a text layer.
+
+## Limits
+
+Filling in or editing an existing PDF is not supported: `Read` extracts its text, and a new PDF can be rebuilt from that text with `DokumenTulis`. Say this plainly rather than promising an in-place edit.

package/dist/resources/skills/builtin/tinjau-keamanan/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: tinjau-keamanan
+description: Use when reviewing unfamiliar or inherited code for security problems, checking a script before running it, or investigating something that looks suspicious. Runs SecurityScan, then judges its findings instead of repeating them — the scanner is deliberately noisy and proves nothing on its own.
+---
+
+# Reviewing code for security problems
+
+`SecurityScan` matches patterns against text. It does not run code, does not
+follow data flow, and cannot tell a deliberate use from an attack. Your job is
+the part it cannot do: deciding which matches mean something.
+
+## The order that matters
+
+1. **Scan first, read second.** Run `SecurityScan` on the directory in question
+   before opening files. It tells you where to look, which is faster than
+   reading in the order the file tree happens to be in.
+2. **Open every finding you report.** A finding is a line number and a pattern
+   name; it is not a conclusion. Read the surrounding code before you describe
+   it to the user.
+3. **Say what you did not check.** The scan skips `node_modules`, `.git`, and
+   build output, and stops at a file limit on large trees. If the report says it
+   stopped early, that is part of your answer.
+
+## Judging findings
+
+Most matches in ordinary code are benign. These are the questions that separate
+them:
+
+- **Where does the input come from?** `exec` on a hard-coded string is a build
+  script. `exec` on something that arrived over the network is a hole.
+- **Is the credential real?** A pattern that looks like a key in a test fixture
+  or an example file is not a leak. One in a committed `.env` is.
+- **Does it persist?** Code that writes to LaunchAgents, crontab, shell rc
+  files, or Registry Run keys survives a reboot. That deserves a sentence of its
+  own in your report, even when it looks intentional.
+- **Is it obfuscated?** Base64 blobs and long escape sequences in source that is
+  otherwise readable are worth explaining, not skipping.
+
+## What NEVER to say
+
+Never tell the user code is safe because the scan came back `safe`. It means no
+known pattern matched. Those are different sentences, and the difference is the
+entire value of this skill: a user who believes the first one stops looking.
+
+If you found nothing, say what you scanned, what you skipped, and that nothing
+matched — then say what a human should still look at by hand.
+
+## When NOT to use this
+
+- Auditing dependencies. That is `npm audit` and supply-chain tooling, not
+  pattern matching over minified files.
+- Code you wrote in this session. You already know what is in it; read the diff.
+- As a gate before shipping. It is a reading aid, not an approval.

package/dist/resources/skills/builtin/word-maker/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: word-maker
+description: Use when the user wants a Word document (.docx) — a report, letter, proposal, CV, meeting minutes, handout, or notes turned into a file they can open and edit in Word or Google Docs. Covers choosing DOCX over PDF, the Markdown DokumenTulis renders, tables and numbered lists, and checking the result.
+---
+
+# Word documents (.docx)
+
+A .docx is a ZIP package of XML parts. It cannot be produced by writing text into a file, and Write refuses to try. The only reliable path in VibeCode is `DokumenTulis`, which generates the package from Markdown and validates it after writing.
+
+## DOCX or PDF?
+
+- **DOCX** when the reader will *edit* it: drafts, templates, letters someone will sign, reports a team will comment on.
+- **PDF** when it must *look the same everywhere* or be printed: invoices, certificates, final handouts. Use the `pdf-maker` skill.
+- If the user did not say, ask once, or pick DOCX for drafts and PDF for finished deliverables and say which you chose.
+
+## The call
+
+```
+DokumenTulis { "path": "reports/q3-summary.docx", "isi": "# Q3 Summary\n\n..." }
+```
+
+Relative paths resolve against the session's working directory. Write the whole document in one call; there is no append mode.
+
+## What the Markdown becomes
+
+| Markdown | In Word |
+|---|---|
+| `#` to `######` | Heading 1-6 (they appear in Word's navigation pane) |
+| blank-line separated text | paragraphs |
+| `**bold**`, `*italic*`, `` `code` `` | bold, italic, Consolas runs |
+| `- item` / `1. item` | bulleted / numbered list; indent two spaces per level |
+| `> quote` | indented italic paragraph |
+| `| a | b |` tables | real Word tables, header row shaded and bold |
+| fenced code blocks | shaded Consolas lines |
+| `[text](url)` | "text (url)" |
+
+Not supported: images, headers and footers, page numbers, columns, tracked changes, custom fonts or colours. If the user needs those, say so plainly — or produce a PDF with `html: true`, where CSS controls the layout.
+
+## Writing a good document
+
+1. Outline first: title, 3-7 sections, and what each section must say.
+2. One `#` title, `##` sections, `###` sub-sections. Do not skip levels.
+3. Keep paragraphs short. Use numbered lists for steps and procedures, bullets for unordered points.
+4. Tables for comparisons and figures. Keep them to about six columns; wider tables wrap badly in portrait pages. Every row should have the same number of cells.
+5. Write in the user's language, including headings and table headers.
+
+## After writing
+
+The result line ends with a validation verdict:
+
+- `Validated: it opens cleanly (N paragraph(s), M table(s))` — done. The document is attached to your reply automatically, so the user can save it anywhere.
+- `VALIDATION FAILED` — the file is broken. Read the listed problems, fix the input, and write it again in the same turn. Never hand a failed file to the user.
+
+For a .docx created any other way (a Python script, a converter, a file the user sent that "won't open"), run `DokumenValidasi` on it, then hand it over with `Lampirkan`.
+
+## Editing an existing .docx
+
+`Read` extracts the text of a .docx; it does not give you the original XML. To change a document, rebuild it with `DokumenTulis` from the extracted content plus the edits, save it under a new name unless the user asked to overwrite, and tell the user that formatting the original had beyond the list above (fonts, images, headers) is not carried over.