ワンクリックで
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 職業分類に基づく
Configures Language Server Protocol integration for Claude Code projects. Use when setting up LSP servers, verifying post-restart initialization, or troubleshooting broken LSP configurations.
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.
Create structured implementation plans using a 4-role scrum team with optional Agent Teams peer debate
Generates Claude Code skills from requirements using adaptive interview, complexity classification, and iterative validation. Use when creating new skills, scaffolding skill structure, or generating skills with sub-agent orchestration.
Generates single-purpose Claude Code sub-agents for use via the Task tool. Use when creating dedicated sub-agents, scaffolding agent definitions, or generating agents with diagnostics and permissions setup.
| name | component-patterns |
| description | Per-component-type verification approaches. Use when generating verification scripts for different component types. |
| user-invocable | false |
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