design-artifact-decomposition-verification
Skill0 starsChanged 2 months agoMITView on GitHub
Independently verify design artifact decomposition against a verified TDD. Enumerate implementation-significant proposed units independently, compare them with registry ownership, detect missing/implicit/semantically unrelated ownership, and block DD progression when ownership closure is incomplete.
In this repository33 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- adversarial-baseline-auditSkill
- architecture-drift-detectionSkill
- architecture-reconstruction-and-diagramsSkill
- artifact-detailed-designSkill
- baseline-source-of-truth-maintenanceSkill
- claim-verification-and-promotionSkill
- configuration-source-traceSkill
- contract-impact-test-designSkill
- current-state-tdd-synthesisSkill
- design-artifact-decompositionSkill
- detailed-design-verificationSkill
- full-reverse-engineeringSkill
- implementation-readiness-certificationSkill
- incident-root-cause-analysisSkill
- integration-selection-analysisSkill
- observability-traceability-analysisSkill
- patch-impact-reviewSkill
- persistence-schema-reverse-engineeringSkill
- post-readiness-adversarial-auditSkill
- regression-test-designSkill
- requirement-compliance-reviewSkill
- resolve-high-impact-unknownsSkill
- resume-reverse-engineeringSkill
- reverse-engineering-bootstrapSkill
- reverse-engineering-coverage-auditSkill
- run-engineering-workflowSkill
- runtime-binding-verificationSkill
- runtime-flow-analysisSkill
- technical-design-proposalSkill
- technical-design-verificationSkill
- wbs-generationSkill
- wbs-verificationSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Do not trust ARTIFACT_REGISTRY_READY merely because the decomposition stage emitted it.
- Distinctive: line 26
Create a fresh inventory without copying the registry's artifact list.
- Distinctive: line 42
Do not infer "all units covered" from the artifact count.
- Distinctive: line 76
If any threshold fails:
- Distinctive: line 80
If source/TDD evidence is insufficient to determine ownership:
- Distinctive: line 84
Only when all thresholds pass:
- Distinctive: line 90
Use the workflow-declared output path.
- Distinctive: line 91
Do not invent or reuse a legacy artifact path.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Design Artifact Decomposition Verification
Purpose
Generator != verifier.
Do not trust ARTIFACT_REGISTRY_READY merely because the decomposition stage emitted it.
Independently re-read:
- verified TDD
- TDD verification
- design artifact registry
- authoritative requirement / verified gap where needed
Then independently enumerate implementation-significant proposed units from the TDD.
1. Independent Proposed Unit Inventory
Create a fresh inventory without copying the registry's artifact list.
A unit is implementation-significant when it creates a distinct:
- class/interface/exception/data carrier/adapter/policy/config owner
- responsibility or contract
- failure behavior
- lifecycle/dependency boundary
- state/configuration ownership
- verification obligation
Create:
| Proposed Unit | Type | TDD Evidence | Why Implementation-Significant? |
Do not infer "all units covered" from the artifact count.
2. Registry Ownership Comparison
For every independently enumerated proposed unit, require exactly one registry ownership disposition:
DEDICATED_ARTIFACT:<ART-ID>
or
SUBORDINATE_TO:<ART-ID>Create:
| Proposed Unit | Registry Owner | Dedicated/Subordinate | Registry Responsibility | Explicitly Owned? | Semantic Match? | Verdict |
Rules:
- a JavaDoc mention, import, method signature,
throws,@see, dependency, or nearby prose is not ownership - an artifact cannot own a semantically unrelated unit merely because it references it
- self-referential labels such as
SUBORDINATE_TO:ART-005for the same ART-005 are invalid ownership semantics unless the registry clearly identifies a separate subordinate proposed unit - existing modified components are not "subordinate to themselves"; their artifact ownership type should describe the artifact itself, while subordinate proposed units must be separately named
3. Required Quantitative Gates
independent proposed-unit inventory completed = YES
proposed-unit ownership coverage = 100%
semantic owner match = 100%
unowned implementation-significant units = 0
implicitly-owned units = 0If any threshold fails:
ARTIFACT_DECOMPOSITION_VERIFICATION_FAILED
If source/TDD evidence is insufficient to determine ownership:
ARTIFACT_DECOMPOSITION_VERIFICATION_BLOCKED
Only when all thresholds pass:
ARTIFACT_DECOMPOSITION_VERIFIED
4. Output
Use the workflow-declared output path. Do not invent or reuse a legacy artifact path.
<!-- workflow-status-contract:start -->emitted_statuses:
- ARTIFACT_DECOMPOSITION_VERIFIED
- ARTIFACT_DECOMPOSITION_VERIFICATION_FAILED
- ARTIFACT_DECOMPOSITION_VERIFICATION_BLOCKED<!-- workflow-status-contract:end -->Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

