@leeovery/claude-technical-workflows 2.1.5 → 2.1.7

package/agents/implementation-polish.md

@@ -20,12 +20,11 @@ You receive file paths and context via the orchestrator's prompt:
 3. **Specification path** — What was intended — design decisions and rationale
 4. **Plan file path** — What was built — the full task landscape
 5. **Plan format reading.md path** — How to read tasks from the plan (format-specific adapter)
-6. **Integration context file path** — Accumulated decisions and patterns from every task
-7. **Project skill paths** — Framework conventions
+6. **Project skill paths** — Framework conventions
 
 On **re-invocation after user feedback**, additionally include:
 
-8. **User feedback** — the user's comments on what to change or focus on
+7. **User feedback** — the user's comments on what to change or focus on
 
 ## Hard Rules
 
@@ -50,7 +49,6 @@ Read and absorb the following. Do not write any code or dispatch any agents duri
 3. **Read project skills** — absorb framework conventions
 4. **Read the plan format's reading.md** — understand how to retrieve tasks from the plan
 5. **Read the plan** — follow the reading adapter's instructions to retrieve all completed tasks. Understand the full scope: phases, tasks, acceptance criteria, what was built
-6. **Read the integration context file** — understand patterns, helpers, and conventions from all tasks
 
 → Proceed to **Step 2**.
 
@@ -58,7 +56,7 @@ Read and absorb the following. Do not write any code or dispatch any agents duri
 
 ## Step 2: Identify Implementation Scope
 
-Find all files changed during implementation. Use git history, the plan's task list, and the integration context to build a complete picture of what was touched. Read and understand the full implemented codebase.
+Find all files changed during implementation. Use git history and the plan's task list to build a complete picture of what was touched. Read and understand the full implemented codebase.
 
 Build a definitive list of implementation files. This list is passed to analysis sub-agents in subsequent steps.
 
@@ -127,14 +125,12 @@ Craft a task description covering the prioritized fixes. Include the following *
 - Modify existing tests for mechanical changes (renames, moves) — yes
 - Modify existing tests semantically (different behavior) — no. If a refactor breaks existing tests, the refactor is wrong. Revert it.
 
-Invoke the `implementation-task-executor` agent (`.claude/agents/implementation-task-executor.md`) with:
+Invoke the `implementation-task-executor` agent (`implementation-task-executor.md`) with:
 - The crafted task description (including test rules) as task content
 - tdd-workflow.md path
 - code-quality.md path
 - Specification path (if available)
 - Project skill paths
-- Plan file path
-- Integration context file path
 
 **STOP.** Do not proceed until the executor has returned its result.
 
@@ -144,11 +140,10 @@ On receipt of result, route on STATUS:
 
 ### F. Invoke Reviewer
 
-Invoke the `implementation-task-reviewer` agent (`.claude/agents/implementation-task-reviewer.md`) to independently verify the executor's work. Include the test rules in the reviewer's prompt so it can flag violations. Pass:
+Invoke the `implementation-task-reviewer` agent (`implementation-task-reviewer.md`) to independently verify the executor's work. Include the test rules in the reviewer's prompt so it can flag violations. Pass:
 - Specification path
 - The same task description used for the executor (including test rules)
 - Project skill paths
-- Integration context file path
 
 **STOP.** Do not proceed until the reviewer has returned its result.
 

package/agents/implementation-task-executor.md

@@ -18,12 +18,10 @@ You receive file paths and context via the orchestrator's prompt:
 3. **Specification path** — For context when rationale is unclear
 4. **Project skill paths** — Relevant `.claude/skills/` paths for framework conventions
 5. **Task content** — Task ID, phase, and all instructional content: goal, implementation steps, acceptance criteria, tests, edge cases, context, notes. This is your scope.
-6. **Plan file path** — The implementation plan, for understanding the overall task landscape and where this task fits
-7. **Integration context file path** (if exists) — Accumulated notes from prior tasks about established patterns, conventions, and decisions
 
 On **re-invocation after review feedback**, you receive all of the above, plus:
-8. **User-approved review notes** — may be the reviewer's original notes, modified by user, or user's own notes
-9. **Specific issues to address**
+6. **User-approved review notes** — may be the reviewer's original notes, modified by user, or user's own notes
+7. **Specific issues to address**
 
 You are stateless — each invocation starts fresh. The full task content is always provided so you can see what was asked, what was done, and what needs fixing.
 
