fuck-my-shit-mountain

Fuck My Shit Mountain — Skill Definition

Purpose

Guide AI to perform an evidence-based, professional code audit of a software project. Despite the irreverent name, the output must be冷静 (calm), professional, actionable, and free of emotional language.

Required Inputs Before Auditing

Before deep auditing, determine whether the user has already supplied all required inputs. Ask only for missing items, in one concise message, and wait for the answer before auditing. Do not re-ask items that are already explicit in the request. A lightweight inventory of file names and manifests is allowed before asking for mode selection.

Required inputs:

1. Audit modes — Accepted values: full, incremental, architecture, security, stability, performance, testing, maintainability, design, release, documentation, observability, configuration, data-integrity, privacy, accessibility, supply-chain, cost, ai-safety, fallback, testing-authenticity, type-safety, frontend-state, backend-api, dependency-weight, code-consistency, comment-coverage, concurrency.
   • If the user picks full, do all dimensions.
   • If the user picks incremental, audit only files changed since a specified commit or branch (requires scope parameter with git reference).
   • If the user picks multiple modes, merge the audit areas from each selected prompt. Use the most specific finding format rules.
   • If audit modes are missing, run scripts/project_inventory.py <project-root> --format json when available, then recommend a few user-facing audit choices in the user's language. Examples: full audit, security and privacy focused, frontend experience focused, release and operability focused. Translate these labels into the user's language; do not lead with raw internal mode tokens.
   • Let the user reply with a number or natural-language option. Map that answer back to the modes field from the inventory recommendation. Show raw mode tokens only when the user asks for exact modes or advanced options.
2. Report language — The language used in the final report, such as English or Chinese. The setup question and audit recommendations should use this language when it is explicit; otherwise use the user's conversation language. The programming language is inferred from the repository and is not a substitute for this answer.
3. Output format — Accepted values: md, html, json, both, stdout.
   • md — Save as audit-report-<project>-<date>.md.
   • html — Save as audit-report-<project>-<date>.html.
   • json — Save as audit-report-<project>-<date>.json using templates/audit-report.json schema.
   • both — Save both md and html files.
   • stdout — Print the report in the conversation only.
   • If md, html, json, or both is requested, write the file(s) after generating the report. For HTML output, read templates/audit-report.html, copy its exact CSS and HTML structure, include the sections and score items required for the selected modes, and replace the content with actual audit data. For JSON output, follow the exact schema in templates/audit-report.json. Do not use placeholder variables; generate complete, self-contained output.
4. Audit scope (optional) — Defines what parts of the codebase to audit:
   • Path patterns: src/auth/**, payments/, *.config.js
   • Semantic labels: authentication, payments, api, frontend, backend
   • Git references: main..HEAD, v1.2.0..HEAD (for incremental mode)
   • If not provided, audit the entire project (default).
   • If provided, focus audit on matching files/areas and note scope limits in the coverage matrix.