Skip to main content

Recommended Setup

A practical setup is to maintain one shared engineering-skills repository and mirror or reference it from each application. The project then adds local skills beside the application code.

This setup supports Predictive Development because Copilot receives both reusable engineering standards and the local product context needed to generate production-ready code.

Example files:

engineering-skills/
├── architecture/
├── react/
├── quality/
└── workflows/

project/
├── .skills/
│   ├── SKILLS.md
│   ├── engineering-skills/
│   ├── project/
│   ├── domains/
│   └── features/
└── src/

Short content:

# project/.skills/SKILLS.md

Use shared skills for architecture, React, quality, and workflows.
Use project skills for local domains and feature behavior.
When rules conflict, project skills override shared skills.

In this setup, .skills/SKILLS.md acts as the orchestrator. It tells the agent which shared skills and which project skills apply before implementation begins.

The orchestrator file reduces prompt variation. Instead of restating standards in every Copilot session, the project has one stable place that defines the expected workflow.

Example files:

# .skills/SKILLS.md

Use these organization skills:

- engineering-skills/architecture/atomic-bomb.md
- engineering-skills/react/page.md
- engineering-skills/quality/testing.md

Use these project skills:

- project/architecture.md
- domains/customer-management.md
- features/product-overview.md

Short content:

# domains/customer-management.md

The customer overview shows active customers by default.
Search matches customer name, email, and customer number.
Only managers can export customer data.

Mini exercise​

Apply Recommended Setup to a feature or workflow you know. In ten minutes:

  1. Describe the current approach in one sentence.
  2. Identify one ambiguity, coupling risk, or missing constraint.
  3. Write one concrete rule or artifact that would improve predictability.
  4. Define how a reviewer or automated check could validate the improvement.

Compare your result with a teammate and revise the rule if two people could interpret it differently.

Example​

For Recommended Setup, consider an accessibility-testing skill:

  • Current approach: The same guidance exists in user prompts, repository notes, and local agent configuration.
  • Risk: Teams cannot tell which version is authoritative.
  • Concrete rule: Store reusable accessibility policy at organization level, project exceptions in the repository, and runtime invocation details with the agent.
  • Validation: Trace one generated component to the exact policy, project rule, and runtime instruction it used.