Skill Detail

DDD Tactical Patterns

- Translating domain rules into code structures. - Designing aggregate boundaries and invariants. - Refactoring an anemic model into behavior-rich domain objects. - Defining repository contracts and domain event boundaries.

GitHub:sickn33/antigravity-awesome-skills ddd-tactical-patterns
version b663b4ba98b5
static analysis only
no human review yet
Trusted

Current public label

Trusted

No major problems were found in the current checks.

This label is currently coming from the automated scorecard.

Automated result

Trusted

1 low Final label: trusted.

Human review

No human review has been recorded yet.

The current public label is still relying on automation. A human has not weighed in yet.

What happened

Driftloom completed a static scan. It inspected the skill files, recorded findings, and generated a scorecard.

Runtime evidence

No sandbox runtime result has been recorded yet.

What did not happen

  • Driftloom did not run this skill in an isolated sandbox yet.
  • This label is not a guarantee that the skill is safe, bug-free, or appropriate for every environment.
  • A good score does not replace human judgment when a skill touches secrets, shell access, or external systems.

Source provenance

Source: Workspace import

Originally ingested from a local workspace copy.

Scorecard

Safety
100
Quality
94
Transparency
100
Operational
92
Maintenance
82

1 low Final label: trusted.

Severity mix: 1 low

What Driftloom checked

  • Read the skill files and metadata to understand what the skill claims to do.
  • Looked for shell commands and risky command patterns, even if none stood out strongly.
  • Looked for external URLs and network behavior.
  • Looked for secrets and credential handling clues.
  • Checked whether the skill structure and references looked internally consistent.

Findings

Documentation-only skill structure
structure.docs_only · quality
Low

The source looks almost entirely documentation-based, with no obvious code or config files to inspect. That does not make it bad, but it limits how much automation can meaningfully verify.

File: SKILL.md
Driftloom is following the boring, correct architecture: Django control plane first, isolated runner later. Miraculously, restraint survives.