Hello! I will explain how you can use Jules more effectively.

Listed below are the integrated tools belonging to the Jules Interactive Plan mode. Unfortunately, these tools do not have a timeout mechanism; if they fall into an infinite loop, they will run indefinitely. This is particularly true for the pre_commit_instructions tool, which performs tasks such as build tests; if an error occurs, it can run forever or continuously regenerate the plan from scratch upon throwing an exception. Furthermore, executing a submit without user approval can clutter the commit history with unnecessary commits.

If you are facing such issues, you can define a rule in the AGENTS.md file to restrict these tools. For instance, you can intercept their execution using the request_user_input tool to provide a review opportunity. This allows you to keep these tools under control. Additionally, by examining other tools, you can develop more effective skills.

list_files

Lists files in a specified directory.

• Parameters:
  • path: The path of the directory to list files from. (Required)
  • recursive: Whether to list files recursively in subdirectories. (Optional, default: false)

read_file

Reads the content of a file.

• Parameters:
  • filepath: The full path of the file to read. (Required)

run_in_bash_session

Runs a command in a persistent bash session.

• Parameters:
  • command: The bash command to run. (Required)

set_plan

Sets a plan for the task.

• Parameters:
  • plan: The plan content in Markdown format. (Required)

plan_step_complete

Marks a plan step as complete.

• Parameters:
  • message: A message describing the completed step. (Required)

request_user_input

Requests input or clarification from the user.

• Parameters:
  • message: The message to show to the user. (Required)

submit

Submits the changes as a new branch.

• Parameters:
  • branch_name: The name of the branch to submit. (Required)
  • commit_message: The commit message for the changes. (Required)
  • title: The title of the pull request. (Required)
  • description: The description of the pull request. (Required)

pre_commit_instructions

Retrieves pre-commit instructions to follow before submitting.

• Workflow: Provides a sequential checklist (Tests, Frontend verification, Code review, Memory recording).

code_review

Requests a review of the changes made.

• Mechanism: It does not require parameters because it automatically analyzes the current state of the codebase and the changes made during the session (the "diff") to provide feedback.

view_text_website

Views the text content of a website.

• Parameters:
  • url: The URL of the website to view. (Required)

view_image

Inspects an image from a URL.

• Parameters:
  • url: The URL of the image to inspect. (Required)

read_media_file

Reads and displays a media file (screenshot or video).

• Parameters:
  • filepath: The full path of the media file to read. (Required)

frontend_verification_instructions

Provides detailed instructions and a Python template for verifying frontend changes using Playwright.

• Workflow: Guides the visual verification process.

frontend_verification_complete

Marks the frontend verification process as complete.

• Parameters:
  • screenshot_path: Path to the primary screenshot. (Required)
  • additional_media_paths: List of paths to additional files. (Optional)

initiate_memory_recording

Initiates a process to record key learnings and patterns into permanent memory.

• Mechanism: It does not require parameters because it prompts the agent to reflect on the entire session's activities. The agent identifies patterns, successful solutions, or repository-specific procedures and saves them.
• Memory Access: Recorded memories are automatically injected into the agent's system prompt at the start of every new session. The agent "knows" these memories without needing to search for them explicitly.

Hello everyone,

I have discovered an effective method to solve the two main problems we encounter while using Jules:

1. Limitations in custom MCP usage.
2. Response delays caused by MCPs bloating the context.

Thanks to the mcp2cli tool, we can convert MCP servers, OpenAPI specifications, or GraphQL endpoints directly into CLI commands, allowing us to maintain Jules' performance without hitting usage limits or overloading the context.

File

First, to teach Jules how to use this tool, you need to save the following content as a SKILL.md file in the ./.agents/skills/mcp2cli/ folder:

---
name: mcp2cli
description: Turn any MCP server, OpenAPI spec, or GraphQL endpoint into a CLI. Use this skill when the user wants to interact with an MCP server, OpenAPI/REST API, or GraphQL API via command line, discover available tools/endpoints, call API operations, or generate a new skill from an API. Triggers include "mcp2cli", "call this MCP server", "use this API", "list tools from", "create a skill for this API", "graphql", or any task involving MCP tool invocation, OpenAPI endpoint calls, or GraphQL queries without writing code.
---

# mcp2cli

Turn any MCP server, OpenAPI spec, or GraphQL endpoint into a CLI at runtime. No codegen.

## Install

