@mohanscodex/spectra-code 0.4.9 → 0.5.0

package/skills/collaboration/phase-prompting/SKILL.md

@@ -0,0 +1,292 @@
+---
+name: Phase Prompting
+description: Turn verified project state into execution-ready phase prompts with wave structure, hard rules, acceptance criteria, and delivery reports. For writing prompts that drive real implementation progress, not design docs.
+when_to_use: when writing execution prompts, round plans, phase delivery packets, or multi-wave coordination plans for any project. Especially when the prompt will be handed to another session or executor.
+version: 1.1.0
+languages: all
+---
+
+# Phase Prompting
+
+## Overview
+
+This skill turns current verified project state into execution-ready prompts. The output is a prompt that another session (or the same session later) can pick up and execute with zero additional context.
+
+**Announce at start:** "I'm using the Phase Prompting skill to write the execution prompt."
+
+**Core principle:** Write from current truth, not from summaries. If code and docs disagree, trust code.
+
+## When to use
+
+- Writing a phase/round/task prompt for implementation work
+- Creating a multi-wave execution packet
+- Writing a follow-on phase after reviewing delivery summaries
+- Any time a prompt will be handed to an executor who has zero conversation context
+
+## First principles
+
+These are non-negotiable:
+
+- `running code > design document`
+- `verified state > claimed support`
+- `one executable round > one giant roadmap`
+- `honest blocked state > fake green`
+- `concrete file paths > vague references`
+
+## Prompt archiving is mandatory and project-scoped
+
+When you produce a complete execution-ready prompt, do not leave it only in chat.
+
+- Save the final prompt into the project repo unless the user explicitly says not to.
+- Archive prompts under a project-specific directory, not a shared flat folder.
+- Archive root convention: `<project-repo>/prompts/` or
+  `<project-repo>/docs/execution-prompts/`
+- If the directory does not exist, create it.
+- If you are writing prompts for a project not listed above, create and use an appropriate directory within that project's repo.
+- Use deterministic filenames:
+  - `task-19-round-2-verify-and-commit.md`
+  - `phase-8-upstream-full-capability.md`
+  - `phase-40-round-7.md`
+  - `phase-40-round-7a.md` (branch variant)
+  - `phase-40-round-7-revision.md` (revision of existing)
+- Archive the final prompt only, not chain-of-thought or scratch analysis.
+- If you materially revise an already-archived prompt in the same turn, update the file instead of creating near-duplicates unless the user clearly wants a separate branch prompt.
+- In your final answer, include the saved file path.
+
+## Before writing: gather truth
+
+Always do this before drafting:
+
+1. Read the project's source-of-truth docs (AGENTS.md, README, architecture docs)
+2. Read the actual implementation files relevant to the task
+3. Check git log for recent changes in the area
+4. If delivery summaries exist, verify claims against code
+
+**If summaries and code disagree, trust code, tests, and live behavior.**
+
+## Prompt structure
+
+Follow this skeleton. Every section is mandatory unless marked optional.
+
+```
+# Phase XX Round Y: [One-line delivery goal]
+
+## Identity
+
+You are [role]. Your task is not [anti-goal] but [real goal].
+
+## First principles
+
+- [3-5 hard rules as inequalities: X > Y]
+
+## Current verified state
+
+### What already works
+- [Only list verified facts, with evidence]
+
+### Key gaps
+- [What actually blocks delivery]
+
+## This round's goal
+
+[One sentence. One dominant delivery objective.]
+
+## Must-read files
+
+1. [Absolute path]
+2. [Absolute path]
+3. [Absolute path]
+
+Read these first. Output a <10 line execution plan before touching code.
+
+## Hard rules
+
+- Do not [specific anti-pattern]
+- Do not [specific anti-pattern]
+- [Runtime/safety constraints if applicable]
+
+## Wave plan
+
+| Wave | Goal | Time |
+|------|------|------|
+| 0 | Baseline freeze | 10m |
+| 1 | [First real action] | 30m |
+| 2 | [Second real action] | 30m |
+| 3 | [Surface/gate/test sync] | 20m |
+| 4 | [Verification and closeout] | 15m |
+
+## Wave 0: [Title]
+
+Goal: [One line]
+
+Tasks:
+- [Concrete task with file path]
+- [Concrete task with file path]
+
+Acceptance:
+- [Observable, verifiable result]
+
+## Wave 1: [Title]
+
+[Same structure]
+
+## Wave N: [Title]
+
+[Same structure]
+
+## Required tests
+
+- [Exact command to run]
+- [Exact command to run]
+
+## Out of scope
+
+- [Explicit exclusion]
+- [Explicit exclusion]
+
+## After each wave, answer these 4 questions
+
+1. What real capability did the user gain?
+2. What false claim was removed or corrected?
+3. What formal gate or verification was added?
+4. What still blocks delivery?
+
+## Final delivery report format
+
+### Modified files
+- [list]
+
+### Wave-by-wave outcomes
+- Wave 0: [one line]
+- Wave 1: [one line]
+
+### New user-visible capabilities
+- [list]
+
+### Tests run
+- [command + result]
+
+### Build/check run
+- [command + result]
+
+### Release-readiness delta
+- [one line]
+
+### Remaining blockers
+- [list]
+
+### Why this round advances delivery
+- [one line]
+
+## Commit message
+
+[Project] vX.Y.Z -- Phase XX round Y [short summary]
+```
+
+## Writing rules
+
+### Round sizing
+
+One round should be:
+
+- 2-3 hours of execution time
+- 3-7 waves
+- One dominant delivery goal
+- Branch conditions when outcome is uncertain
+
+If the next step depends on whether A passes or fails, write Round 2A and Round 2B, not one oversized prompt.
+
+### Wave quality
+
+Good waves:
+
+- Fix a real broken path
+- Replace an overclaim with verified truth
+- Turn a doc concept into a real gate
+- Sync API, UI, protocol, and tests across layers
+
+Weak waves (avoid these):
+
+- "review some files"
+- "polish docs"
+- "clean up naming"
+- "do more validation" with no delivery objective
+
+### Every round must create real user value
+
+Do not write rounds that mostly rename things, restate earlier work, add surface labels without runtime truth, or repeat already-proven chains.
+
+### Force multi-layer progress
+
+Unless scope is explicitly narrowed, each round should advance:
+
+- Backend/core behavior
+- At least one user-facing surface
+- Tests
+- Docs or protocol or verification assets
+
+### Capability honesty
+
+Always distinguish and label:
+
+- `supported` -- verified working
+- `partial` -- works with caveats
+- `best_effort` -- may work, not guaranteed
+- `blocked` -- known broken, with reason
+- `unsupported` -- not applicable
+
+Never let a prompt reward inflated claims.
+
+### Branching rules
+
+When the round depends on a high-risk result:
+
+```
+If [condition A succeeds]:
+  -> proceed to Wave 3A: [productize it]
+If [condition A fails]:
+  -> fall back to Wave 3B: [alternative path]
+If [prerequisite missing]:
+  -> mark blocked, close honesty gap first
+```
+
+Do not make later waves depend on a success path that may never happen.
+
+### Constraint writing
+
+Write constraints as hard negations, not suggestions:
+
+- "Do not expand scope beyond [X]"
+- "Do not write inferred as verified"
+- "Do not add design docs"
+- "Do not modify [specific file] unless [specific condition]"
+
+### File references
+
+Always use repo-relative paths. Never write "the config file" when you can write `src/config.ts`. Repo-relative paths read the same regardless of where the repo lives on disk.
+
+### Anti-repeat rule
+
+If the prior round overclaimed or repeated earlier work, write the anti-repeat rule directly into the prompt:
+
+- "Wave 1 of Phase 5 already verified X. Do not re-verify."
+- "The following paths are already proven: [list]. Skip them."
+
+## Heuristics
+
+- If the prior round overclaimed, make honesty closure the first job
+- If the problem is strategic, write a sharper round, not a larger round
+- If a round risks repeating earlier work, write the anti-repeat rule into the prompt
+- Prefer "blocked with reason" over vague "flaky" language
+- Use exact file paths, explicit acceptance criteria, concrete dates
+- One round that closes one real gap beats three rounds that touch everything lightly
+
+## Output
+
+When using this skill, produce one of:
+
+- A complete execution-ready prompt (most common)
+- A split plan: roadmap + Round 1 prompt + branch prompts
+- A revision of an earlier phase prompt that tightens truth, scope, and gates
+
+The output should be ready to hand to an executor with zero additional conversation context, and by default should be archived under the correct project directory.