@@ -33,14 +31,10 @@ You are stateless — each invocation starts fresh. The full task content is alw
 2. **Read code-quality.md** — absorb quality standards
 3. **Read project skills** — absorb framework conventions, testing patterns, architecture patterns
 4. **Read specification** (if provided) — understand broader context for this task
-5. **Explore codebase** — you are weaving into an existing canvas, not creating isolated patches:
-   - If an integration context file was provided, read it first — identify helpers, patterns, and conventions you must reuse before writing anything new
-   - Skim the plan file to understand the task landscape — what's been built, what's coming, where your task fits. Use this for awareness, not to build ahead (YAGNI still applies)
+5. **Explore codebase** — understand what exists before writing anything:
    - Read files and tests related to the task's domain
-   - Search for existing helpers, utilities, and abstractions that solve similar problems — reuse, don't duplicate
-   - When creating an interface or API boundary, read BOTH sides: the code that will consume it AND the code that will implement it
-   - Match conventions established in the codebase: error message style, naming patterns, file organisation, type placement
-   - Your code should read as if the same developer wrote the entire codebase
+   - Identify patterns, conventions, and structures you'll need to follow or extend
+   - Check for existing code that the task builds on or integrates with
 6. **Execute TDD cycle** — follow the process in tdd-workflow.md for each acceptance criterion and test case.
 7. **Verify all acceptance criteria met** — every criterion from the task must be satisfied
 8. **Return structured result**
@@ -81,10 +75,7 @@ FILES_CHANGED: {list of files created/modified}
 TESTS_WRITTEN: {list of test files/methods}
 TEST_RESULTS: {all passing | failures — details}
 ISSUES: {any concerns, blockers, or deviations discovered}
-INTEGRATION_NOTES:
-- {3-5 concise bullet points: key patterns, helpers, conventions, interface decisions established by this task. Anchor to concrete file paths where applicable (e.g., "Created `ValidationHelper` in `src/helpers/validation.ts` — use for all input validation"), but high-level observations without a specific file reference are also valuable}
 ```
 
 - If STATUS is `blocked` or `failed`, ISSUES **must** explain why and what decision is needed.
 - If STATUS is `complete`, all acceptance criteria must be met and all tests passing.
-- After completing the task, document what you created or established that future tasks should be aware of in INTEGRATION_NOTES. This is factual — what exists and why — not evaluative.

package/agents/implementation-task-reviewer.md

@@ -18,7 +18,6 @@ You receive via the orchestrator's prompt:
 1. **Specification path** — The validated specification for design decision context
 2. **Task content** — Same task content the executor received: task ID, phase, and all instructional content
 3. **Project skill paths** — Relevant `.claude/skills/` paths for checking framework convention adherence
-4. **Integration context file path** (if exists) — Accumulated notes from prior tasks, for evaluating cohesion with established patterns
 
 ## Your Process
 
@@ -26,7 +25,7 @@ You receive via the orchestrator's prompt:
 2. **Check unstaged changes** — use `git diff` and `git status` to identify files changed by the executor
 3. **Read all changed files** — implementation code and test code
 4. **Read project skills** — understand framework conventions, testing patterns, architecture patterns
-5. **Evaluate all six review dimensions** (see below)
+5. **Evaluate all five review dimensions** (see below)
 
 ## Review Dimensions
 
@@ -63,15 +62,6 @@ Is this a sound design decision? Will it compose well with future tasks?
 - Will this cause problems for subsequent tasks in the phase?
 - Are there structural concerns that should be raised now rather than compounding?
 
-### 6. Codebase Cohesion
-Does the new code integrate well with the existing codebase? If integration context exists from prior tasks, check against established patterns.
-- Is there duplicated logic that should be extracted into a shared helper?
-- Are existing helpers and patterns being reused where applicable?
-- Are naming conventions consistent with existing code?
-- Are error message conventions consistent (casing, wrapping style, prefixes)?
-- Do interfaces use concrete types rather than generic/any types where possible?
-- Are related types co-located with the interfaces or functions they serve?
-
 ## Fix Recommendations (needs-changes only)
 
 When your verdict is `needs-changes`, you must also recommend how to fix each issue. You have full context — the spec, the task, the conventions, and the code — so use it.
@@ -96,7 +86,7 @@ When alternatives exist, explain the tradeoff briefly — don't just list option
 2. **No git writes** — Do not commit or stage. Reading git history and diffs is fine. The orchestrator handles all git writes.
 3. **One task only** — You review exactly one plan task per invocation.
 4. **Independent judgement** — Evaluate the code yourself. Do not trust the executor's self-assessment.
-5. **All six dimensions** — Evaluate spec conformance, acceptance criteria, test adequacy, convention adherence, architectural quality, and codebase cohesion.
+5. **All five dimensions** — Evaluate spec conformance, acceptance criteria, test adequacy, convention adherence, and architectural quality.
 6. **Be specific** — Include file paths and line numbers for every issue. Vague findings are not actionable.
 7. **Proportional** — Prioritize by impact. Don't nitpick style when the architecture is wrong.
 8. **Task scope only** — Only review what's in the task. Don't flag issues outside the task's scope.
@@ -113,7 +103,6 @@ ACCEPTANCE_CRITERIA: {all met | gaps — list}
 TEST_COVERAGE: {adequate | gaps — list}
 CONVENTIONS: {followed | violations — list}
 ARCHITECTURE: {sound | concerns — details}
-CODEBASE_COHESION: {cohesive | concerns — details}
 ISSUES:
 - {specific issue with file:line reference}
   FIX: {recommended approach}
@@ -121,12 +110,9 @@ ISSUES:
   CONFIDENCE: {high | medium | low}
 NOTES:
 - {non-blocking observations}
-COHESION_NOTES:
-- {2-4 concise bullet points: patterns to maintain, conventions confirmed, architectural integration observations}
 ```
 
 - If VERDICT is `approved`, omit ISSUES entirely (or leave empty)
 - If VERDICT is `needs-changes`, ISSUES must contain specific, actionable items with file:line references AND fix recommendations
 - Each issue must include FIX and CONFIDENCE. ALTERNATIVE is optional — include only when genuinely multiple valid approaches exist
 - NOTES are for non-blocking observations — things worth noting but not requiring changes
