Skip to content
skillsafebeta
← Report library
Purpose / Development

Codebase Design Skill Security Audit

What the author says it does (original text)

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

Independent security check

Security risks found

Files checked
4
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

Project architecture details are distributed to multiple sub-agents without a separate confirmation

Source references: 5
What we found

After showing an explanation, the workflow immediately starts at least three sub-agents and supplies each with file paths, coupling details, and domain vocabulary from CONTEXT.md. It specifies no data-minimization, sensitive-content exclusion, or separate approval step.

Why this matters

Private code structure, internal service relationships, or sensitive business terms from CONTEXT.md enter additional agent contexts, expanding the processing surface; parallel agents may also create unexpected compute usage.

When the user asks to explore interface alternatives, the workflow immediately launches at least three sub-agents after showing an explanation and supplies them with file paths, coupling details, dependency classifications, and CONTEXT.md domain vocabulary. It does not require renewed consent or sensitive-data filtering. If sub-agents have different processing or retention boundaries, this broadens exposure of architecture information. A user can pre-limit shareable files and fields and ask for explicit sub-agent data boundaries.

DESIGN-IT-TWICE.md:17In the instructionsOpen original file
Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
Show 4 other places
DESIGN-IT-TWICE.md:21In the instructionsOpen original file
Spawn 3+ sub-agents in parallel. Each must produce a **radically different** interface for the deepened module.Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
DESIGN-IT-TWICE.md:30In the instructionsOpen original file
Include both [SKILL.md](SKILL.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
DESIGN-IT-TWICE.md:3In the instructionsOpen original file
When the user wants to explore alternative interfaces for a chosen deepening candidate, use this parallel sub-agent pattern. Based on "Design It Twice" (Ousterhout): your first idea is unlikely to be the best.
DESIGN-IT-TWICE.md:19In the instructionsOpen original file
### 2. Spawn sub-agentsSpawn 3+ sub-agents in parallel. Each must produce a **radically different** interface for the deepened module.Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 1
Medium risk

The refactoring workflow instructs the agent to delete existing unit tests

Source references: 1
What we found

It categorically calls tests of shallow modules “waste” and directs their deletion without first proving that new interface tests cover the same edge cases, failure modes, and security regressions.

Why this matters

A refactor could permanently remove valuable regression coverage, allowing defects in internal behavior, permission checks, or exceptional paths to go undetected.

The workflow explicitly directs deletion of old shallow-module unit tests once interface-level tests exist, but it does not require checking whether boundary cases, failure modes, or security regressions covered by the old tests remain covered. If the new tests cover only ordinary observable outcomes, regression detection could be lost. A user can require a test-by-test coverage mapping and retention of old tests until equivalent coverage is demonstrated.

DEEPENING.md:32In the instructionsOpen original file
## Testing strategy: replace, don't layer- Old unit tests on shallow modules become waste once tests at the deepened module's interface exist; delete them.- Write new tests at the deepened module's interface. The **interface is the test surface**.- Tests assert on observable outcomes through the interface, not internal state.- Tests should survive internal refactors, since they describe behaviour, not implementation. If a test has to change when the implementation changes, it's testing past the interface.
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

7 instruction sections

This Skill provides architecture guidance centered on small interfaces with deep implementations, treating the interface as the shared surface for callers and tests.

View source
SKILL.md:8In the instructionsOpen original file
Design **deep modules**: a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface. Use this language and these principles wherever code is being designed or restructured. The aim is leverage for callers, locality for maintainers, and testability for everyone.
SKILL.md:64In the instructionsOpen original file
- **The deletion test.** Imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.- **The interface is the test surface.** Callers and tests cross the same seam. If you want to test *past* the interface, the module is probably the wrong shape.- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a seam unless something actually varies across it.

It selects test substitutes by dependency type: local stand-ins for local dependencies, in-memory adapters for owned remote services, and mock adapters for third-party services.

View source
DEEPENING.md:15In the instructionsOpen original file
Dependencies that have local test stand-ins (PGLite for Postgres, in-memory filesystem). Deepenable if the stand-in exists. The deepened module is tested with the stand-in running in the test suite. The seam is internal; no port at the module's external interface.
DEEPENING.md:19In the instructionsOpen original file
Your own services across a network boundary (microservices, internal APIs). Define a **port** (interface) at the seam. The deep module owns the logic; the transport is injected as an **adapter**. Tests use an in-memory adapter. Production uses an HTTP/gRPC/queue adapter.
DEEPENING.md:25In the instructionsOpen original file
Third-party services (Stripe, Twilio, etc.) you don't control. The deepened module takes the external dependency as an injected port; tests provide a mock adapter.

When the user explores alternative interfaces, the process immediately starts at least three parallel sub-agents and places file paths, coupling details, dependency classifications, and project-domain vocabulary into their briefs.

View source
DESIGN-IT-TWICE.md:17In the instructionsOpen original file
Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
DESIGN-IT-TWICE.md:21In the instructionsOpen original file
Spawn 3+ sub-agents in parallel. Each must produce a **radically different** interface for the deepened module.
DESIGN-IT-TWICE.md:23In the instructionsOpen original file
Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
DESIGN-IT-TWICE.md:30In the instructionsOpen original file
Include both [SKILL.md](SKILL.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
Start here · InstructionsSKILL.md
codebase-design
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 5
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records4 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • DEEPENING.mdFull text included
  • DESIGN-IT-TWICE.mdFull text included
  • agents/openai.yamlFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • DEEPENING.mdSupporting file
  • DESIGN-IT-TWICE.mdSupporting file
  • SKILL.mdInstructions
  • agents/openai.yamlSupporting file
Lines read
202
File checksum (to compare versions)
532a2bd69461d5248a919a3fff042f165864e18fd05c5706fee58520e8366ab2