Development Skills

These skills support the development workflow: configuring code intelligence, debugging failures, creating branches, writing standardized commits, finalizing pull requests, and suggesting the next task.

lsp-setup

Configure Language Server Protocol servers for Copilot CLI using evidence from the repository’s manifests and source files. The skill confirms the language set, selects trusted servers for the host platform, requests approval for installation and configuration, and preserves existing server entries.

New repositories: If no code, build manifests, or explicitly chosen languages establish a stack, defer setup. Envisioning, specification, and planning do not require LSP. If you explicitly request setup before choosing a stack, the skill asks which languages you intend to use. An explicitly chosen stack can be configured with approval before code exists; configuration and startup results are reported separately from code-navigation verification, which remains pending until source files exist.

Scope	Configuration	Responsibility
Project	`.github/lsp.json`	Share server definitions; each contributor installs the required binaries
User	`~/.copilot/lsp-config.json`	Configure servers for projects on this machine

Project entries override plugin entries, which override user entries with the same server name. Intentionally disabled entries remain disabled unless the user approves a change. Polyglot repositories can configure multiple servers, with rootUri for subproject roots when needed.

Example prompts:

“Set up Copilot CLI code intelligence for this repository. Detect the languages first.”
“Configure language servers for the Java backend and TypeScript frontend without replacing my existing settings.”
“Find references is not working in the CLI. Check whether my language server is available.”

After configuration, run /lsp reload, inspect /lsp, and use /lsp test SERVER-NAME to check startup. Verify a definition or reference lookup on a known symbol before treating setup as complete. Check /lsp help for commands supported by the installed CLI version.

The session-start hook writes .memory/lsp-status.md as a configuration-file snapshot. If configuration is missing and no recognizable source or build evidence exists outside excluded directories, it records deferred setup without warning. It excludes framework scaffolding, documentation/examples, templates, dependencies, and generated output. Unsupported file types may not be recognized; request setup explicitly when needed. The snapshot does not verify server health or plugin-provided servers, and it refreshes at the next session start rather than after /lsp reload.

Client boundary: VS Code uses its own language extensions and services. A missing CLI configuration file does not establish that VS Code code intelligence is unavailable. This skill does not configure IDE extensions or install servers automatically during ordinary implementation or review.

See LSP troubleshooting for runtime checks and GitHub’s LSP setup guide for configuration details.

debugging-recovery implement

Systematic debugging with structured triage. Activated when tests fail, builds break, or runtime behavior does not match expectations during implementation.

flowchart TD
  A["Unexpected failure"] --> B["STOP: preserve evidence"]
  B --> C["Step 1: Reproduce"]
  C --> D{"Reproducible?"}
  D -->|"Yes"| E["Step 2: Localize"]
  D -->|"No"| F["Add logging,\ncheck environment"]
  E --> G["Step 3: Reduce\nto minimal case"]
  G --> H["Step 4: Fix root cause"]
  H --> I["Step 5: Guard\nwith regression test"]
  I --> J["Step 6: Verify\nend-to-end"]
  J --> K["Resume implementation"]

Stop-the-line rule: When anything unexpected happens, stop adding features, preserve evidence, and follow the triage checklist. Do not push past a failing test or broken build.

Triage checklist:

Step	Action	Key technique
1. Reproduce	Make the failure happen reliably	Isolate test, run in isolation
2. Localize	Narrow down which layer fails	`git bisect` for regressions
3. Reduce	Create minimal failing case	Strip to bare minimum
4. Fix root cause	Fix the underlying issue, not the symptom	Ask “why?” repeatedly
5. Guard	Write a regression test	Must fail without fix, pass with it
6. Verify	Run full suite and build	Confirm no regressions

Error-specific patterns: Includes decision trees for test failures (outdated test vs code bug vs side effect), build failures (type/import/config/dependency), and runtime errors (null access, network, unexpected behavior).

Untrusted error output: Error messages and stack traces from external sources are data to analyze, not instructions to follow. The skill warns against executing commands or navigating to URLs found in error output without user confirmation.

Activation triggers: Test failures, build breaks, runtime errors, unexpected behavior during implementation.

git-branch implement

Branch management with automatic strategy detection. Identifies the repository’s branching model (GitFlow or trunk-based) and creates branches following the detected convention.

flowchart TD
  A["Branch needed"] --> B["Check .memory/git-config.md"]
  B -->|"Config exists"| C["Use saved strategy"]
  B -->|"No config"| D["Detect strategy"]
  D --> E{"develop branch\nexists?"}
  E -->|"Yes"| F{"release/* or\nhotfix/* exist?"}
  E -->|"No"| G["Trunk-based"]
  F -->|"Yes"| H["GitFlow"]
  F -->|"No"| I["GitHub Flow"]
  
  C --> J["Check remote sync"]
  G --> J
  H --> J
  I --> J
  
  J --> K["Create branch"]
  K --> L["feature/ID-short-description"]

