تشغيل أي مهارة في Manus بنقرة واحدة

intended-vs-implemented

النجوم٤

التفرعات١

آخر تحديث١٥ يونيو ٢٠٢٦ في ١٥:٣٨

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

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

محللو ضمان جودة البرمجيات والمختبرونمهن الحاسوب والرياضيات·SOC 15-1253

SKILL.md

readonly

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

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.

المزيد من هذا المستودع

نفس المستودع

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.