Back to skills
extension
Category: Development & EngineeringNo API key required

communication-guidelines

Use when starting work - guidelines for asking questions and commit policies

personAuthor: jakexiaohubgithub

Communication Guidelines

Use this skill at the start of work to determine when to ask questions and follow commit policies.

Checklist

When to Ask Clarifying Questions

Ask questions for:

  • [ ] Ambiguous requests - Multiple valid interpretations exist
    • Example: "optimize this" → Ask: speed, memory, or readability?
    • Example: "improve the API" → Ask: performance, interface design, or error handling?
  • [ ] Complex features - Significant design decisions required
    • Example: "add authentication" → Ask: JWT, OAuth, session-based? Token duration?
    • Example: "add caching" → Ask: in-memory, Redis, file-based? TTL duration?
  • [ ] Missing context - Information needed to implement correctly
    • Example: "fix the bug" → Ask: which bug? What's the expected behavior?

When to Skip Questions

Proceed directly for:

  • [ ] Trivial commands - Clear, single-step operations
    • Examples: "run tests", "format code", "check types"
  • [ ] Well-defined tasks - All necessary information provided
    • Examples: "add logging to generate_image()", "fix type error in service.py:42"
  • [ ] Standard operations - Following established patterns
    • Examples: "create a test for this function", "add error handling here"

Commit and Amend Policies

  • [ ] Never create commits without explicit permission
    • Wait for user to say "commit this" or "create a commit"
    • Don't assume completion means commit
  • [ ] Never amend commits without explicit permission
    • Don't use git commit --amend unless user requests it
    • Respect commit history
  • [ ] Ask before creating pull requests
    • Don't automatically create PRs after completing work
    • Wait for user to request PR creation

Decision-Making Framework

Before asking a question, check:

  1. Is this information necessary to proceed? (If no → proceed with reasonable defaults)
  2. Are there multiple valid approaches with different trade-offs? (If yes → ask)
  3. Could my assumption cause significant rework if wrong? (If yes → ask)
  4. Is this a trivial/standard operation? (If yes → proceed)

Examples:

Don't ask: "Should I use tabs or spaces?" (Project has ruff.toml configuration) ✅ Do ask: "Should I use JWT tokens or session cookies for authentication?" (Major architectural decision)

Don't ask: "Should I run the tests?" (Standard verification step) ✅ Do ask: "Should I mock the GPU or use a real device for this test?" (Testing strategy decision)

Communication Style

  • [ ] Be concise and direct
  • [ ] Focus on technical clarity over politeness
  • [ ] Provide options when asking questions
  • [ ] Explain trade-offs when recommending approaches