Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions skills/canonical/gds-ci-performance-verify/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
name: gds-ci-performance-verify
description: Use this skill when the owner asks whether a CI or fleet change actually improved speed or reliability. Compare equivalent runs using end-to-end, queue, provisioning, setup, execution, and deploy timing plus failures and retries. Do not use it to tune, rerun, cancel, or deploy.
---

# Contract

Verify performance with comparable evidence rather than isolated job duration.

## Use when

- A change has before and after evidence that needs performance verification.

## Do not use when

- The request is implementation, current-health audit without baseline, or diagnosis of one run.

## Inputs

- Change identity, before and after windows, repositories, workflows, priorities, and success criteria.

## Preconditions

1. Define the user-visible interval and verify clocks, correlation, and cohort usability.

## Workflow

1. Define the user-visible interval, normally PR-ready to all required checks and deployment complete.
2. Select before/after cohorts matched by repository, workflow, event, change size, cache state, platform, and priority.
3. Decompose median, p90, and p95 latency into queue, provision, setup, execute, upload/deploy, and teardown stages.
4. Compare throughput, utilization, success, retry, infrastructure-failure, flaky-failure, and missing-telemetry rates.
5. Identify critical-path changes and resource contention; keep priority classes separate.
6. Reject conclusions with insufficient samples or incomparable cohorts and label them `NOT_PROVEN`.

## Output

Return cohort definition, metric table, confidence limits or evidence limits, regressions, improvements, reliability impact, and the next measurement needed.

## Stop conditions

Stop before rerunning work, changing configuration, or claiming causality from unmatched evidence.

## Verification

Recompute cohort membership and metrics from authoritative events and state sample and confidence limitations.

## References

Use current GitHub run events and correlated private fleet observability evidence.
4 changes: 4 additions & 0 deletions skills/canonical/gds-ci-performance-verify/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "CI Performance Verify"
short_description: "Verify CI speed with comparable evidence"
default_prompt: "Use $gds-ci-performance-verify to compare CI latency and reliability evidence."
50 changes: 50 additions & 0 deletions skills/canonical/gds-ci-workflows-design/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
name: gds-ci-workflows-design
description: Use this skill when the owner wants a complete reusable CI/CD design for a project or ecosystem. Define coverage, job boundaries, dependencies, inputs, permissions, runner portability, technology setup, telemetry, and failure behavior. Do not use it to edit workflows, deploy runners, or onboard consumers.
---

# Contract

Design reusable CI that is complete, fast, explainable, and portable.

## Use when

- The owner needs a new or revised reusable CI architecture before implementation.

## Do not use when

- The request is to edit workflows, operate the fleet, onboard a project, or measure performance.

## Inputs

- Ecosystems, validation and release obligations, platforms, security policy, and consumer constraints.

## Preconditions

1. Inventory authoritative manifests, lockfiles, release processes, and policy; mark missing facts `NOT_PROVEN`.

## Workflow

1. Inventory validation obligations from source, manifests, lockfiles, release process, security policy, and supported platforms.
2. Group obligations into small jobs with explicit inputs, outputs, permissions, timeouts, and artifacts.
3. Express the minimum dependency DAG that preserves correctness; parallelize all independent jobs.
4. Specify deterministic, lockfile-aware setup for each detected ecosystem and version source.
5. Keep portable behavior and synthetic examples public. Expose runner selection as a consumer input; keep private identities and priorities in estate configuration.
6. Define logs, summaries, correlation fields, failure artifacts, retry classification, cache behavior, and observability degradation behavior.
7. Define hosted/public and private-fleet acceptance fixtures plus compatibility and security tests.

## Output

Return the coverage matrix, DAG, reusable interfaces, runner contract, security model, telemetry contract, acceptance tests, and rollout order.

## Stop conditions

Stop before repository edits, workflow dispatch, ruleset changes, or invented technology requirements.

## Verification

Every obligation has a job, every dependency is necessary, and no private identity occurs in portable design.

## References

Use current public reusable workflow contracts and synthetic public fixtures.
4 changes: 4 additions & 0 deletions skills/canonical/gds-ci-workflows-design/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "CI Workflows Design"
short_description: "Design complete reusable CI behavior"
default_prompt: "Use $gds-ci-workflows-design to design complete reusable CI for a project."
54 changes: 54 additions & 0 deletions skills/canonical/gds-drakkars-audit-fleet/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
---
name: gds-drakkars-audit-fleet
description: Use this skill for a read-only audit of CI fleet health, queue latency, capacity, runner availability, tool compatibility, retries, logs, telemetry, or failure history. Correlate evidence across control plane, GitHub, runners, and observability. Do not use it to deploy, restart, cancel, rerun, resize, or edit configuration.
---

# Contract

Explain fleet health and bottlenecks from correlated, time-bounded evidence.

## Use when

- The owner needs fleet-wide capacity, queue, compatibility, log, or telemetry evidence.

## Do not use when

- The scope is one run, one workflow, or an explicitly requested mutation.

## Inputs

- Audit window, fleet context, priority or pool filters, and technology scope.