-- COHESION_NOTES are always included — they capture patterns and conventions observed for future task context

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leeovery/claude-technical-workflows",
-  "version": "2.1.5",
+  "version": "2.1.7",
   "description": "Technical workflow skills & commands for Claude Code",
   "license": "MIT",
   "author": "Lee Overy <me@leeovery.com>",

package/skills/link-dependencies/SKILL.md

@@ -102,7 +102,7 @@ For each unresolved dependency:
 
 2. **If plan exists**: Load the format's reading reference
    - Read `format:` from the dependency plan's frontmatter
-   - Load `.claude/skills/technical-planning/references/output-formats/{format}/reading.md`
+   - Load `../technical-planning/references/output-formats/{format}/reading.md`
    - Use the task extraction instructions to search for matching tasks
 
 3. **Handle ambiguous matches**:
@@ -117,7 +117,7 @@ For each resolved match:
    - Change the dependency's `state: unresolved` to `state: resolved` and add `task_id: {task-id}`
 
 2. **Create dependency in output format**:
-   - Load `.claude/skills/technical-planning/references/output-formats/{format}/graph.md`
+   - Load `../technical-planning/references/output-formats/{format}/graph.md`
    - Follow the "Adding a Dependency" section to create the blocking relationship
 
 ## Step 6: Bidirectional Check

package/skills/migrate/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: migrate
 description: "Run migrations to keep workflow files in sync with the current system design. This skill is mandatory before running any workflow skill."
-allowed-tools: Bash(.claude/scripts/migrate.sh)
+allowed-tools: Bash(../../scripts/migrate.sh)
 ---
 
 # Migrate
@@ -13,7 +13,7 @@ Keeps your workflow files up to date with how the system is designed to work. Ru
 Run the migration script:
 
 ```bash
-.claude/scripts/migrate.sh
+../../scripts/migrate.sh
 ```
 
 ### If files were updated

package/skills/start-discussion/SKILL.md

@@ -2,7 +2,7 @@
 name: start-discussion
 description: "Start a technical discussion. Discovers research and existing discussions, offers multiple entry paths, and invokes the technical-discussion skill."
 disable-model-invocation: true
-allowed-tools: Bash(.claude/scripts/discovery-for-discussion.sh), Bash(mkdir -p docs/workflow/.cache), Bash(rm docs/workflow/.cache/research-analysis.md)
+allowed-tools: Bash(../../scripts/discovery-for-discussion.sh), Bash(mkdir -p docs/workflow/.cache), Bash(rm docs/workflow/.cache/research-analysis.md)
 ---
 
 Invoke the **technical-discussion** skill for this conversation.
