intended-vs-implemented

Audits gaps between documented intent and actual code implementation.

Updated Aug 10, 2026
One-click install
npx skills add https://github.com/Choi-Keith/skill-arsenal-ultra --skill intended-vs-implemented-choi-keith
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: intended-vs-implemented
Source: https://github.com/Choi-Keith/skill-arsenal-ultra/tree/main/plugins/pm-skills/pm-ai-shipping/skills/intended-vs-implemented
Command: npx skills add https://github.com/Choi-Keith/skill-arsenal-ultra --skill intended-vs-implemented-choi-keith

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Generic scanners and linters check whether code is internally consistent, but they cannot tell whether the code does what it was intended to do. The highest-value security and correctness bugs live in the gap between documented intent (permissions, trust boundaries, data classification) and actual implementation, and this Skill provides a method to find them. ## Core Features & Use Cases - Intent-to-Code Auditing: Treats documentation files like permissions.md, architecture.md, and variables.md as claims to verify against real enforcement points in code. - Evidence-Based Findings: Requires every finding to cite the documented intent, the implementing code (file and line), the attacker and victim, and a concrete fix. - Materiality Classification: Filters out cosmetic deviations and keeps only inconsistencies that cross trust, cost, data, or tenant boundaries. - Use Case: When auditing an AI-built codebase, use this Skill to verify that an endpoint documented as "cron-only" or "admin-only" actually enforces that restriction server-side on every code path. ## Quick Start Audit this repository against its documentation folder and report every place where the code contradicts the documented permissions or trust boundaries.

Frequently Asked Questions about intended-vs-implemented

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit whether code matches its documentation?

Read the documentation as a set of claims about what should be true, then verify each claim against actual enforcement points in the code. Cite file and line numbers as evidence, and only report inconsistencies that cross trust, data, or tenant boundaries.

How to find security bugs that linters and scanners miss?

Compare documented intent against implementation, since linters only check internal code consistency. Bugs like unenforced permissions or public endpoints leaking private data live in the gap between what docs say and what code does.

What documentation is needed before auditing code intent?

You need recorded intent documents such as permissions.md, architecture.md, or variables.md that define access rules, trust boundaries, and data classification. If these are missing or stale, that absence is itself the first finding.

When is a documentation-code mismatch not worth reporting?

A mismatch is not material when crossing it only lets an operator affect their own data. Report only inconsistencies where the gap exposes data, funds, infrastructure, or other tenants to actors who should not reach them.

Does this replace traditional security code review?

No, it complements sink-level security and performance analysis by adding the intent axis those tools lack. It verifies documented rules are enforced but does not replace deeper vulnerability analysis of the code itself.