Skip to main content

Long-Term Evolution

The mature model separates requirements, skills, tools, and code. Requirements describe what must happen, skills describe how the organization builds, MCP tools execute repeatable tasks, and the agent applies all of that to implementation.

This is the long-term shape of Predictive Development with Copilot: requirements define intent, skills define standards, tools perform repeatable checks, and Copilot helps produce code inside those boundaries.

Example files:

requirements/product-overview.md
.skills/domains/customer-management.md
.skills/engineering-skills/react/page.md
mcp/atomic-bomb-tool.json
src/features/product-overview/

Short content:

# requirements/product-overview.md

Show a searchable list of active products.
Display stock status and last updated date.
Allow users to open the product detail page.

This separation matters because skills evolve more slowly than application code. Over time, the skills repository becomes a reusable engineering asset that helps every new project start with the accumulated knowledge of previous projects.

That reuse is what makes code generation scalable. Copilot is no longer guessing from a single prompt; it is working from a maintained engineering system.

Example files:

engineering-skills/workflows/new-feature.md
engineering-skills/workflows/refactor-component.md
engineering-skills/workflows/review-generated-code.md

Short content:

# engineering-skills/workflows/new-feature.md

Start from a written requirement.
Select the relevant organization and project skills.
Generate one small part at a time, then validate with tests.

Mini exercise​

Apply Long-Term Evolution 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 Long-Term Evolution, 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.