devlyn-cli 0.0.1

package/config/commands/devlyn.recommend-features.md

@@ -0,0 +1,286 @@
+---
+description: Recommend top 5 feature specs based on product spec and codebase
+allowed-tools: Bash(find:*), Bash(grep:*), Bash(wc:*), Bash(cat:*), Bash(ls:*), Bash(head:*), Bash(tail:*), Read, Glob
+argument-hint: [focus-area or "all"]
+---
+
+<role>
+You recommend which feature specs to generate next. Analyze product spec, existing specs, and codebase. Output top 5 prioritized by dependencies, value, and readiness.
+</role>
+
+<input>
+$ARGUMENTS
+</input>
+
+<step_1_verify>
+
+```bash
+test -f docs/product-spec.md && echo "OK" || echo "MISSING"
+```
+
+```bash
+ls docs/feature-specs/*.md 2>/dev/null || echo "NONE"
+```
+
+If product spec missing:
+
+```
+No product spec at docs/product-spec.md
+Run /product-spec first.
+```
+
+Stop.
+</step_1_verify>
+
+<step_2_read_product_spec>
+Read docs/product-spec.md.
+
+Extract:
+
+```yaml
+platform: # from meta.platform
+behaviors: # all behavior definitions
+entities: # all entity definitions
+views: # if section exists
+commands: # if CLI platform
+tools: # if MCP platform
+functions: # if library/SDK platform
+contracts: # if Web3 - contract definitions
+instructions: # if Solana - program instructions
+integrations: # external services
+phases: # phase assignments
+```
+
+</step_2_read_product_spec>
+
+<step_3_build_candidates>
+Build candidate list from product spec sections that exist:
+
+```yaml
+sources:
+  behaviors: # always - each behavior → candidate
+  views: # if exists - each view → candidate
+  commands: # if exists - each command → candidate
+  tools: # if exists - each tool → candidate
+  functions: # if exists - complex functions → candidate
+  integrations: # if has business logic → candidate
+  contracts: # if exists - each contract function → candidate
+  instructions: # if Solana - each instruction → candidate
+```
+
+For each candidate:
+
+```yaml
+name: string
+type: behavior | view | command | tool | function | integration | contract | instruction
+phase: number
+entities: [string]
+depends_on: [string]
+```
+
+</step_3_build_candidates>
+
+<step_4_check_existing_specs>
+
+```bash
+for f in docs/feature-specs/*.md; do
+  [ -f "$f" ] && echo "$(basename "$f" .md)|$(grep -m1 '^status:' "$f" 2>/dev/null | cut -d: -f2 | xargs || echo 'draft')"
+done
+```
+
+Mark each candidate:
+
+- `specced: true` if file exists
+- `spec_status: draft|ready|in-progress|done`
+
+Filter to unspecced candidates only.
+</step_4_check_existing_specs>
+
+<step_5_analyze_codebase>
+Detect stack:
+
+```bash
+ls package.json tsconfig.json pyproject.toml Cargo.toml go.mod CMakeLists.txt hardhat.config.js foundry.toml anchor.toml 2>/dev/null
+```
+
+Find source files:
+
+```bash
+find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.py" -o -name "*.go" -o -name "*.rs" -o -name "*.sol" -o -name "*.move" \) 2>/dev/null | grep -v node_modules | grep -v target | head -30
+```
+
+For each unspecced candidate:
+
+```bash
+grep -ril "{candidate_name}" src/ app/ lib/ cmd/ pkg/ contracts/ programs/ 2>/dev/null | head -3
+```
+
+Set `implementation: none | partial | exists`
+</step_5_analyze_codebase>
+
+<step_6_score>
+Score each unspecced candidate:
+
+```yaml
+dependency: # 0-30
+  30: no dependencies
+  20: all dependencies have specs
+  10: some dependencies missing specs
+  0: blocked by unspecced dependency
+
+value: # 0-25
+  25: phase 1 AND core flow
+  20: enables 2+ other features
+  15: user/developer facing
+  5: enhancement
+
+readiness: # 0-20
+  20: implementation exists
+  15: partial implementation
+  10: similar patterns exist
+  5: greenfield
+
+complexity: # 0-15 (simpler = higher)
+  15: single entity, simple logic
+  10: multiple entities, clear flow
+  5: external integration
+  0: complex state/transactions
+
+urgency: # 0-10
+  10: blocks other work
+  5: natural next step
+  2: can defer
+```
+
+`total = dependency + value + readiness + complexity + urgency`
+</step_6_score>
+
+<step_7_filter>
+If $ARGUMENTS provided and ≠ "all":
+
+```yaml
+filters:
+  core: phase = 1
+  backend: type in [behavior, integration] AND NOT ui-only
+  frontend: type = view OR has ui component
+  api: behaviors with HTTP/RPC interface
+  cli: type = command
+  sdk: type = function
+  mcp: type = tool
+  auth: name contains auth|login|session|permission
+  contract: type = contract
+  onchain: type in [contract, instruction]
+  solana: type = instruction
+  { entity }: entities includes {entity}
+  { phase_N }: phase = N
+```
+
+If no matches:
+
+```
+No unspecced features match "{$ARGUMENTS}".
+
+Available filters:
+{list applicable filters with counts}
+
+Try: /recommend-features all
+```
+
+Stop.
+</step_7_filter>
+
+<step_8_output>
+Sort by total score descending. Take top 5.
+
+```markdown
+## Feature Recommendations
+
+**Product Spec:** v{version} · {platform} · {behavior_count} behaviors
+**Existing Specs:** {count} ({done} done, {in_progress} in-progress)
+**Focus:** {$ARGUMENTS or "all"}
+
+---
+
+### #1: {name}
+
+**Score: {total}/100** · Phase {phase} · {type}
+
+{One sentence why this ranks highest}
+
+- Product Spec: `{section}.{name}`
+- Entities: {list}
+- Implementation: {status} {files if any}
+- Dependencies: {✅ | ⏳ | ❌} {names}
+```
+
+/feature-spec {name}
+
+```
+
+---
+
+### #2: {name}
+**Score: {total}/100** · Phase {phase} · {type}
+
+{reason}
+
+- Product Spec: `{section}.{name}`
+- Entities: {list}
+- Implementation: {status}
+- Dependencies: {status}
+
+```
+
+/feature-spec {name}
+
+```
+
+---
+
+### #3: {name}
+{same format}
+
+---
+
+### #4: {name}
+{same format}
+
+---
+
+### #5: {name}
+{same format}
+
+---
+
+## Dependency Order
+
+{blocking relationships}
+
+## Deferred
+
+| Feature | Blocked By |
+|---------|------------|
+| {name} | {dependency} |
+```
+
+</step_8_output>
+
+<all_specced>
+If all candidates have specs:
+
+```markdown
+## All Features Specced
+
+**Specs:** {count}
+
+- Done: {n}
+- In Progress: {n}
+- Draft: {n}
+
+Next:
+
+1. Review drafts
+2. Add features to product spec
+```
+
+</all_specced>