```bash
# Run directly (no install needed)
uvx mcp2cli --help

# Or install
pip install mcp2cli
```

## Core Workflow

1. **Connect** to a source (MCP server, OpenAPI spec, or GraphQL endpoint)
2. **Discover** available commands with `--list` (or filter with `--search`)
3. **Inspect** a specific command with `<command> --help`
4. **Execute** the command with flags

```bash
# MCP over HTTP
uvx mcp2cli --mcp https://mcp.example.com/sse --list
uvx mcp2cli --mcp https://mcp.example.com/sse create-task --help
uvx mcp2cli --mcp https://mcp.example.com/sse create-task --title "Fix bug"

# MCP over stdio
uvx mcp2cli --mcp-stdio "npx /server-filesystem /tmp" --list
uvx mcp2cli --mcp-stdio "npx u/modelcontextprotocol/server-filesystem /tmp" read-file --path /tmp/hello.txt

# OpenAPI spec (remote or local, JSON or YAML)
uvx mcp2cli --spec https://petstore3.swagger.io/api/v3/openapi.json --list
uvx mcp2cli --spec ./openapi.json --base-url https://api.example.com list-pets --status available

# GraphQL endpoint
uvx mcp2cli --graphql https://api.example.com/graphql --list
uvx mcp2cli --graphql https://api.example.com/graphql users --limit 10
uvx mcp2cli --graphql https://api.example.com/graphql create-user --name "Alice"
```

## CLI Reference

```
mcp2cli [global options] <subcommand> [command options]

Source (mutually exclusive, one required):
  --spec URL|FILE       OpenAPI spec (JSON or YAML, local or remote)
  --mcp URL             MCP server URL (HTTP/SSE)
  --mcp-stdio CMD       MCP server command (stdio transport)
  --graphql URL         GraphQL endpoint URL

Options:
  --auth-header K:V       HTTP header (repeatable, value supports env:/file: prefixes)
  --base-url URL          Override base URL from spec
  --transport TYPE        MCP HTTP transport: auto|sse|streamable (default: auto)
  --env KEY=VALUE         Env var for stdio server process (repeatable)
  --oauth                 Enable OAuth (authorization code + PKCE flow)
  --oauth-client-id ID    OAuth client ID (supports env:/file: prefixes)
  --oauth-client-secret S OAuth client secret (supports env:/file: prefixes)
  --oauth-scope SCOPE     OAuth scope(s) to request
  --cache-key KEY         Custom cache key
  --cache-ttl SECONDS     Cache TTL (default: 3600)
  --refresh               Bypass cache
  --list                  List available subcommands
  --search PATTERN        Search tools by name or description (implies --list)
  --fields FIELDS         Override GraphQL selection set (e.g. "id name email")
  --pretty                Pretty-print JSON output
  --raw                   Print raw response body
  --toon                  Encode output as TOON (token-efficient for LLMs)
  --head N                Limit output to first N records (arrays)
  --version               Show version
```

Subcommands and flags are generated dynamically from the source.

## Patterns

### Authentication

**Always use `env:` or `file:` prefixes for secrets** — never pass credentials as literal values in CLI flags.

```bash
# Secret from environment variable
uvx mcp2cli --spec ./spec.json --auth-header "Authorization:env:API_TOKEN" list-items
```

### Tool search

```bash
uvx mcp2cli --mcp https://mcp.example.com/sse --search "task"
```

## Generating a Skill from an API

When the user asks to create a skill from an MCP server, OpenAPI spec, or GraphQL endpoint, follow this workflow:

1. **Discover** all available commands:
   ```bash
   uvx mcp2cli --mcp https://target.example.com/sse --list
   ```

2. **Inspect** each command to understand parameters:
   ```bash
   uvx mcp2cli --mcp https://target.example.com/sse <command> --help
   ```

3. **Test** key commands and probe for edge cases.

