{"id":83652,"plugin_id":"plugin_asdk_app_6ad963ac7c8c8191ad0f23cd3beb563f","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-06T00:15:54.810Z","digest":"8c684870a6ba080c47236ec1a961be198c5eb887c663a9bd9d6ac5fecda90ff1","against":null,"payload":{"description":"Audit an existing Fievel package for gaps, contradictory rules, source problems and evaluation coverage.","included_files":[],"name":"content-audit","skill_md_contents":"---\nname: content-audit\ndescription: Audit an existing Fievel package for gaps, contradictory rules, source problems and evaluation coverage.\n---\n\n# Content Audit\n\n## Using this skill from the Fievel plugin\n\nThis plugin carries Fievel's workflows and Python tools. The user's project is\nseparate from the installed plugin. Find the plugin root two directories above\nthis SKILL.md; its `runtime/` directory is the bundled resource root, called R below.\nResolve R from this skill's actual installed path, never a development checkout.\n\n- Prefer Fievel's MCP tools when they are available (names start with `fievel_`).\n  Local tools such as `fievel_init`, `fievel_validate`, `fievel_check` and\n  `fievel_view` work only inside the user's workspace and never overwrite files;\n  call `fievel_setup_status` first. Remote tools such as `fievel_validate_package`\n  and `fievel_check_responses` receive package content, store nothing, and return\n  results to save as new files; tell the user that content is sent to the Fievel\n  server for processing. Without tools, use the CLI as described below.\n- Read `R/AGENTS.md` for Fievel's conversation and workflow rules. References in\n  this skill and in AGENTS.md to AGENTS.md, docs/, knowledge/, templates/, examples/,\n  schemas/, scripts/ and .agents/skills/ are relative to R, not the user's working directory.\n- Keep the current working directory in the user's chosen workspace. Run the CLI\n  by its absolute path: `python \"R/scripts/fievel.py\" <command> <project> ...`.\n  Replace R with the resolved path. Resolve project and output paths in the user's\n  workspace. Run one simple command per step: the Python interpreter\n  with the CLI path and its arguments, without chained commands, shell variables\n  or PowerShell scripts. Read and list files with the host's file tools. Simple\n  commands keep the user's permission prompts clear and predictable. Never create\n  projects, install dependencies, or edit inside R or the plugin cache. Never copy Fievel AGENTS.md over a user's repository instructions.\n- Check Python 3.10+ and `python -c \"import jsonschema\"`. If missing, explain the\n  prerequisite. When setup is authorized, create a new `.fievel-venv` in the user's\n  workspace and install `R/requirements.txt` with its Python. Reuse a working\n  environment; do not overwrite an existing environment. Use that interpreter for\n  every CLI command. Do not install globally or claim the plugin bundles Python.\n- Follow existing workspace instructions. Explain that project files remain local,\n  but material read into the conversation is handled by the user's coding agent.\n- The repository-maintenance and adapter-sync instructions in R/AGENTS.md are for\n  Fievel development, not for modifying the installed plugin during a user session.\n- Other Fievel skills in this plugin: getting-started, content-system-builder,\n  source-discovery, ai-behavior-designer, evaluation-designer and content-audit.\n  Switch to the one that fits when the user's request changes.\n\nSave projects under the user's chosen folder (default `my-content-system/` in\ntheir workspace). The user approves content; validation does not. Do not run\nmodel evaluations unless the user authorized them.\n\n## Workflow\n\nRead AGENTS.md. Required input: selected project folder and audit scope. Run\n`python scripts/fievel.py validate <folder>` and `status` first. Uncovered draft\nrules are reported as work remaining; run validate with --require-coverage when\nassessing evaluation preparation, not ordinary early-stage draft integrity. Review source\nauthority/freshness, competing rules, approval status, missing context and ownership.\nCheck that scenarios cover actual tasks and failure situations, not just literal\nphrases. Compare result system_sha256 with current package before drawing conclusions.\n\nOutput: a new audit Markdown file separating observed issues, uncertainties and\nsuggested changes, with rule/source IDs and supporting evidence. Do not edit rules\nas part of a read-only audit. Prioritize findings by their effect on user tasks.\nIf validation fails, report exact errors and continue any possible read-only review.\nExample: unknown policy date -> freshness gap, not proof the policy is wrong.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}