@@ -55,7 +55,7 @@ Invoke the `/migrate` skill and assess its output.
 Run the discovery script to gather current state:
 
 ```bash
-.claude/scripts/discovery-for-discussion.sh
+../../scripts/discovery-for-discussion.sh
 ```
 
 This outputs structured YAML. Parse it to understand:

package/skills/start-implementation/SKILL.md

@@ -2,7 +2,7 @@
 name: start-implementation
 description: "Start an implementation session from an existing plan. Discovers available plans, checks environment setup, and invokes the technical-implementation skill."
 disable-model-invocation: true
-allowed-tools: Bash(.claude/scripts/discovery-for-implementation-and-review.sh)
+allowed-tools: Bash(../../scripts/discovery-for-implementation-and-review.sh)
 ---
 
 Invoke the **technical-implementation** skill for this conversation.
@@ -55,7 +55,7 @@ Invoke the `/migrate` skill and assess its output.
 Run the discovery script to gather current state:
 
 ```bash
-.claude/scripts/discovery-for-implementation-and-review.sh
+../../scripts/discovery-for-implementation-and-review.sh
 ```
 
 This outputs structured YAML. Parse it to understand:

package/skills/start-planning/SKILL.md

@@ -2,7 +2,7 @@
 name: start-planning
 description: "Start a planning session from an existing specification. Discovers available specifications, gathers context, and invokes the technical-planning skill."
 disable-model-invocation: true
-allowed-tools: Bash(.claude/scripts/discovery-for-planning.sh)
+allowed-tools: Bash(../../scripts/discovery-for-planning.sh)
 ---
 
 Invoke the **technical-planning** skill for this conversation.
@@ -55,7 +55,7 @@ Invoke the `/migrate` skill and assess its output.
 Run the discovery script to gather current state:
 
 ```bash
-.claude/scripts/discovery-for-planning.sh
+../../scripts/discovery-for-planning.sh
 ```
 
 This outputs structured YAML. Parse it to understand:

package/skills/start-review/SKILL.md

@@ -2,7 +2,7 @@
 name: start-review
 description: "Start a review session from an existing plan and implementation. Discovers available plans, validates implementation exists, and invokes the technical-review skill."
 disable-model-invocation: true
-allowed-tools: Bash(.claude/scripts/discovery-for-implementation-and-review.sh)
+allowed-tools: Bash(../../scripts/discovery-for-implementation-and-review.sh)
 ---
 
 Invoke the **technical-review** skill for this conversation.
@@ -55,7 +55,7 @@ Invoke the `/migrate` skill and assess its output.
 Run the discovery script to gather current state:
 
 ```bash
-.claude/scripts/discovery-for-implementation-and-review.sh
+../../scripts/discovery-for-implementation-and-review.sh
 ```
 
 This outputs structured YAML. Parse it to understand:

package/skills/start-specification/SKILL.md

@@ -2,7 +2,7 @@
 name: start-specification
 description: "Start a specification session from existing discussions. Discovers available discussions, offers consolidation assessment for multiple discussions, and invokes the technical-specification skill."
 disable-model-invocation: true
-allowed-tools: Bash(.claude/scripts/discovery-for-specification.sh), Bash(mkdir -p docs/workflow/.cache), Bash(rm docs/workflow/.cache/discussion-consolidation-analysis.md)
+allowed-tools: Bash(../../scripts/discovery-for-specification.sh), Bash(mkdir -p docs/workflow/.cache), Bash(rm docs/workflow/.cache/discussion-consolidation-analysis.md)
 ---
 
 Invoke the **technical-specification** skill for this conversation.
@@ -55,7 +55,7 @@ Invoke the `/migrate` skill and assess its output.
 Run the discovery script to gather current state:
 
 ```bash
-.claude/scripts/discovery-for-specification.sh
+../../scripts/discovery-for-specification.sh
 ```
 
 This outputs structured YAML. Parse it to understand:

package/skills/technical-discussion/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: technical-discussion
 description: "Document technical discussions as expert architect and meeting assistant. Capture context, decisions, edge cases, debates, and rationale without jumping to specification or implementation. Use when: (1) Users discuss/explore/debate architecture or design, (2) Working through edge cases before specification, (3) Need to document technical decisions and their rationale, (4) Capturing competing solutions and why choices were made. Creates documentation in docs/workflow/discussion/{topic}.md that can be used to build validated specifications."
+user-invocable: false
 ---
 
 # Technical Discussion

package/skills/technical-implementation/SKILL.md