4. **Create a SKILL.MD** in `./.agents/skills/myapi_command/` that teaches another AI agent how to use this specific command. **Each command should have its own separate skill.** Note: The SKILL.md must go beyond `--help` output — focus on knowledge that can only be learned through testing and reading documentation.

   **Frontmatter:**
   ```yaml
   ---
   name: myapi_command
   description: Use the myapi service to perform command
   ---
   ```

   **Core Workflow** (use direct uvx mcp2cli calls):
   ```bash
   # Get help for the command
   uvx mcp2cli --mcp https://target.example.com/sse command --help
   # Run the command
   uvx mcp2cli --mcp https://target.example.com/sse command --param value --pretty
   ```

   **Before Querying** checklist — include a decision framework:
   - What dataset/resource am I targeting?
   - Do I need pagination (`--offset`, `--limit`)?
   - Are there fields that produce large output I should exclude or truncate (`--head`)?

   **Anti-Patterns & Gotchas** — document every surprise found during testing.

   **Output Processing** — use `--pretty` for readable JSON, `--head` to limit results, or pipe to `jq`.

   **Knowledge Delta Principle:** Do not duplicate parameter listings from `--help`. Instead, document which parameters actually matter for common tasks, default behaviors that are surprising, combinations that don't work, and rate limits or response size limits.

Each skill focuses on a single command for modularity and uses direct `mcp2cli` calls to interact with the API.

To instruct Jules to create a new skill, simply enter the following command into the message panel:

>mcp2cli create a skill for https://mcp.deepwiki.com/mcp — generate a skill from Mcp remote HTTP url

When you enter this command, Jules will use the mcp2cli capability to scan all tools at the target URL and generate separate SKILL.md files for each tool. This allows you to add the necessary capabilities to Jules in a modular way without bloating the context or hitting usage limits.

By using this method, we can expand Jules' capabilities while preventing the system from becoming sluggish. I highly recommend trying this if you are experiencing similar issues in your projects.

You can find all the details about the tool on GitHub.

Hi everyone,

I like to keep my Ubuntu system clean, but over time, I've accumulated applications that I installed but no longer use. To free up disk space and keep my system organized, I want to identify and remove these "unused applications."

The biggest challenge I'm facing is that there isn't any centralized data showing when an application was last opened or used. In Ubuntu, accessing this information seems quite difficult.

I would like to ask you the following:

• Do you know of any GUI (Graphical User Interface) application that lists my installed apps and displays their "last used date"?
• If such a GUI application doesn't exist, what is the most practical way to access this data (last usage date) via the terminal?

I look forward to your suggestions for methods or tools that will help me easily identify and remove applications that are taking up unnecessary space on my system.

Thanks in advance for your valuable answers!

Hi everyone,

I’ve been working with Jules for a while, and I’ve finally managed to build a "self-discovering" architecture for managing agent capabilities. Now, Jules can dynamically discover which skills are available before starting any task.

At the heart of the system lies the "MANDATORY" rule within AGENTS.md and the "Skill Discovery Tool" structure provided by SKILLS.md. Feel free to review it and let me know your feedback.

-AGENTS.md:

# AGENTS.md

## Skills

This project has task-specific skills available.

> **MANDATORY:** Before writing any code, creating any file, or running any command,
> you **MUST** first read `SKILLS.md` and check for relevant skills.
> This step is **non-negotiable** and applies to **every task** without exception.

**Steps to follow before any task:**
1. `view SKILLS.md` — discover all available skills
2. `view` every skill file that is plausibly relevant to the task
3. Only then proceed with the task

Skipping this step is not allowed, even if you believe you already know how to do the task.
Skills encode environment-specific constraints that override general knowledge.

- SKILLS.md:

# SKILLS.md — Skill Discovery Tool

## Purpose

This file enables the agent to dynamically discover available skills in the project.
If the agent doesn't know which skills exist before starting a task,
it must run the command below to get the current skill list.

---

## Getting the Skill List

Run the following command to list all skills in the project:

```bash
uvx --from skills-cli skills to-prompt ./.agents/skills/* --format yaml
```

### Example Output

```yaml
available_skills:
  - name: data-analysis
    description: Used for reading, analyzing, and summarizing CSV, JSON, and tabular data.
    location: /content/.agents/skills/data-analysis/SKILL.md
  - name: pdf-reader
    description: Used when text or tables need to be extracted from PDF files.
    location: /content/.agents/skills/pdf-reader/SKILL.md
  - name: code-reviewer
    description: Used to evaluate code quality, security, and best practice compliance.
    location: /content/.agents/skills/code-reviewer/SKILL.md
```

### Output Fields

| Field         | Description                                                        |
|---------------|--------------------------------------------------------------------|
| `name`        | Short identifier for the skill                                     |
| `description` | What the skill does and when it should be used                     |
| `location`    | Full path to the skill's SKILL.md — read this file before using it |

