{"id":34889553,"url":"https://github.com/GitHubSecurityLab/seclab-taskflow-agent","last_synced_at":"2025-12-31T10:01:00.172Z","repository":{"id":315254016,"uuid":"1052954255","full_name":"GitHubSecurityLab/seclab-taskflow-agent","owner":"GitHubSecurityLab","description":"The GitHub Security Lab Taskflow Agent Framework","archived":false,"fork":false,"pushed_at":"2025-12-18T11:46:45.000Z","size":610,"stargazers_count":18,"open_issues_count":10,"forks_count":7,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-12-21T18:02:15.548Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/GitHubSecurityLab.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":"SECURITY.md","support":"SUPPORT.md","governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":"NOTICE","maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-09-08T19:27:09.000Z","updated_at":"2025-12-18T11:46:45.000Z","dependencies_parsed_at":"2025-09-17T15:48:38.170Z","dependency_job_id":"1c671192-e2a9-45cf-96a1-5ca4edb372ac","html_url":"https://github.com/GitHubSecurityLab/seclab-taskflow-agent","commit_stats":null,"previous_names":["githubsecuritylab/seclab-taskflow-agent"],"tags_count":14,"template":false,"template_full_name":null,"purl":"pkg:github/GitHubSecurityLab/seclab-taskflow-agent","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GitHubSecurityLab%2Fseclab-taskflow-agent","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GitHubSecurityLab%2Fseclab-taskflow-agent/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GitHubSecurityLab%2Fseclab-taskflow-agent/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GitHubSecurityLab%2Fseclab-taskflow-agent/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/GitHubSecurityLab","download_url":"https://codeload.github.com/GitHubSecurityLab/seclab-taskflow-agent/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GitHubSecurityLab%2Fseclab-taskflow-agent/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28142151,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-12-31T02:00:06.200Z","response_time":55,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-12-26T05:00:31.731Z","updated_at":"2025-12-31T10:01:00.163Z","avatar_url":"https://github.com/GitHubSecurityLab.png","language":"Python","readme":"# Seclab Taskflow Agent\n\nThe Security Lab Taskflow Agent is an MCP enabled multi-Agent framework.\n\nThe Taskflow Agent is built on top of the [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/).\n\nWhile the Taskflow Agent does not integrate into the GitHub Dotcom Copilot UX, it does operate using the Copilot API (CAPI) as its backend, similar to Copilot IDE extensions.\n\n## Core Concepts\n\nThe Taskflow Agent leverages a GitHub Workflow-esque YAML based grammar to perform a series of tasks using a set of Agents.\n\nIts primary value proposition is as a CLI tool that allows users to quickly define and script Agentic workflows without having to write any code.\n\nAgents are defined through [personalities](examples/personalities/), that receive a [task](examples/taskflows/) to complete, given a set of [tools](src/seclab_taskflow_agent/toolboxes/).\n\nAgents can cooperate to complete sequences of tasks through so-called [taskflows](doc/GRAMMAR.md).\n\nYou can find a detailed overview of the taskflow grammar [here](taskflows/GRAMMAR.md) and example taskflows [here](examples/taskflows/).\n\n## Use Cases and Examples\n\nThe Seclab Taskflow Agent framework was primarily designed to fit the iterative feedback loop driven work involved in Agentic security research workflows and vulnerability triage tasks.\n\nIts design philosophy is centered around the belief that a prompt level focus of capturing vulnerability patterns will greatly improve and scale security research results as frontier model capabilities evolve over time.\n\nWhile the maintainer himself primarily uses this framework as a code auditing tool it also serves as a more generic swiss army knife for exploring Agentic workflows. For example, the GitHub Security Lab also uses this framework for automated code scanning alert triage.\n\nThe framework includes a [CodeQL](https://codeql.github.com/) MCP server that can be used for Agentic code review, see the [CVE-2023-2283](examples/taskflows/CVE-2023-2283.yaml) taskflow for an example of how to have an Agent review C code using a CodeQL database ([demo video](https://www.youtube.com/watch?v=eRSPSVW8RMo)).\n\nInstead of generating CodeQL queries itself, the CodeQL MCP Server is used to provide CodeQL-query based MCP tools that allow an Agent to navigate and explore code. It leverages templated CodeQL queries to provide targeted context for model driven code analysis.\n\n## Requirements\n\nPython \u003e= 3.9 or Docker\n\n## Configuration\n\nProvide a GitHub token for an account that is entitled to use [GitHub Models](https://models.github.ai) via the `AI_API_TOKEN` environment variable. Further configuration is use case dependent, i.e. pending which MCP servers you'd like to use in your taskflows. In a terminal, you can add `AI_API_TOKEN` to the environment like this:\n\n```sh\nexport AI_API_TOKEN=\u003cyour_github_token\u003e\n```\n\nOr, if you are using GitHub Codespaces, then you can [add a Codespace secret](https://github.com/settings/codespaces/secrets/new) so that `AI_API_TOKEN` is automatically available when working in a Codespace.\n\nMany of the MCP servers in the [seclab-taskflow](https://github.com/GitHubSecurityLab/seclab-taskflows) repo also need an environment variable named `GH_TOKEN` for accessing the GitHub API. You can use two separate PATs if you want, or you can use one PAT for both purposes, like this:\n\n```sh\nexport GH_TOKEN=$AI_API_TOKEN\n```\n\nWe do not recommend storing secrets on disk, but you can persist non-sensitive environment variables by adding a `.env` file in the project root.\n\nExample:\n\n```sh\n# MCP configs\nCODEQL_DBS_BASE_PATH=\"/app/my_data/codeql_databases\"\nAI_API_ENDPOINT=\"https://models.github.ai/inference\"\n```\n\n## Deploying from Source\n\nWe use [hatch](https://hatch.pypa.io/) to build the project. Download and build like this:\n\n```bash\ngit clone https://github.com/GitHubSecurityLab/seclab-taskflow-agent.git\ncd seclab-taskflow-agent\npython -m venv .venv\nsource .venv/bin/activate\npip install hatch\nhatch build\n```\n\nThen run `hatch run main`.\n\nExample: deploying a prompt to an Agent Personality:\n\n```sh\nhatch run main -p seclab_taskflow_agent.personalities.assistant 'explain modems to me please'\n```\n\nExample: deploying a Taskflow:\n\n```sh\nhatch run main -t examples.taskflows.example\n```\n\nExample: deploying a Taskflow with command line global variables:\n\n```sh\nhatch run main -t examples.taskflows.example_globals -g fruit=apples\n```\n\nMultiple global variables can be set:\n\n```sh\nhatch run main -t examples.taskflows.example_globals -g fruit=apples -g color=red\n```\n\n## Deploying from Docker\n\nYou can deploy the Taskflow Agent via its Docker image using `docker/run.sh`.\n\nWARNING: the Agent Docker image is _NOT_ intended as a security boundary but strictly a deployment convenience.\n\nThe image entrypoint is `__main__.py` and thus it operates the same as invoking the Agent from source directly.\n\nYou can find the Docker image for the Seclab Taskflow Agent [here](https://github.com/GitHubSecurityLab/seclab-taskflow-agent/pkgs/container/seclab-taskflow-agent) and how it is built [here](release_tools/).\n\nNote that this image is based on a public release of the Taskflow Agent, and you will have to mount any custom taskflows, personalities, or prompts into the image for them to be available to the Agent.\n\nOptional image mount points to supply custom data are configured via the environment:\n\n- Custom data via `MY_DATA`, mounts to `/app/my_data`\n- Custom personalities via `MY_PERSONALITIES`, mounts to `/app/personalities/my_personalities`\n- Custom taskflows via `MY_TASKFLOWS`, mounts to `/app/taskflows/my_taskflows`\n- Custom prompts via `MY_PROMPTS`, mounts to `/app/prompts/my_prompts`\n- Custom toolboxes via `MY_TOOLBOXES`, mounts to `/app/toolboxes/my_toolboxes`\n\nSee [docker/run.sh](docker/run.sh) for further details.\n\nExample: deploying a Taskflow (example.yaml):\n\n```sh\ndocker/run.sh -t example\n```\n\nExample: deploying a Taskflow with global variables:\n\n```sh\ndocker/run.sh -t example_globals -g fruit=apples\n```\n\nExample: deploying a custom taskflow (custom_taskflow.yaml):\n\n```sh\nMY_TASKFLOWS=~/my_taskflows docker/run.sh -t custom_taskflow\n```\n\nExample: deploying a custom taskflow (custom_taskflow.yaml) and making local CodeQL databases available to the CodeQL MCP server:\n\n```sh\nMY_TASKFLOWS=~/my_taskflows MY_DATA=~/app/my_data CODEQL_DBS_BASE_PATH=/app/my_data/codeql_databases docker/run.sh -t custom_taskflow\n```\n\nFor more advanced scenarios like e.g. making custom MCP server code available, you can alter the run script to mount your custom code into the image and configure your toolboxes to use said code accordingly.\n\n```sh\nexport MY_MCP_SERVERS=\"$PWD\"/mcp_servers\nexport MY_TOOLBOXES=\"$PWD\"/toolboxes\nexport MY_PERSONALITIES=\"$PWD\"/personalities\nexport MY_TASKFLOWS=\"$PWD\"/taskflows\nexport MY_PROMPTS=\"$PWD\"/prompts\nexport MY_DATA=\"$PWD\"/data\n\nif [ ! -f \".env\" ]; then\n    touch \".env\"\nfi\n\ndocker run \\\n       --mount type=bind,src=\"$PWD\"/.env,dst=/app/.env,ro \\\n       ${MY_DATA:+--mount type=bind,src=$MY_DATA,dst=/app/my_data} \\\n       ${MY_MCP_SERVERS:+--mount type=bind,src=$MY_MCP_SERVERS,dst=/app/my_mcp_servers,ro} \\\n       ${MY_TASKFLOWS:+--mount type=bind,src=$MY_TASKFLOWS,dst=/app/taskflows/my_taskflows,ro} \\\n       ${MY_TOOLBOXES:+--mount type=bind,src=$MY_TOOLBOXES,dst=/app/toolboxes/my_toolboxes,ro} \\\n       ${MY_PROMPTS:+--mount type=bind,src=$MY_PROMPTS,dst=/app/prompts/my_prompts,ro} \\\n       ${MY_PERSONALITIES:+--mount type=bind,src=$MY_PERSONALITIES,dst=/app/personalities/my_personalities,ro} \\\n       \"ghcr.io/githubsecuritylab/seclab-taskflow-agent\" \"$@\"\n```\n\n## General YAML file headers\n\nEvery YAML files used by the Seclab Taskflow Agent must include a header like this:\n\n```yaml\nseclab-taskflow-agent:\n  version: 1\n  filetype: taskflow\n```\n\nThe `version` number in the header should always be 1. It means that the\nfile uses version 1 of the seclab-taskflow-agent syntax. If we ever need\nto make a major change to the syntax, then we'll update the version number.\nThis will hopefully enable us to make changes without breaking backwards\ncompatibility.\n\nThe `filetype` determines whether the file defines a personality, toolbox, etc.\nThis means that different types of files can be stored in the same directory.\nA `filetype` can be one of the following:\n  - taskflow\n  - personality\n  - toolbox\n  - prompt\n  - model_config\n\nWe'll now explain the role of different types of files and functionalities available to them.\n\n## Personalities\n\nCore characteristics for a single Agent. Configured through YAML files of `filetype` `personality`.\n\nThese are system prompt level instructions.\n\nExample:\n\n```yaml\n# personalities define the system prompt level directives for this Agent\nseclab-taskflow-agent:\n  version: 1\n  filetype: personality\n\npersonality: |\n  You are a simple echo bot. You use echo tools to echo things.\n\ntask: |\n  Echo user inputs using the echo tools.\n\n# personality toolboxes map to mcp servers made available to this Agent\ntoolboxes:\n  - seclab_taskflow_agent.toolboxes.echo\n```\n\nIn the above, the `personality` and `task` field specifies the system prompt to be used whenever this `personality` is used.\nThe `toolboxes` are the tools that are available to this `personality`. The `toolboxes` should be a list of files of the `filetype` `toolbox`. (See the [Import paths](#import-paths) section for how to reference other files.)\n\nPersonalities can be used in two ways. First it can be used standalone with a prompt input from the command line:\n\n```\nhatch run main -p examples.personalities.echo 'echo this message'\n```\n\nIn this case, `personality` and `task` from [`examples/personalities/echo.yaml`](examples/personalities/echo.yaml) are used as the\nsystem prompt while the user argument `echo this message` is used as a user prompt. In this use case, the only tools that this\npersonality has access to is the `toolboxes` specified in the file.\n\nPersonalities can also be used in a `taskflow` to perform tasks. This is done by adding the `personality` to the `agents` field in a `taskflow` file:\n\n```yaml\ntaskflow:\n  - task:\n      ...\n      agents:\n        - personalities.assistant\n      user_prompt: |\n        Fetch all the open pull requests from `github/codeql` github repository.\n        You do not need to provide a summary of the results.\n      toolboxes:\n        - seclab_taskflow_agent.toolboxes.github_official\n```\n\nIn this case, the `personality` specified in `agents` provides the system prompt and the user prompt is specified in the `user_prompt` field of the task. A big difference in this case is that the `toolboxes` specified in the `task` will overwrite the `toolboxes` that the `personality` has access to. So in the above example, the `personalities.assistant` will have access to the `seclab_taskflow_agent.toolboxes.github_official` toolbox instead of its own toolbox. It is important to note that the `personalities` toolboxes get *overwritten* in this case, so whenever a `toolboxes` field is provided in a `task`, it'll use the provided toolboxes and `personality` loses access to its own toolboxes. e.g.\n\n```yaml\ntaskflow:\n  - task:\n      ...\n      agents:\n        - examples.personalities.echo\n      user_prompt: |\n        echo this\n      toolboxes:\n        - seclab_taskflow_agent.toolboxes.github_official\n```\n\nIn the above `task`, `personalities.examples.echo` will only have access to the `toolboxes.github_official` and can no longer access the `seclab_taskflow_agent.toolboxes.echo` `toolbox` (unless it is added also in the `task` `toolboxes`).\n\n## Toolboxes\n\nMCP servers that provide tools. Configured through YAML files of `filetype` `toolbox`. These are files that provide the type and parameters to start an MCP server.\n\nFor example, to start a stdio MCP server that is implemented in a python file:\n\n```yaml\n# stdio mcp server configuration\nseclab-taskflow-agent:\n  version: 1\n  filetype: toolbox\n\nserver_params:\n  kind: stdio\n  command: python\n  args: [\"-m\", \"seclab_taskflow_agent.mcp_servers.echo.echo\"]\n  env:\n    TEST: value\n```\n\nIn the above, `command` and `args` are just the command and arguments that should be run to start the MCP server. Environment variables can be passed using the `env` field.\n\nA [streamable](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) is also supported by setting the `kind` to `streamable`:\n\n```yaml\nserver_params:\n  kind: streamable\n  url: https://api.githubcopilot.com/mcp/\n  #See https://github.com/github/github-mcp-server/blob/main/docs/remote-server.md\n  headers:\n    Authorization: \"{{ env GITHUB_AUTH_HEADER }}\"\n  optional_headers:\n    X-MCP-Toolsets: \"{{ env GITHUB_MCP_TOOLSETS }}\"\n    X-MCP-Readonly: \"{{ env GITHUB_MCP_READONLY }}\"\n```\n\nYou can force certain tools within a `toolbox` to require user confirmation to run. This can be helpful if a tool may perform irreversible actions and should require user approval prior to its use. This is done by including the name of the tool (function) in the MCP server in the `confirm` section:\n\n```yaml\nserver_params:\n  kind: stdio\n  ...\n# the list of tools that you want the framework to confirm with the user before executing\n# use this to guard rail any potentially dangerous functions from MCP servers\nconfirm:\n  - memcache_clear_cache\n```\n\n## Taskflows\n\nA sequence of interdependent tasks performed by a set of Agents. Configured through YAML files of `filetype` `taskflow`.\nTaskflows supports a number of features, and their details can be found [here](doc/GRAMMAR.md).\n\nExample:\n\n```yaml\nseclab-taskflow-agent:\n  version: 1\n  filetype: taskflow\n\ntaskflow:\n  - task:\n      # taskflows can optionally choose any of the support CAPI models for a task\n      model: gpt-4.1\n      # taskflows can optionally limit the max allowed number of Agent task loop\n      # iterations to complete a task, this defaults to 50 when not provided\n      max_steps: 20\n      must_complete: true\n      # taskflows can set a primary (first entry) and handoff (additional entries) agent\n      agents:\n        - seclab_taskflow_agent.personalities.c_auditer\n        - examples.personalities.fruit_expert\n      user_prompt: |\n        Store an example vulnerable C program that uses `strcpy` in the\n        `vulnerable_c_example` memory key and explain why `strcpy`\n        is insecure in the C programming language. Do this before handing off\n        to any other agent.\n\n        Finally, why are apples and oranges healthy to eat?\n\n      # taskflows can set temporary environment variables, these support the general\n      # \"{{ env FROM_EXISTING_ENVIRONMENT }\" pattern we use elsewhere as well\n      # these environment variables can then be made available to any stdio mcp server\n      # through its respective yaml configuration, see memcache.yaml for an example\n      # you can use these to override top-level environment variables on a per-task basis\n      env:\n        MEMCACHE_STATE_DIR: \"example_taskflow/\"\n        MEMCACHE_BACKEND: \"dictionary_file\"\n      # taskflows can optionally override personality toolboxes, in this example\n      # this normally only has the memcache toolbox, but we extend it here with\n      # the GHSA toolbox\n      toolboxes:\n        - seclab_taskflow_agent.toolboxes.memcache\n        - seclab_taskflow_agent.toolboxes.codeql\n  - task:\n      must_complete: true\n      model: gpt-4.1\n      agents:\n        - seclab_taskflow_agent.personalities.c_auditer\n      user_prompt: |\n        Retrieve C code for security review from the `vulnerable_c_example`\n        memory key and perform a review.\n\n        Clear the memory cache when you're done.\n      env:\n        MEMCACHE_STATE_DIR: \"example_taskflow/\"\n        MEMCACHE_BACKEND: \"dictionary_file\"\n      toolboxes:\n        - seclab_taskflow_agent.toolboxes.memcache\n      # headless mode does not prompt for tool call confirms configured for a server\n      # note: this will auto-allow, if you want control over potentially dangerous\n      # tool calls, then you should NOT run a task in headless mode (default: false)\n      headless: true\n  - task:\n      # tasks can also run shell scripts that return e.g. json output for repeat prompt iterable\n      must_complete: true\n      run: |\n        echo '[\"apple\", \"banana\", \"orange\"]'\n  - task:\n      repeat_prompt: true\n      agents:\n        - seclab_taskflow_agent.personalities.assistant\n      user_prompt: |\n        What kind of fruit is {{ RESULT }}?\n```\n\nTaskflows support [Agent handoffs](https://openai.github.io/openai-agents-python/handoffs/). Handoffs are useful for implementing triage patterns where the primary Agent can decide to handoff a task to any subsequent Agents in the `Agents` list.\n\nSee the [taskflow examples](taskflows/examples) for other useful Taskflow patterns such as repeatable and asynchronous templated prompts.\n\n\nYou can run a taskflow from the command line like this:\n\n```\nhatch run main -t examples.taskflows.CVE-2023-2283\n```\n\n## Prompts\n\nPrompts are configured through YAML files of `filetype` `prompt`. They define a reusable prompt that can be referenced in `taskflow` files.\n\nThey contain only one field, the `prompt` field, which is used to replace any `{{ PROMPT_\u003cimport-path\u003e }}` template parameter in a taskflow. For example, the following `prompt`.\n\n```yaml\nseclab-taskflow-agent:\n  version: 1\n  filetype: prompt\n\nprompt: |\n  Tell me more about bananas as well.\n```\n\nwould replace any `{{ PROMPT_examples.prompts.example_prompt }}` template parameter found in the `user_prompt` section in a taskflow:\n\n```yaml\n  - task:\n      agents:\n        - examples.personalities.fruit_expert\n      user_prompt: |\n        Tell me more about apples.\n\n        {{ PROMPTS_examples.prompts.example_prompt }}\n```\n\nbecomes:\n\n```yaml\n  - task:\n      agents:\n        - examples.personalities.fruit_expert\n      user_prompt: |\n        Tell me more about apples.\n\n        Tell me more about bananas as well.\n```\n\n## Model configs\n\nModel configs are configured through YAML files of `filetype` `model_config`. These provide a way to configure model versions.\n\n```yaml\nseclab-taskflow-agent:\n  version: 1\n  filetype: model_config\nmodels:\n  gpt_latest: gpt-5\n```\n\nA `model_config` file can be used in a `taskflow` and the values defined in `models` can then be used throughout.\n\n```yaml\nmodel_config: examples.model_configs.model_config\n\ntaskflow:\n  - task:\n      model: gpt_latest\n```\n\nThe model version can then be updated by changing `gpt_latest` in the `model_config` file and applied across all taskflows that use the config.\n\nIn addition, model specific parameters can be provided via `model_config`. To do so, define a `model_settings` section in the `model_config` file. This section has to be a dictionary with the model names as keys:\n\n```yaml\nmodel_settings:\n  gpt_latest:\n    temperature: 1\n    reasoning:\n      effort: high\n```\n\nYou do not need to set parameters for all models defined in the `models` section. When parameters are not set for a model, they'll fall back to the default value. However, all the settings in this section must belong to one of the models specified in the `models` section, otherwise an error will raise:\n\n```yaml\nmodel_settings:\n  new_model:\n    ...\n```\n\nThe above will result in an error because `new_model` is not defined in `models` section. Model parameters can also be set per task, and any settings defined in a task will override the settings in the config.\n\n## Passing environment variables\n\nFiles of types `taskflow` and `toolbox` allow environment variables to be passed using the `env` field:\n\n```yaml\nserver_params:\n  ...\n  env:\n    CODEQL_DBS_BASE_PATH: \"{{ env CODEQL_DBS_BASE_PATH }}\"\n    # prevent git repo operations on gh codeql executions\n    GH_NO_UPDATE_NOTIFIER: \"disable\"\n```\n\nFor `toolbox`, `env` can be used inside `server_params`. A template of the form `{{ env ENV_VARIABLE_NAME }}` can be used to pass values of the environment variable from the current process to the MCP server. So in the above, the MCP server is run with `GH_NO_UPDATE_NOTIFIER=disable` and passes the value of `CODEQL_DBS_BASE_PATH` from the current process to the MCP server. The templated paramater `{{ env CODEQL_DBS_BASE_PATH }}` is replaced by the value of the environment variable `CODEQL_DBS_BASE_PATH` in the current process.\n\nSimilarly, environment variables can be passed to a `task` in a `taskflow`:\n\n```yaml\ntaskflow:\n  - task:\n      must_complete: true\n      agents:\n        - seclab_taskflow_agent.personalities.assistant\n      user_prompt: |\n        Store the json array [\"apples\", \"oranges\", \"bananas\"] in the `fruits` memory key.\n      env:\n        MEMCACHE_STATE_DIR: \"example_taskflow/\"\n        MEMCACHE_BACKEND: \"dictionary_file\"\n```\n\nThis overwrites the environment variables `MEMCACHE_STATE_DIR` and `MEMCACHE_BACKEND` for the task only. A template `{{ env ENV_VARIABLE_NAME }}` can also be used.\n\nNote that when using the template `{{ env ENV_VARIABLE_NAME }}`, `ENV_VARIABLE_NAME` must be the name of an environment variable in the current process.\n\n## Import paths\n\nYAML files often need to refer to each other. For example, a taskflow can reference a personality like this:\n\n```yaml\ntaskflow:\n  - task:\n      ...\n      agents:\n        - seclab_taskflow_agent.personalities.assistant\n```\n\nWe use Python's import system, so a name like `seclab_taskflow_agent.personalities.assistant` will get resolved to a YAML file using Python's import rules. One of the benefits of this is that it makes it easy to bundle and share taskflows as Python packages on PyPI.\n\nThe implementation works like this:\n\n1. A name like `seclab_taskflow_agent.personalities.assistant` gets split (at the last `.` character) into a package name (`seclab_taskflow_agent.personalities`) and a file name (`assistant`).\n2. Python's [`importlib.resources.files`](https://docs.python.org/3/library/importlib.resources.html#importlib.resources.files) is used to resolve the package name into a directory name.\n3. The extension `.yaml` is added to the filename: `assistant.yaml`.\n4. The yaml file is loaded from the directory that was returned by `importlib.resources.files`.\n\nThe exact code that implements this can be found in [`available_tools.py`](src/seclab_taskflow_agent/available_tools.py).\n\n## Background\n\nSecLab Taskflow Agent is an experimental agentic framework, maintained by [GitHub Security Lab](https://securitylab.github.com/). We are using it to experiment with using AI Agents for security purposes, such as auditing code for vulnerabilities, or triaging issues.\n\nWe'd love to hear your feedback. Please [create an issue](https://github.com/GitHubSecurityLab/seclab-taskflow-agent/issues/new/choose) to send us a feature request or bug report. We also welcome pull requests (see our [contribution guidelines](./CONTRIBUTING.md) for more information if you wish to contribute).\n\n\n## License\n\nThis project is licensed under the terms of the [MIT](https://spdx.org/licenses/MIT.html) license. Please refer to the [LICENSE](./LICENSE) file for the full terms.\n\n## Maintainers\n\n[CODEOWNERS](./CODEOWNERS)\n\n## Support\n\n[SUPPORT](./SUPPORT.md)\n\n## Acknowledgements\n\nSecurity Lab team members [Man Yue Mo](https://github.com/m-y-mo) and [Peter Stöckli](https://github.com/p-) for contributing heavily to the testing and development of this framework, as well as the rest of the Security Lab team for helpful discussions and feedback.\n","funding_links":[],"categories":["Tooling \u0026 Environment"],"sub_categories":["CodeQL AI \u0026 LLM Tooling"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FGitHubSecurityLab%2Fseclab-taskflow-agent","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FGitHubSecurityLab%2Fseclab-taskflow-agent","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FGitHubSecurityLab%2Fseclab-taskflow-agent/lists"}