documentation/research/ai-adoption/findings.md

Eldorado AI adoption — research handoff

Research only. Retrieved 4 October 2026 UTC. This document separates documented vendor capability, empirical evidence, and recommendations. Nothing here certifies an Eldorado rollout, installed client, enabled telemetry, staffing appointment, measured baseline, or realized productivity improvement. Sources and literal supporting passages are in sources.json; fetched text, retrieval outcomes and citation ledger are retained alongside it.

1. Local organizational baseline and scope

Read-only remote fetch and status inspection found a clean documentation checkout on main, with HEAD and origin/main both 14ba1aa1ef66c91525135f743d15c77e32db78d3. Inspected all three current Organization pages: structure.mdx, collaboration.mdx, sdlc.mdx, plus channel wiki /opt/data/wiki/channels/1555510466904727622.md. This is documentation evidence, not independent verification of actual personnel, systems, or deployed controls. No repository file was changed.

Preserve the existing structure:

• Product: Product Management and Product Design.
• Technology: Product Engineering, Platform & IT, Architecture & Security, Quality Engineering, Data & AI.
• Operations: Operations Squad; Marketing: Marketing Squad; Finance & Accounting: Finance & Accounting Squad; HR & Administration: People & Administration Squad.
• Existing leadership documentation locates AI enablement coordination with the AI Architect within Data & AI, alongside established engineering leadership. Do not invent a new AI department, standing committee, delivery team, or confirmed headcount.

The requested target is ONE logical SDLC coordinating agent, with people using local Copilot, Claude Code or Cline agents. Logical coordination does not require a single fragile process and does not transfer human accountability to a model. The recommendations below develop this target; they are not a description of present operations.

2. Principal conclusions

1. Standardize a portable skill content contract, not the fiction of one universal client policy. Agent Skills defines SKILL.md, metadata and resources; allowed-tools is experimental, and the discovery directory is not mandated by the format.[1][21]
2. Treat instructions as guidance. GitHub explicitly warns of nondeterministic instruction following, and Claude describes memory files as context rather than enforced configuration.[3][5] Recommended enforcement belongs in independently administered repository, CI, artifact and release controls.
3. Maintain client-specific adapters and an explicit supported version matrix. Current official docs disagree even about collision precedence: Claude enterprise > personal > project; Cline global skill > project skill; Cline rules use the opposite workspace-over-global rule.[4][8][9]
4. Assess skill selection, execution, artifact quality and business outcomes separately. Repeated trials and environment-state verification matter more than an agent reporting success.[11]
5. Measure a balanced portfolio of flow, quality, risk, cost and human experience. DORA now uses five delivery metrics; SPACE explicitly rejects a single productivity metric.[12][24] Adoption counts or accepted code are not causal productivity evidence.
6. Use comparative pilots, not an imported percentage ROI. Controlled studies have reported substantial speedups and slowdowns in different settings, and METR's newer study explains why selection and concurrent-agent timing make current effects difficult to estimate.[16][17][22]

3. Compatibility and enforcement matrix

Every capability below is documented upstream, not exercised in Eldorado. A supported client means a particular host, version, model configuration and OS combination that passes local conformance tests; a product brand alone is insufficient.

