Pair capability assess ai
Skill foomakers/pair/.claude/skills/pair-capability-assess-ai
Evaluates and recommends AI development tools — coding assistants (Copilot, Claude Code, Cursor), agent frameworks, MCP integrations, models — when the choice is open. Output-only: emits a proposal + target for /pair-capability-record-decision to persist.From its SKILL.md
npx -y skills add foomakers/pair --skill pair-capability-assess-aiAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
8.5 KB, as published. Nobody here has run it
/pair-capability-assess-ai — AI Development Assessment
Evaluate and recommend AI development tools: AI assistants, MCP integrations, AI-specific SDKs, and models. Follows the resolution cascade. Output-only: produces a proposal (rendered AI-section content + target) plus a report — writes no files. Persistence is delegated to /pair-capability-record-decision.
Arguments
| Argument | Required | Description |
|---|---|---|
$choice | No | Override: skip assessment, use this AI tool directly (e.g. claude-code, cursor) |
Composed Skills
Output-only — composes no skill, writes no files; the caller persists via /pair-capability-record-decision (see Composition Interface).
Proposal Target
The rendered adoption content is destined for this section — the caller writes it via /pair-capability-record-decision:
- Target: adoption/tech/tech-stack.md — AI section only
- Ownership: AI section (shared file — /pair-capability-assess-stack owns core sections, /pair-capability-assess-testing owns testing section)
Algorithm
Step 1: Resolution Cascade
Read resolution cascade for the generic Path A/B/C mechanics (check → skip → act → verify).
- Path A delta: override argument is
$choice. On confirm, proceed to Step 3. - Path B delta: adoption check is adoption/tech/tech-stack.md — populated AI section. If a corresponding decision record is missing, report the gap (this skill still writes nothing; the caller persists a backfill via
/pair-capability-record-decision). - Path C delta: proceed to Step 2.
Step 2: Read Guidelines
- Act: Read AI development guidelines:
- AI Development README — maturity model, tool selection matrix, implementation strategies
- AI Tools — tool comparison and configuration
- MCP Integration — MCP protocol standards
- Act: Read project context:
- adoption/product/PRD.md — AI requirements, team size
- adoption/tech/tech-stack.md — existing stack (AI tools must integrate)
- Verify: Every file listed in 1-2 above has been read; any that's missing follows Graceful Degradation (ask the developer directly) instead of silently proceeding to Step 3.
Step 3: Evaluate Options
-
Act: Use the Tool Selection Decision Matrix from guidelines:
- Evaluate tools on: Code Generation, Context Awareness, Architecture Review, Team Integration, Security/Privacy.
- Consider: budget, team size, workflow integration, privacy requirements.
-
Act: Evaluate AI development areas:
- Primary AI assistant: IDE-integrated tool (Cursor, Copilot, Claude Code, etc.)
- Strategic AI: Architecture review, complex problem-solving tool
- MCP integration: If applicable, MCP servers and protocol adoption
- AI-specific libraries: SDKs, embedding tools, AI frameworks with versions
-
Act: Assess team's AI maturity level (from guidelines maturity model):
- Level 1: Basic AI Assistance
- Level 2: Integrated AI Workflows
- Level 3: Strategic AI Architecture
- Level 4: AI-Native Development
-
Act: Present recommendation:
AI Development Recommendation:
- Primary assistant: [tool] — [rationale]
- Strategic AI: [tool] — [rationale]
- MCP: [yes/no — details]
- AI maturity target: Level [N]
- Additional tools: [list with versions]
-
Verify: Developer approves.
Step 4: Render Adoption Proposal
- Act: Render the AI section content — the ready-to-write body for tech-stack.md:
- AI assistants with versions/tiers
- MCP integrations if applicable
- AI-specific SDKs and libraries with versions
- Scope strictly to the AI section so the caller's write preserves all other sections (core, testing)
- Verify: The rendered
contentand itstargetare ready to emit.
Step 5: Emit Proposal
- Act: Emit the proposal to the caller:
content: the rendered AI-section body from Step 4target: adoption/tech/tech-stack.md (AI section)decision-metadata:$type: non-architectural,$topic: ai-development-tools,$summary: "[Primary tool] adopted as AI development assistant with [maturity level] target"- plus the human-facing report (see Output Format)
- Verify: Proposal emitted — see record-decision invocation contract for the persistence contract (persistence is always the caller's responsibility, delegated to
/pair-capability-record-decision).
Output Format
Follows the Decision Shape.
ASSESSMENT COMPLETE (output-only — no files written):
├── Domain: AI Development
├── Path: [Argument Override | Adoption Exists | Full Assessment]
├── Decision: [primary tool + maturity level + additional tools]
├── Proposal: [content rendered for tech-stack.md AI section]
├── Target: adoption/tech/tech-stack.md (AI section)
├── Persist: [caller composes /record-decision(content, target) → ADL]
└── Status: [Proposal ready | Confirmed existing]
Composition Interface
See record-decision invocation contract for the generic tuple + Input/Output/Persistence shape.
When composed by /pair-process-bootstrap:
- Input:
/pair-process-bootstrapinvokes during Phase 2. - Persistence:
/pair-process-bootstrapcomposes/pair-capability-record-decisionto write the AI section and record the ADL.
When invoked independently: the human (or agent) persists the proposal by composing /pair-capability-record-decision, then commits.
Edge Cases
- tech-stack.md exists but no AI section: Render content that adds the AI section; the caller's write preserves all other content.
- Project doesn't use AI tools: Render a minimal section noting "AI development tools not adopted — [reason]" for the caller to persist.
- Multiple AI assistants: Document primary and secondary with roles (e.g. primary for coding, secondary for architecture review).
- MCP adoption requires infrastructure changes: Recommend composing /pair-capability-assess-infrastructure for infra implications.
Graceful Degradation
See graceful degradation (guideline missing → ask developer for AI tool preferences directly) and record-decision contract (persistence unavailable → proposal stands as a report) for the standard scenarios. No additional cases.
Notes
- AI tool decisions are non-architectural → the caller records them as an ADL. Exception: if MCP integration fundamentally changes system architecture, the caller uses ADR.
- Section ownership: this skill renders content ONLY for the AI section of tech-stack.md. The single adoption writer is
/pair-capability-record-decision. - Version tracking: every AI tool includes version or tier (e.g. "Claude Code", "GPT-4o", "Cursor Pro").
- Educational content (AI development principles, best practices, WHY) stays in guidelines.