@goplausible/algorand-mcp 3.0.7

package/dist/resources/knowledge/taxonomy/algokit:cli:features:project:deploy.md

@@ -0,0 +1,211 @@
+# AlgoKit Project Deploy
+
+Deploy your smart contracts effortlessly to various networks with the algokit project deploy feature. This feature is essential for automation in CI/CD pipelines and for seamless deployment to various Algorand network environments.
+
+> **Note**: Invoking deploy from `algokit deploy` is not recommended. Please prefer using `algokit project deploy` instead.
+
+## Usage
+
+```sh
+$ algokit project deploy [OPTIONS] [ENVIRONMENT_NAME] [EXTRA_ARGS]
+```
+
+This command deploys smart contracts from an AlgoKit compliant repository to the specified network.
+
+### Options
+
+- `--command, -C TEXT`: Specifies a custom deploy command. If this option is not provided, the deploy command will be loaded from the `.algokit.toml` file.
+- `--interactive / --non-interactive, --ci`: Enables or disables the interactive prompt for mnemonics. When the CI environment variable is set, it defaults to non-interactive.
+- `--path, -P DIRECTORY`: Specifies the project directory. If not provided, the current working directory will be used.
+- `--deployer`: Specifies the deployer alias. If not provided and if the deployer is specified in `.algokit.toml` file its mnemonic will be prompted.
+- `--dispenser`: Specifies the dispenser alias. If not provided and if the dispenser is specified in `.algokit.toml` file its mnemonic will be prompted.
+- `-p, --project-name`: (Optional) Projects to execute the command on. Defaults to all projects found in
+  the current directory. Option is mutually exclusive with `--command`.
+- `-h, --help`: Show this message and exit.
+- `[EXTRA_ARGS]...`: Additional arguments to pass to the deploy command. For instance, `algokit project deploy -- {custom args}`. This will ensure that the extra arguments are passed to the deploy command specified in the `.algokit.toml` file or directly via `--command` option.
+
+## Environment files
+
+AlgoKit `deploy` employs both a general and network-specific environment file strategy. This allows you to set environment variables that are applicable across all networks and others that are specific to a given network.
+
+The general environment file (`.env`) should be placed at the root of your project. This file will be used to load environment variables that are common across deployments to all networks.
+
+For each network you're deploying to, you can optionally have a corresponding `.env.[network_name]` file. This file should contain environment variables specific to that network. Network-specific environment variables take precedence over general environment variables.
+
+The directory layout would look like this:
+
+```md
+.
+├── ... (your project files and directories)
+├── .algokit.toml # Configuration file for AlgoKit
+├── .env # (OPTIONAL) General environment variables common across all deployments
+└── .env.[{mainnet|testnet|localnet|betanet|custom}] # (OPTIONAL) Environment variables specific to deployments to a network
+```
+
+> ⚠️ Please note that creating `.env` and `.env.[network_name]` files is only necessary if you're deploying to a custom network or if you want to override the default network configurations provided by AlgoKit. AlgoKit comes with predefined configurations for popular networks like `TestNet`, `MainNet`, `BetaNet`, or AlgoKit's `LocalNet`.
+
+The logic for loading environment variables is as follows:
+
+- If a `.env` file exists, the environment variables contained in it are loaded first.
+- If a `.env.[network_name]` file exists, the environment variables in it are loaded, overriding any previously loaded values from the `.env` file for the same variables.
+
+### Default Network Configurations
+
+The `deploy` command assumes default configurations for `mainnet`, `localnet`, and `testnet` environments. If you're deploying to one of these networks and haven't provided specific environment variables, AlgoKit will use these default values:
+
+- **Localnet**:
+
+  - `ALGOD_TOKEN`: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+  - `ALGOD_SERVER`: "http://localhost"
+  - `ALGOD_PORT`: "4001"
+  - `INDEXER_TOKEN`: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+  - `INDEXER_SERVER`: "http://localhost"
+  - `INDEXER_PORT`: "8980"
+
+- **Mainnet**:
+
+  - `ALGOD_SERVER`: "https://mainnet-api.algonode.cloud"
+  - `INDEXER_SERVER`: "https://mainnet-idx.algonode.cloud"
+
+- **Testnet**:
+  - `ALGOD_SERVER`: "https://testnet-api.algonode.cloud"
+  - `INDEXER_SERVER`: "https://testnet-idx.algonode.cloud"
+
+These default values are used when no specific `.env.[network_name]` file is present and the corresponding environment variables are not set. This feature simplifies the deployment process for these common networks, reducing the need for manual configuration in many cases.
+
+If you need to override these defaults or add additional configuration for these networks, you can still do so by creating the appropriate `.env.[network_name]` file or setting the environment variables explicitly or via generic `.env` file.
+
+## AlgoKit Configuration File
+
+AlgoKit uses a configuration file called `.algokit.toml` in the root of your project. The configuration file can be created using the `algokit init` command. This file will define the deployment commands for the various network environments that you want to target.
+
+Here's an example of what the `.algokit.toml` file might look like. When deploying it will prompt for the `DEPLOYER_MNEMONIC` secret unless it is already defined as an environment variable or is deploying to localnet.
+
+```toml
+[algokit]
+min_version = "v{lastest_version}"
+
+[project]
+
+... # project configuration and custom commands
+
+[project.deploy]
+command = "poetry run python -m smart_contracts deploy"
+environment_secrets = [
+  "DEPLOYER_MNEMONIC",
+]
+
+[project.deploy.localnet]
+environment_secrets = []
+```
+
+The `command` key under each `[project.deploy.{network_name}]` section should contain a string that represents the deployment command for that particular network. If a `command` key is not provided in a network-specific section, the command from the general `[project.deploy]` section will be used.
+
+The `environment_secrets` key should contain a list of names of environment variables that should be treated as secrets. This can be defined in the general `[project.deploy]` section, as well as in the network-specific sections. The environment-specific secrets will be added to the general secrets during deployment.
+
+The `[algokit]` section with the `min_version` key allows you to specify the minimum version of AlgoKit that the project requires.
+
+This way, you can define common deployment logic and environment secrets in the `[project.deploy]` section, and provide overrides or additions for specific environments in the `[project.deploy.{environment_name}]` sections.
+
+## Deploying to a Specific Network
+
+The command requires a `ENVIRONMENT` argument, which specifies the network environment to which the smart contracts will be deployed. Please note, the `environment` argument is case-sensitive.
+
+Example:
+
+```sh
+$ algokit project deploy testnet
+```
+
+This command deploys the smart contracts to the testnet.
+
+## Deploying to a Specific Network from a workspace with project name filter
+
+The command requires a `ENVIRONMENT` argument, which specifies the network environment to which the smart contracts will be deployed. Please note, the `environment` argument is case-sensitive.
+
+Example:
+
+Root `.algokit.toml`:
+
+```toml
+[project]
+type = "workspace"
+projects_root_dir = 'projects'
+```
+
+Contract project `.algokit.toml`:
+
+```toml
+[project]
+type = "contract"
+name = "myproject"
+
+[project.deploy]
+command = "{custom_deploy_command}"
+```
+
+```bash
+$ algokit project deploy testnet --project-name myproject
+```
+
+This command deploys the smart contracts to TestNet from a sub project named 'myproject', which is available within the current workspace. All `.env` loading logic described in [Environment files](#environment-files) is applicable, execution from the workspace root orchestrates invoking the deploy command from the working directory of each applicable sub project.
+
+## Custom Project Directory
+
+By default, the deploy command looks for the `.algokit.toml` file in the current working directory. You can specify a custom project directory using the `--project-dir` option.
+
+Example:
+
+```sh
+$ algokit project deploy testnet --project-dir="path/to/project"
+```
+
+## Custom Deploy Command
+
+You can provide a custom deploy command using the `--custom-deploy-command` option. If this option is not provided, the deploy command will be loaded from the `.algokit.toml` file.
+
+Example:
+
+```sh
+$ algokit project deploy testnet --custom-deploy-command="your-custom-command"
+```
+
+> ⚠️ Please note, chaining multiple commands with `&&` is **not** currently supported. If you need to run multiple commands, you can defer to a custom script. Refer to [run](../project/run.md#custom-command-injection) for scenarios where multiple sub-command invocations are required.
+
+## CI Mode
+
+By using the `--ci` or `--non-interactive` flag, you can skip the interactive prompt for mnemonics.
+
+This is useful in CI/CD environments where user interaction is not possible. When using this flag, you need to make sure that the mnemonics are set as environment variables.
+
+Example:
+
+```sh
+$ algokit project deploy testnet --ci
+```
+
+## Passing Extra Arguments
+
+You can pass additional arguments to the deploy command. These extra arguments will be appended to the end of the deploy command specified in your `.algokit.toml` file or to the command specified directly via `--command` option.
+
+To pass extra arguments, use `--` after the AlgoKit command and options to mark the distinction between arguments used by the CLI and arguments to be passed as extras to the deploy command/script.
+
+Example:
+
+```sh
+$ algokit project deploy testnet -- my_contract_name --some_contract_related_param
+```
+
+In this example, `my_contract_name` and `--some_contract_related_param` are extra arguments that can be utilized by the custom deploy command invocation, for instance, to filter the deployment to a specific contract or modify deployment behavior.
+
+## Example of a Full Deployment
+
+```sh
+$ algokit project deploy testnet --custom-deploy-command="your-custom-command"
+```
+
+This example shows how to deploy smart contracts to the testnet using a custom deploy command. This also assumes that .algokit.toml file is present in the current working directory, and .env.testnet file is present in the current working directory and contains the required environment variables for deploying to TestNet environment.
+
+## Further Reading
+
+For in-depth details, visit the [deploy](../../cli/index.md#deploy) section in the AlgoKit CLI reference documentation.

package/dist/resources/knowledge/taxonomy/algokit:cli:features:project:link.md

@@ -0,0 +1,67 @@
+# AlgoKit Project Link Command
+
+The `algokit project link` command is a powerful feature designed to streamline the integration between `frontend` and `contract` typed projects within the AlgoKit ecosystem. This command facilitates the automatic path resolution and invocation of [`algokit generate client`](../generate.md#1-typed-clients) on `contract` projects available in the workspace, making it easier to integrate smart contracts with frontend applications.
+
+## Usage
+
+To use the `link` command, navigate to the root directory of your standalone frontend project and execute:
+
+```sh
+$ algokit project link [OPTIONS]
+```
+
+This command must be invoked from the root of a standalone 'frontend' typed project.
+
+## Options
+
+- `--project-name`, `-p`: Specify one or more contract projects for the command. If not provided, the command defaults to all contract projects in the current workspace. This option can be repeated to specify multiple projects.
+
+- `--language`, `-l`: Set the programming language of the generated client code. The default is `typescript`, but you can specify other supported languages as well.
+
+- `--all`, `-a`: Link all contract projects with the frontend project. This option is mutually exclusive with `--project-name`.
+
+- `--fail-fast`, `-f`: Exit immediately if at least one client generation process fails. This is useful for CI/CD pipelines where you want to ensure all clients are correctly generated before proceeding.
+
+- `--version`, `-v`: Allows specifying the version of the client generator to use when generating client code for contract projects. This can be particularly useful for ensuring consistency across different environments or when a specific version of the client generator includes features or fixes that are necessary for your project.
+
+## How It Works
+
+Below is a visual representation of the `algokit project link` command in action:
+
+```mermaid
+graph LR
+    F[Frontend Project] -->|algokit generate client| C1[Contract Project 1]
+    F -->|algokit generate client| C2[Contract Project 2]
+    F -->|algokit generate client| CN[Contract Project N]
+
+    C1 -->|algokit generate client| F
+    C2 -->|algokit generate client| F
+    CN -->|algokit generate client| F
+
+    classDef frontend fill:#f9f,stroke:#333,stroke-width:4px;
+    classDef contract fill:#bbf,stroke:#333,stroke-width:2px;
+    class F frontend;
+    class C1,C2,CN contract;
+```
+
+1. **Project Type Verification**: The command first verifies that it is being executed within a standalone frontend project by checking the project's type in the `.algokit.toml` configuration file.
+
+2. **Contract Project Selection**: Based on the provided options, it selects the contract projects to link. This can be all contract projects within the workspace, a subset specified by name, or a single project selected interactively.
+
+3. **Client Code Generation**: For each selected contract project, it generates typed client code using the specified language. The generated code is placed in the frontend project's directory specified for contract clients.
+
+4. **Feedback**: The command provides feedback for each contract project it processes, indicating success or failure in generating the client code.
+
+## Example
+
+Linking all contract projects with a frontend project and generating TypeScript clients:
+
+```sh
+$ algokit project link --all -l typescript
+```
+
+This command will generate TypeScript clients for all contract projects and place them in the specified directory within the frontend project.
+
+## Further Reading
+
+To learn more about the `algokit project link` command, please refer to [link](../../cli/index.md#link) in the AlgoKit CLI reference documentation.

package/dist/resources/knowledge/taxonomy/algokit:cli:features:project:list.md

@@ -0,0 +1,43 @@
+# AlgoKit Project List Command
+
+The `algokit project list` command is designed to enumerate all projects within an AlgoKit workspace. This command is particularly useful in workspace environments where multiple projects are managed under a single root directory. It provides a straightforward way to view all the projects that are part of the workspace.
+
+## Usage
+
+To use the `list` command, execute the following **anywhere** within an AlgoKit workspace:
+
+```sh
+$ algokit project list [OPTIONS] [WORKSPACE_PATH]
+```
+
+- `WORKSPACE_PATH` is an optional argument that specifies the path to the workspace. If not provided, the current directory (`.`) is used as the default workspace path.
+
+## How It Works
+
+1. **Workspace Verification**: Initially, the command checks if the specified directory (or the current directory by default) is an AlgoKit workspace. This is determined by looking for a `.algokit.toml` configuration file and verifying if the `project.type` is set to `workspace`.
+
+2. **Project Enumeration**: If the directory is confirmed as a workspace, the command proceeds to enumerate all projects within the workspace. This is achieved by scanning the workspace's subdirectories for `.algokit.toml` files and extracting project names.
+
+3. **Output**: The names of all discovered projects are printed to the console. If the `-v` or `--verbose` option is used, additional details about each project are displayed.
+
+## Example Output
+
+```sh
+workspace: {path_to_workspace} 📁
+  - myapp ({path_to_myapp}) 📜
+  - myproject-app ({path_to_myproject_app}) 🖥️
+```
+
+## Error Handling
+
+If the command is executed in a directory that is not recognized as an AlgoKit workspace, it will issue a warning:
+
+```sh
+WARNING: No AlgoKit workspace found. Check [project.type] definition at .algokit.toml
+```
+
+This message indicates that either the current directory does not contain a `.algokit.toml` file or the `project.type` within the file is not set to `workspace`.
+
+## Further Reading
+
+To learn more about the `algokit project list` command, please refer to [list](../../cli/index.md#list) in the AlgoKit CLI reference documentation.

package/dist/resources/knowledge/taxonomy/algokit:cli:features:project:run.md

@@ -0,0 +1,184 @@
+# AlgoKit Project Run
+
+The `algokit project run` command allows defining custom commands to execute at standalone project level or being orchestrated from a workspace containing multiple standalone projects.
+
+## Usage
+
+```sh
+$ algokit project run [OPTIONS] COMMAND [ARGS]
+```
+
+This command executes a custom command defined in the `.algokit.toml` file of the current project or workspace.
+
+### Options
+
+- `-l, --list`: List all projects associated with the workspace command. (Optional)
+- `-p, --project-name`: Execute the command on specified projects. Defaults to all projects in the current directory. (Optional)
+- `-t, --type`: Limit execution to specific project types if executing from workspace. (Optional)
+- `-s, --sequential`: Execute workspace commands sequentially, for cases where you do not have a preference on the execution order, but want to disable concurrency. (Optional, defaults to concurrent)
+- `[ARGS]...`: Additional arguments to pass to the custom command. These will be appended to the end of the command specified in the `.algokit.toml` file.
+
+To get detailed help on the above options, execute:
+
+```bash
+algokit project run {name_of_your_command} --help
+```
+
+### Workspace vs Standalone Projects
+
+AlgoKit supports two main types of project structures: Workspaces and Standalone Projects. This flexibility caters to the diverse needs of developers, whether managing multiple related projects or focusing on a single application.
+
+- **Workspaces**: Ideal for complex applications comprising multiple sub-projects. Workspaces facilitate organized management of these sub-projects under a single root directory, streamlining dependency management and shared configurations.
+
+- **Standalone Projects**: Suited for simpler applications or when working on a single component. This structure offers straightforward project management, with each project residing in its own directory, independent of others.
+
+> Please note, instantiating a workspace inside a workspace (aka 'workspace nesting') is not supported and not recommended. When you want to add a new project into existing workspace make sure to run `algokit init` **from the root of the workspace**
+
+### Custom Command Injection
+
+AlgoKit enhances project automation by allowing the injection of custom commands into the `.algokit.toml` configuration file. This feature enables developers to tailor the project setup to their specific needs, automating tasks such as deploying to different network environments or integrating with CI/CD pipelines.
+
+## How It Works
+
+The orchestration between workspaces, standalone projects, and custom commands is designed to provide a seamless development experience. Below is a high-level overview of how these components interact within the AlgoKit ecosystem.
+
+```mermaid
+graph TD;
+A[AlgoKit Project] --> B["Workspace (.algokit.toml)"];
+A --> C["Standalone Project (.algokit.toml)"];
+B --> D["Sub-Project 1 (.algokit.toml)"];
+B --> E["Sub-Project 2 (.algokit.toml)"];
+C --> F["Custom Commands defined in .algokit.toml"];
+D --> F;
+E --> F;
+```
+
+- **AlgoKit Project**: The root command that encompasses all project-related functionalities.
+- **Workspace**: A root folder that is managing multiple related sub-projects.
+- **Standalone Project**: An isolated project structure for simpler applications.
+- **Custom Commands**: Commands defined by the user in the `.algokit.toml` and automatically injected into the `algokit project run` command group.
+
+### Workspace cli options
+
+Below is only visible and available when running from a workspace root.
+
+- `-l, --list`: List all projects associated with the workspace command. (Optional)
+- `-p, --project-name`: Execute the command on specified projects. Defaults to all projects in the current directory. (Optional)
+- `-t, --type`: Limit execution to specific project types if executing from workspace. (Optional)
+  To get a detailed help on the above commands execute:
+
+```bash
+algokit project run {name_of_your_command} --help
+```
+
+## Examples
+
+Assume you have a default workspace with the following structure:
+
+```bash
+my_workspace
+├── .algokit.toml
+├── projects
+│   ├── project1
+│   │   └── .algokit.toml
+│   └── project2
+│       └── .algokit.toml
+```
+
+The workspace configuration file is defined as follows:
+
+```toml
+# ... other non [project.run] related metadata
+[project]
+type = 'workspace'
+projects_root_path = 'projects'
+# ... other non [project.run] related metadata
+```
+
+Standalone configuration files are defined as follows:
+
+```toml
+# ... other non [project.run] related metadata
+
+[project]
+type = 'contract'
+name = 'project_a'
+
+[project.run]
+hello = { commands = ['echo hello'], description = 'Prints hello' }
+
+# ... other non [project.run] related metadata
+```
+
+```toml
+# ... other non [project.run] related metadata
+
+[project]
+type = 'frontend'
+name = 'project_b'
+
+[project.run]
+hello = { commands = ['echo hello'], description = 'Prints hello' }
+
+# ... other non [project.run] related metadata
+```
+
+Executing `algokit project run hello` from the root of the workspace will concurrently execute `echo hello` in both `project_a` and `project_b` directories.
+
+Executing `algokit project run hello` from the root of `project_(a|b)` will execute `echo hello` in the `project_(a|b)` directory.
+
+### Controlling Execution Order
+
+Customize the execution order of commands in workspaces for precise control:
+
+1. Define order in `.algokit.toml`:
+
+   ```yaml
+   [project]
+   type = 'workspace'
+   projects_root_path = 'projects'
+
+   [project.run]
+   hello = ['project_a', 'project_b']
+   ```
+
+2. Execution behavior:
+   - Projects are executed in the specified order
+   - Invalid project names are skipped
+   - Partial project lists: Specified projects run first, others follow
+
+> Note: Explicit order always triggers sequential execution.
+
+### Controlling Concurrency
+
+You can control whether commands are executed concurrently or sequentially:
+
+1. Use command-line options:
+
+   ```sh
+   $ algokit project run hello -s  # or --sequential
+   $ algokit project run hello -c  # or --concurrent
+   ```
+
+2. Behavior:
+   - Default: Concurrent execution
+   - Sequential: Use `-s` or `--sequential` flag
+   - Concurrent: Use `-c` or `--concurrent` flag or omit the flag (defaults to concurrent)
+
+> Note: When an explicit order is specified in `.algokit.toml`, execution is always sequential regardless of these flags.
+
+### Passing Extra Arguments
+
+You can pass additional arguments to the custom command. These extra arguments will be appended to the end of the command specified in your `.algokit.toml` file.
+
+Example:
+
+```sh
+$ algokit project run hello -- world
+```
+
+In this example, if the `hello` command in `.algokit.toml` is defined as `echo "Hello"`, the actual command executed will be `echo "Hello" world`.
+
+## Further Reading
+
+To learn more about the `algokit project run` command, please refer to [run](../../cli/index.md#run) in the AlgoKit CLI reference documentation.

package/dist/resources/knowledge/taxonomy/algokit:cli:features:tasks.md

@@ -0,0 +1,16 @@
+# AlgoKit Tasks
+
+AlgoKit Tasks are a collection of handy tasks that can be used to perform various operations on Algorand blockchain.
+
+## Features
+
+- [Wallet Aliasing](./tasks/wallet.md) - Manage your Algorand addresses and accounts effortlessly with the AlgoKit Wallet feature. This feature allows you to create short aliases for your addresses and accounts on AlgoKit CLI.
+- [Vanity Address Generation](./tasks/vanity_address.md) - Generate vanity addresses for your Algorand accounts with the AlgoKit Vanity feature. This feature allows you to generate Algorand addresses which contains a specific keyword of your choice.
+- [Transfer Assets or Algos](./tasks/transfer.md) - Transfer Algos or Assets from one account to another with the AlgoKit Transfer feature. This feature allows you to transfer Algos or Assets from one account to another on Algorand blockchain.
+- [Opt-(in|out) Assets](./tasks/opt.md) - Opt-in or opt-out of Algorand Asset(s). Supports single or multiple assets.
+- [Signing transactions](./tasks/sign.md) - Sign goal clerk compatible Algorand transactions.
+- [Sending transactions](./tasks/send.md) - Send signed goal clerk compatible Algorand transactions.
+- [NFD lookups](./tasks/nfd.md) - Perform a lookup via NFD domain or address, returning the associated address or domain respectively using the AlgoKit CLI.
+- [IPFS uploads](./tasks/ipfs.md) - Upload files to IPFS.
+- [Asset minting](./tasks/mint.md) - Mint new fungible or non-fungible assets on Algorand.
+- [Analyze TEAL code](./tasks/analyze.md) - Analyze TEAL code using [`tealer`](https://github.com/crytic/tealer) integration for common vulnerabilities.

package/dist/resources/knowledge/taxonomy/algokit:cli:features:tasks:analyze.md

@@ -0,0 +1,33 @@
+# AlgoKit Task Analyze
+
+The `analyze` task is a command-line utility that analyzes TEAL programs for common vulnerabilities using [Tealer](https://github.com/crytic/tealer) integration. It allows you to detect a range of common vulnerabilities in code written in TEAL. For full list of vulnerability detectors refer to [Tealer documentation](https://github.com/crytic/tealer?tab=readme-ov-file#detectors).
+
+## Usage
+
+```bash
+algokit task analyze INPUT_PATHS [OPTIONS]
+```
+
+### Arguments
+
+- `INPUT_PATHS`: Paths to the TEAL files or directories containing TEAL files to be analyzed. This argument is required.
+
+### Options
+
+- `-r, --recursive`: Recursively search for all TEAL files within any provided directories.
+- `--force`: Force verification without the disclaimer confirmation prompt.
+- `--diff`: Exit with a non-zero code if differences are found between current and last reports.
+- `-o, --output OUTPUT_PATH`: Directory path where to store the reports of the static analysis.
+- `-e, --exclude DETECTORS`: Exclude specific vulnerabilities from the analysis. Supports multiple exclusions in a single run.
+
+## Example
+
+```bash
+algokit task analyze ./contracts -r --exclude rekey-to --exclude missing-fee-check
+```
+
+This command will recursively analyze all TEAL files in the `contracts` directory and exclude the `missing-fee-check` vulnerability from the analysis.
+
+## Security considerations
+
+This task uses [`tealer`](https://github.com/crytic/tealer), a third-party tool, to suggest improvements for your TEAL programs, but remember to always test your smart contracts code, follow modern software engineering practices and use the [guidelines for smart contract development](https://developer.algorand.org/docs/get-details/dapps/smart-contracts/guidelines/). This should not be used as a substitute for an actual audit.

package/dist/resources/knowledge/taxonomy/algokit:cli:features:tasks:ipfs.md

@@ -0,0 +1,66 @@
+# AlgoKit Task IPFS
+
+The AlgoKit IPFS feature allows you to interact with the IPFS [InterPlanetary File System](https://ipfs.tech/) using the [Piñata provider](https://www.pinata.cloud/). This feature supports logging in and out of the Piñata provider, and uploading files to IPFS.
+
+## Usage
+
+Available commands and possible usage as follows:
+
+```bash
+$ ~ algokit task ipfs
+Usage: algokit task ipfs [OPTIONS]
+
+Upload files to IPFS using Pinata provider.
+
+Options:
+  -f, --file PATH Path to the file to upload. [required]
+  -n, --name TEXT Human readable name for this upload, for use in file listings.
+  -h, --help Show this message and exit.
+```
+
+## Options
+
+- `--file, -f PATH`: Specifies the path to the file to upload. This option is required.
+- `--name, -n TEXT`: Specifies a human readable name for this upload, for use in file listings.
+
+## Prerequisites
+
+Before you can use this feature, you need to ensure that you have signed up for a Piñata account and have a JWT. You can sign up for a Piñata account by reading [quickstart](https://docs.pinata.cloud/docs/getting-started).
+
+## Login
+
+Please note, you need to login to the Piñata provider before you can upload files. You can do this using the `login` command:
+
+```bash
+$ algokit task ipfs login
+```
+
+This will prompt you to enter your Piñata JWT. Once you are logged in, you can upload files to IPFS.
+
+## Upload
+
+To upload a file to IPFS, you can use the `ipfs` command as follows:
+
+```bash
+$ algokit task ipfs --file {PATH_TO_YOUR_FILE}
+```
+
+This will upload the file to IPFS using the Piñata provider and return the CID (Content Identifier) of the uploaded file.
+
+## Logout
+
+If you want to logout from the Piñata provider, you can use the `logout` command:
+
+```bash
+$ algokit task ipfs logout
+```
+
+This will remove your Piñata JWT from the keyring.
+
+## File Size Limit
+
+Please note, the maximum file size that can be uploaded is 100MB. If you try to upload a file larger than this, you will receive an error.
+
+## Further Reading
+
+For in-depth details, visit the [ipfs section](../../cli/index.md#ipfs) in the AlgoKit CLI reference documentation.