Dimension	GitHub Copilot	Claude Code	Cline
Skills and scope	Project .github/skills, .claude/skills, .agents/skills; personal ~/.copilot/skills, ~/.agents/skills. About page includes cloud agent, code review, CLI, app, VS Code and JetBrains agent mode.[2]	Common format plus invocation controls, subagents and dynamic context extensions. Native project/personal .claude/skills; enterprise and nested scopes also documented.[4]	Workspace .cline/skills, global ~/.cline/skills; explicit invocation and enabled-by-default toggles documented.[8]
Always-on instructions	Repository-wide .github/copilot-instructions.md, path-specific files and agent instructions have surface-dependent support. Do not apply the GitHub.com hierarchy to every IDE.[3]	CLAUDE.md and related discovered memory files are concatenated into context, not overriding configuration files.[5]	Workspace/global rules combine, with workspace taking precedence for conflicts; toggles may disable rules.[9]
Name collision / precedence	Inspected docs establish instruction precedence on GitHub.com, not a universal skill-name collision order. Test duplicate personal/project skills before approval.[3]	Enterprise skill over personal over project for same-name collisions; distinct from memory-file concatenation.[4][5]	Global skill over project skill, but workspace rules over global rules. Do not conflate them.[8][9]
Trust and execution	GitHub warns shared skills are not verified, may contain injection or malicious scripts, and shell preapproval can remove a protective confirmation.[26]	Trust/permission dialogs and sandbox capability exist, but approved shell access can exceed working directory; unattended sessions differ.[7]	User toggles do not establish an enterprise security boundary. Current hook landing page redirects to SDK plugin documentation, which describes executable plugins.[8][10][23]
Hooks and enforcement	No universal Copilot hook parity established by inspected sources. Do not promise a portable hook API or use absence of research as proof none exists.	PreToolUse supports blocking, but command/http/MCP timeout does NOT block automatically; plain exit 1 is generally nonblocking without valid decision JSON. Agent SDK callbacks differ.[6]	SDK documents lifecycle hooks and explicit fail_closed policy. This is not proof every IDE/CLI installation exposes identical configuration or failure semantics.[23]
Distribution	Repository content can travel with code. gh skill public preview documents installation, source provenance, @SHA and --pin; pinned skills are skipped in updates.[26]	Repository/managed deployment plus client-specific facilities. Use an external immutable bundle manifest; do not presume Copilot's installer or plugin semantics apply unchanged.[4]	Commit workspace skill directories for team sharing. SDK plugins can come from npm/git/file sources; these require separate software-supply-chain review.[8][23]
Telemetry	Usage API spans multiple surfaces, but rich IDE detail requires telemetry; server-side active-user recovery does not fill missing dimensional data.[19]	OTel supports configured usage/cost/tool export; detailed skill names/tool arguments require explicit collection settings. Version-specific behavior is substantial.[20]	SDK lifecycle hooks provide instrumentation building blocks, not proof of a ready-made comparable enterprise skill dashboard or retention contract.[23]
Portable guarantee	Readable common content only; neither skill selection nor correct execution follows from installation.[3][26]	Shared format does not standardize extension behavior or guarantee instruction adherence.[4][5]	Shared content and client behavior remain different; toggles and name shadowing affect what executes.[8][9]

Version pinning, updates, rollback and stale laptops — recommended operational contract

These are recommended design choices, not features claimed to exist universally:

• Maintain one reviewed registry with stable skill IDs, human owner/reviewer, purpose, risk tier, provenance/license, immutable source revision, artifact digest, dependencies, supported client/OS/version range, evaluation revision/results, approval record, last review date, deprecation state, migration guide and rollback digest. Keep client-specific invocation and tool configuration outside the portable core, generated and tested as adapters.
• Release a manifest mapping stable IDs to exact immutable content and adapter revisions. Pin full commit/digest, not a mutable branch or tag alone. GitHub's preview installer provides pin/provenance mechanisms, but private Gitea compatibility and availability on Eldorado laptops have not been established.[26] A controlled vendored bundle is the simpler cross-client recommendation until proven otherwise.
• Promotion: author branch → independent review → format/resource validation → script/dependency/security checks → per-client behavioral and adversarial evals → canary → approval → distribution. Never permit a proposed skill to approve itself or edit its own promotion checks without independent review.
• Updates: compare signed/verified manifest and content digest; show release notes; stage atomically; restart/reload affected sessions where required by the client. Test whether already-open sessions retain old instructions. Do not infer reload from files changing.
• Rollback: restore a previously approved manifest AND adapter/dependency versions, revoke the unsafe revision centrally, expire affected sessions, rerun a smoke test and read back effective version. Reverting a file does not undo commands already executed or leaked data.
• Offline laptop: a verified cached bundle can support permitted low-risk local drafting, provided required local model/tool dependencies actually work offline. Local files being present do not mean cloud-backed inference is offline-capable. No claim of native offline inference or guaranteed durable telemetry buffering is made for any client.
• Stale/unsupported bundle: show a visible warning and prevent high-risk centrally mediated actions; allow explicitly approved low-risk work only. Recommended grace periods are risk decisions to settle, not fabricated vendor defaults. On reconnect, revalidate revocation and support status before obtaining privileged credentials or submitting gated delivery actions.
• Laptop evidence is fallible and may be altered by its owner. CI should verify repository-delivered manifest/content and actual output, but cannot prove which private prompt or skill a laptop truly used. Treat client attestations as advisory unless an independently verified device/runtime trust mechanism exists. Central enforcement must still protect work with no attestation.
• Avoid conflicting names and broad user-directory installation; prefix governed IDs and detect shadowing. Keep an explicit exception route with owner, scope, justification, expiry and compensating checks. An exception must not quietly disable protected-release controls.

