# Feature Implementation Audit

> Verify whether a claimed feature actually exists in a codebase by separating naming, component capabilities, integration, and runtime proof.

- Skill: `ichichuang/feature-implementation-audit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ichichuang/feature-implementation-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ichichuang/feature-implementation-audit/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: ichichuang (https://skillmd.com/u/ichichuang)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ichichuang/feature-implementation-audit

---


# Feature Implementation Audit

Use when a user asks whether a feature is "already implemented", "actually available", or "successfully shipped" and vague keyword search is not enough.

## Goal

Distinguish between:
1. **Named feature exists** — explicit module/page/command/API/docs match the claimed feature.
2. **Equivalent capabilities exist** — component parts are present, but not integrated into the claimed product.
3. **Runnable implementation exists** — there is a real entrypoint and runtime proof, not just source code.

## Procedure

### 1. Search for the exact claim first
Search the repo for the exact feature name and close English aliases.

Look in:
- source code
- docs
- frontend pages/routes
- CLI command registry
- API routes
- git branches / recent commits
- session history if the user implies prior work

If exact-name search returns nothing, do **not** stop. Move to capability decomposition.

### 2. Decompose the claimed feature into component capabilities
Break the feature into likely building blocks, e.g.:
- diagnosis / doctor
- update / upgrade
- dashboard / status
- analytics / insights
- config / env / logs / sessions

Search each component separately and map concrete files, commands, and routes.

### 3. Verify real entrypoints
For each suspected capability, confirm the actual user-facing entrypoint exists:
- CLI command definitions (`CommandDef`, parser registration, `cmd_*` handlers)
- frontend navigation and routes (`App.tsx`, page files)
- backend API routes (`@app.get`, `@app.post`, etc.)
- docs that describe the feature as shipped

Do not treat a helper module as a shipped feature until its entrypoint is found.

### 4. Check integration shape
Ask: are these components unified into one product surface?
Evidence of integration includes:
- a dedicated page/route/command for the claimed feature
- a dedicated API namespace
- docs naming it as a first-class feature
- workflow glue that links diagnosis → recommendation → execution → verification

If components exist but are spread across unrelated pages/commands, classify as **capabilities present, integration not proven**.

### 5. Perform runtime validation when feasible
If the feature is supposed to be runnable, validate it live:
- start the command/server
- hit a real endpoint
- confirm a response shape
- verify the process stays up

Runtime proof outweighs static claims.

### 6. Deliver a layered verdict
Use this structure:
- **Bottom line** — implemented / partially implemented / not implemented as claimed
- **What is definitely present** — commands, pages, APIs, docs, runtime proof
- **What is missing** — unified entrypoint, named surface, API namespace, workflow closure
- **Most accurate interpretation** — e.g. "the building blocks exist, but not the integrated feature"

## Recommended evidence checklist
- exact-name search result
- frontend page list / route table
- CLI command handler locations
- API route locations
- docs page title/description
- runtime smoke test result
- git history / branch hints as weak evidence only

## Pitfalls

1. **Do not equate related capabilities with the claimed feature.**
   `doctor + update + dashboard` does not automatically mean a shipped "upgrade cockpit".

2. **Do not rely on README positioning language.**
   Phrases like "self-improving agent" are product claims, not proof of a concrete feature surface.

3. **Do not stop at string search.**
   Teams often ship equivalent functionality under different names.

4. **Do not stop at code existence.**
   A real implementation should have an entrypoint, route, or runtime behavior.

5. **Treat git branches and commit subjects as supporting evidence only.**
   They show direction, not shipped reality.

## Output template

- Situation: what feature claim was audited
- Decision: implemented / partially implemented / not implemented as claimed
- Result:
  - exact-name evidence
  - concrete existing components
  - runtime verification
  - missing integration pieces
  - final interpretation