Specialize Lagune from a source or topic you give it, distilling it into a new on-demand specialization the detect and verify phases load later. It writes a focused, language-agnostic, defense-only knowledge module, never an exploit.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
$ARGUMENTS
The User Input above decides how this command runs. Read it before proceeding.
You are giving Lagune a new specialty: a focused, language-agnostic security specialization the detect and verify phases load on demand, listed by the catalog and loaded directly with npx --yes lagune catalog <name>. You distill the user's source or topic into it. A specialization audits and explains a risk area, it never rewrites the user's code, and it never produces an attack input. The shape lives in template.md, next to this file, and the built-in specializations regex, javascript, and browser are worked examples to mirror, each read with npx --yes lagune catalog <name> from the project root.
The result is the specialization at .lagune/catalog/<name>.md and its one-line entry in the project's index, the catalog list in .lagune/configs.json, which the catalog merges with the built-ins. You write both, and both stay under version control with the rest of .lagune/. You never touch the user's source.
Take the User Input as the security source or topic to specialize in. It may be a pasted article or reference, or a short phrase such as "prototype pollution in our cache layer" or "GraphQL injection". If it is empty, ask the user what security concern the specialization should cover, then stop until they answer. Never invent a topic.
This command is defense only. If the topic asks for offensive tooling, a working exploit, an attack payload, or detection evasion, refuse and explain that a specialization audits and explains, it never produces an attack input. Dual-use content is acceptable only in a clearly defensive framing.
First settle the terrain: what the specialization covers, never the vulnerability. The terrain is what the knowledge is about, and the attacks are what it teaches you to defend, so when the topic names an attack, settle on the surface that attack targets. For example, the built-ins set the rule: the regex specialization covers ReDoS, yet its terrain is regex, not redos. This same terrain is the title in Step 5 and the tags in Step 6, so name it once here.
The name is that terrain as a safe filename: lowercase, replace every run of characters outside a-z 0-9 - with a single -, trim leading and trailing -, and collapse repeats. Derive it from the terrain you settled, never from the raw topic, so an attack topic never becomes the name. If the terrain is unclear, ask the user for a short name for it. This name is also the identity of its entry in .lagune/configs.json.
List what the project already uses by running the catalog from the project root:
npx --yes lagune catalog
Then run npx --yes lagune catalog <name>. It prints the specialization the project resolves under that name, its own first and then the built-in, or reports that no specialization has that name.
regex, or one you specialized before): this is a refine. Use what it printed as the base. Reconcile, never append: fold the new knowledge into the existing sections, keep what still holds, rewrite what changed, and preserve the file's shape. Never replace a built-in from scratch and never blindly clobber an earlier version.In plain language, work out what the specialization must check, what distinguishes a real finding from a false one, and what the safer shapes are. Ask the user only what you need to author it well. Keep everything readable by a non-developer.
Fill in template.md, next to this file:
# [SPECIALIZATION_DOMAIN] vulnerabilities title to the terrain you settled in Step 3.## Rules, and the detect/verify shape under ## How to act on the result verbatim.> - Source: ... quote and fill it with a short plain credit. If the input was just a topic, or has no attributable source, drop that line entirely. Never invent a source.## What to look for, add one ### block per risk class in scope, each in plain language: what the dangerous pattern is, why it matters, and how to make it safe (the Safer shape: line, or the bullet list / #### Common safer shapes variants the template's comments allow). Where a popular control is commonly mistaken for the fix, add the optional Does not close it: line, naming that decoy and why it leaves the risk open so it is never accepted as closing the finding. It may reference an existing deterministic hook only if one genuinely fits, never invent a new hook.On a refine, apply these to the existing file rather than a blank one. Write no frontmatter: the tags live in the index, not the .md.
Derive 2 to 4 tags by the same terrain principle as the name (Step 3): the terrain or ecosystem the specialization lives in, an abbreviation, its variation, the plain name, never the vulnerability itself. The built-ins set the shallow style: regex carries RegExp, Regular Expression; javascript carries JavaScript, Node.js, Deno, Bun; browser carries Browser, DOM, Navigator. Propose a flat list of candidate tags and let the user add and drop any freely, never a fixed set to pick one from. On a refine, start from the existing entry's tags and reconcile them the same way.
Ensure .lagune/catalog/ exists, then write .lagune/catalog/<name>.md with the authored or reconciled content. An existing name is reconciled from its current content first, so this never discards a built-in or an earlier version unseen. On a refine of a built-in, this file becomes the project's own version and shadows the built-in from then on.
Update .lagune/configs.json. If the file or its catalog list is absent, create it. Add the { "name": "<name>", "tags": [...] } entry to that list, or on a refine rewrite that one entry, preserving every other entry and every other field untouched.
Run the catalog again from the project root and confirm it lists the entry with the tags the user confirmed:
npx --yes lagune catalog
In plain language, tell the user the specialization's name, its tags, what it covers, and that the detect and verify phases now load it on demand (and they can load it directly with npx --yes lagune catalog <name>), mentioning it shadows any built-in of the same name on a refine. Suggest a commit message such as feat: specialize Lagune in <name>. Say it as a suggestion, not a mandate.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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/.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。