4. Conflicts, weak evidence and what not to conclude

Claim / conflict	Classification and resolution
“Project skills universally override user skills.”	Contradicted as a universal claim. Agent Skills implementation guide says this; current Claude and Cline product docs specify personal/global priority for skill collisions. Weight actual client documentation for that client, then verify behavior locally.[21][4][8]
“GitHub organization instructions enforce company policy everywhere.”	Unsupported. GitHub documents limited surfaces, personal/repository precedence, nondeterminism and head-branch review instructions. Use repository ownership and independently protected gates instead.[3]
“All clients support the same skills/hooks/telemetry.”	Unsupported. Standard content exists, but scope, extensions, hooks and instrumentation differ. Cline's hook page now points to SDK plugins; do not repeat historical hook file recipes without version testing.[1][10][23]
“Copilot supports JetBrains skills.”	About-skills page explicitly includes JetBrains; adding-skills overview currently omits it. This is documentation asymmetry, not sufficient evidence to declare unsupported. Verify the exact target host/version during adapter qualification.[2][26]
“Hook failure blocks dangerous work.”	Not generically true. Claude documents nonblocking timeout and exit-code cases; Cline SDK offers an explicit fail-closed setting. Test timeout, crash and malformed output separately.[6][23]
“AI makes developers 55.8% faster.”	Supported paraphrase only for Peng et al.'s controlled JavaScript HTTP-server task; abstract inspected. Not a software-organization forecast.[17]
“AI makes experienced developers 19% slower today.”	Misleading temporal/generalized claim. METR's early-2025 RCT involved 16 developers and 246 issues; the authors now label those results outdated as current capability evidence.[16]
“METR's newer results prove a universal speedup.”	Unsupported. Follow-up raw estimates suggest shorter task time, but intervals include no effect and authors warn participant/task selection and parallel-agent timing compromise the estimate.[22]
“Independent study proves a 21% Eldorado improvement.”	Unsupported. Paradis et al.'s abstract reports approximately 21% shorter task time for 96 Google engineers, with a large interval and explicit ecosystem/generalization caveats. Primary abstract, not full methods, inspected.[18]
“Agent says done / skill was loaded, therefore compliant.”	Unsupported. Outcome must be inspected in the environment; selection, reading, following, tool execution and outcome are separate observations.[11]

Research hygiene correction: the initial URL seed for arXiv 2410.12944 was mistakenly labelled as a Cui field-experiments source. The retrieved body is Paradis et al.'s Google RCT; sources.json records the correct identity. No Cui statistic is used. Likewise, ACM SPACE returned HTTP 403; an author-hosted Microsoft Research publication summary was retrieved instead. These are bounded acquisition limitations, not invented evidence.

5. Target coordination, authority and organization mapping

Recommended trust flow: people and approved work records → one logical SDLC coordinator → task-scoped local-agent work proposals → repository review → independently administered CI/artifact evidence → authorized human release decision → release service. The coordinator should maintain workflow state, dependencies, requested evidence, retries and escalation. It should not be sole author, evaluator and approver, nor hold unrestricted production credentials.

Use durable IDs, idempotent task transitions and bounded retry budgets so multiple coordinator replicas cannot publish twice. Keep a human takeover and deterministic queue/authorization path if inference is unavailable. Project-level context sharing must be deliberately scoped; shared coordination is not permission to mix secrets, HR records, customer disputes and source code.

Existing owner	Recommended accountability, without creating teams
Product Management	Choose outcome hypotheses and eligible work; accept product value and prioritize pilots rather than maximize AI usage.
Product Design	Validate usability/accessibility and customer research handling; review generated experience changes and design-task skills.
Product Engineering	Own code, practical skill authoring and local-agent use; review generated changes and remain responsible for maintainability.
Platform & IT	Own bundle delivery, device/client support, identity, workload isolation, central CI/release integration, telemetry transport and emergency revocation.
Architecture & Security	Own trust boundaries, data/permission risk classification, supply-chain approval requirements and security exceptions; review privileged skill proposals.
Quality Engineering	Own independent regression/adversarial suites, quality rubrics, gate evidence, failure sampling and evaluation reproducibility.
Data & AI	Coordinate the skills catalog and logical SDLC-agent evaluation with the documented AI Architect function; own statistical analysis and model/client experiment design.
Operations Squad	Supply sanitized service cases and operational acceptance; own human decisions on disputes, refunds, fraud and customer communications, not the coordinator.
Marketing Squad	Own brand/claim review, campaign approval and content rights; start with drafting/review skills rather than autonomous spending or publication.
Finance & Accounting Squad	Validate cost allocation and investment evidence; retain payout, accounting and financial approval segregation.
People & Administration Squad	Own training, onboarding, acceptable use and privacy-sensitive adoption feedback, with Platform & IT on access lifecycle; no individual developer ranking.

