s-quick

/s:quick - Quick Mode

Compressed workflow for small tasks. Skips ceremony, keeps discipline.

Usage: /s:quick "description of the task" Flags: --discuss | --full | --research

Step 1: Parse Input

Accept the task description as the first argument. Parse optional flags:

Flag	Effect
(none)	Compressed workflow - fastest path
--discuss	Add full requirements gathering phase
--full	Redirect to full ceremony: /s:new > /s:discuss > /s:plan > /s:build
--research	Research the topic first using Context7 and web search, then implement

If --full flag is present, inform the user and hand off to the full chain:

[QUICK] Full ceremony requested. Redirecting to /s:discuss > /s:plan > /s:build chain.

Then stop - let the full skills take over.

Step 2: Quick Requirements Check

Unless --discuss flag is set, keep this MINIMAL:

Ask at most 3 clarifying questions. Prefer yes/no or multiple choice:

[QUICK] Task: "{user_description}"

Quick check:
1. Which files/modules does this affect? (or "auto-detect")
2. Any constraints I should know about? (or "none")
3. Should I create tests? (yes/no, default: yes)

If --discuss flag is set, run the full /s:discuss protocol instead.

Step 3: Research Phase (--research only)

If --research flag is present:

1. Identify which libraries/frameworks are involved
2. Use Context7 MCP to pull relevant documentation
3. Search codebase for existing patterns and conventions
4. Summarize findings in 5-10 bullet points
5. Proceed to implementation with research context loaded

Display:

[QUICK] Researching: {topic}
[QUICK] Found: {N} relevant docs, {M} existing patterns
[QUICK] Proceeding with research context loaded.

Step 4: Inline Planning

NO separate plan file. Build a mental model and display it:

[QUICK] Plan:
  1. {step 1} → {file}
  2. {step 2} → {file}
  3. {step 3} → {file}
  Tests: {test file(s)}
  Estimated changes: {N} files

This plan is NOT saved to docs/plans/. It exists only in this conversation.

Exception: if the plan exceeds 5 steps, suggest upgrading to full mode:

[QUICK] This task has {N} steps. Consider using /s:plan for a tracked plan.
Continue in quick mode? (yes/no)

Step 5: TDD Implementation

TDD is NON-NEGOTIABLE even in quick mode. The cycle is lighter but still enforced:

RED

1. Write the test that describes the expected behavior
2. Run it - confirm it fails
3. If test framework is not set up, set it up first

GREEN

1. Write the MINIMAL code to make the test pass
2. Run the test - confirm it passes
3. Run the full test suite - confirm nothing is broken

REFACTOR

1. Clean up if needed (but don't over-engineer for a quick task)
2. Run tests again after refactoring

Display after each phase:

[QUICK] RED: test written, fails as expected
[QUICK] GREEN: implementation done, test passes
[QUICK] REFACTOR: cleaned up, all tests pass

Step 6: Quick Verification

Lighter than full /s:verify but still evidence-based:

1. Run the test suite, capture output
2. Confirm the new/changed test passes
3. Confirm no existing tests broke
4. Quick visual check if UI-related

Display:

[QUICK] Verification:
  New tests: PASS ({N} assertions)
  Existing tests: PASS ({M} total)
  Files changed: {list}

Step 7: Update State

Update .planning/STATE.md with a lightweight entry:

## Quick Task: {description}
**Date:** {YYYY-MM-DD}
**Status:** complete
**Files:** {list of changed files}
**Tests:** {test file(s)}

This is a shorter format than full skill updates but still maintains the project memory.

Step 8: Suggest Next Steps

Based on what was done:

[QUICK] Done. Options:
  - /s:review   → Get a code review
  - /s:ship     → Push and create PR
  - /s:compound → Save learnings (recommended if you learned something new)

Good For

• Bug fixes (known cause, clear fix)
• Small features (1-3 files)
• Config changes (env vars, settings)
• Dependency updates (upgrade, test, done)
• Typo/copy fixes
• Adding a single test
• Small refactors (rename, extract function)

NOT Good For

• New modules or major features → use full /s:plan > /s:build
• Architecture changes → use /s:brainstorm > /s:plan
• Multi-phase work → use /s:auto
• Unclear requirements → use /s:discuss first

Notes

• Quick mode still respects all rules (TDD, quality, no any types)
• Quick mode still updates STATE.md (lighter format)
• Quick mode can be interrupted at any step
• If the task grows beyond quick scope, suggest upgrading to full mode