Author a new built-in Lagune specialization inside the Lagune source, not a project's own catalog. Use when adding or refining a security knowledge module that ships with Lagune, against the native layout (`catalog/*.md` plus the built-in index).
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
The published skill skills/lagune.specialize/SKILL.md writes into a project's own catalog: .lagune/catalog/<name>.md plus its entry in .lagune/configs.json. This repo is the Lagune source, where built-in specializations live in catalog/<name>.md and their index is a TypeScript array, not a runtime JSON file. A built-in is registered in code, published with the engine, and tested.
So you reuse the skill's authoring discipline (terrain, defense-only gate, template, tags, reconcile-never-append) but override every output path to the native layout, and you update the registration points the published skill never has to.
Read and follow skills/lagune.specialize/SKILL.md in full. Its authoring steps hold unchanged. The one thing that does not is where files are read and written, since the skill targets a project and you are in the source. Remap every path it names:
| Skill path (a project's own catalog) | Native path (use this instead) |
|---|---|
catalog <name> for regex, javascript, browser | every *.md already in catalog/ (list the directory, mirror the closest one) |
template.md, next to the skill | skills/lagune.specialize/template.md |
catalog (list what exists) | read catalog/ and BUILTIN_SPECIALIZATIONS in src/catalog/builtin.ts |
.lagune/catalog/<name>.md (the specialization file) | catalog/<name>.md |
.lagune/configs.json (index entry) | a BuiltinSpecialization in src/catalog/builtin.ts |
A hook reference inside the .md body uses the engine command, npx --yes lagune <hook>, with long flags only, because that body ships verbatim to the end user.
Every built-in belongs to at least one category, which is how a project brings it into its catalog with npx lagune add --categories <category>. Categories live in CATEGORIES in src/categories/categories.ts.
python under python, and so on).owasp.Category to CATEGORIES (key, label, description) and its icon. Ask the user before inventing one, do not force an unrelated module into owasp to avoid the question.A project's own index entry carries no categories, but the built-in index entry does. Set it.
A new built-in is not done when the .md exists. Touch each of these:
catalog/<name>.md (Step 1). The engine reads catalog/<name>.md by name, so the file resolves once it is on disk and indexed.BuiltinSpecialization { name, tags, categories } to src/catalog/builtin.ts. Without this row, catalog never lists it and catalog <name> cannot resolve it.Category to src/categories/categories.ts, but only when you introduced a new category.src/dashboard/shared/specialization-meta.ts, which the dashboard and the website share.BUILTIN_SPECIALIZATIONS (for example, no built-in repeats its name inside its own tags, every index row has a file and every file a row, every engine call carries the package version and long flags), so a new entry is exercised automatically. Update a hardcoded list only when your change alters it, such as the built-ins a category holds.npm test. It runs scripts/build.sh first, so the engine the e2e tests exercise is rebuilt automatically. All green before you call it done.website/docs/catalog.mdx, giving the built-in its categories and focus. The sync test fails until the row matches the index.README.md only when it enumerates built-ins..lagune/configs.json and .lagune/catalog/: these hold a project's own catalog. A built-in never writes there.[ ] catalog/<name>.md authored from skills/lagune.specialize/template.md (reconciled on a refine)
[ ] src/catalog/builtin.ts BuiltinSpecialization added { name, tags, categories }
[ ] src/categories/categories.ts only if a new category was introduced
[ ] src/dashboard/shared/specialization-meta.ts label, description, icon, prompt task
[ ] tests updated + npm test green
[ ] website/docs/catalog.mdx table row added
As Step 8 of the skill: state the name, tags, categories, what it covers, and that the phases load it on demand once shipped (a prompt loads it directly with the engine's catalog <name>). Note that a project's own specialization of the same name shadows it. Suggest a commit such as feat: add specialization in `<name>` defense, matching the wording the existing built-ins use, as a suggestion, not a mandate.
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.
Authoritative architecture reference for Lagune, covering repository layout, the three owners, the published skills, the catalog, the engine command and its fallback, and the tracking-map model. Use when a decision depends on repo shape.
The English summary is being prepared. Showing the original description.
Visual verification of a running page through Chrome's DevTools Protocol, capturing screenshots and measuring the rendered DOM. Use when a frontend change can only be confirmed once rendered, for layout, spacing, alignment, overflow, or theme tokens.
The English summary is being prepared. Showing the original description.
Authoritative reference for the Lagune dashboard, a live view of a project's .lagune/ chain with a locked-down local action surface. Use before changing anything under src/dashboard/ or src/types/dashboard/.
The English summary is being prepared. Showing the original description.
Authoritative engineering reference covering code conventions, comments, TypeScript type rules, testing, and commit messages. Use before writing or changing any source file, and when suggesting a commit message.
The English summary is being prepared. Showing the original description.
Do the work the prompt asks for, with security guarding the build as it happens. Loads the charter, matches the security knowledge the work touches, builds safe-by-default, then checks its own result against what it used.
The English summary is being prepared. Showing the original description.
Establish or update the project's security charter, the safe-by-default principles every later phase must respect. Reads the project's files to learn what it is and uses, weighs any description you give against them, and asks when something is unclear.
The English summary is being prepared. Showing the original description.