package/skills/collaboration/receiving-code-review/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: Code Review Reception
+description: Receive and act on code review feedback with technical rigor, not performative agreement or blind implementation
+when_to_use: when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable
+version: 1.1.0
+---
+
+# Code Review Reception
+
+## Overview
+
+Code review requires technical evaluation, not emotional performance.
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
+
+```
+WHEN receiving code review feedback:
+
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
+```
+
+## Forbidden Responses
+
+**NEVER:**
+- "You're absolutely right!" (explicit instruction violation)
+- "Great point!" / "Excellent feedback!" (performative)
+- "Let me implement that now" (before verification)
+
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+**Example:**
+```
+your human partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+
+❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
+✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
+```
+
+## Source-Specific Handling
+
+### From your human partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
+
+### From External Reviewers
+```
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
+
+IF suggestion seems wrong:
+  Push back with technical reasoning
+
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+
+IF conflicts with your human partner's prior decisions:
+  Stop and discuss with your human partner first
+```
+
+**your human partner's rule:** "External feedback - be skeptical, but check carefully"
+
+## YAGNI Check for "Professional" Features
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
+```
+
+**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
+
+## Implementation Order
+
+```
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
+```
+
+## When To Push Back
+
+Push back when:
+- Suggestion breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for this stack
+- Legacy/compatibility reasons exist
+- Conflicts with your human partner's architectural decisions
+
+**How to push back:**
+- Use technical reasoning, not defensiveness
+- Ask specific questions
+- Reference working tests/code
+- Involve your human partner if architectural
+
+**Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K"
+
+## Acknowledging Correct Feedback
+
+When feedback IS correct:
+```
+✅ "Fixed. [Brief description of what changed]"
+✅ "Good catch - [specific issue]. Fixed in [location]."
+✅ [Just fix it and show in the code]
+
+❌ "You're absolutely right!"
+❌ "Great point!"
+❌ "Thanks for catching that!"
+❌ "Thanks for [anything]"
+❌ ANY gratitude expression
+```
+
+**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
+
+**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
+
+## Gracefully Correcting Your Pushback
+
+If you pushed back and were wrong:
+```
+✅ "You were right - I checked [X] and it does [Y]. Implementing now."
+✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
+
+❌ Long apology
+❌ Defending why you pushed back
+❌ Over-explaining
+```
+
+State the correction factually and move on.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or just act |
+| Blind implementation | Verify against codebase first |
+| Batch without testing | One at a time, test each |
+| Assuming reviewer is right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+| Partial implementation | Clarify all items first |
+| Can't verify, proceed anyway | State limitation, ask for direction |
+
+## Real Examples
+
+**Performative Agreement (Bad):**
+```
+Reviewer: "Remove legacy code"
+❌ "You're absolutely right! Let me remove that..."
+```
+
+**Technical Verification (Good):**
+```
+Reviewer: "Remove legacy code"
+✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
+```
+
+**YAGNI (Good):**
+```
+Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
+✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
+```
+
+**Unclear Item (Good):**
+```
+your human partner: "Fix items 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
+```
+
+## The Bottom Line
+
+**External feedback = suggestions to evaluate, not orders to follow.**
+
+Verify. Question. Then implement.
+
+No performative agreement. Technical rigor always.

package/skills/collaboration/requesting-code-review/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: Requesting Code Review
+description: Dispatch code-reviewer subagent to review implementation against plan or requirements before proceeding
+when_to_use: when completing tasks, implementing major features, or before merging, to verify work meets requirements
+version: 1.1.0
+---
+
+# Requesting Code Review
+
+Dispatch code-reviewer subagent to catch issues before they cascade.
+
+**Core principle:** Review early, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code-reviewer subagent:**
+
+Use Task tool with code-reviewer type, fill template at `code-reviewer.md`
+
+**Placeholders:**
+- `{WHAT_WAS_IMPLEMENTED}` - What you just built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+- `{DESCRIPTION}` - Brief summary
+
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code-reviewer subagent]
+  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Workflows
+
+**Subagent-Driven Development:**
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+- Review after each batch (3 tasks)
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: skills/collaboration/requesting-code-review/code-reviewer.md