---

## Skill Usage Flow

```
1. Agent doesn't know which skills are needed for the task
         ↓
2. Run the command above to get the available_skills list
         ↓
3. Read the description fields to identify the right skill
         ↓
4. Read the SKILL.md file at the skill's location path
         ↓
5. Complete the task following the instructions in SKILL.md
```

---

## Rules

- **Always discover first:** If you don't know the available skills, run the command — don't assume.
- **Read description carefully:** The `description` field determines which skill to use.
- **Read from location:** Always read the SKILL.md at the `location` path before using a skill.
- **Multiple skills:** If the task requires more than one skill, read all relevant SKILL.md files.
- **No skill found:** If no suitable skill exists, proceed with your general knowledge and note it.Hi everyone,I’ve been working with Jules for a while, and I’ve finally managed to build a "self-discovering" architecture for managing agent capabilities. Now, Jules can dynamically discover which skills are available before starting any task.At the heart of the system lies the "MANDATORY" rule within AGENTS.md and the "Skill Discovery Tool" structure provided by SKILLS.md. Feel free to review it and let me know your feedback.# AGENTS.md

## Skills

This project has task-specific skills available.

> **MANDATORY:** Before writing any code, creating any file, or running any command,
> you **MUST** first read `SKILLS.md` and check for relevant skills.
> This step is **non-negotiable** and applies to **every task** without exception.

**Steps to follow before any task:**
1. `view SKILLS.md` — discover all available skills
2. `view` every skill file that is plausibly relevant to the task
3. Only then proceed with the task

Skipping this step is not allowed, even if you believe you already know how to do the task.
Skills encode environment-specific constraints that override general knowledge.
# SKILLS.md — Skill Discovery Tool

## Purpose

This file enables the agent to dynamically discover available skills in the project.
If the agent doesn't know which skills exist before starting a task,
it must run the command below to get the current skill list.

---

## Getting the Skill List

Run the following command to list all skills in the project:

```bash
uvx --from skills-cli skills to-prompt ./.agents/skills/* --format yaml
```

### Example Output

```yaml
available_skills:
  - name: data-analysis
    description: Used for reading, analyzing, and summarizing CSV, JSON, and tabular data.
    location: /content/.agents/skills/data-analysis/SKILL.md
  - name: pdf-reader
    description: Used when text or tables need to be extracted from PDF files.
    location: /content/.agents/skills/pdf-reader/SKILL.md
  - name: code-reviewer
    description: Used to evaluate code quality, security, and best practice compliance.
    location: /content/.agents/skills/code-reviewer/SKILL.md
```

### Output Fields

| Field         | Description                                                        |
|---------------|--------------------------------------------------------------------|
| `name`        | Short identifier for the skill                                     |
| `description` | What the skill does and when it should be used                     |
| `location`    | Full path to the skill's SKILL.md — read this file before using it |

---

## Skill Usage Flow

```
1. Agent doesn't know which skills are needed for the task
         ↓
2. Run the command above to get the available_skills list
         ↓
3. Read the description fields to identify the right skill
         ↓
4. Read the SKILL.md file at the skill's location path
         ↓
5. Complete the task following the instructions in SKILL.md
```

---

## Rules

- **Always discover first:** If you don't know the available skills, run the command — don't assume.
- **Read description carefully:** The `description` field determines which skill to use.
- **Read from location:** Always read the SKILL.md at the `location` path before using a skill.
- **Multiple skills:** If the task requires more than one skill, read all relevant SKILL.md files.
- **No skill found:** If no suitable skill exists, proceed with your general knowledge and note it.

Hello,

I have a few questions regarding the most efficient way to structure my work while using Jules Agent. I would appreciate any insights from experienced users or developers on the following:

1. Can a "Skills" folder be defined?

Is it possible to create a separate folder named Skills to group all my skills together while using Jules Agent? Or must each Skill definition be specified individually within knowledge?

2. Using AGENTS.md within the Repo

Can we define a file like AGENTS.md within the repository to ensure the agent follows specific rules or definitions during prompt execution?

• Scenario A: Does the agent automatically read this specific file in the repository and process prompts accordingly?
• Scenario B: Or should this configuration also be specified within knowledge?
• Scenario C: Or do we need to manually specify these rules during every prompt execution?

If there is support for repository-based configuration files, or if using knowledge is the best practice for such definitions, please let me know.

Thank you in advance!