mirror of
https://github.com/jparkerweb/plan2code.git
synced 2026-07-21 18:33:22 -07:00
v1.14.0 — add Step 3b review workflow, unify file naming, resilient code references
- Add /plan2code-3b-review: 5-step post-implementation review with adaptive scope, 11 dimensions, reference-file architecture, and Plan/Apply/Verify fixes - Unify workflow/skill file naming to single-dash (drop -- and --- conventions) - Add Devin platform support and CLAUDE.md MANDATORY FIRST STEP template - Guide agents to use semantic anchors over line numbers in workflow prompts - Bump version to 1.14.0
This commit is contained in:
@@ -23,7 +23,7 @@ Check if `./AGENTS.md` exists:
|
||||
>
|
||||
> "No `AGENTS.md` found. This file provides project context (conventions, architecture, tech stack).
|
||||
>
|
||||
> **To create it:** `plan2code---init`
|
||||
> **To create it:** `plan2code-init`
|
||||
>
|
||||
> Let me know when ready to continue."
|
||||
|
||||
@@ -157,7 +157,7 @@ State assessment and ask user to confirm.
|
||||
3. Create `specs/<feature-name>/PLAN-DRAFT-<YYYYMMDD>.md` with Phases 1-3
|
||||
4. Set status: `Phase 3 Complete - Resume at Phase 4`
|
||||
5. Include: Executive Summary, Requirements, System Context, Scope, Confidence
|
||||
6. Instruct: "Large project. Progress saved. Start NEW conversation with `/plan2code-1--plan` to resume at Phase 4."
|
||||
6. Instruct: "Large project. Progress saved. Start NEW conversation with `/plan2code-1-plan` to resume at Phase 4."
|
||||
7. STOP
|
||||
|
||||
### PHASE 4: Tech Stack
|
||||
@@ -210,7 +210,7 @@ State assessment and ask user to confirm.
|
||||
2. Create `specs/<feature-name>/` if needed
|
||||
3. Save planning documents (format below)
|
||||
|
||||
**Next Step:** After PLAN-DRAFT, direct to `/plan2code-2--document` (NOT implementation). Workflow: Plan -> Document -> Implement -> Finalize.
|
||||
**Next Step:** After PLAN-DRAFT, direct to `/plan2code-2-document` (NOT implementation). Workflow: Plan -> Document -> Implement -> Finalize.
|
||||
|
||||
**If < 90%:**
|
||||
- List areas needing clarification (reference dimension)
|
||||
@@ -263,7 +263,7 @@ Sections:
|
||||
|
||||
When complete (PLAN-DRAFT created), tell user:
|
||||
1. What was accomplished
|
||||
2. **Next: `/plan2code-2--document`** (NOT implementation)
|
||||
2. **Next: `/plan2code-2-document`** (NOT implementation)
|
||||
3. Documentation auto-discovers planning files
|
||||
|
||||
**Closing example:**
|
||||
@@ -279,7 +279,7 @@ When complete (PLAN-DRAFT created), tell user:
|
||||
> ╰───╯
|
||||
> =============================================
|
||||
> NEXT STEP: Start a NEW conversation then run:
|
||||
> `/plan2code-2--document`
|
||||
> `/plan2code-2-document`
|
||||
> ```"
|
||||
|
||||
## Abort / Recovery
|
||||
@@ -293,6 +293,6 @@ When complete (PLAN-DRAFT created), tell user:
|
||||
- Final phase: PLANNING PHASE 7: Transition Decision
|
||||
- Do NOT implement - design and present plan only
|
||||
- Responses start with: `🤔 [PLANNING PHASE X: Name]`
|
||||
- **Workflow:** Plan -> Document -> Implement -> Finalize. After planning: `/plan2code-2--document`
|
||||
- **Workflow:** Plan -> Document -> Implement -> Finalize. After planning: `/plan2code-2-document`
|
||||
- Save conversation log (7A) before PLAN-DRAFT (7B), run verification (7C) after
|
||||
- Run verification (7C) after PLAN-DRAFT - conversation log is source of truth
|
||||
@@ -91,6 +91,8 @@ Proceed with revision? (yes / no / discuss)
|
||||
|
||||
`🔄 [REVISION] Step 3: Execute Revisions`
|
||||
|
||||
**Code references:** When writing or revising task descriptions, never use line numbers as primary references — they become stale as tasks modify files. Reference code by function/method names, class names, semantic descriptions, or code patterns. Line numbers may only appear as supplemental context (e.g., "Update `validateEmail()` (currently ~L45) to...").
|
||||
|
||||
1. Update affected tasks with `🔄 REVISED` flag:
|
||||
|
||||
```markdown
|
||||
@@ -178,7 +180,7 @@ Report and resolve issues before proceeding.
|
||||
║ Specs have been updated. To continue implementation: ║
|
||||
║ ║
|
||||
║ 1. Start a NEW conversation ║
|
||||
║ 2. Use command: /plan2code-3--implement ║
|
||||
║ 2. Use command: /plan2code-3-implement ║
|
||||
║ 3. Provide path: specs/<feature-name>/overview.md ║
|
||||
║ ║
|
||||
║ The command will auto-detect the next Phase to implement. ║
|
||||
@@ -37,7 +37,7 @@ If no PLAN-DRAFT found and user hasn't provided one, ask for:
|
||||
|
||||
If no plan exists and user wants to skip:
|
||||
> "Documentation transforms planning into specs. Without a plan, either:
|
||||
> 1. Run planning first (`/plan2code-1--plan`)
|
||||
> 1. Run planning first (`/plan2code-1-plan`)
|
||||
> 2. Describe requirements so I can help create a minimal plan"
|
||||
|
||||
## Phase Sizing
|
||||
@@ -60,6 +60,14 @@ If no plan exists and user wants to skip:
|
||||
| Action-oriented | Imperative: "Create...", "Implement..." |
|
||||
| Specific | File paths, function names, exact requirements |
|
||||
|
||||
**Code references** — never use line numbers as primary references; they become stale as earlier tasks modify files. Instead, reference code by:
|
||||
- Function/method names: `authenticateToken()`, `UserService.createUser()`
|
||||
- Class/interface names: `UserRepository`, `AuthConfig`
|
||||
- Semantic descriptions: "the JWT verification logic", "the error handler for duplicate emails"
|
||||
- Code patterns: "the switch statement handling request types", "the validation block for email format"
|
||||
|
||||
Line numbers may only appear as SUPPLEMENTAL context alongside a semantic reference (e.g., "Update `validateEmail()` (currently ~L45) to...").
|
||||
|
||||
**Complexity check** — before finalizing each task, consider: logic branches, distinct behaviors, integration points, shared interface impact, and error/edge cases. Tasks that are complex on 3+ of these signals should be split.
|
||||
|
||||
**Examples:**
|
||||
@@ -206,7 +214,7 @@ Replace values with actuals. `verification_items_added` = total Added column fro
|
||||
**Tell user:**
|
||||
1. What was created (spec files list)
|
||||
2. Path for next session: `specs/<feature-name>/overview.md`
|
||||
3. Next command: `/plan2code-3--implement`
|
||||
3. Next command: `/plan2code-3-implement`
|
||||
4. Start NEW conversation for implementation
|
||||
|
||||
**Closing example:**
|
||||
@@ -220,7 +228,7 @@ Replace values with actuals. `verification_items_added` = total Added column fro
|
||||
> ╰───╯
|
||||
> ============================================
|
||||
> NEXT STEP: Start a NEW conversation and run:
|
||||
> `/plan2code-3--implement`
|
||||
> `/plan2code-3-implement`
|
||||
> ```"
|
||||
|
||||
## Abort Handling
|
||||
@@ -240,4 +248,4 @@ If user says "abort", "cancel", "start over":
|
||||
|
||||
## Session Hint
|
||||
|
||||
If you discovered project-specific insights during documentation, suggest `/plan2code---init-update` to capture them in `AGENTS.md`.
|
||||
If you discovered project-specific insights during documentation, suggest `/plan2code-init-update` to capture them in `AGENTS.md`.
|
||||
@@ -85,6 +85,7 @@ Only show consecutive same-group incomplete phases. After selection, mark `[/]`,
|
||||
| No extra files | Only create files mentioned in tasks |
|
||||
| Minimal dependencies | No packages outside approved tech stack |
|
||||
| No placeholder code | Fully implement every function |
|
||||
| Verify locations | Treat any line numbers in specs as approximate — read the file and locate by function/symbol name |
|
||||
|
||||
## Examples
|
||||
|
||||
@@ -200,9 +201,10 @@ On user "approved":
|
||||
1. Mark `[/]` → `[x]` in overview.md, update phase-X.md status to "Complete"
|
||||
2. Show Planny art with completion message
|
||||
3. Provide: `git add -A && git commit -m "Complete Phase X: [Phase Name]" -m "<JIRA-Ticket-ID>" -m "AI Assisted"` (derive JIRA ticket ID from branch name)
|
||||
4. **If more phases:** "NEXT STEP: Start NEW conversation and run: `/plan2code-3--implement`"
|
||||
5. **If final phase:** "NEXT STEP: Start NEW conversation and run: `/plan2code-4--finalize`"
|
||||
6. Mention `/plan2code-1b--revise` option
|
||||
4. **If more phases:** "NEXT STEP: Start NEW conversation and run: `/plan2code-3-implement`"
|
||||
5. **If final phase:** "NEXT STEP: Start NEW conversation and run: `/plan2code-4-finalize`"
|
||||
6. Mention `/plan2code-1b-revise-plan` option
|
||||
7. Suggest: "Optional: run `/plan2code-3b-review` for a post-phase code review -- recommended after key features or milestones."
|
||||
|
||||
Planny (continuing):
|
||||
```
|
||||
@@ -230,7 +232,7 @@ If user says "abort", "cancel", or similar:
|
||||
- List completed vs remaining tasks
|
||||
- Note created/modified files
|
||||
- Do NOT change phase checkbox (stays `[/]`)
|
||||
- Explain: "Run `/plan2code-3--implement` again to resume."
|
||||
- Explain: "Run `/plan2code-3-implement` again to resume."
|
||||
3. Stop implementation
|
||||
|
||||
## Recovery
|
||||
@@ -239,7 +241,7 @@ If user says "abort", "cancel", or similar:
|
||||
|-------|----------|
|
||||
| Lost context mid-phase | Attach specs, say "resume from Task X.Y" |
|
||||
| Spec unclear/conflicting | Mark task blocked, ask user |
|
||||
| Need to change plan | Pause, use `/plan2code-1b--revise-plan` |
|
||||
| Need to change plan | Pause, use `/plan2code-1b-revise-plan` |
|
||||
|
||||
## Learning Capture
|
||||
|
||||
@@ -0,0 +1,191 @@
|
||||
# Dimension Checklists
|
||||
> Part of plan2code-3b-review — loaded during Step 3 (Analyze).
|
||||
|
||||
Non-obvious check items, anti-patterns, and "don't flag" guidance for each review dimension. Focus on what LLMs commonly miss.
|
||||
|
||||
---
|
||||
|
||||
## 1. Correctness
|
||||
|
||||
1. Trace variable mutations through async paths — can a value change between check and use?
|
||||
2. Check type coercion at boundaries — string-to-number, truthy/falsy assumptions on `0`/`""`/`false`
|
||||
3. Check that map/filter/reduce callbacks handle all element shapes (null members, missing keys)
|
||||
4. Verify copy operations produce deep copies when mutation independence is required
|
||||
5. Check array bounds — does code handle empty arrays and out-of-range indices?
|
||||
6. Verify regex patterns reject edge cases (empty string, special chars, Unicode)
|
||||
7. Check for race conditions — shared mutable state across async reads/writes
|
||||
8. Verify error handling paths return/throw correctly — no silent swallowing
|
||||
|
||||
**Anti-patterns:** `catch(e) {}` silent suppression · `if (value)` when `0`/`""`/`false` are valid · `indexOf > 0` instead of `!== -1` · Mutating arguments instead of returning new values
|
||||
|
||||
**Don't flag:** Intentional `==` for null coalescing (`if (x == null)`) · Missing switch default with TypeScript `never` exhaustive check · Optional chaining `?.` returning undefined
|
||||
|
||||
---
|
||||
|
||||
## 2. Completeness
|
||||
|
||||
1. Search for TODO, FIXME, HACK, XXX, TEMP — each must be intentional or tracked
|
||||
2. Check cleanup/teardown exists for every setup/initialization
|
||||
3. Verify rollback/undo logic for multi-step operations that can partially fail
|
||||
4. Check event listeners and subscriptions have corresponding unsubscribe/cleanup
|
||||
5. Verify all file/resource handles closed in both success and error paths
|
||||
6. Check all enum/union type values have handling — no missing cases
|
||||
7. Verify pagination — does code fetch all pages or just the first?
|
||||
8. Check retry logic has backoff and maximum retry count
|
||||
|
||||
**Anti-patterns:** Happy-path-only functions that return undefined on error · Event listeners without cleanup · Missing else in critical chains where the "impossible" case can occur
|
||||
|
||||
**Don't flag:** TODOs with linked ticket numbers · Features explicitly "not in scope" · Bare `throw` in catch blocks (intentional re-throw)
|
||||
|
||||
---
|
||||
|
||||
## 3. Security
|
||||
|
||||
1. Check for injection — string concatenation in queries instead of parameterized
|
||||
2. Search for hardcoded secrets, API keys, tokens in source files and configs
|
||||
3. Verify sensitive data (passwords, tokens, PII) is not logged, even at debug level
|
||||
4. Check file path operations prevent traversal — no unsanitized `../` from user input
|
||||
5. Check for mass assignment — `Object.assign`/spread from user input without allow-list
|
||||
6. Verify error responses don't leak stack traces, internal paths, or system info
|
||||
7. Verify session tokens use cryptographic randomness, not `Math.random()`
|
||||
8. Check dependency versions against known CVEs
|
||||
|
||||
**Anti-patterns:** Dynamic code evaluation with user-influenced input · Plaintext password storage · JWT `none` algorithm accepted
|
||||
|
||||
**Don't flag:** Hardcoded non-sensitive values (page sizes, route paths) · Internal tools documented as trusted-environment-only · Test fixture credentials in `.test.`/`.fixture.` files
|
||||
|
||||
---
|
||||
|
||||
## 4. Performance
|
||||
|
||||
1. Check for N+1 queries — loops issuing a query per iteration instead of batching
|
||||
2. Check for synchronous blocking in async contexts (fs.readFileSync in server request handlers)
|
||||
3. Check for memory leaks — growing arrays/maps without bounds, unclosed streams
|
||||
4. Check for quadratic complexity — nested iterations over the same collection
|
||||
5. Verify bulk operations used where available (bulk insert vs individual)
|
||||
6. Check regex for catastrophic backtracking potential (nested quantifiers)
|
||||
7. Verify connection pools for database and HTTP clients, not per-request connections
|
||||
8. Check event handlers debounced/throttled for high-frequency events
|
||||
|
||||
**Anti-patterns:** `await` in `for` loops instead of `Promise.all` · Loading entire tables to filter in app code · New regex instances inside loops
|
||||
|
||||
**Don't flag:** `readFileSync` at startup/module load · Loading small files (<100KB) once · Missing caching in one-shot scripts/CLI tools
|
||||
|
||||
---
|
||||
|
||||
## 5. Standards
|
||||
|
||||
1. Check function length — functions over 50 lines warrant scrutiny
|
||||
2. Verify DRY applied judiciously — shared logic extracted, not over-abstracted
|
||||
3. Check magic numbers/strings are extracted to named constants
|
||||
4. Verify comments explain "why" not "what"
|
||||
5. Check file organization matches project conventions
|
||||
6. Verify consistent async/await vs callbacks vs promises within a module
|
||||
7. Check naming conventions consistent (camelCase, snake_case, PascalCase)
|
||||
8. Verify linting rules not disabled without justification
|
||||
|
||||
**Anti-patterns:** Mixed naming conventions in one module · God objects/functions · Deep nesting (>3 levels) instead of early returns
|
||||
|
||||
**Don't flag:** Framework-imposed patterns · Single-use helpers for readability · Comments on complex algorithms/regex
|
||||
|
||||
---
|
||||
|
||||
## 6. Tech Debt
|
||||
|
||||
1. Check for deprecated API usage — verify against current library versions
|
||||
2. Identify commented-out code blocks — should be removed or tracked
|
||||
3. Check for copy-paste blocks that could be shared utilities
|
||||
4. Look for dead feature flags — always true/false with no toggle
|
||||
5. Check for orphaned files — modules with no imports from the codebase
|
||||
6. Verify error messages reference current code, not stale names
|
||||
7. Check for inconsistent abstraction levels — mixing orchestration with low-level ops
|
||||
8. Look for workarounds with "temporary" comments that persisted
|
||||
|
||||
**Anti-patterns:** `TODO: remove after migration` with no date/ticket · Wrapper functions that just forward args · Multiple implementations of the same utility
|
||||
|
||||
**Don't flag:** Intentional per-platform duplication · Verbose code prioritizing clarity · Deprecated APIs with tracked migration tickets
|
||||
|
||||
---
|
||||
|
||||
## 7. Test Quality
|
||||
|
||||
1. Check assertions are meaningful — not just `toBeTruthy()` on objects
|
||||
2. Verify tests are isolated — no shared mutable state between cases
|
||||
3. Check error case tests actually trigger the error path, not just catch any error
|
||||
4. Verify async tests properly await results — no fire-and-forget assertions
|
||||
5. Check for tests that pass for wrong reason — wrong assertion target, always-true conditions
|
||||
6. Verify mock/stub scope is minimal — only mock what's necessary
|
||||
7. Check test descriptions describe behavior, not implementation
|
||||
8. Verify critical paths have coverage — happy path, error path, edge cases
|
||||
|
||||
**Anti-patterns:** `expect(fn).not.toThrow()` without checking return value · Mocking the module under test · Assertions in callbacks that may never execute
|
||||
|
||||
**Don't flag:** Shared test utility files · Missing tests for generated/scaffolded code · Integration tests using real databases when project prefers it
|
||||
|
||||
---
|
||||
|
||||
## 8. Maintainability
|
||||
|
||||
1. Check cyclomatic complexity — functions with >10 branch paths are hard to maintain
|
||||
2. Verify dependencies between modules are explicit, not implicit through globals
|
||||
3. Check for tight coupling — can this module be tested independently?
|
||||
4. Verify data transformations are traceable — can you follow a value from input to output?
|
||||
5. Check file length — files over 500 lines warrant scrutiny
|
||||
6. Verify similar operations use consistent approaches throughout
|
||||
7. Check boolean parameters are replaced with enums or option objects for clarity
|
||||
8. Verify function/variable names describe purpose without needing comments
|
||||
|
||||
**Anti-patterns:** Functions requiring implementation knowledge to call · Circular dependencies · God files · Stringly-typed APIs
|
||||
|
||||
**Don't flag:** Long cohesive files (comprehensive test suites) · Inherently complex domain functions · Coupling between genuinely related modules
|
||||
|
||||
---
|
||||
|
||||
## 9. Spec Compliance
|
||||
|
||||
1. Verify every acceptance criterion has corresponding implementation
|
||||
2. Check file paths, names, directory structures match spec exactly
|
||||
3. Verify implementation doesn't add undocumented behavior beyond spec
|
||||
4. Check all spec-defined edge cases have explicit handling
|
||||
5. Verify task completion state in phase files matches actual implementation
|
||||
6. Check integration points match spec contracts
|
||||
7. Verify function signatures match spec definitions
|
||||
8. Check data formats match spec (JSON schema, file formats)
|
||||
|
||||
**Anti-patterns:** Implementing a "better" approach without raising the divergence · Assuming spec intent on ambiguous points · Marking tasks complete when implementation differs
|
||||
|
||||
**Don't flag:** Minor naming variations preserving intent · Defensive coding beyond spec · Details spec leaves to developer judgment
|
||||
|
||||
---
|
||||
|
||||
## 10. UX/DX
|
||||
|
||||
1. Verify error messages are actionable — tell user what to do, not just what went wrong
|
||||
2. Check empty states have clear messaging — not blank pages or silent failures
|
||||
3. Verify configuration has sensible defaults — zero-config produces working setup
|
||||
4. Check breaking changes are communicated — deprecation warnings, migration guides
|
||||
5. Verify CLI tools have `--help`, consistent flags, meaningful exit codes
|
||||
6. Check bulk operations provide progress feedback and handle partial failures
|
||||
7. Verify documentation examples are runnable, not pseudo-code
|
||||
8. Check loading states exist for operations over 1 second
|
||||
|
||||
**Anti-patterns:** Stack traces shown to end users · Required config with no example file · 200 OK with error in body · Silent failures
|
||||
|
||||
**Don't flag:** Verbose debug output · Internal tooling with minimal polish · CLI tools requiring initial setup
|
||||
|
||||
---
|
||||
|
||||
## 11. Improvements
|
||||
|
||||
1. Check for manual implementations of standard library functionality
|
||||
2. Identify error-prone patterns replaceable with safer abstractions
|
||||
3. Look for synchronous operations that could be parallelized
|
||||
4. Identify complex conditionals clearer as lookup tables or strategy patterns
|
||||
5. Check for hardcoded limits that should be configurable
|
||||
6. Look for opportunities to improve test coverage on critical paths
|
||||
7. Identify documentation gaps — undocumented public APIs
|
||||
8. Check for opportunities to use newer language features improving clarity
|
||||
|
||||
**Anti-patterns:** Rewrites for aesthetic reasons · Patterns from different ecosystems · Optimizations without evidence of problems · Premature DRY abstractions
|
||||
|
||||
**Don't flag:** Correct code written differently than you'd write it · Performance appropriate for actual load · Features tracked in backlog
|
||||
@@ -0,0 +1,105 @@
|
||||
# False-Positive Catalog
|
||||
> Part of plan2code-3b-review — loaded before presenting findings in Step 3 (Analyze).
|
||||
|
||||
Check every finding against this catalog before presenting it. These patterns represent common categories of false findings that waste reviewer and developer time. Each entry includes the bias, a concrete example, why it's wrong, and how to verify before flagging.
|
||||
|
||||
---
|
||||
|
||||
## 1. Optimization Bias
|
||||
|
||||
**Pattern:** Recommending removal or reduction of something to optimize a metric (context size, file count, memory, line count) when the thing being removed is necessary for correctness.
|
||||
|
||||
**Example:** Reviewer recommends removing `jira-api-catalog.md` and `jira-field-schema.md` from agent read loading to "reduce context overhead." The reviewer sees large files being loaded and assumes smaller context = better performance.
|
||||
|
||||
**Why it's wrong:** Agents consume these files at runtime to know which API endpoints exist and what fields are available. Without them, agents construct invalid API calls. The "overhead" is actually essential working knowledge. Optimizing for context size sacrificed correctness.
|
||||
|
||||
**How to check before flagging:**
|
||||
1. Identify what metric you're optimizing (file count, context size, line count, memory).
|
||||
2. Ask: "What happens if this is removed?" Trace the downstream impact.
|
||||
3. Search for all consumers of the thing you want to remove — not just direct imports, but Read directives, config references, and runtime loading.
|
||||
4. If any consumer depends on it for correct execution, the finding is invalid.
|
||||
|
||||
---
|
||||
|
||||
## 2. Simplification Bias
|
||||
|
||||
**Pattern:** Recommending consolidation or simplification of something that is intentionally structured for separation of concerns, different consumers, or independent evolution.
|
||||
|
||||
**Example:** Reviewer flags that `config/platforms/windsurf.json` and `config/platforms/cursor.json` have "similar structure" and recommends consolidating into `flat-file-platforms.json` to "reduce duplication."
|
||||
|
||||
**Why it's wrong:** The per-platform files exist deliberately. Each platform has distinct frontmatter requirements, path conventions, and feature flags. They share a common schema but contain different values. Consolidation would require conditionals everywhere and make per-platform changes harder. The separation is a design choice, not an oversight.
|
||||
|
||||
**How to check before flagging:**
|
||||
1. Ask: "Why are these separate?" Read the commit history or documentation for context.
|
||||
2. Check if the "duplicated" files serve different consumers or contexts.
|
||||
3. Verify whether the files are expected to diverge further over time.
|
||||
4. If separation serves independent evolution, different consumers, or different deployment targets, the finding is invalid.
|
||||
|
||||
---
|
||||
|
||||
## 3. Duplication False Alarm
|
||||
|
||||
**Pattern:** Flagging intentional redundancy as a DRY violation when the similar-looking code serves genuinely different purposes or domains.
|
||||
|
||||
**Example:** Reviewer flags that `handleTicketCreate()` and `handleTicketUpdate()` share 80% of their code and recommends extracting a common `handleTicketMutation()`. Both functions validate input, call the API, and format the response — but they use different validation rules, different API endpoints, different error messages, and different response transformations.
|
||||
|
||||
**Why it's wrong:** The structural similarity is coincidental. Each function handles a distinct domain operation with distinct requirements. Extracting a common function would create a complex conditional monster that's harder to maintain than two clear, self-contained handlers. DRY applies to shared knowledge, not shared structure.
|
||||
|
||||
**How to check before flagging:**
|
||||
1. Compare the "duplicate" functions at the detail level, not the structural level.
|
||||
2. Ask: "If I change one, should the other change identically?" If no, they're not duplicates.
|
||||
3. Check if the functions handle different domain concepts, even if the code shape is similar.
|
||||
4. If combining them would require conditionals or parameters to differentiate behavior, the separation is likely intentional.
|
||||
|
||||
---
|
||||
|
||||
## 4. Performance Theater
|
||||
|
||||
**Pattern:** Flagging operations as "too expensive" when the operation is not in a hot path, runs infrequently, or when the "cost" is actually necessary for correctness.
|
||||
|
||||
**Example:** Reviewer flags that the installer reads 15 platform configuration files at startup and recommends lazy loading. The installer runs once during setup, takes <200ms total, and needs all configurations to determine which platforms to install.
|
||||
|
||||
**Why it's wrong:** The installer is a one-shot CLI tool, not a server handling concurrent requests. Startup performance of a tool that runs once per install is irrelevant. The "optimization" would add complexity (lazy loading, caching, error handling for deferred loads) with zero user-visible benefit.
|
||||
|
||||
**How to check before flagging:**
|
||||
1. Determine the execution context: Is this a hot path (server request handler, tight loop) or a cold path (startup, CLI command, migration script)?
|
||||
2. Measure or estimate the actual cost. "Reads many files" is not a performance issue if total I/O is <1 second.
|
||||
3. Ask: "Would a user notice the difference?" If the answer is no, the optimization is theater.
|
||||
4. Check whether the "expensive" operation is necessary for correctness — if so, optimization means finding a faster way to do it, not skipping it.
|
||||
|
||||
---
|
||||
|
||||
## 5. Missing Context
|
||||
|
||||
**Pattern:** Flagging something as wrong, unused, or unnecessary because the reviewer didn't read all related files, packages, or documentation before forming a conclusion.
|
||||
|
||||
**Example:** Reviewer flags `export function formatJiraKey()` in `utils/jira.ts` as "unused export — remove or make private." The function is not imported in any file within the current package.
|
||||
|
||||
**Why it's wrong:** The function is consumed by a different package in the monorepo (`packages/cli/src/commands/jira.ts`). The reviewer only searched the current package directory, not the entire workspace. Cross-package consumption is common in monorepos and multi-package projects.
|
||||
|
||||
**How to check before flagging:**
|
||||
1. Search the ENTIRE codebase for references, not just the current package or directory.
|
||||
2. Check for dynamic imports, string-based requires, and config-driven module loading.
|
||||
3. For exports: search all packages in the workspace, not just the current one.
|
||||
4. For files: check build scripts, installation scripts, CI/CD configs, and documentation references.
|
||||
5. If you can't find all consumers, state that explicitly rather than assuming there are none.
|
||||
|
||||
---
|
||||
|
||||
## Detection Shortcuts
|
||||
|
||||
Quick checks to run against any finding before presenting. If a check triggers, investigate further before flagging.
|
||||
|
||||
- **Does the finding recommend removing or simplifying something?** Trace who consumes it first. Search all packages, config files, scripts, and documentation for references. "I didn't find references in this file" is not "nothing references this."
|
||||
|
||||
- **Does the finding flag duplication?** Check if the "duplicates" serve different consumers, contexts, or domain concepts. Ask: "If I change one, must the other change identically?" If no, they aren't duplicates.
|
||||
|
||||
- **Does the finding flag performance?** Verify the operation is actually in a hot path. CLI tools, installers, migration scripts, and one-shot operations don't need the same performance treatment as request handlers.
|
||||
|
||||
- **Does the finding flag unused code?** Search ALL packages, consumers, and entry points — not just the current file or directory. Check for dynamic loading, Read directives, and cross-package imports.
|
||||
|
||||
- **Does the finding assume a different architecture?** Verify against AGENTS.md, README, and actual project conventions. The project may have deliberately chosen a pattern that differs from your preferred approach.
|
||||
|
||||
- **Does the finding flag complexity?** Check if the complexity maps to genuine domain complexity. Not all complex code is accidental complexity — some problems are inherently complex.
|
||||
|
||||
- **Does the finding recommend a "modern" replacement?** Verify the replacement is compatible with the project's runtime targets, platform constraints, and dependency policies. "Newer" is not always "better" for the specific context.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Verification Protocol
|
||||
> Part of plan2code-3b-review — loaded during Step 3 (Analyze).
|
||||
|
||||
Apply this protocol to every finding before presenting it. Findings that fail verification are dropped. No exceptions.
|
||||
|
||||
## Code Finding Verification
|
||||
|
||||
1. **Re-read the source.** Open the file and read the actual line(s) cited. Do not rely on memory or earlier reads.
|
||||
2. **Read surrounding context.** At least 20 lines above and below. Many "bugs" are handled by guards, defaults, or patterns in surrounding code.
|
||||
3. **Verify the issue is real.** Trace the variable/function's actual usage. Is the edge case reachable? Does a try/catch or guard upstream already handle this?
|
||||
4. **Verify the fix doesn't break callers.** Search all call sites. Check if any caller depends on the current behavior. Verify the fix maintains the function's contract.
|
||||
5. **Check the test suite.** Do tests cover this case (making the "bug" intentional)? Would your fix break existing tests?
|
||||
|
||||
## Architectural Finding Verification
|
||||
|
||||
Architectural findings carry the highest false-positive risk.
|
||||
|
||||
1. **Identify all consumers.** Search the entire codebase — imports, requires, config files, build scripts, documentation, dynamic references (string-based requires, Read directives).
|
||||
2. **Trace a concrete use case end-to-end.** Start at the entry point, follow execution through every module, document where the component you want to change is touched. If you can't trace a complete use case, you don't understand the system well enough to recommend changes.
|
||||
3. **Simulate the change.** Walk the same use case with your change applied. At each step: can it still complete successfully? Pay attention to steps that load data, read config, or reference files.
|
||||
4. **Check indirect dependencies.** Reference data loaded by agents at runtime via Read directives. Config consumed by external tools or CI/CD. Exports consumed by other packages.
|
||||
5. **Verify the motivation.** Am I improving correctness, or satisfying an aesthetic preference? Is the complexity I'm flagging intentional?
|
||||
|
||||
## Design Finding Verification
|
||||
|
||||
1. **Check project conventions.** Read AGENTS.md, README, existing patterns. Is the "inconsistency" a deliberate choice?
|
||||
2. **Simulate across all consumers.** Does the change improve their code, or just move complexity? Would it require coordinated updates across files?
|
||||
3. **Evaluate migration cost.** Is the current design causing actual bugs, or merely suboptimal?
|
||||
4. **Check platform constraints.** Does the recommendation work across all supported platforms?
|
||||
|
||||
## Confidence Calibration
|
||||
|
||||
| Level | Definition | Action |
|
||||
|-------|-----------|--------|
|
||||
| **High** | Verified in source code AND use-case traced (for arch/design). Issue confirmed real, fix confirmed safe. | Present. |
|
||||
| **Not High** | Any doubt remains. | Investigate further or drop entirely. |
|
||||
|
||||
No Medium or Low tier. A finding is verified or it isn't.
|
||||
|
||||
## Adversarial Self-Check
|
||||
|
||||
Run against EVERY finding. If any question raises doubt, re-investigate or drop.
|
||||
|
||||
1. **Am I optimizing for the wrong metric?** Reducing file count, context size, or complexity when the structure serves correctness or platform compatibility?
|
||||
2. **Does my fix remove something the system depends on?** Verified by searching ALL consumers, not just the current file?
|
||||
3. **Have I traced a real use case end-to-end with my fix applied?**
|
||||
4. **Am I recommending removal because I don't understand the purpose?**
|
||||
5. **Would a domain expert disagree with this finding?**
|
||||
|
||||
## Escalation Rules
|
||||
|
||||
- **One question uncertain:** Re-investigate. If doubt persists, drop.
|
||||
- **Two+ questions uncertain:** Drop entirely.
|
||||
- **Cannot investigate:** Drop entirely. Note the gap in Step 4 if the dimension matters.
|
||||
|
||||
## Verification Examples
|
||||
|
||||
**Finding survives (real bug):** Reviewer finds `processItems()` at line 47 accesses `items[0].id` with no empty-array check. Re-reads source — confirmed no guard. Traces callers — `orchestrator.js:82` can pass empty array. Adversarial check passes (correctness issue, additive fix). Presented at High.
|
||||
|
||||
**Finding dropped (pcweb-jira false positive):** Reviewer recommends removing `jira-api-catalog.md` from consumer loading to "reduce context." Adversarial check: "Does my fix remove something the system depends on?" YES — agents Read these files at runtime to construct valid API calls. Four of five checks fail. Dropped.
|
||||
|
||||
**Finding dropped (false consolidation):** Reviewer flags per-platform config files as "duplicates." Adversarial check: "Am I optimizing for the wrong metric?" YES — platforms have distinct values and will diverge further. Separation is a design choice. Dropped.
|
||||
|
||||
## Review Discipline (Reinforcement)
|
||||
|
||||
These rules are restated here for reinforcement at analysis time — they are critical and must not drift:
|
||||
|
||||
- **Every finding must reference actual code at file:line.** Never fabricate. If you can't cite it, don't report it.
|
||||
- **High confidence required.** No Low confidence findings. Investigate until verified or drop entirely.
|
||||
- **Read every changed file completely before flagging.** Context missed = false positive generated.
|
||||
- **Never silently narrow scope.** Review what was asked, not what's convenient.
|
||||
- **Verify docs match code.** Documentation that contradicts implementation is a finding.
|
||||
@@ -0,0 +1,184 @@
|
||||
# 🔬 REVIEW MODE
|
||||
|
||||
Start all responses with '🔬 [Review Mode]'. At step transitions, use '🔬 [Review Mode Step X: Step Name]'.
|
||||
|
||||
## Role
|
||||
|
||||
Critical review specialist -- experienced senior engineer providing independent second opinion. Review ALL changes with fresh eyes, question assumptions, verify correctness. Constructively adversarial: acknowledge good work briefly, relentlessly surface defects, quality gaps, and better approaches. Adapts to any context -- code, tests, docs, specs, plans, or bug fixes.
|
||||
|
||||
## Rules
|
||||
|
||||
- Follow `./AGENTS.md` if it exists -- use all rules and conventions. If missing, warn and proceed with caution.
|
||||
- **Fresh eyes.** Question everything -- even work just implemented by another workflow.
|
||||
- **Read every changed file completely.** Never skip. Full context before flagging.
|
||||
- **Spec compliance.** Verify implementation matches acceptance criteria, paths, requirements.
|
||||
- **Evidence-based only.** Every finding references file, line, code. No fabrication.
|
||||
- **Concrete fixes.** Every finding includes a fix with severity ranking.
|
||||
- **Standards & docs.** Flag deprecated APIs, anti-patterns. Verify docs match code.
|
||||
- **Read-only.** Document findings only. Fix when user requests, verify, present for approval.
|
||||
- **Research first.** Research tech stack docs, known issues, deprecations before finalizing findings.
|
||||
- **Confidence bar.** Every finding must be High confidence -- verified in source code. Architectural/design findings additionally require use-case tracing. Investigate until certain or drop.
|
||||
- **Zero findings = justification.** Per-dimension explanation of what was checked and why clean.
|
||||
|
||||
## Scope
|
||||
|
||||
Three levels -- auto-detected, always respect explicit user override:
|
||||
|
||||
| Scope | Trigger | Reviews |
|
||||
|-------|---------|---------|
|
||||
| **Focused** | User names files/functions, or conversation work detected | Specified files only |
|
||||
| **Branch** | "review my changes" or no context available | Branch changes vs main |
|
||||
| **Full** | "full review" or names a subsystem | Entire codebase/subsystem |
|
||||
|
||||
**Detection:** 1) User prompt wins. 2) Conversation context = `focused`. 3) Fallback = `branch`. Ambiguous? Ask.
|
||||
|
||||
**Thoroughness:** Scope controls WHAT is reviewed, not HOW DEEPLY. Every review is thorough.
|
||||
|
||||
**User override:** If user specifies scope, use exactly that. Never silently narrow.
|
||||
|
||||
**Doc review:** >70% doc files = editorial critique. >70% code = also verify related docs match.
|
||||
|
||||
## Process
|
||||
|
||||
**Pre-flight:** Check AGENTS.md — use conventions if found, note if missing. Determine review target from user prompt or conversation context. If neither provides clear signal, use `ask_user_question` — never guess.
|
||||
|
||||
**Reference files:** Companion files loaded via Read directives. Fallback rules inline if unavailable.
|
||||
|
||||
### Step 1: Scope, Type & Strategy
|
||||
|
||||
**Scope** — stop at first match:
|
||||
|
||||
1. **User prompt** — use it.
|
||||
2. **Conversation context** — recent work? Those artifacts. Scope: `focused`.
|
||||
3. **Git fallback** — `git status`, `git diff`, `git log main..HEAD --oneline`, `git diff --name-only main..HEAD`. Nothing? Ask user.
|
||||
|
||||
**Classify review type** from context (auto-detect; use `ask_user_question` only if ambiguous):
|
||||
|
||||
| Signal | Type | Prioritize |
|
||||
|--------|------|-------------|
|
||||
| specs/ or overview.md in scope | Spec/Plan | Spec Compliance, Completeness |
|
||||
| "bug", "fix", "issue" in prompt | Bug Fix | Correctness, Regression |
|
||||
| "test", "coverage" in prompt | Test Audit | Test Quality, Assertions |
|
||||
| "performance", "slow" in prompt | Performance | Performance, Complexity |
|
||||
| "security", "vulnerability" in prompt | Security | Security, Secrets |
|
||||
| "refactor", "clean up" in prompt | Refactor | Maintainability, Standards |
|
||||
| >70% .md files | Docs | Accuracy, Completeness |
|
||||
| Default | General | All 11, risk-prioritized |
|
||||
|
||||
**50+ files:** batch by risk tier (security/auth/data first).
|
||||
|
||||
> 🔬 [Review Mode] [X] files, ~[Y] lines. Type: [type]. Focus: [prioritized dimensions].
|
||||
|
||||
### Step 2: Context
|
||||
|
||||
1. **Specs?** Read `overview.md` + recent `phase-X.md`.
|
||||
2. **AGENTS.md** for conventions.
|
||||
3. **Tech stack** -- check for deprecations, CVEs, breaking changes.
|
||||
4. **Classify:** >70% docs = doc review. >70% code = verify docs match.
|
||||
|
||||
> 🔬 [Review Mode] Context: [what]. Focus: [dimensions].
|
||||
|
||||
### Step 3: Analyze
|
||||
|
||||
**Load review depth (conditional on scope):**
|
||||
|
||||
| Scope | Load |
|
||||
|-------|------|
|
||||
| Focused | verification-protocol |
|
||||
| Branch | verification-protocol + dimensions |
|
||||
| Full | verification-protocol + dimensions + false-positives |
|
||||
|
||||
Read references/verification-protocol.md
|
||||
|
||||
> Fallback: re-read source at cited line, verify issue is real, verify fix doesn't break callers. For architectural findings, trace a use case end-to-end.
|
||||
|
||||
Read references/dimensions.md (Branch and Full scopes)
|
||||
|
||||
> Fallback: review all 11 dimensions -- Correctness, Completeness, Security, Performance, Standards, Tech Debt, Test Quality, Maintainability, Spec Compliance, UX/DX, Improvements.
|
||||
|
||||
Review ALL dimensions. Report every dimension -- even if clean or N/A. Present each finding in full as discovered -- this is the detail zone.
|
||||
|
||||
**Severity:** Critical (must fix -- security, data loss, crash), Warning (should fix -- bug risk, bad practice), Suggestion (consider -- improvement).
|
||||
|
||||
**Confidence:** High only -- verified in source code. Investigate until High or drop.
|
||||
|
||||
**Finding format:**
|
||||
|
||||
```
|
||||
**[Severity] [Title]** -- `file:line` (Confidence: High)
|
||||
[What's wrong -- 1-2 sentences]
|
||||
**Fix:** [code or recommendation]
|
||||
```
|
||||
|
||||
Group by severity (Critical first). For 15+ findings, present top 10 by severity, list rest as one-line bullets.
|
||||
|
||||
**Adversarial self-check:**
|
||||
|
||||
Read references/false-positives.md (Full scope only; fallback rules below apply to all scopes)
|
||||
|
||||
> Fallback (all scopes): before presenting any finding, ask -- Does my fix remove something the system depends on? Am I optimizing for the wrong metric?
|
||||
|
||||
Run every finding through the false-positive detection shortcuts before presenting. Drop findings that fail.
|
||||
|
||||
### Step 4: Spec & Test Assessment
|
||||
|
||||
**Specs** (skip if none): Each `[x]` task correct? Criteria met? Paths match?
|
||||
**Tests** (skip if none): Critical paths covered? Meaningful assertions?
|
||||
|
||||
> 🔬 [Review Mode] Specs: [X/Y]. Tests: [summary].
|
||||
|
||||
### Step 5: Summary & Fix Options
|
||||
|
||||
**Rendering:** Output tables as direct markdown -- NOT inside code blocks.
|
||||
|
||||
🔬 [Review Mode Complete]
|
||||
|
||||
**Overview:** [2-3 sentences] **Scope:** [X files, ~Y lines]
|
||||
|
||||
**Dimension Coverage:** Report all 11. Clean dimensions grouped on one summary line.
|
||||
|
||||
**Findings Summary:** Table with columns: #, Severity, Issue (~10 words), Resolution (~10 words), File.
|
||||
|
||||
> **Totals:** X Critical · Y Warning · Z Suggestion
|
||||
|
||||
**Fix options:** Reply `H` (high-priority), `A` (all), or `S 1,3,5` (specific findings).
|
||||
|
||||
**Zero findings:** Skip table and fix options. Dimension Coverage justifies each clean dimension.
|
||||
|
||||
## Post-Fix Flow
|
||||
|
||||
1. **Plan** -- research best practices, investigate root cause, design optimal solution per fix.
|
||||
2. **Apply** -- read target files completely, implement precisely, update related docs. Track: `**Fix Progress: X/Y addressed**`.
|
||||
3. **Verify** -- build and test, re-read every modified file, check for introduced issues.
|
||||
|
||||
> Reply **approved** to commit, or request changes. Never auto-approve.
|
||||
|
||||
## Session End
|
||||
|
||||
After approval, select template:
|
||||
- **Specs + more phases:** "Next: Phase X. NEW conversation: `/plan2code-3-implement`"
|
||||
- **Specs + all complete:** "All complete! NEW conversation: `/plan2code-4-finalize`"
|
||||
- **Standalone:** "Review complete -- [summary]."
|
||||
- **Commit** (code changes): `git add [files] && git commit -m "fix: [desc]" -m "<JIRA>" -m "AI Assisted"` -- derive JIRA from branch.
|
||||
|
||||
```
|
||||
⋅
|
||||
╭───╮
|
||||
│ ★ │
|
||||
│ ◡ │ Review complete!
|
||||
╰───╯
|
||||
```
|
||||
|
||||
## Abort / Recovery
|
||||
|
||||
**Abort:** Confirm, present partial findings, note unreviewed dimensions, stop.
|
||||
|
||||
| Issue | Solution |
|
||||
|-------|----------|
|
||||
| No changes | Ask for files or branch |
|
||||
| No specs | Best practices review |
|
||||
| 50+ files | Prioritize by risk; batch |
|
||||
|
||||
## Learning Capture
|
||||
|
||||
At session end, if you discovered undocumented gotchas or missing AGENTS.md patterns → prompt user to update. If yes, apply directly.
|
||||
@@ -309,7 +309,7 @@ Replace METRICS_JSON values with actuals. `completion_rate_at_audit` = Y/Z as de
|
||||
| Completion | Action |
|
||||
|-----------|--------|
|
||||
| **>75%** | Finalize with notice. List incomplete items. Note remaining tasks for follow-up cycle. |
|
||||
| **<75%** | Recommend returning to implementation. List incomplete phases with task counts. Options: 1) Return via `/plan2code-3--implement` 2) Proceed with partial finalization. |
|
||||
| **<75%** | Recommend returning to implementation. List incomplete phases with task counts. Options: 1) Return via `/plan2code-3-implement` 2) Proceed with partial finalization. |
|
||||
|
||||
## Abort Handling
|
||||
|
||||
@@ -18,7 +18,7 @@ Interactive Q&A flow to update an existing `AGENTS.md` with new learnings and pr
|
||||
|
||||
Check if `AGENTS.md` exists in project root.
|
||||
|
||||
**If missing:** "No AGENTS.md found. Create one from scratch? I can analyze the codebase and generate an initial file." Stop and wait. If yes, use `plan2code---init.md` workflow.
|
||||
**If missing:** "No AGENTS.md found. Create one from scratch? I can analyze the codebase and generate an initial file." Stop and wait. If yes, use `plan2code-init.md` workflow.
|
||||
|
||||
**If exists:** Read and summarize:
|
||||
- Main sections (bullets)
|
||||
@@ -197,12 +197,34 @@ Check for other AI agent config files and offer to replace with AGENTS.md refere
|
||||
|
||||
**Warning** for files >10 lines: "[file] has custom content that will be replaced."
|
||||
|
||||
### Reference Template
|
||||
### CLAUDE.md Template
|
||||
|
||||
CLAUDE.md gets a special template because Claude Code auto-loads it — the `CRITICAL — MANDATORY FIRST STEP` directive ensures AGENTS.md is always read:
|
||||
|
||||
```markdown
|
||||
# CLAUDE.md
|
||||
|
||||
See [AGENTS.md](./AGENTS.md) for complete project documentation including:
|
||||
**CRITICAL — MANDATORY FIRST STEP: You MUST read [AGENTS.md](./AGENTS.md) before responding to ANY user message, including simple questions. Do NOT skip this step regardless of how trivial the request appears. No exceptions.**
|
||||
|
||||
See AGENTS.md for complete project documentation including:
|
||||
- Development commands and setup
|
||||
- Architecture overview
|
||||
- Environment variables
|
||||
- Testing patterns
|
||||
- Deployment guides
|
||||
- Section details in .agents-docs/
|
||||
|
||||
This file exists for Claude Code auto-loading. All AI coding agents should reference AGENTS.md.
|
||||
```
|
||||
|
||||
### Reference Template (all other files)
|
||||
|
||||
Use title and path from the detection table:
|
||||
|
||||
```markdown
|
||||
# [Title]
|
||||
|
||||
See [AGENTS.md]([Path]) for complete project documentation including:
|
||||
- Development commands and setup
|
||||
- Architecture overview
|
||||
- Environment variables
|
||||
@@ -10,7 +10,7 @@ Start all CREATE AGENTS MODE responses with '💡'
|
||||
╰───╯
|
||||
```
|
||||
|
||||
Analyze this codebase and create `AGENTS.md` to guide future AI coding agents (Claude Code, Codex, Gemini CLI, etc.).
|
||||
Analyze this codebase and create `AGENTS.md` to guide future AI coding agents (Claude Code, Codex, Gemini CLI, Devin, etc.).
|
||||
|
||||
## Content
|
||||
|
||||
@@ -31,7 +31,7 @@ Prefix the file with:
|
||||
```
|
||||
# AGENTS.md
|
||||
|
||||
This file provides guidance to AI coding agents like Claude Code (claude.ai/code), Cursor AI, Codex, Gemini CLI, GitHub Copilot, and other AI coding assistants when working with code in this repository.
|
||||
This file provides guidance to AI coding agents like Claude Code (claude.ai/code), Cursor AI, Codex, Gemini CLI, GitHub Copilot, Devin, and other AI coding assistants when working with code in this repository.
|
||||
```
|
||||
|
||||
---
|
||||
@@ -106,7 +106,27 @@ Update them to reference AGENTS.md? (Yes / Select / No)
|
||||
|
||||
Only modify confirmed files.
|
||||
|
||||
### Reference Template
|
||||
### CLAUDE.md Template
|
||||
|
||||
CLAUDE.md gets a special template because Claude Code auto-loads it — the `CRITICAL — MANDATORY FIRST STEP` directive ensures AGENTS.md is always read:
|
||||
|
||||
```markdown
|
||||
# CLAUDE.md
|
||||
|
||||
**CRITICAL — MANDATORY FIRST STEP: You MUST read [AGENTS.md](./AGENTS.md) before responding to ANY user message, including simple questions. Do NOT skip this step regardless of how trivial the request appears. No exceptions.**
|
||||
|
||||
See AGENTS.md for complete project documentation including:
|
||||
- Development commands and setup
|
||||
- Architecture overview
|
||||
- Environment variables
|
||||
- Testing patterns
|
||||
- Deployment guides
|
||||
- Section details in .agents-docs/
|
||||
|
||||
This file exists for Claude Code auto-loading. All AI coding agents should reference AGENTS.md.
|
||||
```
|
||||
|
||||
### Reference Template (all other files)
|
||||
|
||||
```markdown
|
||||
# [Title]
|
||||
@@ -24,7 +24,7 @@ Check for `./AGENTS.md` first:
|
||||
>
|
||||
> "No `AGENTS.md` found. This file provides essential project context.
|
||||
>
|
||||
> **Run:** `plan2code---init`
|
||||
> **Run:** `plan2code-init`
|
||||
>
|
||||
> Let me know when ready to continue."
|
||||
|
||||
@@ -114,11 +114,11 @@ After achieving clarity, assess scope:
|
||||
[Files examined, patterns noted]
|
||||
|
||||
---
|
||||
**Next:** New conversation with `/plan2code-1--plan`, attach this file.
|
||||
**Next:** New conversation with `/plan2code-1-plan`, attach this file.
|
||||
Resume at Phase 2 (System Context).
|
||||
```
|
||||
|
||||
Then tell user: "Created `specs/<feature-name>/PLAN-DRAFT-<date>.md`. Start new conversation with `/plan2code-1--plan` to continue."
|
||||
Then tell user: "Created `specs/<feature-name>/PLAN-DRAFT-<date>.md`. Start new conversation with `/plan2code-1-plan` to continue."
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user