docs: skills (#6062)
This commit is contained in:
dianed-square
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"label": "Context Engineering",
|
||||
"position": 3,
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "guides/context-engineering/index"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Context Engineering
|
||||
hide_title: true
|
||||
description: Provide goose with the knowledge, preferences, and workflows it needs to work effectively
|
||||
---
|
||||
|
||||
import Card from '@site/src/components/Card';
|
||||
import styles from '@site/src/components/Card/styles.module.css';
|
||||
|
||||
<h1 className={styles.pageTitle}>Context Engineering</h1>
|
||||
<p className={styles.pageDescription}>
|
||||
Context engineering is about building background knowledge, preferences, and workflows that help goose work more effectively. Instead of repeating instructions, you define them once and teach goose how you work.
|
||||
</p>
|
||||
|
||||
<div className={styles.categorySection}>
|
||||
<h2 className={styles.categoryTitle}>📚 Documentation & Guides</h2>
|
||||
<div className={styles.cardGrid}>
|
||||
<Card
|
||||
title="Using goosehints"
|
||||
description="Use AGENTS.md, .goosehints, and other files to provide project context, preferences, and instructions that goose loads automatically."
|
||||
link="/docs/guides/context-engineering/using-goosehints"
|
||||
/>
|
||||
<Card
|
||||
title="Using Skills"
|
||||
description="Create reusable instruction sets containing workflows, scripts, and other resources that goose can load on demand."
|
||||
link="/docs/guides/context-engineering/using-skills"
|
||||
/>
|
||||
<Card
|
||||
title="Memory Extension"
|
||||
description="Teach goose persistent knowledge it can recall across sessions. Save commands, code snippets, and preferences for consistent assistance."
|
||||
link="/docs/mcp/memory-mcp"
|
||||
/>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div className={styles.categorySection}>
|
||||
<h2 className={styles.categoryTitle}>📝 Featured Blog Posts</h2>
|
||||
<div className={styles.cardGrid}>
|
||||
<Card
|
||||
title="What's in my .goosehints file"
|
||||
description="A deep dive into .goosehints vs Memory Extension, and how to optimize your goose configuration for better performance."
|
||||
link="/blog/2025/06/05/whats-in-my-goosehints-file"
|
||||
/>
|
||||
<Card
|
||||
title="Stop Your AI Agent From Making Unwanted Changes"
|
||||
description="Teach your AI agent how to commit early and often so you can control changes and roll back safely."
|
||||
link="/blog/2025/12/10/stop-ai-agent-unwanted-changes"
|
||||
/>
|
||||
<Card
|
||||
title="The AI Skeptic's Guide to Context Windows"
|
||||
description="Why do AI agents forget? Learn how context windows, tokens, and goose help you manage memory and long conversations."
|
||||
link="/blog/2025/08/18/understanding-context-windows"
|
||||
/>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,240 @@
|
||||
---
|
||||
title: Providing Hints to goose
|
||||
sidebar_position: 1
|
||||
sidebar_label: Using goosehints
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
import { PanelLeft } from 'lucide-react';
|
||||
|
||||
`.goosehints` is a text file used to provide additional context about your project and improve the communication with goose. The use of `.goosehints` ensures that goose understands your requirements better and can execute tasks more effectively.
|
||||
|
||||
<details>
|
||||
<summary>goose Hints Video Walkthrough</summary>
|
||||
<iframe
|
||||
class="aspect-ratio"
|
||||
src="https://www.youtube.com/embed/kWXJC5p0608"
|
||||
title="goose Hints"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
</details>
|
||||
|
||||
A good time to consider adding a `.goosehints` file is when you find yourself repeating prompts, or providing the same kind of instructions multiple times. It's also a great way to provide a lot of context which might be better suited in a file.
|
||||
|
||||
This guide will walk you through creating and using `.goosehints` files to streamline your workflow with custom instructions and context.
|
||||
|
||||
:::info Developer extension required
|
||||
To make use of the hints file, you need to have the `Developer` extension [enabled](/docs/getting-started/using-extensions).
|
||||
:::
|
||||
|
||||
## Creating Your Hints File
|
||||
|
||||
goose supports two types of hint files:
|
||||
- **Global hints file** - These hints will apply to all your sessions with goose, regardless of directory. Global hints are stored in `~/.config/goose/.goosehints`.
|
||||
- **Local hints files** - These hints will only apply when working in a specific directory or directory hierarchy.
|
||||
|
||||
You can use both global and local hints at the same time. When both exist, goose will consider both your global preferences and project-specific requirements. If the instructions in your local hints file conflict with your global preferences, goose will prioritize the local hints.
|
||||
|
||||
:::tip Custom Context Files
|
||||
You can use other agent rule files with goose by using the [`CONTEXT_FILE_NAMES` environment variable](#custom-context-files).
|
||||
:::
|
||||
|
||||
<Tabs groupId="interface">
|
||||
<TabItem value="ui" label="goose Desktop" default>
|
||||
|
||||
#### Global hints file
|
||||
1. Create a `.goosehints` file in `~/.config/goose`
|
||||
|
||||
#### Local hints file
|
||||
|
||||
1. Click the directory path at the bottom of the app and open the directory where you want to create the file
|
||||
2. Click the <PanelLeft className="inline" size={16} /> button in the top-left to open the sidebar
|
||||
3. Click `Settings` in the sidebar
|
||||
4. Click `Chat`
|
||||
5. Scroll down to the `Project Hints (.goosehints)` section and click `Configure`
|
||||
6. Enter your local hints in the text area
|
||||
7. Click `Save`
|
||||
8. Restart your session so goose can read the updated `.goosehints`
|
||||
|
||||
If a `.goosehints` file already exists in the given directory, you can edit your existing hints.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="manual" label="Manual">
|
||||
|
||||
- **Global hints file** - Create a `.goosehints` file in `~/.config/goose`.
|
||||
- **Local hints file** - Create a `.goosehints` file at the root of your project and/or in any directory in the hierarchy.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
The `.goosehints` file can include any instructions or contextual details relevant to your projects.
|
||||
|
||||
## Setting Up Hints
|
||||
|
||||
The `.goosehints` file supports natural language. Write clear, specific instructions using direct language that goose can easily understand and follow. Include relevant context about your project and workflow preferences, and prioritize your most important guidelines first.
|
||||
|
||||
goosehints are loaded at the start of your session and become part of the system prompt sent with every request. This means the content of `.goosehints` contributes to token usage, so keeping it concise can save both cost and processing time.
|
||||
|
||||
### Example Global `.goosehints` File
|
||||
|
||||
```
|
||||
Always use TypeScript for new Next.js projects.
|
||||
|
||||
@coding-standards.md # Contains our coding standards
|
||||
docs/contributing.md # Contains our pull request process
|
||||
|
||||
Follow the [Google Style Guide](https://google.github.io/styleguide/pyguide.html) for Python code.
|
||||
|
||||
Run unit tests before committing any changes.
|
||||
|
||||
Prefer functional programming patterns where applicable.
|
||||
```
|
||||
|
||||
### Example Local `.goosehints` File
|
||||
|
||||
```
|
||||
This is a simple example JavaScript web application that uses the Express.js framework. View [Express documentation](https://expressjs.com/) for extended guidance.
|
||||
|
||||
Go through the @README.md for information on how to build and test it as needed.
|
||||
|
||||
Make sure to confirm all changes with me before applying.
|
||||
|
||||
Run tests with `npm run test` ideally after each change.
|
||||
```
|
||||
|
||||
These examples show two ways to reference other files:
|
||||
- **`@` syntax**: Automatically includes the file content in goose's immediate context
|
||||
- **Plain reference**: Points goose to files to review when needed (use for optional or very large files)
|
||||
|
||||
### Nested `.goosehints` Files
|
||||
|
||||
goose supports hierarchical local hints in git repositories. All `.goosehints` files from your current directory up to the root directory are automatically loaded and combined. If you're not working in a git repository, goose only loads the `.goosehints` file from the current directory.
|
||||
|
||||
As a best practice, `.goosehints` at each level should only include hints relevant to that scope:
|
||||
- **Root level**: Include project-wide standards, build processes, and general guidelines
|
||||
- **Module/feature level**: Add specific requirements for that area of the codebase
|
||||
- **Directory level**: Include very specific context like local testing procedures or component patterns
|
||||
|
||||
**Example Project Structure:**
|
||||
```sh
|
||||
my-project/
|
||||
├── .git/
|
||||
├── .goosehints # Project-wide hints
|
||||
├── frontend/
|
||||
│ ├── .goosehints # Frontend-specific hints
|
||||
│ └── components/
|
||||
│ ├── .goosehints # Component-specific hints
|
||||
│ └── Button.tsx
|
||||
└── backend/
|
||||
├── .goosehints # Backend-specific hints
|
||||
└── api/
|
||||
└── routes.py
|
||||
```
|
||||
|
||||
When working in `frontend/components/` in this example project, goose loads hints from directories higher up the hierarchy in the following order:
|
||||
1. <details>
|
||||
<summary>`my-project/.goosehints` (project root)</summary>
|
||||
```
|
||||
This is a React + TypeScript project using Vite.
|
||||
|
||||
@README.md # Project overview and setup instructions
|
||||
@docs/development-setup.md # Development environment configuration
|
||||
|
||||
Always run tests before committing: `npm test`
|
||||
Use conventional commits for all changes.
|
||||
```
|
||||
</details>
|
||||
2. <details>
|
||||
<summary>`frontend/.goosehints`</summary>
|
||||
```
|
||||
This frontend uses React 18 with TypeScript and Tailwind CSS.
|
||||
|
||||
@package.json # Dependencies and scripts
|
||||
@docs/frontend-architecture.md # Frontend structure and patterns
|
||||
|
||||
## Development Standards
|
||||
- Use functional components with hooks (no class components)
|
||||
- Implement proper TypeScript interfaces for all props
|
||||
- Follow the component structure: /components/ComponentName/index.tsx
|
||||
- Use Tailwind classes instead of custom CSS when possible
|
||||
|
||||
## Testing Requirements
|
||||
- Write unit tests for all components using React Testing Library
|
||||
- Test files should be co-located: ComponentName.test.tsx
|
||||
- Run `npm run test:frontend` before committing changes
|
||||
|
||||
## State Management
|
||||
- Use React Query for server state
|
||||
- Use Zustand for client state management
|
||||
- Avoid prop drilling - lift state appropriately
|
||||
|
||||
Always confirm UI changes with design team before implementation.
|
||||
```
|
||||
</details>
|
||||
3. <details>
|
||||
<summary>`frontend/components/.goosehints` (current directory)</summary>
|
||||
```
|
||||
Components in this directory use our design system.
|
||||
|
||||
@docs/component-api.md # Component interface standards and examples
|
||||
|
||||
All components must:
|
||||
- Export a default component
|
||||
- Include TypeScript props interface
|
||||
- Have corresponding .test.tsx file
|
||||
- Follow naming convention: PascalCase
|
||||
```
|
||||
</details>
|
||||
|
||||
## Common Use Cases
|
||||
Here are some ways people have used hints to provide additional context to goose:
|
||||
|
||||
- **Decision-Making**: Specify if goose should autonomously make changes or confirm actions with you first.
|
||||
|
||||
- **Validation Routines**: Provide test cases or validation methods that goose should perform to ensure changes meet project specifications.
|
||||
|
||||
- **Feedback Loop**: Include steps that allow goose to receive feedback and iteratively improve its suggestions.
|
||||
|
||||
- **Point to more detailed documentation**: Indicate important files like `README.md`, `docs/setup-guide.md`, or others that goose should consult for detailed explanations.
|
||||
|
||||
- **Organize with @-mentions**: For frequently-needed documentation, use `@filename.md` or `@relative/path/testing.md` to automatically include file content in your current context instead of just referencing it. This ensures goose has immediate access to important information.
|
||||
Include core documentation (like API schemas or coding standards) with @-mentions for immediate context, but use plain references (without `@`) for optional or very large files.
|
||||
|
||||
Like prompts, this is not an extensive list to shape your `.goosehints` file. You can include as much context as you need.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Keep files updated**: Regularly update the `.goosehints` files to reflect any changes in project protocols or priorities.
|
||||
- **Be concise**: Make sure the content is straightforward and to the point, ensuring goose can quickly parse and act on the information.
|
||||
- **Start small**: Create a small set of clear, specific hints and gradually expand them based on your needs. This makes it easier to understand how goose interprets and applies your instructions.
|
||||
- **Reference other files**: Point goose to relevant files like /docs/style.md or /scripts/validation.js to reduce repetition and keep instructions lightweight.
|
||||
|
||||
## Custom Context Files
|
||||
|
||||
goose looks for `AGENTS.md` then `.goosehints` files by default, but you can configure a different filename or multiple context files using the `CONTEXT_FILE_NAMES` environment variable. This is useful for:
|
||||
|
||||
- **Tool compatibility**: Use conventions from other AI tools (e.g. `CLAUDE.md`)
|
||||
- **Organization**: Separate frequently-used rules into multiple files that load automatically
|
||||
- **Project conventions**: Use context files from your project's established toolchain (`.cursorrules`)
|
||||
|
||||
Here's how it works:
|
||||
1. goose looks for each configured filename in both global (~/.config/goose/) and local (current directory) locations
|
||||
2. All found files are loaded and combined into the context
|
||||
|
||||
### Configuration
|
||||
|
||||
Set the `CONTEXT_FILE_NAMES` environment variable to a JSON array of filenames. The default is `["AGENTS.md", ".goosehints"]`.
|
||||
|
||||
```bash
|
||||
# Single custom file
|
||||
export CONTEXT_FILE_NAMES='["AGENTS.md"]'
|
||||
|
||||
# Project toolchain files
|
||||
export CONTEXT_FILE_NAMES='[".cursorrules", "AGENTS.md"]'
|
||||
|
||||
# Multiple files
|
||||
export CONTEXT_FILE_NAMES='["CLAUDE.md", ".goosehints", "project_rules.txt"]'
|
||||
```
|
||||
@@ -0,0 +1,266 @@
|
||||
---
|
||||
title: Using Skills
|
||||
sidebar_position: 2
|
||||
sidebar_label: Using Skills
|
||||
---
|
||||
|
||||
Skills are reusable sets of instructions and resources that teach goose how to perform specific tasks. A skill can range from a simple checklist to a detailed workflow with domain expertise, and can include supporting files like scripts or templates. Example use cases include deployment procedures, code review checklists, and API integration guides.
|
||||
|
||||
:::info
|
||||
This functionality requires the built-in [Skills extension](/docs/mcp/skills-mcp) to be enabled (it's enabled by default).
|
||||
:::
|
||||
|
||||
When a session starts, goose adds any skills that it discovers to its instructions. During the session, goose automatically loads a skill when:
|
||||
- Your request clearly matches a skill's purpose
|
||||
- You explicitly ask to use a skill, for example:
|
||||
- "Use the code-review skill to review this PR"
|
||||
- "Follow the new-service skill to set up the auth service"
|
||||
- "Apply the deployment skill"
|
||||
|
||||
You can also ask goose what skills are available.
|
||||
|
||||
:::tip Other goose features that support reuse
|
||||
- [.goosehints](/docs/guides/context-engineering/using-goosehints): Best for general preferences, project context, and repeated instructions like "Always use TypeScript"
|
||||
- [recipes](/docs/guides/recipes/session-recipes): Shareable configurations that package instructions, prompts, and settings together
|
||||
:::
|
||||
|
||||
## Claude Compatibility
|
||||
|
||||
goose skills use the same format as Claude Desktop skills. goose discovers skills from both `.claude/skills/` and `.goose/skills/` directories, so you can share skills between both tools or create tool-specific versions as needed.
|
||||
|
||||
When the same skill name exists in multiple directories, goose follows the priority order listed in [Skill Locations](#skill-locations). Later directories override earlier ones regardless of whether they're `.claude` or `.goose` directories.
|
||||
|
||||
## Creating a Skill
|
||||
|
||||
Create a skill when you have a repeatable workflow that involves multiple steps, specialized knowledge, or supporting files.
|
||||
|
||||
### Skill Locations
|
||||
|
||||
Skills can be stored globally and/or per-project. goose checks all of these directories in order and combines what it finds. If the same skill name exists in multiple directories, the latest directory takes priority:
|
||||
|
||||
1. `~/.claude/skills/` — Global, shared with Claude Desktop
|
||||
2. `~/.config/goose/skills/` — Global, goose-specific
|
||||
3. `./.claude/skills/` — Current directory, shared with Claude Desktop
|
||||
4. `./.goose/skills/` — Current directory, goose-specific (highest priority)
|
||||
|
||||
Use global skills for workflows you use across projects. Use project-specific skills for procedures unique to a codebase.
|
||||
|
||||
### Skill File Structure
|
||||
|
||||
Each skill lives in its own directory with a `SKILL.md` file:
|
||||
|
||||
```
|
||||
~/.config/goose/skills/
|
||||
└── code-review/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
A `SKILL.md` file requires YAML frontmatter with `name` and `description`, followed by the skill content:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: code-review
|
||||
description: Comprehensive code review checklist for pull requests
|
||||
---
|
||||
|
||||
# Code Review Checklist
|
||||
|
||||
When reviewing code, check each of these areas:
|
||||
|
||||
## Functionality
|
||||
- [ ] Code does what the PR description claims
|
||||
- [ ] Edge cases are handled
|
||||
- [ ] Error handling is appropriate
|
||||
|
||||
## Code Quality
|
||||
- [ ] Follows project style guide
|
||||
- [ ] No hardcoded values that should be configurable
|
||||
- [ ] Functions are focused and well-named
|
||||
|
||||
## Testing
|
||||
- [ ] New functionality has tests
|
||||
- [ ] Tests are meaningful, not just for coverage
|
||||
- [ ] Existing tests still pass
|
||||
|
||||
## Security
|
||||
- [ ] No credentials or secrets in code
|
||||
- [ ] User input is validated
|
||||
- [ ] SQL queries are parameterized
|
||||
```
|
||||
|
||||
### Supporting Files
|
||||
|
||||
Skills can include supporting files like scripts, templates, or configuration files. Place them in the skill directory:
|
||||
|
||||
```
|
||||
~/.config/goose/skills/
|
||||
└── api-setup/
|
||||
├── SKILL.md
|
||||
├── setup.sh
|
||||
└── templates/
|
||||
└── config.template.json
|
||||
```
|
||||
|
||||
When goose loads the skill, it sees the supporting files and can access them using the [Developer extension's](/docs/mcp/developer-mcp) file tools.
|
||||
|
||||
<details>
|
||||
<summary>Example Skill with Supporting Files</summary>
|
||||
|
||||
**SKILL.md:**
|
||||
```markdown
|
||||
---
|
||||
name: api-setup
|
||||
description: Set up API integration with configuration and helper scripts
|
||||
---
|
||||
|
||||
# API Setup
|
||||
|
||||
This skill helps you set up a new API integration with our standard configuration.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Run `setup.sh <api-name>` to create the integration directory
|
||||
2. Copy `templates/config.template.json` to your integration directory
|
||||
3. Update the config with your API credentials
|
||||
4. Test the connection
|
||||
|
||||
## Configuration
|
||||
|
||||
The config template includes:
|
||||
- `api_key`: Your API key (get from the provider's dashboard)
|
||||
- `endpoint`: API endpoint URL
|
||||
- `timeout`: Request timeout in seconds (default: 30)
|
||||
|
||||
## Verification
|
||||
|
||||
After setup, verify:
|
||||
- [ ] Config file is valid JSON
|
||||
- [ ] API key is set and not a placeholder
|
||||
- [ ] Test connection succeeds
|
||||
```
|
||||
|
||||
**setup.sh:**
|
||||
```bash
|
||||
#!/bin/bash
|
||||
API_NAME=$1
|
||||
mkdir -p "integrations/$API_NAME"
|
||||
cp templates/config.template.json "integrations/$API_NAME/config.json"
|
||||
echo "Created integration directory for $API_NAME"
|
||||
echo "Edit integrations/$API_NAME/config.json with your credentials"
|
||||
```
|
||||
|
||||
**templates/config.template.json:**
|
||||
```json
|
||||
{
|
||||
"api_key": "YOUR_API_KEY_HERE",
|
||||
"endpoint": "https://api.example.com/v1",
|
||||
"timeout": 30,
|
||||
"retry_attempts": 3
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Common Use Case Examples
|
||||
|
||||
<details>
|
||||
<summary>Deployment Workflow</summary>
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: production-deploy
|
||||
description: Safe deployment procedure for production environment
|
||||
---
|
||||
|
||||
# Production Deployment
|
||||
|
||||
## Pre-deployment
|
||||
1. Ensure all tests pass
|
||||
2. Get approval from at least 2 reviewers
|
||||
3. Notify #deployments channel
|
||||
|
||||
## Deploy
|
||||
1. Create release branch from main
|
||||
2. Run `npm run build:prod`
|
||||
3. Deploy to staging, verify, then production
|
||||
4. Monitor error rates for 30 minutes
|
||||
|
||||
## Rollback
|
||||
If error rate exceeds 1%:
|
||||
1. Revert to previous deployment
|
||||
2. Notify #incidents channel
|
||||
3. Create incident report
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Testing Strategy</summary>
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: testing-strategy
|
||||
description: Guidelines for writing effective tests in this project
|
||||
---
|
||||
|
||||
# Testing Guidelines
|
||||
|
||||
## Unit Tests
|
||||
- Test one thing per test
|
||||
- Use descriptive test names: `test_user_creation_fails_with_invalid_email`
|
||||
- Mock external dependencies
|
||||
|
||||
## Integration Tests
|
||||
- Test API endpoints with realistic data
|
||||
- Verify database state changes
|
||||
- Clean up test data after each test
|
||||
|
||||
## Running Tests
|
||||
- `npm test` — Run all tests
|
||||
- `npm test:unit` — Unit tests only
|
||||
- `npm test:integration` — Integration tests (requires database)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>API Integration Guide</summary>
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: square-integration
|
||||
description: How to integrate with our Square account
|
||||
---
|
||||
|
||||
# Square Integration
|
||||
|
||||
## Authentication
|
||||
- Test key: Use `SQUARE_TEST_KEY` from `.env.test`
|
||||
- Production key: In 1Password under "Square Production"
|
||||
|
||||
## Common Operations
|
||||
|
||||
### Create a customer
|
||||
```javascript
|
||||
const customer = await squareup.customers.create({
|
||||
email: user.email,
|
||||
metadata: { userId: user.id }
|
||||
});
|
||||
```
|
||||
|
||||
### Handle webhooks
|
||||
Always verify webhook signatures. See `src/webhooks/square.js` for our handler pattern.
|
||||
|
||||
## Error Handling
|
||||
- `card_declined`: Show user-friendly message, suggest different payment method
|
||||
- `rate_limit`: Implement exponential backoff
|
||||
- `invalid_request`: Log full error, likely a bug in our code
|
||||
````
|
||||
|
||||
</details>
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Keep skills focused** — One skill per workflow or domain. If a skill is getting long, consider splitting it.
|
||||
- **Write for clarity** — Skills are instructions for goose. Use clear, direct language and numbered steps.
|
||||
- **Include verification steps** — Help goose confirm the workflow completed successfully.
|
||||
Reference in New Issue
Block a user