Department leaders retain business accountability. Staffing capacity, named approvers and deputies need human confirmation; the operating-model role description is not evidence that every position is filled. For synthesis, map recommendations to existing responsibilities rather than publish uncertain staffing as fact.

Threat and failure controls

NIST supplies a voluntary lifecycle governance framework and GenAI companion, not certification; the RMF core organizes work around govern, map, measure and manage.[13][14][25]

OWASP identifies external-content injection and recommends least privilege, human approval and adversarial testing.[15]

Recommended controls by failure mode:

• Malicious skill, script, dependency, MCP server or changed upstream tag: allowlisted source, immutable digest, independent review, license/provenance inventory, restricted network/runtime and no automatic arbitrary installs. A reviewed Markdown file does not make referenced executable code safe.
• Prompt injection from issues, repository instructions, web pages or tool results: treat as untrusted input; separate data from authority; limit credentials and egress; require independent authorization. GitHub code review's use of PR-head instructions is a concrete reason not to trust AI review as the sole gate.[3][15]
• Fabricated success, omitted tests, cherry-picked evidence or judge manipulation: verify actual artifact/CI state tied to exact commit and policy revision; keep evaluation checks outside candidate-controlled changes; sample human review.
• Overbroad local shell permissions: isolate process/OS identity, filesystem, network and secrets. A profile, skill folder or current directory is not containment. Claude's own docs distinguish permission prompts from sandbox controls.[7]
• Duplicate or looping agent work, runaway spend and unavailable coordinator: task idempotency, bounded retries/time/cost, lease expiry, human recovery and read-only/degraded mode. Never downgrade a release gate because the model or evidence service is unavailable.
• Model/client/context drift or stale session instructions: version-qualified adapters; requalification on material updates; compaction/long-session tests; version-aware incident analysis.
• Privacy leakage through telemetry or shared memory: minimal structured events, pseudonymous IDs, restricted retention and access; no raw prompts, secrets or source contents by default. Explicitly review the privacy cost before enabling detailed tool/skill-name export.[20]
• Kill switch: independently revoke mutation/release credentials and stop scheduling; disable affected revisions and preserve evidence. Sending “stop” to a model is not the security boundary.

6. Skill quality, evaluation and lifecycle recommendations

A useful skill must state when to use it, when not to use it, prerequisites, exact steps, expected artifacts, verification, failure handling and escalation. Keep the portable body small and reference bounded resources. The format specification supports progressive disclosure and recommends concise main files.[1]

Proposed evaluation layers:

1. Static contract: parse metadata; verify stable identity/owner/review date; validate links and resource paths; detect embedded secrets, prohibited dependencies, unsafe commands and unsupported client-only fields.
2. Selection tests: positive trigger tasks, near misses and negative tasks; report false activation and missed activation separately. A larger catalog should be tested for routing regressions, not presumed better.
3. Execution tests: run representative sanitized tasks in disposable environments with fixed starting repositories; verify real outputs, not self-reports. Include missing prerequisite, invalid input, tool timeout, denied permission, malformed evidence and interrupted session.
4. Safety tests: injected repository text, malicious referenced scripts, conflicting global/project skills, user toggle, unsupported version, expired/revoked bundle, offline network, context compaction and stale in-memory version.
5. Outcome grading: deterministic tests for mechanically checkable constraints; independent human review for product/design/maintainability; model judges only with explicit rubric and human calibration. Record disagreements and judge version.[11]
6. Comparison: same tasks and conditions for no-skill/current-approved/candidate versions; repeated trials, failure/abandonment retained; separate client/model/skill changes. Report sample size, variability, confidence and task mix, not only a mean pass percentage.[11]

