Meeting notes — 24 August 2026

Field	Value
Document status	Published
Meeting date	24 August 2026
Redmine project	Weekly Discussion & Updates (weekly-discussion-updates, id 30)
Redmine ticket	https://redmine.teamteki.com/issues/156
Instance	https://redmine.teamteki.com/

Topics: Cursor Rules and Skills, Buddy Chatbot, and raising a ticket in Redmine.

Sources: Cursor Rules, Cursor Skills, Redmine issues, and this Redmine instance (24 August 2026).

---

1. How to use Rules and Skills in Cursor

1.1 Explanation: what Rules are

Rules are system-level instructions for Cursor Agent. When a rule applies, it is added at the start of the model context so the agent follows the same conventions every time.

Type	Where it lives	Scope
Project rules	.cursor/rules/*.mdc	This repository
User rules	Customize → Rules	All of your projects
Team rules	Cursor dashboard (Team and Enterprise)	The whole organisation
AGENTS.md	AGENTS.md in the project or a subdirectory	Simple markdown alternative to .cursor/rules

Rules apply to Agent (Chat). They do not apply to Cursor Tab or Inline Edit (Cmd/Ctrl+K).

1.2 Explanation: what Skills are

Skills are reusable instructions for a specific, often multi-step, task. Each skill is a folder with a SKILL.md file. Cursor shows the agent the skill name and description, and loads the full instructions only when the skill is relevant or you invoke it.

1.3 Explanation: when to use Rules or Skills

Topic	Rules	Skills
Purpose	Short guidelines and standing constraints	Multi-step workflows
How applied	Included in matching conversations	/skill-name, @skill-name, or auto-selected from the description

Use a rule when a short instruction should stay in force. Use a skill when the agent needs a repeatable procedure. Convert a long, step-by-step rule with /create-skill or /migrate-to-skills.

Keep rules short (under 500 lines), split large ones, and add a rule only when the agent repeats the same mistake.

To choose between them:

1. Standing constraint (“always use X”, “never edit Y”) → Rule
2. Procedure with several steps → Skill
3. Needed in every chat → Rule with alwaysApply true (keep it short)
4. Only for certain files → Rule globs or skill paths
5. Human opt-in each time → Manual rule or skill with disable-model-invocation true

1.4 Procedure: create and apply a project rule

1. In Agent chat, type /create-rule and describe the rule.
2. Review the .mdc file under .cursor/rules/.
3. Or open Customize → Rules → Add Rule and set Always, Intelligently, Specific files, or Manual.
4. Commit the file.

To apply a manual rule, type @ in chat and select it. Team rules (Team/Enterprise) are created in the Cursor dashboard. When guidance conflicts, official precedence is Team Rules → Project Rules → User Rules.

1.5 Procedure: create and apply a skill

1. In Agent chat, type /create-skill and describe the workflow.
2. Review .cursor/skills/<skill-name>/SKILL.md, or create that file by hand.
3. Commit the skill folder.

Run a skill with / plus the skill name, or attach it with @. Agent may also apply it from the description unless disable-model-invocation is true. /migrate-to-skills converts eligible dynamic rules and slash commands. Rules with alwaysApply true or with globs are not migrated.

1.6 Best practice: Rules and Skills

• Write rules as concrete instructions, not vague advice.
• Put long procedures in skills, not in always-on rules.
• Write skill descriptions so the agent can tell when to load them.
• Commit rules and skills to git. Update the rule when the agent repeats a mistake.

---

2. Buddy Chatbot use case

2.1 Explanation: what was requested

The meeting outline asked this documentation to cover the Buddy chatbot use case, purpose, workflow, key functionality, and examples.

2.2 Explanation: what can be stated

A topic named Buddy Chatbot was on the 24 August 2026 agenda. It was described as a use case, and a demonstration of purpose, workflow, and functionality was expected.

No product URL, repository, screenshots, transcript, or workflow notes were included in the source materials, so those details are not documented here.

---

3. How to raise a ticket in Redmine

These steps apply to https://redmine.teamteki.com/ and project Weekly Discussion & Updates.

3.1 Explanation: what a ticket is

In Redmine, work is an issue (ticket). It belongs to a project and has a tracker, status, priority, optional assignee, and description. Updates go in the journal. Watchers are notified of changes.

This project has Issue tracking enabled. At inspection it had no issue categories and no versions.

3.2 Procedure: create a ticket in the UI

1. Sign in at https://redmine.teamteki.com/
2. Open Weekly Discussion & Updates: https://redmine.teamteki.com/projects/weekly-discussion-updates
3. Issues → New issue: https://redmine.teamteki.com/projects/weekly-discussion-updates/issues/new
4. Select a Tracker.
5. Enter a specific Subject and a Description (Textile: h1. / h2. headings and *bold*).
6. Set Priority, Assignee, and dates if known. Leave Category and Target version empty unless those lists are added later.
7. Attach files and add Watchers if needed, then Save.

You need the permission Issue tracking → Add issues. If a field is missing, the tracker or your role is hiding it.

3.3 Reference: required and standard fields

Subject and Tracker are required.

Field	Notes on this instance
Tracker	See trackers below
Subject	Required
Description	Textile
Status	Default depends on tracker
Priority	Default is Normal
Assignee	A project member
Parent task	For subtasks
Start date / Due date	Optional
Estimated time	Optional, hours
% Done	0–100
Category	None configured
Target version	None configured
Files	Optional
Watchers	Optional

Trackers:

Tracker	id	Instance description	Default status
Bug	1	For reporting bugs	Default
Feature	2	New functionality request	New
Improvement	3	Enhancement of existing feature	New
Task	4	General work task	New
Support	5	Support or help request	New
development	6	No description set	Default

Statuses: Default (1), New (8), In Progress (9), Resolved (10), Feedback (11), Closed (12, closed), Rejected (13, closed).

Priorities: Low (2), Urgent (3), High (4), Normal (5, default).

Pick the tracker that matches the work. Use Normal priority unless the work is blocking (High / Urgent) or backlog (Low).

3.4 Procedure: assign, prioritize, categorize, and track

Assign: Update the issue, set Assignee to a project member, Save. Assignees must be project members. Watchers can be added without being the assignee.

Prioritize: Set Priority when creating or updating. Use Due date for deadlines. There is no separate severity field on these trackers.

Categorize: Use Tracker (Bug, Feature, Improvement, Task, Support, development). Issue categories and Target version are not configured on this project.

Track: Move Status New → In Progress → Resolved → Closed (Feedback if changes are needed; Rejected if invalid). Add journal notes. Related issues follow standard Redmine (duplicates close together; a blocked issue cannot close while the blocker is open). Time tracking is enabled. Filter the issues list by tracker, status, assignee, or parent task.

Subtasks: Add a subtask from the parent, or set Parent task on the child.

3.5 Best practice: tickets on this instance

• One concern per ticket when work will be assigned separately.
• Put reproduction steps in Bug tickets; put the desired behaviour in Feature or Improvement tickets.
• Assign someone if action is expected.
• Do not invent categories or versions; this project had none at inspection.
• Update status instead of duplicating the same work.
• Keep secrets out of ticket descriptions and attachments.