agentsclimarketplace

Cloud logging query generation

Skill hamzabellouch/agent-skills/Google Cloud and GKE/cloud-logging-query-generation

Comprehensive collection of 380+ production-ready Agent Skills (26 domains) conforming to the Agent Skills Standard, featuring native auto-discovery for Antigravity, Gemini CLI, Claude Code, Cursor, and Codex.

Install
npx -y skills add hamzabellouch/agent-skills --skill cloud-logging-query-generation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generates Logging Query Language (LQL) queries for Google Cloud Logging from natural language. Use this skill when you need to query log data or when you are debugging issues. You can filter log data by Google Cloud service. Don't use this skill to query other databases, such as SQL or Spanner.

SKILL.md

6.4 KB, as published. Nobody here has run it

Generate Logging Query Language queries

Use this skill to generate correct Logging Query Language (LQL) queries for Cloud Logging.

Core rules

  1. Strict syntax requirements:

    • Always use double quotes (") for string literals. Do not use single quotes (').
    • Write boolean operators in all capitals: AND, OR, NOT.
    • Always use parentheses to group terms and explicitly enforce precedence.

  2. Common pitfalls:

    • Instance ID vs. Instance Name: For the gce_instance resource type, do NOT compare instance names to instance IDs. Instance names are strings (for example, my-instance). Instance IDs are numeric. If you only have the name, then search by instance name, SEARCH("my-instance"), or use resource.labels.instance_name if that label is available for the resource.
    • Resource Type Accuracy: Do not guess resource types. You must look up the correct resource.type value in the service-specific reference files. For example, use internal_http_lb_rule for Internal HTTP(S) Load Balancer rules when filtering by forwarding rule name or region (instead of http_load_balancer).

  3. Output format and placeholders:

    • Output only the raw LQL query text. Do not include conversational filler. Do not wrap the query in markdown code blocks unless explicitly requested by the user. Valid LQL comments (using --) are allowed, and are the ONLY acceptable way to include explanations or warnings.
    • Never block on missing variables. If the user's request lacks specific identifiers (like a project ID, instance name, or IP address), do not ask them for clarification. Instead, insert uppercase placeholder strings wrapped in angle brackets (for example, "<PROJECT_ID>", "<YOUR_SERVICE_NAME>") directly into the query.

  4. Preferred fields:

    • Include resource.type and log_id restrictions when the query targets specific Google Cloud services or resources. Global queries (for example, "latest error logs") do not require these restrictions.

Detailed reference

Refer to references/api_reference.md for LQL syntax rules, including Operators, NULL handling, SEARCH, and Regex.

Service reference files

Before generating a query, you MUST read the examples for the specific service. LQL schemas and resource.type values are service-specific.

For the following services, read the exact file listed:

For Google Cloud services that aren't listed: If the service is not listed above, write the LQL query based on your general knowledge.

Query generation rules

  1. Resource Types: Explicitly define the resource.type in your queries when focusing on specific services. For some queries, you may need to search across multiple types (for example, resource.type=("bigquery_project" OR "bigquery_dataset")).
  2. Audit and admin logs: Google Cloud Audit logs (Admin Activity, Data Access) always follow a standard structure inside protoPayload. If the user asks for logs about who created, updated, or deleted a resource, or an API being called:
    • Do NOT fall back to SEARCH(). Instead, use protoPayload.methodName.
    • Construct the method name by guessing the service and the verb. Example: protoPayload.methodName:"compute.instances.insert".
    • Always use the colon operator (:) instead of equals (=) for methodName. The colon operator results in substring matching, which is the only feasible option when the exact API string isn't known.
    • For generic API enable/disable events, use resource.type="audited_resource".
  3. Handling Unknown Schemas (Crucial): If the user asks to filter by a specific field or condition, and if you cannot find a matching example or schema in the reference files, then you must generate a query using global search.
    • Only specify jsonPayload.* or protoPayload.* field structures when you are certain of their exact name.
    • Use the SEARCH() function to find the keyword globally within the correct resource.type.
    • Agent Prompt to User: When delivering a query that uses SEARCH, you MUST add an LQL comment (using --) at the top of the query indicating you used a global keyword search because the exact schema wasn't in your references. Do NOT output conversational text, strictly adhere to the Output Format rule.

Supporting links

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.