package/config/commands/devlyn.resolve.md

@@ -0,0 +1,108 @@
+Perform deep root cause analysis for the following issue. Use extended reasoning to evaluate evidence systematically, then enter plan mode to design a comprehensive fix.
+
+<issue>
+$ARGUMENTS
+</issue>
+
+<default_to_plan_mode>
+After completing root cause analysis, enter plan mode before implementing fixes. This ensures the user can review your understanding of the problem and approve your approach before changes are made.
+
+Only skip plan mode if ALL conditions are true:
+- Single-line or trivial change (typo, obvious syntax error)
+- Exactly one correct solution with no alternatives
+- Single file affected with no side effects
+
+When in doubt, enter plan mode.
+</default_to_plan_mode>
+
+<investigate_before_answering>
+ALWAYS read and inspect relevant files before forming hypotheses. Do not speculate about code you have not opened.
+
+1. Read relevant files and error logs
+2. Trace execution path from symptom to source
+3. Map the code paths involved:
+
+```
+Entry: `file.ts:123` functionName()
+  → calls `other.ts:45` helperFunction()
+    → calls `service.ts:89` apiCall()
+      → potential issue here
+```
+
+4. Find related test files that cover this area
+5. Verify each assumption with actual code inspection
+
+Evidence-based reasoning only. Every claim must reference specific file:line.
+</investigate_before_answering>
+
+<analysis_approach>
+Apply the 5 Whys technique when root cause is not immediately obvious:
+- Ask "why did this happen?" until you reach the fundamental cause
+- Stop when you identify something actionable
+- Document each "why" with supporting evidence
+
+Generate 2-3 hypotheses with evidence:
+1. **[Hypothesis]** - Evidence: [what supports this]
+2. **[Hypothesis]** - Evidence: [what supports this]
+</analysis_approach>
+
+<test_driven_validation>
+Before implementing the fix:
+
+1. **Write a failing test** that reproduces the bug
+2. **Implement fix** for most likely hypothesis
+3. **Run test** - if fails, revert and try next hypothesis
+4. **Iterate** until test passes
+5. **Run full test suite** to check for regressions
+
+If fix doesn't work, revert completely before trying next approach. Never layer fixes on top of failed attempts.
+</test_driven_validation>
+
+<no_fallbacks_or_workarounds>
+Implement a robust fix that addresses the actual root cause. Do not:
+- Add defensive fallbacks that mask problems (e.g., `|| defaultValue`)
+- Hard-code values for the specific failing case
+- Suppress errors without resolving the cause
+- Use optional chaining (?.) to bypass null when null is the bug
+
+Instead:
+- Fix the code path that produces incorrect state
+- Ensure solution works for all valid inputs
+- Follow codebase's existing patterns
+- Escalate blockers rather than shipping fragile patches
+</no_fallbacks_or_workarounds>
+
+<use_parallel_tool_calls>
+Read multiple potentially relevant files in parallel. If the issue might involve 3 modules, read all 3 simultaneously.
+</use_parallel_tool_calls>
+
+<output_format>
+Present findings before entering plan mode:
+
+<root_cause_analysis>
+**Symptom**: [What the user observed]
+**Code Path**: [Entry point → ... → issue location with file:line]
+**Root Cause**: [Fundamental issue with specific file:line]
+**Hypotheses Tested**: [Which hypotheses were validated/invalidated]
+**Why it matters**: [Impact if unfixed]
+**Complexity**: [Simple fix / Multiple files / Architectural change]
+</root_cause_analysis>
+
+After fix is implemented:
+
+<resolution>
+**Fix Applied**: [file:line - what changed and why]
+**Test Added**: [test file - what it validates]
+**Verification**:
+- [ ] Failing test now passes
+- [ ] No regressions in test suite
+- [ ] Manual verification (if applicable)
+</resolution>
+</output_format>
+
+<next_steps>
+1. If Complexity beyond "Simple fix" → enter plan mode immediately
+2. In plan mode, present fix options if multiple valid solutions exist
+3. Write failing test before implementing
+4. Only mark complete after full test suite passes
+</next_steps>

