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