Recommended promotion policy: all mandatory deterministic safety/authorization checks must pass; any observed critical unauthorized action blocks promotion pending investigation. This is a proposed policy, NOT proof of zero residual risk. Quantitative success-rate thresholds should be set after pilot variance and business impact are known, by risk tier; do not invent universally validated percentages. Privileged release/payment/customer-impact workflows need stronger review than read-only documentation assistance.

Lifecycle: proposed → experimental → approved → deprecated → retired, with quarantine available from every active state. Review triggered by incident, tool/model/client change, dependency change, usage feedback or scheduled owner review. Each approved skill needs an owner and backup, change history, support window, migration route and known-good rollback. Deprecation should warn, offer replacement and track consumers before retirement; urgent security revocation overrides convenience. Do not retain unowned skills merely because they remain popular.

Adoption should begin with training on how to inspect results, report failures and refuse unsafe requests. Build examples from actual team workflows; offer office hours and opt-in feedback; record why a skill was rejected. Measure whether people can perform and verify work, not whether they obey a target number of invocations. Avoid automatically promoting agent-written corrections into the governed catalog.

7. KPI instrumentation options and recommended choices

Practical source tiers

A. Start with authoritative repository/CI/deployment/incident events. These can measure delivery outcomes without observing every laptop prompt. No event feed has been inspected here; feasibility must be verified with the current hosting platforms and retention.

B. Add a governed catalog/version inventory and opt-in task-level skill/client declarations. This supplies adoption and support coverage, but declarations are not proof of execution or adherence.

C. Add client adapters where supported: Copilot usage APIs and Claude OTel may help; their fields, licensing, enabled state and missingness differ.[19][20] Cline SDK hooks are an instrumentation option requiring engineering and exact-version qualification, not a proven universal collector.[23]

D. Use short anonymous surveys, work sampling and pilot comparisons for cognitive load, confidence and rework not visible in logs. SPACE's multidimensional premise supports this combination; surveys alone cannot establish time saved.[24][16]

Candidate measurement contracts for synthesis

These are recommended options, not observed metrics or approved targets. All denominators must use a predeclared eligible population and reporting window; zero denominators produce “not available,” never zero performance.

Measure	Definition and useful source	Owner / interpretation / missingness
Validated task success	Independently accepted successful tasks / all eligible initiated tasks with matured observation window; count failed/abandoned tasks as nonsuccess and show still-open separately. Task ID + acceptance evidence, not agent message.	Quality Engineering; weekly pilot report. Show task type, sample size and unobserved outcomes separately; exclude cancelled-before-start work by stated rule, not post-hoc cherry-picking.
Skill selection precision / recall	Correct relevant activations / all activations; relevant tasks with activation / all relevant tasks, on a labeled evaluation set.	Data & AI with Quality Engineering; per candidate/client release. Not obtainable from skill-loaded logs without relevance labels.
Supported bundle coverage	Eligible active installations with verified supported revision / eligible active installations inventoried.	Platform & IT; weekly. Unknown/invisible laptops remain unknown and inventory coverage is separately reported; do not treat silence as compliant.
Useful adoption	Distinct eligible participants using an approved skill in an eligible workflow / eligible participants during window, plus qualitative usefulness.	Data & AI and People & Administration Squad; monthly aggregate. Separate declared, observed and inferred usage; suppress small cohorts and never rank people.
Change lead time	Commit-to-production elapsed time per deployed change; report distribution and population. Repository + deployment SHA association.	Platform & IT / Product Engineering; service-level trend. Missing SHA mapping is missing coverage, not instantaneous delivery. DORA definition, not PR-open-to-merge time.[12]
Deployment frequency	Production deployments / stated period, service-scoped.	Platform & IT; report with quality measures. Exclude retries/duplicate events; no incentive to split meaningless deployments.[12]
Change fail rate	Production deployments requiring immediate intervention / all production deployments.	Quality Engineering / Platform & IT; require incident/rollback linkage and intervention definition. Missing incident links limit confidence.[12]
Failed deployment recovery time	Recovery timestamp minus failed-deployment failure timestamp; distribution over relevant failed deployments.	Platform & IT; unresolved failures shown separately, never dropped as if recovered. Not all-incident MTTR.[12]
Deployment rework rate	Unplanned incident-driven production deployments / all production deployments.	Platform & IT; preserve planned/unplanned classification and incident link. DORA fifth metric, distinct from change fail rate.[12]
Escaped quality issues	Severity-stratified post-acceptance defects / accepted changes with completed follow-up, plus absolute incident counts.	Quality Engineering; agreed maturation window. Do not compare immature and mature cohorts or imply every defect was AI-caused.
Safety / policy violations	Confirmed prohibited actions or attempted bypasses / evaluated eligible runs, with severe incidents also as absolute counts.	Architecture & Security; immediate incident response and periodic trend. Separate detected attempts, blocked attempts and actual effects; zero observed is not proof of no risk.
Cost per accepted outcome	Allocated license + model/tool/compute + human review/rework costs / independently accepted outcomes; include costs of failed/abandoned attempts in numerator.	Finance & Accounting Squad; monthly. Show uncertain allocation and missing spend; do not call model tokens the whole cost.
Human experience	Aggregate survey distribution for cognitive load, confidence in verification and perceived usefulness, with response count / invited eligible population.	People & Administration Squad / Data & AI; periodic. Self-selection and perception bias explicit; no employee surveillance dashboard.
Maintenance health	Approved skills within review window / active approved skills; separately count ownerless, deprecated-in-use and revoked-in-use revisions.	Data & AI / Platform & IT; catalog release and periodic review. Review stamp alone is not quality evidence.