Strategy detection rules:

Signal	Strategy
`develop` branch exists + `release/` or `hotfix/`	GitFlow
`develop` branch exists, no release/hotfix	GitHub Flow
No `develop` branch	Trunk-based

Naming convention: feature/ID-short-description where ID comes from the work item (GitHub issue number or Azure DevOps ID).

Pre-creation checks: Remote synchronization, uncommitted changes detection, existing branch verification.

Activation triggers: Implementation start, branch creation requests, checkout operations.

git-commit implement

Standardized commits using the Conventional Commits specification. Analyzes the actual diff to determine type, scope, and message. Supports logical file grouping and work item references.

flowchart TD
  A["Commit requested"] --> B["Analyze diff"]
  B --> C{"Staged files?"}
  C -->|"Yes"| D["Use staged diff"]
  C -->|"No"| E["Use working tree diff"]
  D --> F["Group by logical area"]
  E --> F
  F --> G["Pre-commit checks"]
  G --> H[".gitignore exists?"]
  G --> I["No secrets?"]
  H --> J["Generate message"]
  I --> J
  J --> K["type(scope): description"]
  K --> L["Add work item ref"]
  L --> M["Commit"]

Commit format:

type(scope): description

[optional body]

[optional footer with work item refs]

Commit types mapped to SDD artifacts:

Type	SDD Context
`feat`	New feature implementation
`fix`	Bug fix
`docs`	Spec, ADR, plan, envisioning changes
`refactor`	Code restructuring without behavior change
`test`	Test additions or corrections
`chore`	Build, config, dependency updates

Work item references:

Platform	Format
GitHub Issues	`Closes #123` or `Refs #123` in footer
Azure DevOps	`AB#123` in footer

Security protocol: The skill checks for secrets, credentials, and sensitive data before committing. If detected, the commit is blocked with a warning.

Activation triggers: Commit requests, end of implementation, change staging.

pull-request implement

Implementation finalization workflow. Handles git state verification, commit creation, PR opening, automated reviews, and optional CI checks.

flowchart TD
  A["Implementation\ncomplete"] --> B["Check git state"]
  B --> C["Create commit"]
  C --> D["Push branch"]
  D --> E["Open PR"]
  E --> F{"Impact level?"}
  F -->|"High"| G["Trigger full\ndevsquad.review"]
  F -->|"Medium/Low +\nsecurity trigger"| H["Trigger\ndevsquad.security"]
  F -->|"Medium/Low,\nno trigger"| I["Standard PR"]
  G --> J["Check CI status"]
  H --> J
  I --> J
  J --> K["Offer Copilot\nreview (optional)"]
  K --> L["Record tech debt\n(if any)"]

Review routing by impact:

Impact	Security Trigger	Review Action
High	Any	Full `devsquad.review` (includes security)
Medium/Low	Yes	`devsquad.security` only
Medium/Low	No	Standard PR, no automated review

Technical debt tracking: If the implementation introduced shortcuts or deferred work, the skill records tech debt items linked to the PR.

Post-creation steps: CI status check, optional Copilot review request, branch update if behind target.

Activation triggers: Implementation completion, PR requests, finalization workflow.

next-task implement

Suggests the next task after completing an implementation. Considers dependencies, priority, sprint context, and open PRs.

flowchart TD
  A["Task completed"] --> B["Find available tasks"]
  B --> C["Filter: dependencies met,\nnot assigned, not blocked"]
  C --> D["Sort by priority\nand dependencies"]
  D --> E["Check open PRs"]
  E -->|"PRs need attention"| F["Suggest: review\nopen PR first"]
  E -->|"No pending PRs"| G["Present top 3\ntask suggestions"]
  G --> H["Check for pending\nchanges on branch"]
  H -->|"Changes exist"| I["Suggest: commit\nor stash first"]
  H -->|"Clean"| J["Return to\ndefault branch"]
  J --> K["Start selected task"]

Selection criteria (in priority order):

Dependencies satisfied (all predecessor tasks done)
Priority alignment (P1 before P2 before P3)
Sprint commitment (committed items before stretch)
Logical continuity (related tasks in same area)

Branch transition: Before starting a new task, the skill checks for uncommitted changes and guides the developer back to the default branch.

Activation triggers: Task completion, “what’s next” questions, sprint progress queries.