## Preconditions

1. Resolve GDS context and the private estate source without copying private facts into public artifacts.

## Workflow

1. Resolve GDS context and the private estate source without copying its facts into public outputs.
2. Establish the audit window and inventory expected pools, capacity, priority, and technologies.
3. Correlate GitHub queue/start/end events with scheduler, provider, host, runner, and telemetry records using stable run, job, intent, and instance identifiers.
4. Measure end-to-end latency, queue time, provisioning, setup, execution, teardown, utilization, failure, retry, and orphan rates by pool and priority.
5. Check support for every detected toolchain and package manager; classify unsupported-tool failures separately from project defects.
6. Check log completeness, redaction, retention, clock alignment, and missing correlation fields.
7. Separate confirmed faults, saturation, waste, and `NOT_PROVEN` gaps.

## Safety

Never expose private topology or tenant identifiers in a public artifact. Never treat a retry as proof that the cause disappeared.

## Output

Return prioritized findings, evidence, latency decomposition, compatibility gaps, capacity risks, and non-mutating remediation options.

## Stop conditions

Stop before restart, retry, cancellation, deployment, resize, or configuration write.

## Verification

Cross-check GitHub, runtime journals, provider inventory, hosts, and observability freshness; mark gaps `NOT_PROVEN`.

## References

Use current structured GDS, GitHub, provider, host, and observability evidence.
4 changes: 4 additions & 0 deletions skills/canonical/gds-drakkars-audit-fleet/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Drakkars Audit Fleet"
short_description: "Audit fleet health, capacity, and compatibility"
default_prompt: "Use $gds-drakkars-audit-fleet for a read-only evidence-backed fleet audit."
49 changes: 49 additions & 0 deletions skills/canonical/gds-drakkars-audit-workflow/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
name: gds-drakkars-audit-workflow
description: Use this skill for a read-only review of GitHub Actions coverage, dependencies, parallelism, runner selection, permissions, caching, reproducibility, observability, and latency. Check that public and private repositories use the correct runner authority. Do not use it to edit workflows or change GitHub settings.
---

# Contract

Audit one project's CI/CD behavior without reducing verification scope or mutating state.

## Use when

- One repository's workflows need a correctness, coverage, safety, or performance audit.

## Do not use when

- The owner asks to implement changes, audit fleet runtime, or trace only one run.

## Inputs

- Repository path, workflow scope, required checks, and supported release targets.

## Preconditions

1. Resolve repository visibility, instructions, and required-check authority.

## Workflow

1. Inventory workflows, triggers, required checks, reusable calls, matrices, environments, artifacts, caches, and deployment gates.
2. Map project languages, package managers, generated assets, security obligations, builds, tests, and release paths to actual jobs.
3. Verify public Linux jobs use GitHub-hosted resources and private Linux jobs use the declared private fleet; keep macOS and Windows hosted unless private capacity is explicitly declared.
4. Build the dependency graph and critical path. Find accidental serialization, duplicated setup, oversized matrices, unsafe cache keys, and missing cancellation semantics.
5. Verify least-privilege permissions, pinning, secret isolation, fork safety, timeouts, concurrency, retry ownership, logs, telemetry, and artifact retention.
6. Report missing coverage separately from speed opportunities.

## Output

Return coverage gaps, correctness risks, critical-path evidence, safe parallelization opportunities, and an ordered change plan.

## Stop conditions

Stop before editing YAML, changing rulesets, dispatching workflows, or changing runners.

## Verification

Prove each finding from workflow source, manifests, policy, and required-check state.

## References

Use current workflow source, repository manifests, public reusable contracts, and private estate policy.
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Drakkars Audit Workflow"
short_description: "Audit CI coverage, safety, and parallelism"
default_prompt: "Use $gds-drakkars-audit-workflow for a read-only workflow audit."
51 changes: 51 additions & 0 deletions skills/canonical/gds-drakkars-onboard-project/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
---
name: gds-drakkars-onboard-project
description: Use this skill only when the owner explicitly asks to connect one repository to Drakkars and the reusable CI system. Inventory its technologies, classify visibility, add the correct runner policy and complete checks, canary them, and record estate evidence. Do not use it for multi-repository migration or interrupting existing runs.
disable-model-invocation: true
---

# Contract

Onboard one project with complete CI coverage and no unsupported-tool surprises.

## Use when

- The owner explicitly approves end-to-end CI onboarding for one repository.

## Do not use when

- The repository only needs audit or optimization, or scope spans multiple consumers.

## Inputs

- Repository identity, visibility, required checks, release targets, and approved estate selector.

## Preconditions

1. Resolve every Git boundary and prove visibility before choosing runners or writing configuration.

## Workflow

1. Resolve repository identity, visibility, policy, required checks, and independent Git boundaries.
2. Detect languages, runtimes, package managers, lockfiles, services, containers, build tools, release targets, and architecture needs from source evidence.
3. Select public reusable workflow capabilities and keep private repository/priority/runner mappings in the estate overlay.
4. Add deterministic setup, validation, logs, telemetry, timeouts, fork safety, and artifacts for failures.
5. Validate workflow syntax and policy locally.
6. Roll out one non-destructive canary while existing labels and jobs remain available.
7. Promote only after required checks and telemetry are complete; journal the exact commits and runtime evidence.