Recommended minimal event schema: event_id, schema_version, event_type, occurred_at, received_at, producer, task_id, attempt_id, project_id, pseudonymous_actor_id where necessary, client/host/version, model_id/version_if_exposed, skill_id/revision/digest, adapter_revision, policy_revision, repo_commit, outcome, reason_code, evidence_ref, cost_amount/currency/basis, measurement_origin (server/client/self-report), and consent_or_collection_basis. Fields can be nullable with reason; do not fabricate a model revision hidden by a provider.

Recommended ingestion rules: deduplicate by producer + event_id; model retries as attempts, not extra completed tasks; preserve late events and recompute versioned aggregates; use server receipt and skew checks rather than trusting laptop clocks blindly. A lost terminal event is unknown until reconciled, not automatically success or abandonment. Distinguish paused, failed, abandoned, cancelled-before-start and accepted. A skill-loaded event records loading only. A task can involve multiple skills/versions and agents; avoid attributing the entire outcome or labor time to every invocation.

Suggested privacy starting point for human approval: short raw structured-event retention (for example 30 days), longer aggregate trends (for example 12 months), no raw prompts/code/screens by default, role-limited incident evidence, and explicit deletion/access process. These durations are policy proposals, not legal requirements or existing Eldorado settings. Confirm employment/privacy constraints with responsible owners before collection.

Pilot comparison recommendation: define task classes and quality acceptance first; collect a prospective baseline and eligible population; compare matched or randomized cohorts when ethical/practical; record concurrent process/client/model changes. Keep quality and risk guardrails fixed. Report descriptive trends separately from causal estimates. Measure elapsed lead time and human effort separately because parallel agents break the assumption that elapsed time equals labor saved; METR's follow-up explicitly raises this issue.[22]

For executable downstream examples, use clearly synthetic fixtures covering duplicates, retries, unknown outcomes, multiple skills, zero denominator, immature quality window and late deployment/incident events. Assert exact expected numerator/denominator and units. Do not display synthetic values as Eldorado baseline data.

8. Recommended sequence and evidence gates

• Foundation: inventory actual clients, repositories, data sensitivity, available events and accountable owners. Exit only with a supported pilot boundary and explicit forbidden actions, not with a catalog full of untested skills.
• Low-risk pilot: small set of useful read-only/drafting/test-assistance skills; reviewed immutable bundles; exact-client smoke and adversarial tests; human review and failure reporting. Exit with reproducible quality evidence and usable measurement coverage.
• Governed distribution: add version-aware adapters, onboarding, staged upgrades, rollback/revocation drills and exception expiry. Exit when stale/offline/unsupported clients cannot bypass central privileged gates.
• Logical SDLC coordination: coordinator starts by observing and assembling evidence, then proposing work and routing approvals. Expand mutation only after idempotency, separation of duties, scoped credentials, outage recovery and kill-switch tests pass.
• Broader departmental use: Operations, Marketing, Finance & Accounting and HR & Administration adopt domain-specific skills with their own human decisions, data boundaries and outcome measures. Do not copy coding autonomy into payments, personnel decisions or disputes.

