agent-skills: add chronos documentation and add helper copy script

infra/experimental/agent-skills/copy_to_global.sh

@@ -0,0 +1,60 @@
+#!/bin/bash -eu
+# Copyright 2026 Google LLC
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#      http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+################################################################################
+
+# Copy the skills folder into the global skills directory
+
+# Accept user input. Should by default be "gemini" but can be overridden by the user.
+SKILLS_DIR=${1:-"gemini"}
+
+
+# Gemini skills dir = ~/.gemini/skills
+# Claude skills dir = ~/.claude/skills
+if [ "$SKILLS_DIR" == "gemini" ]; then
+  GLOBAL_SKILLS_DIR="$HOME/.gemini/skills"
+elif [ "$SKILLS_DIR" == "claude" ]; then
+  GLOBAL_SKILLS_DIR="$HOME/.claude/skills"
+else
+  echo "Invalid skills directory specified. Use 'gemini' or 'claude'."
+  exit 1
+fi
+
+# Log target skill directory
+echo "Copying skills to global skills directory: $GLOBAL_SKILLS_DIR"
+
+
+# Now copy each of the skills from the local "skills" directory to the global skills directory
+# Overwrite existing skills with the same name.
+# Check if the global skills directory exists, if not create it
+if [ ! -d "$GLOBAL_SKILLS_DIR" ]; then
+  mkdir -p "$GLOBAL_SKILLS_DIR"
+fi
+
+# Copy each skill from the local "skills" directory to the global skills directory
+# Make sure we work from this scripts base folder and copy each of the skills
+# fuzzing-memory-unsafe-expert
+# oss-fuzz-engineer
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+for skill in "fuzzing-memory-unsafe-expert" "oss-fuzz-engineer"; do
+  abs_skill="$SCRIPT_DIR/$skill"
+  # Copy over the skill and replace any existing skill with the same name in the global skills directory
+  if [ -d "$GLOBAL_SKILLS_DIR/$skill" ]; then
+    rm -rf "$GLOBAL_SKILLS_DIR/$skill"
+  fi
+
+  echo "Copying $abs_skill to $GLOBAL_SKILLS_DIR/"
+  cp -r "$abs_skill" "$GLOBAL_SKILLS_DIR/"
+done

infra/experimental/agent-skills/oss-fuzz-engineer/SKILL.md

@@ -62,3 +62,34 @@ python3 infra/helper.py check_build PROJECT_NAME
 ```
 
 The agent should never make any commits or push anything to GitHub, but should conclude on the work for the security engineer to review. The agent should never submit any changes to OSS-Fuzz's Github.
+
+
+### Chronos integration
+
+A common task for an OSS-Fuzz engineer is to add Chronos support for a given OSS-Fuzz project.
+
+Chronos is a feature of OSS-Fuzz that makes it possible to quickly rebuild OSS-Fuzz projects and run unit tests of a given OSS-Fuzz project. This is used to efficiently validate e.g. patches of a project without having to rebuild the entire target project image.
+
+To add Chronos support a project needs to have two key scripts:
+
+- replay_build.sh: used to quickly rebuild the project without network access.
+- run_tests.sh: used to run unit tests of the project without network access.
+
+There are several constraints on these scripts, e.g. no network access, and it's important to always check the infra/chronos/README.md file to understand the specifics.
+
+A given Chronos integration must succeed with:
+
+```sh
+python3 infra/experimental/chronos/manager.py check-replay PROJECT_NAME
+python3 infra/experimental/chronos/manager.py check-tests PROJECT_NAME
+```
+
+The above two commands must succeed without error, and when integrating a new project these commands must be run before concluding on the work for the security engineer to review.
+
+
+# Guidelines for working locally on OSS-Fuzz projects
+
+1. Always work from the base folder of the current OSS-Fuzz project unless otherwise specified.
+2. Make a local checkout of the target source code to make working with the target project easy. This involves e.g. studying the `Dockerfile` of the target project, finding the e.g. `git clone` of the target project, and then cloning this repository locally and using e.g. `COPY` instead of `RUN git clone` in the Dockerfile to get the source code into the container.
+3. Use the `python3 infra/helper.py` tool to build and test fuzz targets locally.
+4. Analyse if build scripts can be optimized to improve local building efficiency.