## Stop conditions

Stop on missing credentials, unknown visibility, unsupported required technology, or a canary regression. Never terminate an existing run to make room.

## Output

Return inventory, runner mapping, coverage map, canary result, evidence locations, rollback path, and remaining gaps.

## Verification

Prove technology coverage, visibility-to-runner mapping, green canary, unchanged active jobs, and rollback evidence.

## References

Use source manifests and lockfiles, public reusable contracts, private estate policy, GitHub checks, and runtime telemetry.
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
interface:
display_name: "Drakkars Onboard Project"
short_description: "Connect one project to its correct CI runners"
default_prompt: "Use $gds-drakkars-onboard-project to onboard one approved project to Drakkars."
policy:
allow_implicit_invocation: false
57 changes: 57 additions & 0 deletions skills/canonical/gds-drakkars-optimize-workflow/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
name: gds-drakkars-optimize-workflow
description: Use this skill only when the owner explicitly asks to change a project's GitHub Actions for lower end-to-end latency while preserving or increasing coverage, stability, logs, and telemetry. Implement within one repository, verify locally, and prepare measured rollout evidence. Do not use it for fleet infrastructure changes or job cancellation.
disable-model-invocation: true
---

# Contract

Optimize the full PR-to-deploy critical path without weakening required checks.

## Use when

- The owner explicitly requests an approved workflow optimization in one repository.

## Do not use when

- The request is audit-only, fleet/provider work, multi-consumer rollout, or would reduce coverage.

## Inputs

- Repository, approved scope, required checks, supported technologies, and baseline evidence.

## Preconditions

- Resolve GDS context and inspect repository instructions.
- Record a comparable baseline or mark it `NOT_PROVEN`.
- Preserve unrelated work and existing required-check identities unless migration is planned.

## Workflow

1. Derive the job DAG and locate the measured critical path.
2. Parallelize independent work; keep true dependencies explicit with `needs`.
3. Move reusable behavior to the pinned public CI workflow module when portable.
4. Select runners by visibility: public Linux hosted; private Linux private fleet; macOS/Windows hosted unless estate policy says otherwise.
5. Make setup deterministic for every detected ecosystem, including lockfile-aware caches and supported package managers.
6. Add bounded timeouts, useful summaries, correlation data, artifacts on failure, and safe retry classification.
7. Run syntax, policy, security, and project validations before any external write.

## Invariants

Do not skip tests to gain speed. Do not cancel active jobs. Do not put private facts in public reusable workflows.

## Output

Return changed files, preserved coverage, validation results, expected latency effect, and remaining measurement gaps.

## Stop conditions

Stop on lost coverage, unknown check identity, unsupported technology, unsafe cache or secret behavior, or unrelated dirty-state overlap.

## Verification

Show obligation-to-job coverage, validators, workflow policy checks, and a measurable latency hypothesis.

## References

Use current repository instructions, public reusable workflow contracts, and private runner policy.
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
interface:
display_name: "Drakkars Optimize Workflow"
short_description: "Optimize CI latency without reducing coverage"
default_prompt: "Use $gds-drakkars-optimize-workflow to implement an approved workflow optimization."
policy:
allow_implicit_invocation: false
49 changes: 49 additions & 0 deletions skills/canonical/gds-drakkars-orient/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
name: gds-drakkars-orient
description: Use this skill when the owner asks where CI or Drakkars behavior is owned, which runner policy applies, or how public product code and private estate facts are separated. Resolve verified context without changing anything. Do not use it for a deep audit, optimization, rollout, or provider write.
---

# Contract

Resolve the current CI/fleet context and its authority boundaries without mutation.

## Use when

- The owner asks which CI or fleet authority, visibility rule, or Git boundary applies.

## Do not use when

- The request needs a deep audit, run trace, implementation, onboarding, or rollout.

## Inputs

- Repository path or stable identity and the owner's context question.

## Preconditions

1. Work from the relevant Git boundary and keep remote facts `NOT_PROVEN` until refreshed.

## Workflow

1. Run `gds context --json` at the relevant Git boundary.
2. Identify repository visibility, active profiles, module pins, and canonical owner.
3. Treat portable engines, reusable workflows, schemas, and generic skills as public product concerns.
4. Treat organizations, repository identities, priorities, hosts, networks, credentials, and runtime evidence as private estate concerns.
5. Mark unfetched provider or telemetry facts `NOT_PROVEN`.
6. Recommend the narrowest next skill and Git boundary.

## Stop conditions

Stop before edits, fetch-based conclusions, workflow dispatch, runner changes, or provider writes.

## Output

Return verified context, independent mutation boundaries, visibility constraints, evidence gaps, and the safe next workflow.

## Verification

Every stated fact names its verified source and public output contains no private topology or tenant detail.

## References

Use current structured `gds context --json` output and the active repository policy.
Loading