一键在 Manus 中运行任何 Skill

intended-vs-implemented

星标4

分支1

更新时间2026年6月15日 15:38

Audit the gap between what the code is documented to do and what it actually does. Run before claiming any feature works, before a release, and whenever a doc/README/CLAUDE.md says a subsystem is "done". Turns "Presence ≠ completeness" into a repeatable check. Especially for marketplace sync, payment, invoice.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

yasinatesim

yasinatesim/sklent

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

intended-vs-implemented

An agent is optimistic by nature — it will say "this works". This skill forces proof. It makes the project's central rule — Presence ≠ completeness; verify, don't assume — a repeatable audit.

When to run

Before claiming any feature works.
Before a release.
Whenever a doc (README, CLAUDE.md, a comment) asserts a subsystem is "done".
Always for the reference-skeleton areas: marketplace/{hb,ty}, payment/iyzico, invoice.

Procedure

Collect the INTENDED behaviour. From the docs/spec/PR body/CLAUDE.md: what is this subsystem claimed to do? Write it as a short list of concrete capabilities.
Trace the IMPLEMENTED behaviour. Read the real code path end to end. For each claimed capability, find the line that delivers it — or note its absence. A stub, a TODO, an errors.New("not wired"), or a happy-path with no error handling counts as not implemented.
Run it, don't read it. Where possible, exercise the path: a unit test, go test, or the e2e/verify.mjs browser run. Trust the observed result, not the source's intent.
Produce the gap report. Three buckets:
- ✅ Implemented + verified (claim matched by code and a run/test).
- ⚠️ Implemented, unverified (code exists, no test/run proves it).
- ❌ Claimed, missing (doc says yes, code says no).
Reconcile the docs. Every ❌ and ⚠️ either gets fixed in code or downgraded in the docs. Never leave a doc claiming more than the code delivers.

Output

A short report: subsystem, each claim, its bucket, and the file:line evidence. CRITICAL gaps (payment/auth/invoice claiming more than they do) escalate to a hotfix.

同仓库更多 Skills

同仓库

braid-plan

yasinatesim/sklent

Generate a BRAID reasoning graph (Mermaid flowchart TD) for a complex multi-step task. Cache to .local-artifacts/braid/<task-slug>.mmd. Hand to the braid-solver agent for execution. Use before non-trivial features, multi-hypothesis debugging, architecture decisions.

2026-06-154

coverage-gate

yasinatesim/sklent

Run unit-test coverage for the changed surface and block if below threshold. Backend (Go) via go test -cover. Frontend (web) via vitest --coverage. Threshold 70% now, target 80%. Reports delta vs base branch.

2026-06-154

issue-create

yasinatesim/sklent

Create a GitHub issue with required milestone + labels + body template. Enforces the "no issue, no branch" rule. Returns the issue number for the branch name.

2026-06-154

playwright-snapshot

yasinatesim/sklent

Capture Playwright snapshots + screenshots for a list of URLs. Saves artifacts to .local-artifacts/screenshots/<branch>/. Lightweight helper invoked by wtf-ux-playwright or directly when verifying a specific surface.

2026-06-154

api-pentest

yasinatesim/sklent

Black-box pentest of the Go/Gin REST API. JWT handling, IDOR, rate limiting, payment-callback verification, business-logic abuse. Run before major releases.

2026-06-154

network-pentest

yasinatesim/sklent

Black-box pentest of the deployment surface. TLS config, security headers, exposed ports, DNS, container exposure. Run before major releases and after infra changes.

2026-06-154

name	intended-vs-implemented
description	Audit the gap between what the code is documented to do and what it actually does. Run before claiming any feature works, before a release, and whenever a doc/README/CLAUDE.md says a subsystem is "done". Turns "Presence ≠ completeness" into a repeatable check. Especially for marketplace sync, payment, invoice.

intended-vs-implemented

When to run

Before claiming any feature works.
Before a release.
Whenever a doc (README, CLAUDE.md, a comment) asserts a subsystem is "done".
Always for the reference-skeleton areas: marketplace/{hb,ty}, payment/iyzico, invoice.

Procedure

Collect the INTENDED behaviour. From the docs/spec/PR body/CLAUDE.md: what is this subsystem claimed to do? Write it as a short list of concrete capabilities.
Trace the IMPLEMENTED behaviour. Read the real code path end to end. For each claimed capability, find the line that delivers it — or note its absence. A stub, a TODO, an errors.New("not wired"), or a happy-path with no error handling counts as not implemented.
Run it, don't read it. Where possible, exercise the path: a unit test, go test, or the e2e/verify.mjs browser run. Trust the observed result, not the source's intent.
Produce the gap report. Three buckets:
- ✅ Implemented + verified (claim matched by code and a run/test).
- ⚠️ Implemented, unverified (code exists, no test/run proves it).
- ❌ Claimed, missing (doc says yes, code says no).
Reconcile the docs. Every ❌ and ⚠️ either gets fixed in code or downgraded in the docs. Never leave a doc claiming more than the code delivers.

Output

A short report: subsystem, each claim, its bucket, and the file:line evidence. CRITICAL gaps (payment/auth/invoice claiming more than they do) escalate to a hotfix.