pastiche-init — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pastiche-init (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Bootstrap pastiche in the user's repo. Refuses to touch an existing pastiche/ — the verb is init, not update.
Stay terse. Do detection silently — do not narrate what you're reading, why a file matched, or how pastiche works internally. The only things the user sees are: the one-line preflight path, the proposed config block, the confirm question, any direct question for ambiguous fields, and the close message. No reasoning, no per-field commentary, no explanation of FACT/KNOWLEDGE/WISDOM. The config block plus the printed status messages below are the entire surface.
git rev-parse --show-toplevel; on failure, fall back silently to cwd. Print: "Writing to `<repo-root>/pastiche/`."<repo-root>/pastiche/ contains any file, stop:pastiche/already exists. Run/pastiche-syncto refresh FACT,/pastiche-setupto continue curation, or deletepastiche/first to reinitialize.
Read <repo-root>/package.json and probe canonical locations. Classify against these priors; combine as needed.
`packages`: each entry needs a name plus exactly one of types/source_dir.
name: — the package's published/workspace name (the name field in its package.json, e.g. @org/web). For a source_dir-only setup with no package name, use a short logical label (e.g. ui). Required and non-empty — the extractor rejects entries without it.dist/index.d.ts → types: (monorepo / built lib).node_modules/<pkg>/dist/index.d.ts (or types/module in its package.json) → types: (Primer / MUI / Mantine / Chakra shape).components.json at repo root → source_dir: pointing at the configured alias dir (shadcn).`tokens`: check the obvious spots only — a global stylesheet referenced by the app entry, or a conventional path (src/styles/, app/globals.css, src/index.css). A quick match is enough:
@theme { ... } → Tailwind v4 theme file.:root { --... } → plain CSS vars.Do not exhaustively crawl the repo for token files. If the first obvious candidates don't make it clear, leave tokens empty in the draft and ask the user to name the file in the confirm step — don't keep hunting.
`typecheck_command`: check package.json scripts for typecheck / type-check / tsc. Detect package manager from lockfile (pnpm-lock.yaml → pnpm, yarn.lock → yarn, bun.lock → bun, else npm run). Compose accordingly.
`build_command`: check package.json scripts for build. Detect package manager from lockfile (same as above). Compose accordingly (e.g., npm run build).
Trust your judgment on non-standard workspace names or weird exports fields. But don't over-invest in any single field: if something is ambiguous — especially token paths — stop guessing and ask the user to identify it directly in the confirm step. A direct question beats an obsessive search for a recommendation.
Present the full proposed config in one block — platform: claude-code (hardcoded), then drafted packages (each with its name and types/source_dir), tokens, typecheck_command, build_command. Ask:
Looks right? Edit anything?
If the user requests edits, apply them to the current draft and re-display the updated config. Do not re-run detection. Loop until the user accepts.
If detection produced nothing usable, skip the draft and prompt:
I couldn't classify your setup. Paste your config or describe your stack.
Then draft from the response and confirm as above.
Once accepted, write:
<repo-root>/pastiche/config.yaml — read the template from this skill's sibling templates/config.yaml directory, mutate platform, packages, tokens, typecheck_command, build_command. Leave design_md_reference: null and setup_progress untouched (13 stubs).<repo-root>/pastiche/KNOWLEDGE.md — copy templates/KNOWLEDGE.md (sibling to this skill's directory) verbatim.<repo-root>/pastiche/WISDOM.md — copy templates/WISDOM.md (sibling to this skill's directory) verbatim.If the user left typecheck_command blank, write null and print:
typecheck_command left null — implementers will skip the typecheck step.If the user left build_command blank, write null and print:
build_command left null — the orchestrator will skip the final build check.Do not scan for DESIGN.md. Do not pre-fill design_md_reference. /pastiche-setup owns that surface.
Shell: extract-fact (cwd = <repo-root>). It is on PATH via the plugin's bin/ — do not search for it. Block on completion.
Extractor failed: <stderr>. Fix config or rebuild your DS, then run /pastiche-sync to retry FACT extraction. KNOWLEDGE/WISDOM templates and config are already in place.Do not delete pastiche/. The partial state is the recovery point for /pastiche-sync.
Extractor ran but found no atoms. Check yourpackages[].types/source_dirpaths. You can re-run extraction with/pastiche-sync.
Print exactly:
Pastiche initialized at <repo-root>/pastiche/.>
FACT.md extracted (<N>components,<M>tokens). KNOWLEDGE.md and WISDOM.md are stubs.
>
Next: run/pastiche-setupto curate KNOWLEDGE and seed[GENERAL]WISDOM rules — section-by-section, resumable across sessions.
Do not invoke another skill. Do not run lint.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.