package/config/commands/devlyn.review.md

@@ -0,0 +1,99 @@
+Perform a comprehensive post-implementation review. After receiving tool results, carefully reflect on their quality and determine optimal next steps before proceeding.
+
+<procedure>
+1. Run `git diff --name-only HEAD` to get all changed files
+2. Read all changed files in parallel (use parallel tool calls)
+3. Check each file against the review checklist below
+4. Fix issues directly—do not just suggest fixes
+5. Run test suite to verify changes don't break existing functionality
+6. If tests fail → use devlyn.resolve workflow to fix, then re-run tests
+7. Generate summary report with file:line references
+8. Block approval if any CRITICAL or HIGH issues remain unfixed OR tests fail
+</procedure>
+
+<investigate_before_fixing>
+ALWAYS read files before proposing edits. Do not speculate about code you have not inspected. Verify assumptions by reading actual implementation. Give grounded, hallucination-free assessments.
+</investigate_before_fixing>
+
+<use_parallel_tool_calls>
+Make all independent tool calls in parallel. When reviewing 5 files, run 5 read calls simultaneously. Only execute sequentially when edits depend on prior reads. Never guess parameters.
+</use_parallel_tool_calls>
+
+<review_checklist>
+
+## CRITICAL — Security (must fix, blocks approval)
+
+Security vulnerabilities can cause data breaches and system compromise:
+
+- Hardcoded credentials, API keys, tokens, secrets
+- SQL injection (unsanitized queries)
+- XSS (unescaped user input in HTML/JSX)
+- Missing input validation at system boundaries
+- Insecure dependencies (known CVEs)
+- Path traversal (unsanitized file paths)
+
+## HIGH — Code Quality (must fix, blocks approval)
+
+These issues cause bugs or significant maintenance burden:
+
+- Functions > 50 lines → split
+- Files > 800 lines → decompose
+- Nesting > 4 levels → flatten or extract
+- Missing error handling at boundaries
+- `console.log` in production code → remove
+- Unresolved TODO/FIXME → resolve or remove
+- Missing JSDoc for public APIs
+
+## MEDIUM — Best Practices (fix or justify)
+
+- Mutation where immutable patterns preferred
+- Missing tests for new functionality
+- Accessibility gaps (alt text, ARIA, keyboard nav)
+- Inconsistent naming or structure
+- Over-engineering: unnecessary abstractions, unused config, premature optimization
+
+## LOW — Cleanup (fix if quick)
+
+- Unused imports/dependencies
+- Unreferenced functions/variables
+- Commented-out code
+- Obsolete files
+
+</review_checklist>
+
+<action_instructions>
+For each issue:
+
+1. State severity, file:line
+2. One sentence: what and why it matters
+3. Make the fix immediately
+4. Continue to next issue
+
+Be persistent. Complete the full review before stopping.
+</action_instructions>
+
+<output_format>
+<review_summary>
+
+### Review Complete
+
+**Approval**: [BLOCKED / APPROVED]
+
+- BLOCKED if any CRITICAL or HIGH issues remain unfixed OR tests fail
+
+**Tests**: [PASS / FAIL]
+- [test summary or failure details]
+
+**Fixed**:
+- [CRITICAL] file.ts:42 — Removed hardcoded API key
+- [HIGH] utils.ts:156 — Split 80-line function
+
+**Verified**:
+- Authentication flow handles edge cases
+- Input validation at API boundaries
+
+**Deferred** (with justification):
+- [MEDIUM] Missing tests — existing coverage adequate for hotfix
+
+</review_summary>
+</output_format>