How do I install the Multi Tool Architecture Assessment skill?

Run npx skillmds@latest add vamseeachanta/multi-tool-architecture-assessment in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Multi Tool Architecture Assessment safe to use?

SkillMD's automated safety review verdict for this skill is PASS. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Multi Tool Architecture Assessment?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Multi Tool Architecture Assessment free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Multi Tool Architecture Assessment?

vamseeachanta (@vamseeachanta) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Multi Tool Architecture Assessment by vamseeachanta

Name: Multi Tool Architecture Assessment
Author: vamseeachanta

Multi Tool Architecture Assessment

Systematic comparison of competing tools/approaches before committing to a multi-account, multi-tool architecture. Uses parallel subagents for research, system-state audit, and data quality analysis. Produces a decision matrix with explicit trade-offs.

vamseeachanta Updated Sep 17, 2026

File contents

Multi-Tool Architecture Assessment

Pattern: When choosing between 3+ competing approaches for a feature area, DO NOT guess. Systematically assess all options with parallel research before committing.

When to Use

Choosing between multiple tools, libraries, or approaches
Need to support multiple accounts, tenants, or personas differently
Existing tools have partial coverage but no single winner
Decision will block dependent work for weeks

Step Pattern (Parallel 3-Agent)

Agent 1: External Research

Research all available tools/approaches on the open market.

goal: "Research [tool category] options. Check: 1) GitHub repos, 2) npm/PyPI packages, 
  3) Star counts and download stats. Compare: setup complexity, multi-account support, 
  feature completeness, auth methods. Provide a comparison table with recommendation."
toolsets: ["web", "terminal"]

Agent 2: System State Audit

Check what's installed/missing locally.

goal: "Check current state of [tool candidates] on this machine. Run: which commands, 
  check config dirs, check for tokens/credentials, check installed packages, verify skill 
  scripts exist and their dependencies. Report exact state."
toolsets: ["terminal", "file"]

Agent 3: Data Quality Analysis

Analyze the actual data the tools will operate on.

goal: "Analyze the input data files for [feature]. Check: row counts, data quality issues, 
  encoding, duplicates, missing fields, domain distribution. Recommend normalization steps."
toolsets: ["terminal", "file"]

Synthesis

Combine results into:

Decision matrix table (approach × criteria)
Primary + fallback selection with rationale
Execution plan with phases and dependencies
Concrete GitHub issues (one per phase/component)

Output Template

TOOL ASSESSMENT — WINNER: [primary] + [fallback]
================================================================

Evaluated N approaches:
| Approach | Multi | Setup | Auth | Feature X | Verdict |
| ... | ... | ... | ... | ... | ... |

CHOSEN (primary):  [name]
  - Reason 1
  - Reason 2

CHOSEN (fallback):  [name]
  - For [specific use case]

REJECTED:
  - [name]: reason
  - [name]: reason

KEY GAPS: [what no tool does natively]

EXECUTION PLAN — 3 PHASES
================================================================

 PHASE 1: Infrastructure (BLOCKING)
 PHASE 2: Data/Migration (PARALLEL)
 PHASE 3: Workflow/Feature (after 1+2)

AGENT ASSIGNMENT
================================================================

Pitfalls

Don't pick the most popular tool — pick the one matching constraints (multi-account, CLI-only, etc.)
Always pick a fallback (not everything needs to go through the "primary" tool)
Identify what NO tool does — those become custom scripts/parsers you need to write
If data is messy (80%+ uncategorized), plan normalization BEFORE workflows
External repos may be in separate git clones or submodules — commit changes from within each repo
Don't block all work on the hardest-to-set-up component — run parallel work on data/prep
For skills: write-back to both ~/.hermes/skills/ AND .Codex/skills/ in repo (per WRITE-BACK RULE)

---name: multi-tool-architecture-assessmentdescription: Systematic comparison of competing tools/approaches before committing to a multi-account, multi-tool architecture. Uses parallel subagents for research, system-state audit, and data quality analysis. Produces a decision matrix with explicit trade-offs.---# Multi-Tool Architecture AssessmentPattern: When choosing between 3+ competing approaches for a feature area, DO NOT guess. Systematically assess all options with parallel research before committing.## When to Use- Choosing between multiple tools, libraries, or approaches- Need to support multiple accounts, tenants, or personas differently- Existing tools have partial coverage but no single winner- Decision will block dependent work for weeks## Step Pattern (Parallel 3-Agent)### Agent 1: External ResearchResearch all available tools/approaches on the open market.```goal: "Research [tool category] options. Check: 1) GitHub repos, 2) npm/PyPI packages, 3) Star counts and download stats. Compare: setup complexity, multi-account support, feature completeness, auth methods. Provide a comparison table with recommendation."toolsets: ["web", "terminal"]```### Agent 2: System State AuditCheck what's installed/missing locally.```goal: "Check current state of [tool candidates] on this machine. Run: which commands, check config dirs, check for tokens/credentials, check installed packages, verify skill scripts exist and their dependencies. Report exact state."toolsets: ["terminal", "file"]```### Agent 3: Data Quality AnalysisAnalyze the actual data the tools will operate on.```goal: "Analyze the input data files for [feature]. Check: row counts, data quality issues, encoding, duplicates, missing fields, domain distribution. Recommend normalization steps."toolsets: ["terminal", "file"]```### SynthesisCombine results into:1. Decision matrix table (approach × criteria)2. Primary + fallback selection with rationale3. Execution plan with phases and dependencies4. Concrete GitHub issues (one per phase/component)## Output Template```TOOL ASSESSMENT — WINNER: [primary] + [fallback]================================================================Evaluated N approaches:| Approach | Multi | Setup | Auth | Feature X | Verdict || ... | ... | ... | ... | ... | ... |CHOSEN (primary): [name] - Reason 1 - Reason 2CHOSEN (fallback): [name] - For [specific use case]REJECTED: - [name]: reason - [name]: reasonKEY GAPS: [what no tool does natively]EXECUTION PLAN — 3 PHASES================================================================ PHASE 1: Infrastructure (BLOCKING) PHASE 2: Data/Migration (PARALLEL) PHASE 3: Workflow/Feature (after 1+2)AGENT ASSIGNMENT================================================================```## Pitfalls1. Don't pick the most popular tool — pick the one matching constraints (multi-account, CLI-only, etc.)2. Always pick a fallback (not everything needs to go through the "primary" tool)3. Identify what NO tool does — those become custom scripts/parsers you need to write4. If data is messy (80%+ uncategorized), plan normalization BEFORE workflows5. External repos may be in separate git clones or submodules — commit changes from within each repo6. Don't block all work on the hardest-to-set-up component — run parallel work on data/prep7. For skills: write-back to both ~/.hermes/skills/ AND .Codex/skills/ in repo (per WRITE-BACK RULE)

Frequently asked questions