Task #156
Updated by Ayush Sharma on 08/24/2026 10:19 AM
h1. Meeting notes — 24 August 2026 |_. Field|_. Value| |Document status|For senior review| |Meeting date|24 August 2026| |Redmine project|Weekly *Project:* Weekly Discussion & Updates (@weekly-discussion-updates@, id 30)| |Redmine ticket|https://redmine.teamteki.com/issues/156| |Instance|https://redmine.teamteki.com/| |Prepared for|Senior verification| p. This document is written so a reviewer *Instance:* https://redmine.teamteki.com/ *Project identifier:* @weekly-discussion-updates@ *Audience:* Anyone who did not attend can check each statement. Every section is either *official documentation*, *instance-verified*, or *not provided*. Nothing the meeting and needs to apply the topics independently h2. Topics covered # How to use Rules and Skills in this file is Cursor # Buddy Chatbot use case # How to raise a substitute for a meeting transcript. ticket in Redmine h2. How to read this document Sections are labelled so explanations, procedures, examples, and guidance stay distinct: |_. Label|_. Meaning| |Explanation|What |*Explanation*|What something is| is and why it exists| |Procedure|Step-by-step |*Procedure*|Step-by-step instructions| |Example|A |*Example*|A concrete snippet| snippet or scenario| |Best practice|Guidance copied |*Best practice*|Recommended usage from official docs, docs or a cautious instance note| this Redmine instance| |Official documentation|Taken from the cited Cursor or Redmine pages, |*Not provided*|Requested meeting detail that was not from spoken minutes| |Instance-verified|Read from https://redmine.teamteki.com/ via REST API on 24 August 2026| |Not provided|Requested or expected from in the meeting, but absent from the source materials| p. Sources used: *Sources used* * Cursor Rules: https://cursor.com/docs/context/rules * Cursor Skills: https://cursor.com/docs/skills and https://cursor.com/help/customization/skills * Redmine issue tracking: https://www.redmine.org/projects/redmine/wiki/RedmineIssues * Teamteki Redmine project 30 field lists, retrieved instance fields, inspected 24 August 2026 via the REST API (project id @30@) p. No meeting transcript, slides, or screenshots were provided. Team Meeting-specific team conventions that were not written down are marked *Not provided*. They are not provided* rather than guessed. --- h2. h1. 1. How to use Rules and Skills in Cursor p. This section is *official documentation*. It is not minutes of what was said in the meeting. Product behaviour should be checked against the cited Cursor pages if a reviewer needs to confirm a detail after a Cursor version change. h3. h2. 1.1 Explanation: Explanation — what Rules are p. Rules are system-level instructions *system-level instructions* given to Cursor Agent. They are persistent, reusable context. When a rule applies, its contents are context that is included at the start of the model context. context when a rule applies. p. Large language models do not retain memory between completions. Rules exist so the agent receives gets the same guidance each every time: how to generate code, how to interpret edits, and which project conventions to follow. p. Cursor supports four kinds of rules: |_. Type|_. Where it lives|_. Scope| |Project rules|@.cursor/rules/*.mdc@ |*Project rules*|@.cursor/rules/*.mdc@ in the repository|This codebase; version-controlled with git| |User rules|Customize |*User rules*|Customize → Rules in the Cursor UI|Your Cursor environment, all projects| |Team rules|Cursor |*Team rules*|Cursor dashboard (Team and Enterprise plans)|Entire organization; can be enforced| |AGENTS.md|@AGENTS.md@ |*AGENTS.md*|@AGENTS.md@ at the project root or in subdirectories|Simple markdown alternative to @.cursor/rules@| p. When applied, rule contents are prepended to the prompt. They do not *not* affect Cursor Tab or other non-Agent AI features. User rules apply to Agent (Chat) only. They do only, not apply to Inline Edit (Cmd/Ctrl+K). h3. h2. 1.2 Explanation: Explanation — what Skills are p. Skills are reusable *reusable packages of instructions instructions* that teach Agent how to perform a specific, often multi-step, task. They follow the Agent Skills open standard. p. A skill is a folder that contains a @SKILL.md@ file. It may also contain file (and optionally scripts, reference docs, and assets. assets). Cursor discovers skills at startup. The agent sees each skill’s name *name and description, description*, then loads the full body only when the skill is relevant or when you invoke it. p. Skills are: * Portable *Portable* — they work with agents that support the Agent Skills standard * Version-controlled *Version-controlled* — stored as files in the repo or installed from GitHub * Actionable *Actionable* — they can include scripts and templates the agent can run * Progressive *Progressive* — supporting files load on demand so context stays smaller h3. h2. 1.3 Explanation: Explanation — purpose and when to use Rules or Skills which |_. Topic|_. |_. Rules|_. Skills| |Purpose|Short |*Purpose*|Short coding guidelines and standing constraints|Multi-step workflows and procedures| |Length|A |*Length*|A few lines to a few hundred lines|Often longer, with step-by-step instructions| |How applied|Included |*How applied*|Included in every matching conversation|Invoked on demand with <code>/skill-name</code> @/skill-name@ or <code>@skill-name</code>, @@skill-name@, or auto-selected from the description| |Example|Use |*Example*|“Use TypeScript for all new files|Deploy files”|“Deploy to staging: run tests, build, deploy, verify| verify”| p. Best *Best practice (official Cursor guidance): guidance)* * Use a rule *rule* when a short instruction should always, or often, always (or often) be in force. * Use a skill *skill* when Agent needs a detailed, repeatable process. * If a rule has grown into numbered steps, convert it to a skill with <code>/create-skill</code> (@/create-skill@ or <code>/migrate-to-skills</code>. @/migrate-to-skills@). * Keep rules under 500 lines. Split large rules into focused files. * Do not copy entire style guides into rules. Use rules; use a linter for formatting. * Do not document every CLI command the agent already knows (@npm@, @git@, and similar). * Start simple. Add a rule only after Agent repeats the same mistake. p. Not provided: any *Not provided:* Any extra team-specific convention from the meeting (naming standards, required rule files, or a shared skills library) beyond the official Cursor model above. h3. h2. 1.4 Reference: file File structure p. h3. Project rules: rules <pre> <pre><code class="text"> .cursor/rules/ typescript-defaults.mdc # recognized (has .mdc + frontmatter) api-guidelines.md # ignored by the rules system frontend/ components.mdc # folders are allowed </pre> </code></pre> p. Project rules must *must* use the @.mdc@ extension. A plain @.md@ file in @.cursor/rules@ is ignored because it has no frontmatter for @description@, @globs@, and @alwaysApply@. For plain markdown, use @AGENTS.md@ instead. p. Skills: h3. Skills <pre> <pre><code class="text"> .cursor/skills/ deploy-app/ SKILL.md scripts/ deploy.sh validate.py references/ REFERENCE.md assets/ config-template.json </pre> </code></pre> p. Cursor also loads skills from: |_. Location|_. Scope| |@.agents/skills/@|Project| |@.cursor/skills/@|Project| |@~/.agents/skills/@|User (all projects)| |@~/.cursor/skills/@|User (all projects)| p. For compatibility it also loads @.claude/skills/@ and @.codex/skills/@ (project and user). Nested category folders work. The work; the skill name *name* comes from the folder that contains @SKILL.md@, not from the category folder above it. p. Skills under a nested package (for example @apps/web/.cursor/skills/@) are automatically scoped to that directory. p. AGENTS.md: h3. AGENTS.md <pre> <pre><code class="text"> project/ AGENTS.md # global frontend/ AGENTS.md # combined with parent; more specific wins backend/ AGENTS.md </pre> </code></pre> h3. h2. 1.5 Reference: Important sections — rule frontmatter p. Each @.mdc@ file is markdown with YAML frontmatter. The type dropdown in Cursor maps to these fields: |_. Rule type in UI|_. Behaviour| |Always Apply|Included in every chat session| |Apply Intelligently|Agent decides from the @description@| |Apply to Specific Files|File path matches @globs@| |Apply Manually|Only when @-mentioned @@@-mentioned (for example <code>@my-rule</code>)| @@my-rule@)| p. How the fields combine: |_. alwaysApply|_. description|_. globs|_. @alwaysApply@|_. @description@|_. @globs@|_. Behaviour| |true|—|—|Always |@true@|—|—|Always included. Other fields ignored.| |false|—|provided|Auto-attached |@false@|—|provided|Auto-attached when a matching file is in context| |false|provided|omitted|Agent |@false@|provided|omitted|Agent pulls it in when the description matches| |false|omitted|omitted|Only |@false@|omitted|omitted|Only via @-mention| @@@-mention| p. Example: h3. Example — always-on rule. rule <pre> <pre><code class="markdown"> --- alwaysApply: true --- - All source files must include the company copyright header - When you are unsure about implementation details, read the relevant source files before proposing changes - Never modify generated files in the dist/ `dist/` or build/ `build/` directories </pre> </code></pre> p. Example: h3. Example — glob-scoped React rule. rule <pre> <pre><code class="markdown"> --- globs: src/components/**/*.tsx alwaysApply: false --- - Use named exports, not default exports - Co-locate styles in a module CSS file next to the component - Keep components under 200 lines - Prefer composition over prop drilling </pre> </code></pre> p. Comma-separated globs are allowed, for example @docs/**/*.md, docs/**/*.mdx@. p. Example: h3. Example — agent-selected from description. description <pre> <pre><code class="markdown"> --- description: RPC service conventions and patterns for the backend alwaysApply: false --- - Define each service in its own file under src/services/ `src/services/` - Always validate inputs at the service boundary - Return structured error objects with a code `code` and message `message` field </pre> </code></pre> p. Example: h3. Example — manual only. only <pre> <pre><code class="markdown"> --- alwaysApply: false --- - Every database migration must have both up `up` and down `down` functions - Never alter a column type in-place @migration-template.sql </pre> </code></pre> p. <code>@filename</code> @@filename@ inside a rule includes that file in the rule’s context instead of copying its contents. h3. h2. 1.6 Reference: Important sections — skill frontmatter p. @SKILL.md@ starts with YAML frontmatter, then markdown instructions. |_. Field|_. Required|_. Description| |name|Yes|Identifier: |@name@|Yes|Identifier: lowercase letters, numbers, hyphens. Must match the parent folder name.| |description|Yes|What |@description@|Yes|What it does and when to use it. The agent uses this to decide relevance.| |paths|No|Glob |@paths@|No|Glob patterns that scope the skill to matching files| |disable-model-invocation|No|If true, |@disable-model-invocation@|No|If @true@, only runs when you type <code>/skill-name</code>| @/skill-name@| |icon |@icon@ / color|No|Badge @color@|No|Badge styling when the skill is used as a Custom Mode| |metadata|No|Arbitrary |@metadata@|No|Arbitrary key-value mapping| p. Optional directories next to @SKILL.md@: |_. Directory|_. Purpose| |scripts/|Executable |@scripts/@|Executable code the agent can run| |references/|Extra |@references/@|Extra docs loaded on demand| |assets/|Templates, |@assets/@|Templates, images, data files| p. Example: h3. Example — skill with scripts. scripts <pre> <pre><code class="markdown"> --- name: deploy-app description: Deploy the application to staging or production. Use when deploying code, releases, or environments. --- # Deploy App ## Usage Run scripts/deploy.sh <environment> `scripts/deploy.sh <environment>` where environment is staging `staging` or production. `production`. ## Pre-deployment validation Before deploying, run python scripts/validate.py. `python scripts/validate.py`. </pre> </code></pre> p. The @# Deploy App@ and @## Usage@ lines above are examples of headings inside a h3. Example — skill file. They are not headings of this meeting document. p. Example: skill scoped to files. files <pre> <pre><code class="markdown"> --- name: react-component-patterns description: Conventions for writing React components in this codebase. paths: - "**/*.tsx" - "packages/ui/**/*.ts" --- # React component patterns ... </pre> </code></pre> h3. h2. 1.7 Procedure: Procedure — create and apply a project rule # Open Agent chat in Cursor. # Type <code>/create-rule</code> @/create-rule@ and describe the rule (what it should enforce and when). # Review the generated @.mdc@ file under @.cursor/rules/@. # Alternatively: open Customize *Customize* in the sidebar → Rules *Rules* → Add Rule. *Add Rule*. # Choose the application type (Always / Intelligently / Specific files / Manual). # Commit the file so the rest of the team gets it. p. To *To apply a manual rule: rule:* in chat, type <code>@</code> @@@ and select the rule (for example <code>@typescript-defaults</code>). @@typescript-defaults@). p. To *To import rules from GitHub: GitHub:* Customize → Rules → Add Rule → Remote Rule (Github) → paste the repository URL. Cursor scans for @.mdc@ files and places them under @.cursor/rules/imported/@. p. Team *Team rules (Team/Enterprise): (Team/Enterprise):* admins create them in the Cursor dashboard. Precedence when guidance conflicts, according to official Cursor docs: Team conflicts: *Team Rules → Project Rules → User Rules. Rules*. Enforced team rules cannot be turned off in Customize. Whether this organisation uses Team Rules was *not provided*. h3. h2. 1.8 Procedure: Procedure — create and apply a skill # Type <code>/create-skill</code> @/create-skill@ in Agent chat and describe the workflow. # Review <code>.cursor/skills/<skill-name>/SKILL.md</code>. @.cursor/skills/<skill-name>/SKILL.md@. # Or create the folder and @SKILL.md@ by hand using the frontmatter above. # Commit the skill folder. p. To *To run a skill: skill* * Type <code>/</code> @/@ in Agent chat and search for the skill name (for example <code>/deploy-app</code>). @/deploy-app@). * Or type <code>@</code> @@@ and attach the skill as context. * Agent may also apply a skill automatically when the request matches the description (unless @disable-model-invocation@ is true). @disable-model-invocation: true@). p. To *To keep a skill on for the whole session: session:* use it as a Custom Mode with Option+Enter (Mac) or Alt+Enter (Windows). p. To *To convert an old rule or slash command: command:* type <code>/migrate-to-skills</code>. @/migrate-to-skills@. Eligible items: * Dynamic rules (@alwaysApply@ false (@alwaysApply: false@ or unset, and no @globs@) * User-level and workspace-level slash commands (become skills with @disable-model-invocation@ true) @disable-model-invocation: true@) p. Rules with @alwaysApply@ true @alwaysApply: true@ or with @globs@ are not *not* migrated. User rules in the UI are not migrated because they are not files. h3. h2. 1.9 Reference: built-in Built-in Cursor skills (reference) p. These ship with Cursor and appear alongside project skills. Invoke them with <code>/</code> @/@ in Agent chat. This table is a snapshot from official Cursor Skills documentation retrieved 24 August 2026. Cursor may add or remove built-in skills in later versions. |_. Skill|_. What it does| |<code>/create-rule</code>|Creates |@/create-rule@|Creates a project rule with the right scope and frontmatter| |<code>/create-skill</code>|Creates |@/create-skill@|Creates a skill folder and @SKILL.md@| |<code>/migrate-to-skills</code>|Converts |@/migrate-to-skills@|Converts eligible dynamic rules and slash commands| |<code>/create-subagent</code>|Creates |@/create-subagent@|Creates a custom subagent| |<code>/review</code>|Runs |@/review@|Runs the appropriate code-review agent| |<code>/review-bugbot</code>|Bug-focused |@/review-bugbot@|Bug-focused review| |<code>/review-security</code>|Security-focused |@/review-security@|Security-focused review| |<code>/automate</code>|Creates |@/automate@|Creates Cursor Automations| |<code>/babysit</code>|Monitors |@/babysit@|Monitors a pull request and follow-up work| |<code>/loop</code>|Repeats |@/loop@|Repeats a prompt or skill on an interval| |<code>/shell</code>|Runs |@/shell@|Runs the provided text as a literal shell command| p. The full list is in the official Skills docs. docs and can change between Cursor versions. h3. h2. 1.10 Best practice: Rules practices and Skills meeting considerations p. Official Cursor guidance: *Best practice (official)* * Write rules like internal docs: concrete, not vague. * Point at canonical files with <code>@path</code> @@path@ instead of pasting large code blocks that go stale. * Put long procedures in skills, not in always-on rules (always-on rules cost context on every request). * Write skill @description@ fields carefully; that is how the agent decides to load the skill. * Check rules and skills into git. * When Agent makes a repeated mistake, update the rule rather than re-explaining in chat. p. Not provided: *Not provided* * Screenshots from the meeting of the Customize UI * Any team-agreed list of required rules for this organisation organization * Confirmation of which Cursor plan (Team vs individual) the attendees use for Team Rules --- h2. h1. 2. Buddy Chatbot use case p. This section is incomplete on purpose. Demonstration details were *not provided*. No product is inferred. h3. h2. 2.1 Explanation: what What was requested p. The meeting outline asked this documentation to cover: * The use case of the Buddy chatbot * Its purpose, workflow, and how it can be used * Key functionality and the overall process demonstrated in the meeting * Relevant examples h3. h2. 2.2 Explanation: what What can be stated from the source materials p. The only facts supplied in the request are: * A topic named Buddy Chatbot *Buddy Chatbot* was on the agenda for the 24 August 2026 today’s meeting. * The chatbot was described as a use case, not *use case* (not as a setup guide for Cursor Rules/Skills or for Redmine. Redmine). * The meeting was expected to demonstrate *demonstrate* purpose, workflow, key functionality, and examples. p. No product URL, repository, screenshots, transcript, speaker notes, or workflow diagram were attached. h3. h2. 2.3 Reference: requested Requested content that is not available |_. Requested item|_. Status| |Product identity (internal tool vs third-party, vendor, URL)|Not provided| URL)|*Not provided*| |Purpose / problem it solves|Not provided| solves|*Not provided*| |End-to-end workflow (who uses it, in what order, with which systems)|Not provided| systems)|*Not provided*| |Key functionality demonstrated|Not provided| demonstrated|*Not provided*| |Example conversations, prompts, or screens|Not provided| screens|*Not provided*| |How it relates to Cursor or Redmine|Not provided| Redmine|*Not provided*| |Access, environments, or credentials|Not provided| credentials|*Not provided*| |Best practices discussed in the meeting|Not provided| meeting|*Not provided*| p. This section does not *not* substitute a similar-sounding public product. product (for example a meeting-assistant named Meet Buddy). That would be invention. h3. h2. 2.4 Procedure: how How to complete this section later p. When notes or a recording from the demonstration are available, add: # Explanation: *Explanation* — what Buddy is and who it is for # Procedure: *Procedure* — numbered steps as shown in the demo # Example: *Example* — one realistic interaction from the meeting # Best practice: *Best practice* — only items that were actually stated p. Until then, readers should treat Buddy Chatbot as an agenda item whose demonstration details are missing from this write-up. --- h2. h1. 3. How to raise a ticket in Redmine p. The steps below combine *official mix *standard Redmine issue tracking* with *instance-verified* fields from *fields verified on this Teamteki site instance* on 24 August 2026. They apply to https://redmine.teamteki.com/ and the project Weekly *Weekly Discussion & Updates. Updates*. p. Where a field does not exist on this project, that is stated. Custom-field definitions could not be listed: the REST API returned 403 Forbidden *403 Forbidden* for <code>/custom_fields.json</code> @/custom_fields.json@ (that endpoint is typically admin-only). If the New issue form shows extra labelled fields, fill those as shown in the UI. They UI; they are not enumerated here. h3. h2. 3.1 Explanation: Explanation — what a ticket is p. In Redmine, work is tracked as an issue *issue* (ticket). An issue belongs to a project, *project*, has a tracker *tracker* (the kind of work), a status, *status*, a priority, *priority*, an optional assignee, *assignee*, and a description. *description*. Updates are recorded in chronological journals. Watchers are notified of changes. p. On this instance the Weekly Discussion & Updates project has the Issue tracking *Issue tracking* module enabled, along with time tracking, news, documents, files, wiki, repository, boards, calendar, and gantt. This project had no currently has *no issue categories categories* and no versions at inspection. The *no versions*. Wiki pages exist as a module was enabled. Its page index was but were empty at the time of inspection. h3. h2. 3.2 Procedure: Procedure — create a ticket in the UI (UI) # Sign in at https://redmine.teamteki.com/ . # Open the project Weekly *Weekly Discussion & Updates. Updates* Direct URL: https://redmine.teamteki.com/projects/weekly-discussion-updates # Choose Issues *Issues* in the project menu, then New issue. *New issue*. Direct URL: https://redmine.teamteki.com/projects/weekly-discussion-updates/issues/new # Select a Tracker *Tracker* (see the trackers table). table below). The tracker sets the default status and which standard fields appear. # Fill Subject *Subject* with a short, specific title. # Fill Description *Description* with the problem, goal, or request. Use the formatting toolbar. Issue 156 on this toolbar (this instance renders Textile (@h1.@ / @h2.@ headings and stores issue text in *Textile*, for example @*bold*@). # Set Priority, Assignee, *Priority*, *Assignee*, dates, and estimate if you know them. Leave Category *Category* and Target version *Target version* empty unless this your project later adds those lists. # Attach files if needed. # Add Watchers *Watchers* for people who should be notified but are not the assignee. # Submit the form (Save / Create). p. You need the permission Issue *Issue tracking → Add issues issues* for your role. Memberships returned by On this project, typical member roles observed via the API for this project included the roles are Manager, Developer, and Tester Role. That is Confirm in the UI if a membership snapshot, not a meeting-assigned RACI. If a field is missing in missing; that usually means the UI, the tracker or your role is hiding hides it. h3. h2. 3.3 Reference: required Required and standard fields on this instance p. Subject is always required. Tracker is required. Other standard fields enabled on every tracker inspected here: |_. Field|_. API name|_. Notes on this instance| |Tracker|tracker_id|See |Tracker|@tracker_id@|See trackers table| |Subject|subject|Required. |Subject|@subject@|Required. Keep it specific.| |Description|description|Textile on this instance. |Description|@description@|Textile. Include goal, context, and acceptance criteria when you have them.| |Status|status_id|Default |Status|@status_id@|Default depends on tracker| tracker (see below)| |Priority|priority_id|Default |Priority|@priority_id@|Default is Normal| *Normal*| |Assignee|assigned_to_id|Choose |Assignee|@assigned_to_id@|Choose a project member| |Parent task|parent_issue_id|For task|@parent_issue_id@|For subtasks| |Start date / Due date|start_date date|@start_date@ / due_date|Optional| @due_date@|Optional| |Estimated time|estimated_hours|Optional, time|@estimated_hours@|Optional, hours| |% Done|done_ratio|0–100| Done|@done_ratio@|0–100| |Category|category_id|No |Category|@category_id@|*No categories configured configured* on this project| |Target version|fixed_version_id|No version|@fixed_version_id@|*No versions configured configured* on this project| |Files|uploads|Optional attachments| |Watchers|watcher_user_ids|Optional| |Watchers|@watcher_user_ids@|Optional| p. h3. Trackers available on Weekly Discussion & Updates: Updates |_. Tracker|_. id|_. Intended use (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 |development|6|*(no description set on the instance|Default| set)*|Default| p. Best practice: *Best practice:* pick the tracker that matches the work. Use Bug *Bug* for defects, Feature *Feature* for new capability, Improvement *Improvement* for changing something that already exists, Task *Task* for general work (including meeting notes and follow-ups), Support *Support* for help requests. Use development *development* only if your team has already agreed what that tracker means. The means; the instance description for development is empty. That agreement was *not provided*. p. h3. Statuses on this instance: instance |_. Status|_. id|_. Closed?|_. Description on the instance| |Default|1|No|Empty description| |Default|1|No|*(empty)*| |New|8|No|Issue created, not started| |In Progress|9|No|Work ongoing| |Resolved|10|No|Work done, waiting for review| |Feedback|11|No|Changes required| |Closed|12|Yes|Final completed| |Rejected|13|Yes|Invalid issue| p. h3. Priorities on this instance: instance |_. Priority|_. id|_. Default?| |Low|2|No| |Urgent|3|No| |High|4|No| |Normal|5|Yes| p. Best practice: *Best practice:* leave Normal *Normal* unless the work is blocking others (High (*High* / Urgent) *Urgent*) or is explicitly backlog (Low). (*Low*). The meeting did not define a local priority policy beyond these labels. h3. h2. 3.4 Procedure: Procedure — assign, prioritize, categorize, and track p. Assign: h3. Assign # Open the issue. # Click Update *Update* (pencil) at the top or bottom. # Set Assignee *Assignee* to a project member. # Save. p. Alternatively set Assignee on create. Assignees must be members of the project. Watchers can be added without making them the assignee. They assignee; they still receive notifications. p. Not provided: *Not provided:* a meeting rule for who should be assigned meeting-notes tickets versus vs implementation tickets. p. Prioritize: h3. Prioritize p. Set Priority *Priority* when creating or updating. Combined with Due date, *Due date*, this is how the issues list and calendar surface urgency. There is no separate severity “severity” field in the standard trackers inspected here. p. Categorize: h3. Categorize * Tracker *Tracker* is the primary category (Bug / Feature / Improvement / Task / Support / development). * Issue categories *Issue categories* (a second dropdown on many Redmine sites) are not configured *not configured* on this project. * Target version *Target version* is not configured. *not configured*. * A Subject Use a clear *Subject* prefix such as if the team later agrees on one (for example @Meeting notes —@ can help findability. —@). That prefix was not provided *not provided* as a meeting decision. decision; it is only a suggestion for findability. p. Track: h3. Track # Move Status *Status* along the workflow as work happens: New → In Progress → Resolved → Closed (use Feedback if review sends it back; use Rejected if the ticket is invalid). # Use % Done *% Done* and Estimated time *Estimated time* if you log progress. # Add comments in the update notes so the journal shows history. # Link related work with Related issues *Related issues* (related to, duplicates, blocks, precedes, copied from). Closing behaviour for duplicate/blocks relations follows standard Redmine: duplicates — ** *duplicates:* closing the original also closes the duplicate; blocks — duplicate ** *blocks:* the blocked issue cannot be closed while the blocker is open. open # Optional: log time (Time tracking module is enabled on this project). # Filter the issues list by tracker, status, assignee, or parent task. Sorting by parent task shows subtasks as a tree. p. Subtasks: h3. Subtasks Break large work into children: # On the parent issue, use Add *Add* in the Subtasks section, or # Set Parent task *Parent task* to the parent’s id when creating or updating creating/updating the child. p. Standard Redmine parent/child roll-ups apply (dates, done ratio, estimated/spent time, highest child priority). Whether cross-project parents are allowed is an administrator setting and was not verified *not verified* here. h3. h2. 3.5 Example: Example — a well-formed ticket |_. Field|_. Example value| |Tracker|Task| |Subject|Meeting *Tracker:* Task *Subject:* Meeting notes — 24 Aug 2026: Cursor Rules and Skills, Buddy Chatbot, raising Redmine tickets| |Priority|Normal| |Status|New| tickets *Priority:* Normal *Status:* New *Description (Textile style):* p. Example description (Textile): <pre> <pre><code class="text"> h2. Goal Publish notes from the 24 August 2026 weekly discussion so people who missed the meeting can follow the three topics. h2. Scope * Cursor Rules and Skills * Buddy Chatbot use case (details still missing from source materials) * How to raise a ticket in Redmine h2. Acceptance * Notes are readable without attending the meeting * Gaps are labelled instead of guessed </pre> </code></pre> p. The @h2.@ lines in that example belong to the sample ticket text. They are not extra headings of this meeting document. h3. h2. 3.6 Best practice: tickets on practices (standard Redmine + this instance instance) * One concern per ticket when the work will be assigned or scheduled separately. * Put reproduction steps in Bug tickets. Put *Bug* tickets; put the desired behaviour in Feature or Improvement *Feature* / *Improvement* tickets. * Do not leave Assignee empty if someone is expected to act. act; otherwise it sits in the unassigned pile. * Do not invent categories or versions in the UI. This UI; this project had has none at inspection. yet. * Prefer updating status instead of creating a duplicate ticket for the same work. * Watch the issue if you need notifications but are not implementing it. * Keep secrets (API keys, passwords) out of ticket descriptions and attachments. p. Not *Not provided from the meeting: meeting* * A required template beyond the fields above * SLA or must-assign-within-N-hours “must assign within N hours” policy * Screenshot walkthrough of the New issue form * Whether the team prefers Wiki pages versus vs issues for long documentation h3. h2. 3.7 Reference: instance Instance notes used for this write-up p. Verified via REST API as user ayush.sharma@softervice.com @ayush.sharma@softervice.com@ (user id 18): * Base URL: https://redmine.teamteki.com/ * Project name: Weekly *Weekly Discussion & Updates Updates* (the request said Weekly “Weekly Discussion & Update; Update”; this was is the unique matching project) * Project id: 30 @30@ * Identifier: weekly-discussion-updates @weekly-discussion-updates@ * Open issues at first inspection: 0 inspection time: @0@ * Text format: Textile, confirmed by rendering of this ticket (h1. / h2. headings) format inferred from other projects on the same instance: *Textile* (@*bold*@ markup) --- h2. 4. h1. Appendix A: A — Cursor glob examples |_. Pattern|_. Matches| |@*@|One path segment| |@**@|Any depth of directories| |@*.ts@|@.ts@ files in the project root| |@**/*.ts@|@.ts@ files in any directory| |@src/**@|Everything under @src/@| |@src/**/*.tsx@|@.tsx@ files under @src/@| |@tailwind.config.*@|@tailwind.config@ with any extension| h2. 5. h1. Appendix B: B — Rules vs Skills decision # Is this a standing constraint (“always use X”, “never edit Y”)? Use a Rule. → *Rule* # Is this a procedure with several steps, scripts, or a runbook? Use a Skill. → *Skill* # Should it run on every chat? Use a rule → Rule with @alwaysApply@ true, and keep @alwaysApply: true@ (keep it short. short) # Should it run only for certain files? Use rule → Rule @globs@ or skill @paths@. @paths@ # Should the human opt in each time? Use a manual → Manual rule (<code>@name</code>) (@@name@) or a skill with @disable-model-invocation@ true. @disable-model-invocation: true@ h2. 6. h1. Appendix C: open C — Open gaps for senior review # Buddy Chatbot demonstration details (see section 2.3) # Screenshots from the meeting # Team-specific Cursor rule/skill inventory # Redmine custom fields (API 403) # Administrator setting for cross-project subtasks