Notre avis
Configure l'outil de gestion de projet pour le projet actuel en guidant la sélection, en appliquant les guides d'implémentation et en enregistrant la décision.
Points forts
- Idempotent : détecte la configuration existante et évite les doublons.
- Guide le développeur dans le choix de l'outil avec des recommandations.
- Applique automatiquement les guides d'implémentation pour les outils supportés.
- Enregistre la décision et met à jour les fichiers d'adoption.
Limites
- Seuls deux outils (GitHub Projects, Filesystem) disposent d'un guide d'implémentation.
- Pour tout autre outil, le processus s'arrête et nécessite une création manuelle de guide.
- Dépend de la structure de fichiers .pair/adoption et des guides existants.
Lorsque vous devez configurer un outil de gestion de projet pour la première fois ou le changer dans un projet utilisant le framework Pair.
Si l'outil souhaité n'est pas supporté par un guide d'implémentation ou si vous préférez une configuration manuelle sans enregistrement de décision.
Analyse de sécurité
SûrThe skill guides the developer through text-based configuration steps, file reads/writes, and calling a companion skill. No execution of external commands, no network access, no data exfiltration, and no obfuscated payloads. All file operations are contained within a project's .pair directory.
Aucun point d'attention détecté
Exemples
/pair-capability-setup-pm $tool=github/pair-capability-setup-pm/pair-capability-setup-pmname: pair-capability-setup-pm description: "Configures the project management tool by guiding selection from supported options, applying the implementation guide, updating way-of-working adoption, and recording the decision via /pair-capability-record-decision. Idempotent — detects existing configuration." version: 0.4.1 author: Foomakers
/pair-capability-setup-pm — PM Tool Configuration
Configure the project management tool for the current project. Guides the developer through tool selection, applies the implementation guide, updates adoption files, and records the decision.
Arguments
| Argument | Required | Description |
| -------- | -------- | ------------------------------------------------------------------------------------------- |
| $tool | No | PM tool to configure (e.g., github, filesystem). If omitted, presents selection options. |
Composed Skills
| Skill | Type | Required |
| ------------------ | ---------- | ----------------------------------------------------------- |
| /pair-capability-record-decision | Capability | Yes — records PM tool choice as ADL entry + adoption update |
Algorithm
Step 1: Detect Existing Configuration
-
Check: Read adoption/tech/way-of-working.md. Does it contain a PM tool configuration (e.g., "Github Projects is adopted" or "Filesystem is adopted" for project management)?
-
Skip (not configured): Proceed to Step 2.
-
Act (already configured): Present current configuration:
PM tool already configured: [tool name].
- Current setup: [summary of PM section from way-of-working.md]
Options:
- Keep current — no changes needed
- Reconfigure — switch to a different PM tool
- If Keep current → stop, output current state.
- If Reconfigure → proceed to Step 2.
-
Verify: Mode is
configureordone.
Step 2: Select PM Tool
-
Check: Is
$toolprovided and valid? -
Skip: If valid
$tool, proceed to Step 3 with that tool. -
Act: Present PM tool options using the selection framework:
Select a project management tool:
| Tool | Best For | Implementation Guide | |------|----------|---------------------| | GitHub Projects | Teams using GitHub, remote collaboration, any size | Available | | Filesystem | Small teams, offline work, high security | Available | | Other (Jira, Linear, Azure DevOps, etc.) | Enterprise, complex workflows | No implementation guide yet |
Which tool does your team use or want to adopt?
-
Act: If developer selects a tool without an implementation guide → HALT:
No implementation guide available for [tool name]. To add support:
- Create
guidelines/collaboration/project-management-tool/<tool>-implementation.md - Follow the structure of existing implementation guides
For now, you can manually configure
adoption/tech/way-of-working.md. - Create
-
Verify: Tool selected with available implementation guide.
Step 3: Apply Implementation Guide
-
Act: Read the implementation guide for the selected tool:
- GitHub: github-implementation.md
- Filesystem: filesystem-implementation.md
-
Act: Walk the developer through the setup steps from the implementation guide:
- For GitHub Projects: project creation, board configuration, label setup, automation rules, MCP integration
- For Filesystem: directory structure creation, status tracking files, workflow templates
-
Act: Gather project-specific details needed for configuration:
- Project/organization name
- Board columns and workflow methodology (Kanban, Scrum, etc.)
- Label taxonomy
- Automation preferences
-
Verify: PM tool is configured and accessible.
Step 4: Update Way-of-Working
- Check: Read current adoption/tech/way-of-working.md.
- Act: Add or update the PM tool section with:
- Tool name and version/tier
- Workflow methodology (Kanban, Scrum, etc.)
- Project identifier (e.g., GitHub org/project name, filesystem path)
- Access method (e.g., MCP, CLI, direct)
- Reference to implementation guide
- Verify: Way-of-working reflects current PM configuration.
Step 5: Record Decision
-
Act: Compose
/pair-capability-record-decisionwith:$type:non-architectural$topic:pm-tool-choice$summary: "[Tool] adopted for project management with [methodology] workflow"
-
Verify: ADL entry created at
adoption/decision-log/YYYY-MM-DD-pm-tool-choice.mdand adoption files updated.
Output Format
PM CONFIGURED:
├── Tool: [tool name]
├── Methodology: [Kanban | Scrum | etc.]
├── Project: [project identifier]
├── Access: [MCP | CLI | filesystem]
├── Adoption: [way-of-working.md updated]
├── Decision: [ADL entry path]
└── Status: [Configured | Already configured (unchanged) | Reconfigured]
Composition Interface
When composed by /pair-process-bootstrap:
- Input:
/pair-process-bootstrapreaches PM configuration phase and invokes/pair-capability-setup-pm(optionally with$toolif developer pre-selected). - Output: Returns tool name, configuration status, and ADL entry path.
/pair-process-bootstrapincludes the adoption and ADL changes in the next commit.
When invoked independently:
- Interactive: full Step 1-5 flow. Developer commits changes when satisfied.
Edge Cases
- PM tool already configured + reconfigure: Old configuration is replaced, not appended. The new ADL entry references the previous decision if one exists.
- No MCP connection for GitHub: Warn that GitHub Projects requires MCP or CLI access. Offer to configure the adoption file manually and validate connectivity later.
- Multiple PM tools: Not supported in a single project. One tool per project. If developer needs multiple, suggest primary + secondary pattern and document in way-of-working.
Graceful Degradation
- If way-of-working.md doesn't exist, create it with PM section as initial content. Warn: "Created way-of-working.md — this appears to be a new project."
- If implementation guide not found for selected tool, HALT with contribution instructions (Step 2.4).
- If
/pair-capability-record-decisionis not installed, warn and skip ADL recording: "Decision not recorded — /pair-capability-record-decision not installed. Please manually document the PM tool choice."
Notes
- Supported tools with implementation guides: GitHub Projects, Filesystem.
- The selection framework provides decision matrix and cost-benefit analysis for tool selection.
- This skill modifies:
adoption/tech/way-of-working.mdand creates an ADL entry via/pair-capability-record-decision. - PM tool configuration is a project-level decision — it applies to all team members and workflows.
Expert Next.js App Router
Developpement
Un skill qui transforme Claude en expert Next.js App Router.
Générateur de README
Developpement
Crée des README.md professionnels et complets pour vos projets.
Rédacteur de Documentation API
Developpement
Génère de la documentation API complète au format OpenAPI/Swagger.