Menu
Use when running a criteria-based review (health check, security audit, accessibility review, pen test, bug bash, spec compliance). Creates an Audit document with findings and presents them to the user for triage.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use when carrying out the work a delivery document describes -- the build loop -- against its task breakdown and acceptance criteria.
Use as the entry point for any work, including reported bugs, defects, and unexpected behaviour. Reads the configured DAG and the user's position, then dispatches the right verb -- advancing within the current document automatically but stopping at type boundaries.
Use when moving a document to its next status along the type's lifecycle DAG, maintaining links and checking gates at the transition.
Use when drafting a document of a configured type collaboratively -- AI proposes a draft body, the human edits, iterate -- up to the type's authorship ceiling.
Use when adding a new custom document type to a lazyspec project. Interviews the user to co-author the type's methodology -- intent, authorship, lifecycle, gates, relations -- then writes its enriched template and `[[types]]` config via the config-write CLI. One type per run.
Use when authoring a full document body of a configured type from context -- AI writes the complete body, then asks for review -- only permitted when the type's authorship ceiling is `generated`.
| name | create-audit |
| description | Use when running a criteria-based review (health check, security audit, accessibility review, pen test, bug bash, spec compliance). Creates an Audit document with findings and presents them to the user for triage. |
AUDITS DOCUMENT FINDINGS. THEY DON'T FIX THEM.
Present findings to the user. Let them decide what to act on.
Do NOT create iterations from findings. The audit produces a findings report that the user triages. Only after the user selects findings to act on should `/lazy` be used to author a delivery document for them, and that is a separate skill invocation. - Do NOT write document files directly. Use `lazyspec create` and `lazyspec link`. - Do NOT edit a document you haven't read. Always `lazyspec show --json` or `Read` first. - Do NOT create iterations from audit findings. Present findings to the user for triage. - Do NOT fix issues found during the audit. Document them only. Documents stored in GitHub Issues (store = "github-issues") are managed through the GitHub API. The `.lazyspec/cache/` directory contains read-only mirrors. - Never edit files under `.lazyspec/cache/`. Use `lazyspec update --body` to modify content. - Always use shorthand IDs (e.g. STORY-095) not cache file paths when referencing documents in `lazyspec link`, `lazyspec update`, `lazyspec show`, etc. - To set body content at creation: `lazyspec create --body "content"`. - To modify after creation: `lazyspec update <ID> --body "new content"`. </GITHUB-ISSUES-DOCUMENTS> Always run lazyspec help <subcommand> before using unfamiliar commands. Always pass--json. On failure, check --help before retrying.
Define scope and criteria -> Create audit doc -> Review codebase -> Document findings -> Validate -> Present to user
Present to user -> User triages findings -> Use /lazy skill: for selected findings
Present to user.shape: diamond
Use /lazy skill.shape: double_circle
lazyspec search "<topic>" --jsonlazyspec create audit "<title>" --author <name>lazyspec link <audit-path> related-to <target-path> for every document the audit references.lazyspec validate --json