component-patterns
Per-component-type verification approaches. Use when generating verification scripts for different component types.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Per-component-type verification approaches. Use when generating verification scripts for different component types.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Validates Claude Code assets (skills, hooks, agents, commands, MCP servers, plugins) against official Anthropic standards. Fetches latest docs dynamically and produces structured validation reports.
Real output verification vs mock calls. Use when transforming T1-T4 violating tests to verify observable behavior.
Curated edge case test data for boundary testing, verification scripts, and test generation. Provides pre-curated reference data organized by data type with context-specific loading guidance.
Role-based brainstorming with dual modes: --scoped (sequential Task tool, 5 roles) and --exploratory (Agent Teams peer debate, 4 roles). Use for feasibility assessment and idea validation.
Structured multi-viewpoint research using 5 parallel Sonnet sub-agents. Use when deep research is needed on a complex topic before implementation planning.
Initialize Bulwark infrastructure in a project: language-aware Justfile (8 langs), bun + eval-framework toolchain, logs/ subdirectories, and optional hooks.
| name | component-patterns |
| description | Per-component-type verification approaches. Use when generating verification scripts for different component types. |
| user-invocable | false |
| allowed-tools | ["Read","Write"] |
| version | 1.0.0 |
| author | Ashay Kubal @ Qball Inc. |
Provide verification strategies for different component types. This skill defines how to test real behavior for CLIs, servers, parsers, processes, databases, and external APIs.
Load this skill when:
Analyze the code to determine component type based on these indicators:
| Indicators | Component Type | Pattern Reference |
|---|---|---|
Imports child_process, has spawn/exec/execSync | Process Spawner | references/pattern-process-spawner.md |
Imports http/https/express/fastify/koa, has listen() | HTTP Server | references/pattern-http-server.md |
Imports fs, reads/parses files, has parse functions | File Parser | references/pattern-file-parser.md |
Has CLI argument parsing (process.argv, yargs, commander, argparse) | CLI Command | references/pattern-cli-command.md |
Imports database driver (pg, mysql, mongoose, sqlite, prisma) | Database | references/pattern-database.md |
Makes outbound HTTP calls (fetch, axios, got, requests) | External API | references/pattern-external-api.md |
Each pattern reference contains:
| Pattern | File | Languages |
|---|---|---|
| CLI Command | references/pattern-cli-command.md | Bash, Node, Python |
| HTTP Server | references/pattern-http-server.md | Bash, Node (supertest), Python |
| File Parser | references/pattern-file-parser.md | Bash, Node, Python |
| Process Spawner | references/pattern-process-spawner.md | Bash, Node |
| Database | references/pattern-database.md | Node, Python, Bash (SQLite) |
| External API | references/pattern-external-api.md | Node (MSW), Python (responses) |
Analyze the target component code using the detection table above.
Read the appropriate pattern file from references/:
Read skills/component-patterns/references/pattern-{type}.md
Choose the template that matches the project language:
package.json present): Use Node/Jest templatepyproject.toml or setup.py present): Use Python/pytest templateReplace all {placeholder} values with component-specific information:
| Common Placeholders | Description |
|---|---|
{component_name} | Name of the component being tested |
{component_path} | Import path to the module |
{port} | Network port (for servers/processes) |
{expected_value} | Expected output to verify |
| Component Type | Verification Strategy | Key Assertion |
|---|---|---|
| CLI Command | Spawn, capture stdout/stderr | Exit code + output text |
| HTTP Server | Start, HTTP request, verify response | Status code + response body |
| File Parser | Create input, parse, check structure | Parsed fields + values |
| Process Spawner | Spawn, check port/pid, verify behavior | Process alive + responds |
| Database | Setup DB, execute ops, query state | Records exist/modified |
| External API | MSW intercept, real fetch, check result | Response data matches |
All patterns follow the same principle: verify observable output, not mock calls.
| Anti-Pattern | Real Pattern |
|---|---|
expect(spawn).toHaveBeenCalled() | expect(await checkPort(8080)).toBe(true) |
expect(fs.writeFile).toHaveBeenCalled() | expect(fs.existsSync(path)).toBe(true) |
expect(fetch).toHaveBeenCalledWith(url) | const resp = await fetch(url); expect(resp.status).toBe(200) |
expect(db.save).toHaveBeenCalled() | const found = await db.find(id); expect(found).toBeDefined() |
Write diagnostic output to logs/diagnostics/component-patterns-{YYYYMMDD-HHMMSS}.yaml:
skill: component-patterns
timestamp: {ISO-8601}
diagnostics:
component_type_detected: cli|http|file-parser|process|database|api
pattern_applied: "CLI Command Verification"
template_language: bash|node|python
files_analyzed: 1
completion_status: success