Skill: Process Improvement Proposal

Purpose

Produce structured, evidence-based proposals to improve the team’s workflow, skills, prompts, or agent responsibilities.

This skill exists to turn diagnosis into deliberate change, while preserving human oversight and system stability.

This skill does NOT apply changes.

Trigger

Use this skill whenever ANY of the following occur:

•metrics diagnosis identifies repeated or systemic issues
•failures recur across multiple features or phases
•workflow friction or ambiguity is consistently observed
•skills or prompts appear underspecified or misaligned
•the Lead is asked to recommend improvements to how the team works

This skill MUST be preceded by a metrics or diagnosis step.

Authoritative references

This skill treats the following as authoritative:

•docs/team/WORKFLOW.md → current workflow topology
•docs/team/METRICS_REVIEW.md → evidence and diagnoses
•docs/quality/BUG_LOG.md → quality signals and injected phases

Proposals must reference at least one of these sources.

Inputs

•one or more metrics review entries
•diagnosis hypotheses with confidence levels
•current workflow and skill definitions
•constraints or guidance from human stakeholders (if any)

Outputs

This skill MUST append a Process Improvement Proposal to:

•docs/team/PROCESS_PROPOSALS.md

Each proposal MUST include all sections listed below.

This skill MUST NOT modify any other files.

Proposal structure (mandatory)

Each proposal MUST follow this structure exactly:

Proposal metadata

•ID: PIP-YYYY-NNN
•Date:
•Proposed by: Lead / Integrator
•Status: proposed

Problem statement

A concise description of the systemic issue being addressed.

Must be phrased as a process or system problem, not a people problem.

Evidence

Concrete signals supporting the problem, including references to:

•metrics review entries
•bug log patterns
•workflow or handoff artifacts

Evidence must span multiple instances where possible.

Diagnosis

The suspected root cause(s), clearly separated from symptoms.

Each diagnosis MUST include a confidence level:

•high / medium / low

Proposed change

A clear description of the proposed change, limited to one or more of:

•workflow topology
•skill definition
•prompt clarification
•agent responsibility boundaries

The proposal MUST specify:

•what would change
•where the change would live
•what would remain unchanged

Expected impact

What improvement is expected if the change is adopted.

Examples:

•earlier defect detection
•reduced rework loops
•clearer ownership
•lower coordination friction

Risks and tradeoffs

Explicit downsides, costs, or risks introduced by the change.

If no risks are listed, the proposal is incomplete.

Rollout considerations

How the change could be introduced safely, such as:

•pilot on next N features
•documentation updates required
•metrics to monitor post-change

Decision request

One of:

•approve
•approve with modifications
•reject
•defer

This section explicitly hands control to a human.

Proposal rules (strict)

•Proposals MUST be incremental and reversible.
•Proposals MUST address system behavior, not individual behavior.
•Proposals MUST be justified by patterns, not anecdotes.
•Multiple unrelated changes MUST NOT be bundled into one proposal.
•If uncertainty is high, the proposal MUST recommend further observation instead.

Explicit non-responsibilities

This skill MUST NOT:

•apply or simulate the proposed change
•edit workflow, skills, prompts, or agent files
•override human decisions
•optimize for a single metric
•frame issues as agent or human failures

It produces recommendations only.

Interaction with other skills

This skill typically follows:

•metrics-reading-and-diagnosis

It may reference outputs from:

•workflow-enforcement
•handoff-coordination
•verification-gate
•bug-management
•bug-phase-classification

It does not replace any of them.

Failure handling

If a proposal cannot be adequately justified:

•Record the uncertainty explicitly
•Recommend additional observation or instrumentation
•Do NOT force a change proposal

No proposal is preferable to a weak proposal.

Acceptance criteria

This skill is successful when:

•proposals are clearly structured and evidence-backed
•human reviewers can make an informed decision
•changes are scoped, intentional, and reversible
•system learning is explicit and auditable
•workflow evolution remains controlled and transparent

Design principle

Process changes should be rare, justified, and deliberate.

If improvements feel frequent or reactive, this skill is being misused.