wiki-policy-check
wiki-policy-check — Audit business-rule leaks in this repo
Convention this skill enforces: technical rules live in the project repo; business and product rules live in the central wiki. This skill audits all markdown in the current repo for content that crossed the line and reports what should migrate.
Project guardrails
If .wiki-guardrails.yml exists, treat it as the local policy source for wiki path, markdown allowlist, and sensitive paths. Do not infer a different allowlist from the skill. If it is missing, read CLAUDE.md/AGENTS.md and report that guardrails are missing.
Where the wiki lives
The path of "the central wiki" is project-specific. Before running, read the project's CLAUDE.md and/or AGENTS.md (and .agents/rules/ if present) to find:
- The wiki location (e.g.
wiki/as a subfolder,../knowledge-base/as a sibling, an external URL). - The project's own definition of what is a business rule — most projects spell this out in a "Business rules — policy" section. Respect the line they draw, especially nuances (e.g. a tax product might say "regulatory algorithm = technical, regulatory scope decision = product"; a public site might say "marketing copy = local, the rule it encodes = wiki").
If the project has no policy spelled out, fall back to the generic definition below and report that the policy is missing as part of the audit.
When to run
More from djalmajr/essential-skills
agile-proto
Create interactive UI prototypes with a CDN-only stack (z-proto + Tailwind v4 + shadcn-style components + Preact/htm + preact-iso), including faithful send-to-Figma captures when requested. Use when asked to "prototype", "create proto", "mockup screens", "interactive prototype", "send to Figma", or when exploring UI flows before implementation.
18agile-metrics
Consolidates objective metrics of a sprint. Use when you need quantitative data about deliveries, blockers, deviations, and velocity to feed retro, sprint review, or capacity decisions.
17agile-retro
Conducts retrospective with learnings and improvement actions. Use when a cycle, sprint, or delivery has ended and the team needs to reflect on what worked and what needs to change. Also absorbs post-implementation reflection aspects.
16agile-intake
Structures new and vague problems into clear intake documents. Use when the problem is not yet mature enough for the backlog, when someone brings an idea or need without defined scope, or when you need to decide what the next artifact in the flow should be.
16agile-roadmap
Maps multi-phase trajectories with dependencies into clear, sequenced roadmaps. Use when work has multiple phases that need sequencing, when decisions today affect future decisions, when stakeholders need to see the whole journey, or when external dependencies exist. Applicable regardless of total duration — a 4-week multi-phase initiative benefits as much as a quarterly roadmap.
16agile-epic
Structures large initiatives into a decomposed backlog with roadmap, dependencies, and verification. Generates an overview file plus individual story files with tasks. Use when work requires several coordinated stories, has dependencies between deliveries, or needs a roadmap.
16