Signal Capture

---
name: signal-capture
description: Detect and capture technical preferences, naming conventions, and architectural practices from user messages into Packmind standards. Trigger when user prescribes HOW to code rather than WHAT to build (e.g., "Use snake_case for columns", "Always use async/await", "Prefix interfaces with I"). Does NOT trigger for feature requests, bug reports, or general implementation tasks without coding preferences.
---

# Signal Capture Workflow

This skill helps detect technical preferences in user messages and captures them systematically in `.packmind/changes.yaml` for integration into coding standards.

## When to Trigger

**TRIGGER CONDITIONS** - User prescribes HOW to code:

- Naming conventions: "All interfaces should start with I", "Use snake_case for columns"
- Code structure directives: "Wrap emojis for accessibility", "Always use async/await", "Don't use class components"
- Pattern enforcement: "Use composition over inheritance", "Prefer functional programming"
- Removal/updates: "Remove the rule about X", "We no longer need Y convention"
- Formatting rules: "Always add JSDoc comments", "Use single quotes"

**NON-TRIGGER CONDITIONS** - User asks WHAT to build or fix:

- Feature requests: "Add a search feature", "Create a new component"
- Bug reports: "This function is broken", "Fix the error on line 10"
- Questions: "How does this work?", "What's the best approach?"
- Implementation tasks WITHOUT coding preferences: "Implement the login page", "Add error handling"

## Workflow

### Step 1: Detection

When a technical preference is detected in the user's message:

1. Identify the specific coding rule or convention being stated
2. Determine which existing standard it belongs to (or if a new standard is needed)
3. Classify the operation type: ADDED (new rule), UPDATED (modifying existing rule), or DELETED (removing old rule)

### Step 2: Ask for Validation

Present the detected preference to the user for approval:

> I detected a technical preference. Add this rule to **[STANDARD_NAME]**?
>
> Proposed rule: _"[REFORMULATED_RULE]"_

**Format guidelines for the proposed rule:**

- Start with a verb (imperative mood)
- Be concise and clear
- Focus on the "what" and "why" not implementation details
- Example: "Prefix interfaces with I to distinguish them from types"

Wait for user approval before proceeding. If user refuses, continue with the original task without updating standards.

### Step 3: Log to `.packmind/changes.yaml`

If approved, append the change to `.packmind/changes.yaml`:

```yaml
- newRule: '<rule text>' # omit this field for DELETED operations
  oldRule: '<previous text>' # required for UPDATED and DELETED operations
  operation: ADDED | UPDATED | DELETED
  standard: '<short-name>' # e.g., typescript-code-standards, tests-redaction
  date: '<ISO date>' # e.g., 2025-12-19
  sourceFile: '<file path where signal was captured>' # file being worked on when rule was captured
  language: '<language>' # omit for DELETED operations
  goodExample: | # omit for DELETED operations
    <valid code example>
  badExample: | # omit for DELETED operations
    <invalid code example>
```

**YAML Logging Rules:**

1. **Operations:**
   - `ADDED`: New rule being added (requires: newRule, standard, date, sourceFile, language, goodExample, badExample)
   - `UPDATED`: Existing rule being modified (requires: newRule, oldRule, standard, date, sourceFile, language, goodExample, badExample)
   - `DELETED`: Rule being removed (requires: oldRule, standard, date, sourceFile)

2. **Examples:**
   - Always include meaningful, realistic code examples
   - Good example shows the correct way following the rule
   - Bad example shows what NOT to do (violating the rule)
   - Examples should be concise but illustrative
   - Use proper code formatting with appropriate language syntax

3. **Standard Names:**
   - Use existing standard names when applicable
   - Common standards: `typescript-code-standards`, `tests-redaction`, `changelog`, `api-design`, `react-patterns`
   - Use kebab-case for new standard names

4. **Source File:**
   - Include the file path where the preference was mentioned or where it will be applied
   - If no specific file, use the project root or most relevant path

### Step 4: Confirmation

After logging, confirm to the user:

> Rule logged to `.packmind/changes.yaml` for the **[STANDARD_NAME]** standard.

Then continue with the original task.

## Important Guidelines

1. **Only add if not already covered**: Check if the rule is already captured in existing standards before proposing to add it
2. **Keep wording concise**: Rules should be clear and actionable, not verbose
3. **Always include meaningful examples**: Both good and bad examples must be realistic and helpful
4. **Don't interrupt flow**: Signal capture should be quick and non-intrusive to the main task
5. **Be precise about operation type**: Distinguish clearly between ADDED, UPDATED, and DELETED operations

## Example Scenarios

### Example 1: Adding a New Rule

**User message:** "All API response types should have a 'data' property wrapper"

**Detection:** New architectural practice detected

**Validation prompt:**

> I detected a technical preference. Add this rule to **api-design**?
>
> Proposed rule: _"Wrap all API responses in a data property for consistency"_

**If approved, log:**

```yaml
- newRule: 'Wrap all API responses in a data property for consistency'
  operation: ADDED
  standard: 'api-design'
  date: '2025-12-19'
  sourceFile: 'src/api/users.ts'
  language: 'TYPESCRIPT'
  goodExample: |
    return {
      data: { users: [...] },
      meta: { total: 100 }
    }
  badExample: |
    return {
      users: [...],
      total: 100
    }
```

### Example 2: Updating an Existing Rule

**User message:** "Actually, let's update our interface naming - only prefix public interfaces with I, not internal ones"

**Detection:** Modification to existing naming convention

**Validation prompt:**

> I detected a technical preference. Update the rule in **typescript-code-standards**?
>
> Old rule: _"Prefix interfaces with I"_
> New rule: _"Prefix public interfaces with I (internal interfaces don't need prefix)"_

**If approved, log:**

```yaml
- newRule: "Prefix public interfaces with I (internal interfaces don't need prefix)"
  oldRule: 'Prefix interfaces with I'
  operation: UPDATED
  standard: 'typescript-code-standards'
  date: '2025-12-19'
  sourceFile: 'src/types/user.ts'
  language: 'TYPESCRIPT'
  goodExample: |
    // Public
    export interface IUserService { }

    // Internal
    interface UserCache { }
  badExample: |
    // Public
    export interface UserService { }

    // Internal
    interface IUserCache { }
```

### Example 3: Removing a Rule

**User message:** "Remove the rule about using JSDoc comments everywhere, it's too verbose"

**Detection:** Rule removal requested

**Validation prompt:**

> I detected a request to remove a rule from **typescript-code-standards**?
>
> Rule to remove: _"Add JSDoc comments to all exported functions"_

**If approved, log:**

```yaml
- oldRule: 'Add JSDoc comments to all exported functions'
  operation: DELETED
  standard: 'typescript-code-standards'
  date: '2025-12-19'
  sourceFile: 'CLAUDE.md'
```

## Integration with Main Task

Signal capture should happen seamlessly:

1. Detect the preference in the user's message
2. Quickly validate with the user
3. Log if approved
4. Continue with the main task without significant disruption

The goal is to build a knowledge base of coding preferences over time without interrupting the development flow.