@@ -1,14 +1,15 @@
 ---
 name: technical-implementation
 description: "Orchestrate implementation of plans using agent-based TDD workflow with per-task review and approval gate (auto mode available). Use when: (1) Implementing a plan from docs/workflow/planning/{topic}.md, (2) User says 'implement', 'build', or 'code this' with a plan available, (3) Ad hoc coding that should follow TDD and quality standards, (4) Bug fixes or features benefiting from structured implementation. Dispatches executor and reviewer agents per task, commits after review approval."
+user-invocable: false
 ---
 
 # Technical Implementation
 
 Orchestrate implementation by dispatching **executor** and **reviewer** agents per task. Each agent invocation starts fresh — flat context, no accumulated state.
 
-- **Executor** (`.claude/agents/implementation-task-executor.md`) — implements one task via strict TDD
-- **Reviewer** (`.claude/agents/implementation-task-reviewer.md`) — independently verifies the task (opus)
+- **Executor** (`../../agents/implementation-task-executor.md`) — implements one task via strict TDD
+- **Reviewer** (`../../agents/implementation-task-reviewer.md`) — independently verifies the task (opus)
 
 The orchestrator owns: plan reading, task extraction, agent invocation, git operations, tracking, task gates.
 
@@ -100,7 +101,7 @@ Save their instructions to `docs/workflow/environment-setup.md` (or "No special
 
 1. Read the plan from the provided location (typically `docs/workflow/planning/{topic}.md`)
 2. Plans can be stored in various formats. The `format` field in the plan's frontmatter identifies which format this plan uses.
-3. Load the format's per-concern adapter files from `.claude/skills/technical-planning/references/output-formats/{format}/`:
+3. Load the format's per-concern adapter files from `../technical-planning/references/output-formats/{format}/`:
    - **reading.md** — how to read tasks from the plan
    - **updating.md** — how to write progress to the plan
 4. If no `format` field exists, ask the user which format the plan uses.
@@ -195,8 +196,6 @@ After creating the file, populate `project_skills` with the paths confirmed in S
 
 Commit: `impl({topic}): start implementation`
 
-Integration context will accumulate in `docs/workflow/implementation/{topic}-context.md` as tasks complete. This file is created automatically during the task loop — no initialisation needed here.
-
 → Proceed to **Step 5**.
 
 ---
@@ -304,4 +303,4 @@ Commit: `impl({topic}): complete implementation`
 - **[task-normalisation.md](references/task-normalisation.md)** — Normalised task shape for agent invocation
 - **[tdd-workflow.md](references/tdd-workflow.md)** — TDD cycle (passed to executor agent)
 - **[code-quality.md](references/code-quality.md)** — Quality standards (passed to executor agent)
-- **Integration context** — `docs/workflow/implementation/{topic}-context.md` — accumulated notes from completed tasks (created during task loop)
+

package/skills/technical-implementation/references/code-quality.md

@@ -37,15 +37,5 @@ Only implement what's in the plan. Ask: "Is this in the plan?"
 - Long parameter lists (4+)
 - Boolean parameters
 
-## Convention Consistency
-
-When adding to an existing codebase, match what's already there:
-- **Error messages**: Match the casing, wrapping style, and prefix patterns in existing code
-- **Naming**: Follow the project's conventions for files, functions, types, and variables
-- **File organisation**: Follow the project's pattern for splitting concerns across files
-- **Helpers**: Search for existing helpers before creating new ones. After creating one, check if existing code could use it too
-- **Types**: Prefer concrete types over generic/any types when the set of possibilities is known. Use structured return types over multiple bare return values for extensibility
-- **Co-location**: Keep related types near the interfaces or functions they serve
-
 ## Project Standards
 Check `.claude/skills/` for project-specific patterns.

package/skills/technical-implementation/references/environment-setup.md

@@ -55,7 +55,7 @@ If the environment setup document contains only "No special setup required" (or
 Some plan formats require specific tools. Check the plan's `format` field and load the format's about file for setup instructions:
 
 ```
-.claude/skills/technical-planning/references/output-formats/{format}/about.md
+../../technical-planning/references/output-formats/{format}/about.md
 ```
 
 Each format's about.md contains prerequisites and installation instructions.

package/skills/technical-implementation/references/steps/invoke-executor.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step invokes the `implementation-task-executor` agent (`.claude/agents/implementation-task-executor.md`) to implement one task.
+This step invokes the `implementation-task-executor` agent (`../../../../agents/implementation-task-executor.md`) to implement one task.
 
 ---
 
@@ -12,17 +12,15 @@ This step invokes the `implementation-task-executor` agent (`.claude/agents/impl
 
 **Every invocation** — initial or re-attempt — includes these file paths:
 
-1. **tdd-workflow.md**: `.claude/skills/technical-implementation/references/tdd-workflow.md`
-2. **code-quality.md**: `.claude/skills/technical-implementation/references/code-quality.md`
+1. **tdd-workflow.md**: `../tdd-workflow.md`
+2. **code-quality.md**: `../code-quality.md`
 3. **Specification path**: from the plan's frontmatter (if available)
 4. **Project skill paths**: from `project_skills` in the implementation tracking file
 5. **Task content**: normalised task content (see [task-normalisation.md](../task-normalisation.md))
-6. **Plan file path**: the implementation plan (same path used to read tasks)
-7. **Integration context file** (if exists): `docs/workflow/implementation/{topic}-context.md`
 
 **Re-attempts after review feedback** additionally include:
-8. **User-approved review notes**: verbatim or as modified by the user
-9. **Specific issues to address**: the ISSUES from the review
+6. **User-approved review notes**: verbatim or as modified by the user
+7. **Specific issues to address**: the ISSUES from the review
 
 The executor is stateless — each invocation starts fresh with no memory of previous attempts. Always pass the full task content so the executor can see what was asked, what was done, and what needs fixing.
 
@@ -38,8 +36,6 @@ TASK: {task name}
 SUMMARY: {2-5 lines — commentary, decisions made, anything off-script}
 TEST_RESULTS: {all passing | failures — details only if failures}
 ISSUES: {blockers or deviations — omit if none}
-INTEGRATION_NOTES:
-- {3-5 bullets: patterns, helpers, conventions established — anchor to file paths where applicable}
 ```
 
 - `complete`: all acceptance criteria met, tests passing

package/skills/technical-implementation/references/steps/invoke-polish.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step invokes the `implementation-polish` agent (`.claude/agents/implementation-polish.md`) to perform holistic quality analysis and orchestrate fixes after all tasks are complete.
+This step invokes the `implementation-polish` agent (`../../../../agents/implementation-polish.md`) to perform holistic quality analysis and orchestrate fixes after all tasks are complete.
 
 ---
 
@@ -12,17 +12,16 @@ This step invokes the `implementation-polish` agent (`.claude/agents/implementat
 
 **Every invocation** includes these file paths:
 
-1. **code-quality.md**: `.claude/skills/technical-implementation/references/code-quality.md`
-2. **tdd-workflow.md**: `.claude/skills/technical-implementation/references/tdd-workflow.md`
+1. **code-quality.md**: `../code-quality.md`
+2. **tdd-workflow.md**: `../tdd-workflow.md`
 3. **Specification path**: from the plan's frontmatter (if available)
 4. **Plan file path**: the implementation plan
-5. **Plan format reading.md**: `.claude/skills/technical-planning/references/output-formats/{format}/reading.md` (format from plan frontmatter)
-6. **Integration context file**: `docs/workflow/implementation/{topic}-context.md`
-7. **Project skill paths**: from `project_skills` in the implementation tracking file
+5. **Plan format reading.md**: `../../../technical-planning/references/output-formats/{format}/reading.md` (format from plan frontmatter)
+6. **Project skill paths**: from `project_skills` in the implementation tracking file
 
 **Re-invocation after user feedback** additionally includes:
 
-8. **User feedback**: the user's comments on what to change or focus on
+7. **User feedback**: the user's comments on what to change or focus on
 
 The polish agent is stateless — each invocation starts fresh. Always pass all inputs.
 

package/skills/technical-implementation/references/steps/invoke-reviewer.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step invokes the `implementation-task-reviewer` agent (`.claude/agents/implementation-task-reviewer.md`) to independently verify a completed task.
+This step invokes the `implementation-task-reviewer` agent (`../../../../agents/implementation-task-reviewer.md`) to independently verify a completed task.
 
 ---
 
@@ -15,7 +15,6 @@ Invoke `implementation-task-reviewer` with:
 1. **Specification path**: same path given to the executor
 2. **Task content**: same normalised task content the executor received
 3. **Project skill paths**: from `project_skills` in the implementation tracking file
-4. **Integration context file** (if exists): `docs/workflow/implementation/{topic}-context.md` — for checking cohesion with established patterns
 
 ---
 
@@ -31,7 +30,6 @@ ACCEPTANCE_CRITERIA: {all met | gaps — list}
 TEST_COVERAGE: {adequate | gaps — list}
 CONVENTIONS: {followed | violations — list}
 ARCHITECTURE: {sound | concerns — details}
-CODEBASE_COHESION: {cohesive | concerns — details}
 ISSUES:
 - {specific issue with file:line reference}
   FIX: {recommended approach}
@@ -39,9 +37,7 @@ ISSUES:
   CONFIDENCE: {high | medium | low}
 NOTES:
 - {non-blocking observations}
-COHESION_NOTES:
-- {2-4 bullets: patterns to maintain, conventions confirmed, integration quality}
 ```
 
-- `approved`: task passes all six review dimensions
+- `approved`: task passes all five review dimensions
 - `needs-changes`: ISSUES contains specific, actionable items with fix recommendations and confidence levels

package/skills/technical-implementation/references/steps/task-loop.md

@@ -169,27 +169,13 @@ Announce the result (one line, no stop):
 
 The tracking file is a derived view for discovery scripts and cross-topic dependency resolution — not a decision-making input during implementation (except `task_gate_mode` and `fix_gate_mode`).
 
-**Append integration context** — extract INTEGRATION_NOTES from the executor's final output and COHESION_NOTES from the reviewer's output. Append both to `docs/workflow/implementation/{topic}-context.md`:
-
-```
-## T{task-id}: {task name}
-
-### Integration (executor)
-{INTEGRATION_NOTES content}
-
-### Cohesion (reviewer)
-{COHESION_NOTES content}
-```
-
-Create the file if it doesn't exist. This is mechanical text extraction and file append — the same as extracting STATUS to route on. Use outputs from the final approved iteration only.
-
 **Commit all changes** in a single commit:
 
 ```
 impl({topic}): T{task-id} — {brief description}
 ```
 
-Code, tests, plan progress, tracking file, and integration context — one commit per approved task.
+Code, tests, plan progress, and tracking file — one commit per approved task.
 
 This is the end of this iteration.
 

package/skills/technical-planning/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: technical-planning
 description: "Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Use when: (1) User asks to create/write an implementation plan, (2) User asks to plan implementation from a specification, (3) Converting specifications from docs/workflow/specification/{topic}.md into implementation plans, (4) User says 'plan this' or 'create a plan', (5) Need to structure how to build something with phases and concrete steps. Creates plans in docs/workflow/planning/{topic}.md that can be executed via strict TDD."
+user-invocable: false
 ---
 
 # Technical Planning

package/skills/technical-planning/references/steps/analyze-task-graph.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step uses the `planning-dependency-grapher` agent (`.claude/agents/planning-dependency-grapher.md`) to analyze all authored tasks, establish internal dependencies, assign priorities, and detect cycles. You invoke the agent, present its output, and handle the approval gate.
+This step uses the `planning-dependency-grapher` agent (`../../../../agents/planning-dependency-grapher.md`) to analyze all authored tasks, establish internal dependencies, assign priorities, and detect cycles. You invoke the agent, present its output, and handle the approval gate.
 
 ---
 

package/skills/technical-planning/references/steps/author-tasks.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step uses the `planning-task-author` agent (`.claude/agents/planning-task-author.md`) to write full detail for a single task. You invoke the agent, present its output, and handle the approval gate.
+This step uses the `planning-task-author` agent (`../../../../agents/planning-task-author.md`) to write full detail for a single task. You invoke the agent, present its output, and handle the approval gate.
 
 ---
 
@@ -14,14 +14,14 @@ This step uses the `planning-task-author` agent (`.claude/agents/planning-task-a
 
 Invoke `planning-task-author` with these file paths:
 
-1. **read-specification.md**: `.claude/skills/technical-planning/references/read-specification.md`
+1. **read-specification.md**: `../read-specification.md`
 2. **Specification**: path from the Plan Index File's `specification:` field
 3. **Cross-cutting specs**: paths from the Plan Index File's `cross_cutting_specs:` field (if any)
-4. **task-design.md**: `.claude/skills/technical-planning/references/task-design.md`
+4. **task-design.md**: `../task-design.md`
 5. **All approved phases**: the complete phase structure from the Plan Index File body
 6. **Task list for current phase**: the approved task table
 7. **Target task**: the task name, edge cases, and ID from the table
-8. **Output format authoring reference**: path to the format's `authoring.md` (e.g., `.claude/skills/technical-planning/references/output-formats/{format}/authoring.md`)
+8. **Output format authoring reference**: path to the format's `authoring.md` (e.g., `../output-formats/{format}/authoring.md`)
 
 ### Present the Output
 

package/skills/technical-planning/references/steps/define-phases.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step uses the `planning-phase-designer` agent (`.claude/agents/planning-phase-designer.md`) to define or review the phase structure. Whether phases are being designed for the first time or reviewed from a previous session, the process converges on the same approval gate.
+This step uses the `planning-phase-designer` agent (`../../../../agents/planning-phase-designer.md`) to define or review the phase structure. Whether phases are being designed for the first time or reviewed from a previous session, the process converges on the same approval gate.
 
 ---
 
@@ -30,11 +30,11 @@ Orient the user:
 
 Invoke `planning-phase-designer` with these file paths:
 
-1. **read-specification.md**: `.claude/skills/technical-planning/references/read-specification.md`
+1. **read-specification.md**: `../read-specification.md`
 2. **Specification**: path from the Plan Index File's `specification:` field
 3. **Cross-cutting specs**: paths from the Plan Index File's `cross_cutting_specs:` field (if any)
-4. **phase-design.md**: `.claude/skills/technical-planning/references/phase-design.md`
-5. **task-design.md**: `.claude/skills/technical-planning/references/task-design.md`
+4. **phase-design.md**: `../phase-design.md`
+5. **task-design.md**: `../task-design.md`
 
 The agent returns a complete phase structure. Write it directly to the Plan Index File body.
 

package/skills/technical-planning/references/steps/define-tasks.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step uses the `planning-task-designer` agent (`.claude/agents/planning-task-designer.md`) to design a task list for a single phase. You invoke the agent, present its output, and handle the approval gate.
+This step uses the `planning-task-designer` agent (`../../../../agents/planning-task-designer.md`) to design a task list for a single phase. You invoke the agent, present its output, and handle the approval gate.
 
 ---
 
@@ -18,10 +18,10 @@ Orient the user:
 
 Invoke `planning-task-designer` with these file paths:
 
-1. **read-specification.md**: `.claude/skills/technical-planning/references/read-specification.md`
+1. **read-specification.md**: `../read-specification.md`
 2. **Specification**: path from the Plan Index File's `specification:` field
 3. **Cross-cutting specs**: paths from the Plan Index File's `cross_cutting_specs:` field (if any)
-4. **task-design.md**: `.claude/skills/technical-planning/references/task-design.md`
+4. **task-design.md**: `../task-design.md`
 5. **All approved phases**: the complete phase structure from the Plan Index File body
 6. **Target phase number**: the phase being broken into tasks
 

package/skills/technical-research/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: technical-research
 description: "Explore ideas, validate concepts, and research broadly across technical, business, and market domains. Use when: (1) User has a new idea to explore, (2) Need to research a topic deeply, (3) Validating feasibility - technical, business, or market, (4) Learning and exploration without necessarily building anything, (5) User says 'research this' or 'explore this idea', (6) Brain dumping early thoughts before formal discussion. Creates research documents in docs/workflow/research/ that may feed into discussion or specification."
+user-invocable: false
 ---
 
 # Technical Research

package/skills/technical-review/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: technical-review
 description: "Validate completed implementation against plan tasks and acceptance criteria. Use when: (1) Implementation is complete, (2) User wants validation before merging/shipping, (3) Quality gate check needed after implementation. Reviews ALL plan tasks for implementation correctness, test adequacy, and code quality. Produces structured feedback (approve, request changes, or comments) - does NOT fix code."
+user-invocable: false
 ---
 
 # Technical Review

package/skills/technical-specification/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: technical-specification
 description: "Build validated specifications from source material through collaborative refinement. Use when: (1) User asks to create/build a specification from source material, (2) User wants to validate and refine content before planning, (3) Converting source material (discussions, research, requirements) into standalone specifications, (4) User says 'specify this' or 'create a spec', (5) Need to filter hallucinations and enrich gaps before formal planning. Creates specifications in docs/workflow/specification/{topic}.md that can be used to build implementation plans."
+user-invocable: false
 ---
 
 # Technical Specification

package/skills/view-plan/SKILL.md

@@ -25,7 +25,7 @@ Read the plan file from `docs/workflow/planning/{topic}.md` and check the `forma
 Load the format's reading reference:
 
 ```
-.claude/skills/technical-planning/references/output-formats/{format}/reading.md
+../technical-planning/references/output-formats/{format}/reading.md
 ```
 
 This file contains instructions for reading plans in that format.