No invented rollout dates, budget, staffing capacity or required improvement percentage. Scale only when quality, risk and cost evidence support it; stop or narrow scope when benefits are not demonstrated.

9. Source coverage and unresolved questions

Coverage: 26 retrieved primary-source records with 50 literal evidence passages. Includes Agent Skills specification and integration guidance; GitHub support/instructions/install/metrics; Claude skills/memory/hooks/security/monitoring; Cline skills/rules/hooks and linked SDK plugins; agent-evaluation methodology; current DORA definitions; author-hosted SPACE summary; NIST framework/core/GenAI profile landing page; OWASP prompt injection; two primary research abstracts plus METR historical study and 2026 follow-up. This is substantive source-body review, but not a systematic literature review, independent replication, legal assessment or live client qualification. Full PDFs for the two arXiv papers and NIST GenAI profile were not reviewed; claims are limited accordingly. ACM's 403 is recorded and resolved only to the author-hosted summary, not bypassed or silently called full text.

Open decisions/evidence needed before implementation:

1. Which actual client hosts, versions, models, OSs, subscriptions and managed-device controls are in use? What is the allowed support window?
2. Which repository/CI/release systems and protected-branch controls are authoritative? Can required checks and policy definitions be altered by a candidate PR or bypassed by administrators?
3. Who fills each approving/operating function and who provides cover? What pilot capacity is available? The documented organization does not establish personnel availability.
4. What data may reach each model provider or telemetry endpoint; what retention/training/region and contractual terms apply? No provider contract was inspected.
5. Which low-risk workflows have enough representative tasks and independent quality labels? What is the actual eligible population and baseline coverage?
6. What timeout, stale-bundle grace, critical-risk rejection and emergency-revocation policies will owners approve? Can laptop access be independently revoked?
7. Does the chosen distributor support private Gitea securely, and can every supported client report effective skill/adapter versions without collecting sensitive content?
8. What causal claims, if any, can the proposed pilot design justify given self-selection, learning, task mix and parallel work?
9. Which detailed Cline/Copilot hooks and offline/resume behavior exist in the precise deployed builds? Sources here do not establish cross-client equivalence.

Synthesis handoff: keep this research trail outside reader-facing portal prose. Use ordinary operating-model language for the strategy, preserve all existing teams and leadership uncertainty, visibly distinguish target maturity from current state, and retain recommendation/source mapping internally. No portal publication is part of this research card.

Sources

[1] https://agentskills.io/specification — Agent Skills specification [2] https://docs.github.com/en/copilot/concepts/agents/about-agent-skills — Copilot Agent Skills [3] https://docs.github.com/en/copilot/concepts/prompting/response-customization — Copilot custom instructions [4] https://code.claude.com/docs/en/skills — Claude Code skills [5] https://code.claude.com/docs/en/memory — Claude Code memory [6] https://code.claude.com/docs/en/hooks — Claude Code hooks [7] https://code.claude.com/docs/en/security — Claude Code security [8] https://docs.cline.bot/customization/skills — Cline skills [9] https://docs.cline.bot/customization/cline-rules — Cline rules [10] https://docs.cline.bot/customization/hooks — Cline hooks [11] https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents — Demystifying evals for AI agents [12] https://dora.dev/guides/dora-metrics — DORA software delivery metrics [13] https://www.nist.gov/itl/ai-risk-management-framework — NIST AI RMF [14] https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence — NIST Generative AI Profile [15] https://genai.owasp.org/llmrisk/llm01-prompt-injection — OWASP prompt injection [16] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study — Experienced developer RCT [17] https://arxiv.org/abs/2302.06590 — AI developer productivity experiment [18] https://arxiv.org/abs/2410.12944 — Field experiments in software development [19] https://docs.github.com/en/copilot/concepts/billing-and-usage/copilot-usage-metrics/copilot-metrics — Copilot metrics concepts [20] https://code.claude.com/docs/en/monitoring-usage — Claude Code monitoring [21] https://agentskills.io/client-implementation/adding-skills-support — Agent Skills security [22] https://metr.org/blog/2026-02-24-uplift-update — METR productivity update 2026 [23] https://docs.cline.bot/sdk/plugins — Cline SDK plugins [24] https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think — SPACE research publication [25] https://airc.nist.gov/airmf-resources/airmf/5-sec-core — NIST AI RMF Core [26] https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills — Copilot adding skills