Sprint planning with skills (/refine-story, /plan-tasks, /write-issue)

[rucka]

Resolution

Delivered by PR #110 (merged). Board: Done.

feat: sprint planning with skills (/refine-story, /plan-tasks, /write-issue).

Story Statement

As a product engineer planning sprint work with AI assistance
I want to invoke /refine-story and /plan-tasks which compose /write-issue for PM tool integration, with how-to-08 and how-to-09 thinned to orchestrators
So that story refinement and task breakdown follow a structured process that produces properly formatted issues in the adopted PM tool

Where: dataset/.skills/process/refine-story/, dataset/.skills/process/plan-tasks/, dataset/.skills/capability/write-issue/, .pair/knowledge/how-to/08-how-to-refine-a-user-story.md, .pair/knowledge/how-to/09-how-to-create-tasks.md

Epic Context

Parent Epic: Agent Skills in Knowledge Base #97
Status: Refined
Priority: P0 (Must-Have)

Acceptance Criteria

Functional Requirements

1. Given a user story in Todo state
   When /refine-story is invoked in Claude Code
   Then the skill follows the refinement process: story selection → requirements analysis (Given-When-Then) → technical analysis → sprint readiness → documentation, producing a refined story in the adopted PM tool format

2. Given /refine-story is invoked on a story that is already partially refined (e.g. Given-When-Then written but technical analysis missing)
   When the skill evaluates each refinement step
   Then it detects already-completed sections, skips them, and resumes from the first missing section (idempotent execution)

3. Given /refine-story is invoked on a story already in Refined state
   When the skill detects the story is already refined
   Then it offers to update specific sections rather than re-doing the entire refinement

4. Given a refined user story
   When /plan-tasks is invoked
   Then the skill follows the task breakdown process: story analysis → task identification → task definition → documentation using the task template, creating tasks via /write-issue

5. Given /plan-tasks is invoked on a story where some tasks already exist
   When the skill evaluates the task list
   Then it detects existing tasks, skips them, and creates only missing tasks (idempotent execution)

6. Given /write-issue is invoked with $type: story and story content, without $id
   When the skill executes
   Then it reads user-story-template.md, formats the issue body following that template structure, and creates a new issue in the adopted PM tool with proper labels, hierarchy linking (epic → story), and project field configuration

7. Given /write-issue is invoked with $type: story, story content, and $id: 42
   When the skill executes
   Then it reads user-story-template.md, formats the issue body following that template structure, and updates the existing issue chore(test): manual tag smoke #42 in the adopted PM tool

8. Given /write-issue is invoked with $type: task and task content, without $id
   When the skill executes
   Then it reads task-template.md, formats the issue body following that template structure, and creates a new issue in the adopted PM tool with proper labels, hierarchy linking (story → task), and project field configuration

9. Given /write-issue is invoked with $type: task, task content, and $id: 55
   When the skill executes
   Then it reads task-template.md, formats the issue body following that template structure, and updates the existing issue chore: release v0.1.0 #55 in the adopted PM tool

10. Given how-to-08 and how-to-09 are thinned
    When a non-skill assistant reads either file
    Then both remain readable with phase flows, HALT conditions, and selection criteria — just without procedural details

11. Given /write-issue is invoked independently (not via /refine-story or /plan-tasks)
    When called with $type, $content, and optionally $id and $parent
    Then it reads the corresponding template, formats the issue body accordingly, and creates (no $id) or updates ($id provided) the issue in the adopted PM tool

Business Rules

• Idempotent execution (cross-cutting, applies to ALL skills): every step in a skill MUST check current state before acting, and only execute missing actions. Re-invoking a skill on a partially completed workflow resumes from where it left off — never re-does already completed work.
• Template-driven formatting: /write-issue MUST read and apply the type-specific template for every issue it creates or updates:
  • $type: story → reads collaboration/templates/user-story-template.md
  • $type: task → reads collaboration/templates/task-template.md
  • The template defines the issue body structure — /write-issue fills it with the provided content
• Create vs Update via $id: /write-issue behavior is determined by the $id argument:
  • $id absent → create new issue in PM tool
  • $id present → update existing issue identified by $id
  • Skills that compose /write-issue (e.g. /refine-story, /plan-tasks) are responsible for passing $id when updating an existing issue
• PM tool agnostic: /write-issue uses ONLY the PM tool specified in adoption (adoption/tech/way-of-working.md). There is NO fallback to a different tool. If the adopted PM tool is unavailable or encounters errors, /write-issue HALTs with an error and reports the issue to the developer — it does NOT silently switch to an alternative tool.
• Extensible by design: in this story /write-issue supports story and task types. Support for epic and initiative types (with their own templates) is added in #103 when the strategic planning skills need them.
• /write-issue is a single skill handling multiple issue types — target type passed as argument
• Adoption binding: /write-issue reads adoption/tech/way-of-working.md for PM tool choice
• How-to-08 keeps: phase flow (selection → analysis → requirements → validation → documentation → completion), HALT conditions, INVEST validation framework
• How-to-08 loses → /refine-story: requirements gathering procedures, Given-When-Then generation, technical analysis execution, template filling
• How-to-09 keeps: phase flow (7 phases), HALT conditions, task decomposition criteria
• How-to-09 loses → /plan-tasks: task identification patterns, template filling, dependency identification procedures
• Templates (user-story-template.md, task-template.md) are consumed BY skills, not modified

Edge Cases and Error Handling

• PM tool not configured: /write-issue HALTs and asks developer to configure via /setup-pm or manually set way-of-working.md
• Story not refined: /plan-tasks HALTs — requires refined story as input
• PM tool error: /write-issue HALTs with an error describing the problem (e.g. API unavailable, authentication failure, rate limit). No fallback to a different tool — the developer must resolve the issue with the adopted PM tool.
• Story already refined: /refine-story detects Refined state, offers selective update
• Tasks partially created: /plan-tasks detects existing tasks, creates only missing ones
• $id provided but issue not found: /write-issue HALTs with error "issue #N not found"
• Template not found: /write-issue HALTs with error indicating which template is missing
• Unsupported $type: /write-issue HALTs with error listing currently supported types (story/task in this story; epic/initiative added in Strategic planning process skills (/plan-initiatives through /plan-stories) #103)

Definition of Done Checklist

Development Completion

• dataset/.skills/process/refine-story/SKILL.md created with idempotent section-level checks
• dataset/.skills/process/plan-tasks/SKILL.md created with idempotent task-level checks
• dataset/.skills/capability/write-issue/SKILL.md created with PM tool abstraction, template-driven formatting, $id for create/update, extensible type system, no tool fallback
• /write-issue reads and applies user-story-template.md for story issues
• /write-issue reads and applies task-template.md for task issues
• /write-issue creates (no $id) or updates ($id provided) correctly
• /write-issue HALTs on PM tool errors with descriptive message (no fallback)
• /write-issue returns issue identifier after create (for compose chains)
• /write-issue designed for extensibility (epic/initiative types added in Strategic planning process skills (/plan-initiatives through /plan-stories) #103)
• how-to-08 thinned to ~120 lines (orchestration only)
• how-to-09 thinned to ~140 lines (orchestration only)
• Every skill step follows check→skip→act→verify pattern (idempotency)
• /write-issue tested with adopted PM tool (create + update)
• Both thinned how-to files readable as standalone
• Code reviewed and merged

Quality Assurance

• /refine-story invocable in Claude Code — produces refined story
• /refine-story re-invoked on partially refined story — completes only missing sections
• /refine-story on already-refined story — offers selective update (passes $id to /write-issue)
• /plan-tasks invocable in Claude Code — produces task breakdown
• /plan-tasks re-invoked with some tasks existing — creates only missing tasks
• /write-issue create mode (no $id) — creates issue, body follows template structure
• /write-issue update mode ($id provided) — updates existing issue, body follows template structure
• /write-issue with $id for non-existent issue — HALTs with clear error
• /write-issue on PM tool error — HALTs with descriptive error, no fallback
• /write-issue invocable independently — creates or updates issue in adopted PM tool
• Adoption binding: /write-issue reads way-of-working.md correctly

Story Sizing and Sprint Readiness

Refined Story Points

Final Story Points: L(5)
Confidence Level: High
Sizing Justification: 3 SKILL.md + 2 how-to thinnings + idempotency (section-level, task-level, issue-level). /write-issue is the most complex atomic skill (PM tool abstraction + template-driven formatting + create/update via $id + no fallback error handling) but content is well-defined in existing PM tool implementation guides and templates.

Sprint Fit Assessment

Sprint Fit: Yes — single sprint
Development Estimate: 3 days (3 skills + 2 how-to thinnings)
Testing Estimate: 1 day (Claude Code + PM tool modes + template validation + create/update tests + error handling tests + re-invocation tests + standalone readability)

Dependencies and Coordination

Story Dependencies

Prerequisite Stories: #98 (skill infrastructure)
Dependent Stories: #103 (extends /write-issue with epic + initiative types)

Validation and Testing Strategy

Acceptance Testing

• Invoke /refine-story with a sample Todo story → verify refinement process
• Re-invoke /refine-story on partially refined story → verify resumes from missing section
• Invoke /refine-story on already-refined story → verify offers update, passes $id
• Invoke /plan-tasks with a refined story → verify task breakdown, new tasks via /write-issue (no $id)
• Re-invoke /plan-tasks with some tasks existing → verify creates only missing tasks
• Invoke /write-issue with $type: story, no $id → verify creates issue, body matches user-story-template.md
• Invoke /write-issue with $type: story, $id: 42 → verify updates issue chore(test): manual tag smoke #42, body matches template
• Invoke /write-issue with $type: task, no $id → verify creates issue, body matches task-template.md
• Invoke /write-issue with $type: task, $id: 55 → verify updates issue chore: release v0.1.0 #55
• Invoke /write-issue with $id for non-existent issue → verify HALT with error
• Simulate PM tool error → verify /write-issue HALTs with descriptive error, no fallback
• Read thinned how-to-08 and how-to-09 as standalone → verify comprehensibility

Notes

Open questions resolved:

• /write-issue handles story and task types in this story — single skill with $type argument, reads the type-specific template file
• /write-issue is extensible: epic and initiative types (with their templates) are added in Strategic planning process skills (/plan-initiatives through /plan-stories) #103 when strategic planning skills need them
• /write-issue template-driven: reads the template, parses its structure, fills with content. Template = the source of truth for issue body format.
• Create vs Update: determined by $id argument — absent = create, present = update. No ambiguous title matching. Callers (e.g. /refine-story, /plan-tasks) pass $id when updating.
• /refine-story transition: skill handles template switching from Initial Breakdown to Refined format
• Idempotency: /refine-story checks sections, /plan-tasks checks existing tasks, /write-issue uses explicit $id for updates. All follow check→skip→act→verify pattern.
• No PM tool fallback: /write-issue uses ONLY the adopted PM tool. On error, it HALTs with a descriptive message — the developer resolves the issue, then re-invokes (idempotent).

Completes Circle 1 (sprint cycle). After #98-#101, daily development workflow fully covered by skills.

Design reference: docs/design/skills-in-knowledge-base.md sections 1, 2, 3, composition pattern

Technical Analysis

Strategy

Write 3 SKILL.md files. Thin 2 how-to files. /write-issue introduces PM tool abstraction — reads adoption for tool choice, reads type-specific template for formatting. No fallback between tools. Designed for extensibility: adding new types (epic, initiative in #103) means adding template references, not restructuring. All skills follow check→skip→act→verify idempotency pattern from #99.

/write-issue Flow

1. Read $type argument → validate supported type → select template
2. Read template file → parse expected structure/sections
3. Fill template with $content data
4. Read PM tool from adoption → select implementation guide
5. If $id provided → update existing issue; if absent → create new issue
6. Create/update issue in PM tool following implementation guide
7. If PM tool returns error → HALT with descriptive error (no fallback)
8. Return the issue identifier (for compose chains)

Idempotency per Skill

• /refine-story: checks each section (Given-When-Then, technical analysis, DoD, sprint readiness) → skips sections already present. On update, passes $id to /write-issue.
• /plan-tasks: reads existing tasks → identifies missing → creates only missing via /write-issue (no $id). Updates existing via $id.
• /write-issue: $id absent = create, $id present = update.

Technical Risks

Risk	Impact	Probability	Mitigation Strategy
PM tool abstraction too complex	Medium	Low	/write-issue reads implementation guide per tool — no code logic, just markdown routing
Template path changes break /write-issue	Medium	Low	Template paths defined in SKILL.md frontmatter, easy to update
Two how-to files thinned at once	Low	Low	Pattern established by #99
PM tool error with no fallback	Medium	Low	Clear error messages guide developer; re-invokable (idempotent)

Task Breakdown

• T-1: Create /write-issue SKILL.md (capability skill)
• T-2: Create /refine-story SKILL.md (process skill)
• T-3: Create /plan-tasks SKILL.md (process skill)
• T-4: Thin how-to-08 from ~308 to ~120 lines
• T-5: Thin how-to-09 from ~358 to ~140 lines
• T-6: Validate skills and thinned how-to files in Claude Code

Dependency Graph

T-1 (/write-issue) ──┬── T-2 (/refine-story) ── T-4 (thin how-to-08)
                      └── T-3 (/plan-tasks) ──── T-5 (thin how-to-09)
                                                              │
T-4 + T-5 ─────────────────────────────────────── T-6 (validate)

AC Coverage

AC	Tasks
AC-1 (/refine-story process)	T-2
AC-2 (refine idempotent)	T-2, T-6
AC-3 (already-refined update)	T-2
AC-4 (/plan-tasks breakdown)	T-3
AC-5 (plan-tasks idempotent)	T-3, T-6
AC-6..9 (/write-issue create/update story/task)	T-1
AC-10 (thinned how-tos)	T-4, T-5
AC-11 (/write-issue independent)	T-1, T-6

---

T-1: Create /write-issue SKILL.md (capability skill)

Priority: P0 | Estimated Hours: 5h | Bounded Context: Knowledge Base Management

Summary: Create /write-issue atomic capability skill with PM tool abstraction and template-driven formatting.

Type: Documentation

Description: PM tool abstraction: reads adoption/tech/way-of-working.md for tool choice, reads type-specific template ($type: story → user-story-template.md, $type: task → task-template.md), formats body, creates (no $id) or updates ($id provided). No PM tool fallback — HALT on error. Extensible: epic/initiative types added in #103. Arguments: $type (required), $content (required), $id (optional), $parent (optional). Returns issue identifier for compose chains. References collaboration/project-management-tool/github-implementation.md or filesystem-implementation.md for tool-specific behavior.

Acceptance Criteria:

• Primary deliverable: SKILL.md with valid YAML frontmatter per agentskills.io spec
• Quality standard: Creates and updates issues correctly; template-driven formatting
• Integration requirement: Independently invocable AND composable by /refine-story and /plan-tasks
• Verification method: Manual validation — create story, update story, create task, update task, PM tool error → HALT

Technical Requirements:

• Functionality: PM tool read from adoption, template-driven formatting, create/update via $id, HALT on error
• Performance: N/A
• Security: N/A

Implementation Approach:

• Technical Design: Read adoption → select PM tool → read template → format body → create/update issue
• Bounded Context & Modules: Knowledge Base Management — dataset/.skills/capability/
• Files to Modify/Create:
  • dataset/.skills/capability/write-issue/SKILL.md — new capability skill
• Technical Standards: agentskills.io spec, template-driven, no fallback

Dependencies:

• Technical: Skill infrastructure from Skill infrastructure + navigator (/next) #98
• Tasks: Skill infrastructure + navigator (/next) #98 complete

Implementation Steps:

1. Create directory dataset/.skills/capability/write-issue/
2. Write YAML frontmatter (name, description, arguments: $type, $content, $id, $parent)
3. Write PM tool detection logic (read way-of-working.md)
4. Write template selection logic ($type → template file)
5. Write template filling logic
6. Write create vs update routing ($id absent → create, present → update)
7. Write PM tool implementation guide reference
8. Write error handling (HALT on PM tool error, no fallback)
9. Write return value (issue identifier for compose chains)

Testing Strategy:

• Unit Tests: N/A (markdown skill)
• Manual Testing: Create story, update story, create task, update task, PM tool error → HALT

Notes: Most complex atomic skill. Designed for extensibility — epic/initiative added in #103 by adding template references.

---

T-2: Create /refine-story SKILL.md (process skill)

Priority: P0 | Estimated Hours: 4h | Bounded Context: Knowledge Base Management

Summary: Create /refine-story process skill with section-level idempotency and template reordering.

Type: Documentation

Description: Section-level idempotency: selection → requirements (Given-When-Then) → technical analysis → sprint readiness → documentation. Detects partial refinement, resumes from missing section. Already-refined → offers selective update (passes $id to /write-issue). Composes /write-issue ($type: story). Template reordering: user story body has functional sections first (Story Statement → Epic Context → AC → DoD → Sizing → Dependencies → Validation → Notes), then technical sections last (Technical Analysis → Task Breakdown). Update collaboration/templates/user-story-template.md to reflect functional-first/technical-last ordering. Update collaboration/templates/task-template.md to formalize Dependency Graph and AC Coverage in the Task Breakdown Format for Story Body section.

Acceptance Criteria:

• Primary deliverable: SKILL.md with valid frontmatter; section-level idempotency
• Quality standard: Partial resume works; already-refined offers update; template reordered
• Integration requirement: Composes /write-issue; produces properly formatted story issues
• Verification method: Manual validation — refine Todo story, re-invoke partial, re-invoke already-refined

Technical Requirements:

• Functionality: Section-level idempotency, partial resume, already-refined detection, template reordering
• Performance: N/A
• Security: N/A

Implementation Approach:

• Technical Design: Section checklist with check→skip→act→verify per section, /write-issue composition
• Bounded Context & Modules: Knowledge Base Management — dataset/.skills/process/
• Files to Modify/Create:
  • dataset/.skills/process/refine-story/SKILL.md — new process skill
  • packages/knowledge-hub/dataset/.pair/knowledge/guidelines/collaboration/templates/user-story-template.md — functional-first/technical-last ordering
  • packages/knowledge-hub/dataset/.pair/knowledge/guidelines/collaboration/templates/task-template.md — add Dependency Graph + AC Coverage to Task Breakdown Format
• Technical Standards: check→skip→act→verify, composes /write-issue

Dependencies:

• Technical: /write-issue (T-1)
• Tasks: T-1

Implementation Steps:

1. Create directory dataset/.skills/process/refine-story/
2. Write YAML frontmatter (name, description, composed skills)
3. Write section-level idempotency logic (detect existing sections, skip completed)
4. Write refinement phases: selection → requirements → technical analysis → sprint readiness → documentation
5. Write already-refined detection and selective update logic
6. Write /write-issue composition ($type: story, pass $id for updates)
7. Reorder user-story-template.md: functional sections first, Technical Analysis + Task Breakdown last (after Notes, before footer)
8. Update task-template.md: add Dependency Graph (ASCII block) and AC Coverage table to "Task Breakdown Format for Story Body" section

Testing Strategy:

• Unit Tests: N/A (markdown skill)
• Manual Testing: Refine Todo story, re-invoke partial, re-invoke already-refined

Notes: Template reordering positions Technical Analysis as bridge to Task Breakdown.

---

T-3: Create /plan-tasks SKILL.md (process skill)

Priority: P0 | Estimated Hours: 4h | Bounded Context: Knowledge Base Management

Summary: Create /plan-tasks process skill with task-level idempotency and integrated technical section format.

Type: Documentation

Description: Task-level idempotency: story analysis → task identification → task definition → documentation via /write-issue. Detects existing tasks, creates only missing ones ($type: task, no $id). Updates existing via $id. Coverage validation: all ACs mapped to tasks. Composes /write-issue. Integrated Technical Analysis + Task Breakdown format: Technical Analysis and Task Breakdown are the last content sections in the story body (after Notes, before footer). When appending, condenses Technical Analysis (keeps strategy summary, data flow/pipeline order, risks), then appends: task checklist → Dependency Graph (ASCII block showing task dependencies) → AC Coverage table (maps each AC to covering tasks) → detailed tasks.

Acceptance Criteria:

• Primary deliverable: SKILL.md with valid frontmatter; task-level idempotency
• Quality standard: Creates only missing tasks; coverage validation; integrated technical section
• Integration requirement: Composes /write-issue; appends Task Breakdown to story issue
• Verification method: Manual validation — plan tasks for refined story, re-invoke with existing tasks

Technical Requirements:

• Functionality: Task-level idempotency, coverage validation, integrated Technical Analysis + Task Breakdown
• Performance: N/A
• Security: N/A

Implementation Approach:

• Technical Design: Task checklist with check→skip→act→verify, /write-issue composition, TA condensation
• Bounded Context & Modules: Knowledge Base Management — dataset/.skills/process/
• Files to Modify/Create:
  • dataset/.skills/process/plan-tasks/SKILL.md — new process skill
  • packages/knowledge-hub/dataset/.pair/knowledge/guidelines/collaboration/templates/task-template.md — formalize Dependency Graph + AC Coverage in Task Breakdown Format
• Technical Standards: check→skip→act→verify, composes /write-issue, task-template.md

Dependencies:

• Technical: /write-issue (T-1)
• Tasks: T-1

Implementation Steps:

1. Create directory dataset/.skills/process/plan-tasks/
2. Write YAML frontmatter (name, description, composed skills)
3. Write story analysis phase (read story, extract ACs)
4. Write task identification phase (decompose into bounded contexts)
5. Write task definition phase (fill task template per task)
6. Write existing task detection logic (idempotent)
7. Write coverage validation (all ACs mapped to tasks)
8. Write Technical Analysis condensation logic (strategy + data flow + risks)
9. Write Task Breakdown appending logic (position at end of story body: condensed TA → checklist → Dependency Graph → AC Coverage table → detailed tasks)
10. Update task-template.md: add Dependency Graph and AC Coverage to "Task Breakdown Format for Story Body"
11. Write /write-issue composition ($type: task for each task)

Testing Strategy:

• Unit Tests: N/A (markdown skill)
• Manual Testing: Plan tasks for refined story, re-invoke with existing tasks

Notes: Integrated Technical Analysis + Task Breakdown format is the same pattern used manually for this epic's task breakdown.

---

T-4: Thin how-to-08 from ~308 to ~120 lines

Priority: P0 | Estimated Hours: 2h | Bounded Context: Knowledge Base Management

Summary: Remove operational content from how-to-08, keeping orchestration structure.

Type: Documentation

Description: Keep: phase flow (selection → analysis → requirements → validation → documentation → completion), HALT conditions, INVEST validation framework, selection criteria. Remove (now in skills): requirements gathering procedures, Given-When-Then generation, technical analysis execution, template filling. Standalone readable for non-skill assistants.

Acceptance Criteria:

• Primary deliverable: how-to-08 thinned to ~120 lines
• Quality standard: Phase flow preserved; HALT conditions preserved; standalone readable
• Integration requirement: Non-skill assistants can still follow the how-to
• Verification method: Manual readability review

Technical Requirements:

• Functionality: Orchestration preserved, operational details removed
• Performance: N/A
• Security: N/A

Implementation Approach:

• Technical Design: Remove operational sections, preserve workflow map and HALT conditions
• Bounded Context & Modules: Knowledge Base Management — .pair/knowledge/how-to/
• Files to Modify/Create:
  • .pair/knowledge/how-to/08-how-to-refine-a-user-story.md — thin to ~120 lines
• Technical Standards: Standalone readability

Dependencies:

• Technical: /refine-story skill must exist (T-2) to receive operational content
• Tasks: T-2

Implementation Steps:

1. Read current how-to-08, identify operational vs orchestration sections
2. Remove requirements gathering procedures, Given-When-Then generation
3. Remove technical analysis execution, template filling
4. Verify remaining content (~120 lines) has phase flow, HALT conditions, INVEST framework
5. Review as standalone document

Testing Strategy:

• Unit Tests: N/A
• Manual Testing: Standalone readability review

Notes: Second how-to thinning (after #99's how-to-10). Pattern well-established.

---

T-5: Thin how-to-09 from ~358 to ~140 lines

Priority: P0 | Estimated Hours: 2h | Bounded Context: Knowledge Base Management

Summary: Remove operational content from how-to-09, keeping orchestration structure.

Type: Documentation

Description: Keep: 7-phase flow, HALT conditions, task decomposition criteria, bounded context mapping requirement. Remove (now in skills): task identification patterns, template filling, dependency identification procedures. Standalone readable for non-skill assistants.

Acceptance Criteria:

• Primary deliverable: how-to-09 thinned to ~140 lines
• Quality standard: 7-phase flow preserved; HALT conditions preserved; standalone readable
• Integration requirement: Non-skill assistants can still follow the how-to
• Verification method: Manual readability review

Technical Requirements:

• Functionality: Orchestration preserved, operational details removed
• Performance: N/A
• Security: N/A

Implementation Approach:

• Technical Design: Remove operational sections, preserve workflow map and HALT conditions
• Bounded Context & Modules: Knowledge Base Management — .pair/knowledge/how-to/
• Files to Modify/Create:
  • .pair/knowledge/how-to/09-how-to-create-tasks.md — thin to ~140 lines
• Technical Standards: Standalone readability

Dependencies:

• Technical: /plan-tasks skill must exist (T-3) to receive operational content
• Tasks: T-3

Implementation Steps:

1. Read current how-to-09, identify operational vs orchestration sections
2. Remove task identification patterns, template filling
3. Remove dependency identification procedures
4. Verify remaining content (~140 lines) has 7-phase flow, HALT conditions, decomposition criteria
5. Review as standalone document

Testing Strategy:

• Unit Tests: N/A
• Manual Testing: Standalone readability review

Notes: Thins in parallel with T-4 (how-to-08).

---

T-6: Validate skills and thinned how-to files in Claude Code

Priority: P0 | Estimated Hours: 2h | Bounded Context: Knowledge Base Management

Summary: End-to-end validation of all skills and thinned how-to-08/how-to-09 in Claude Code.

Type: Testing

Description: Validate: /refine-story on Todo story (full refinement); re-invoke partial (resumes); already-refined (offers update); /plan-tasks on refined story (creates tasks); re-invoke with existing tasks (creates only missing); /write-issue independently (create + update for both story and task types); PM tool error → HALT; thinned how-to-08 and how-to-09 standalone readability.

Acceptance Criteria:

• Primary deliverable: All skills invocable and producing correct output
• Quality standard: Re-invocation works; PM tool error handling correct
• Integration requirement: All skills work in Claude Code environment
• Verification method: Manual Claude Code validation for all scenarios

Technical Requirements:

• Functionality: All skills invocable, idempotent, correct output
• Performance: N/A
• Security: N/A

Implementation Approach:

• Technical Design: Manual validation in Claude Code
• Bounded Context & Modules: Knowledge Base Management
• Files to Modify/Create: None (validation only)
• Technical Standards: All AC scenarios must pass

Dependencies:

• Technical: All skills and thinned how-tos must exist
• Tasks: T-4, T-5, Skill infrastructure + navigator (/next) #98 complete

Implementation Steps:

1. Invoke /refine-story on Todo story → verify full refinement
2. Re-invoke /refine-story on partially refined → verify resume
3. Re-invoke /refine-story on already-refined → verify offers update
4. Invoke /plan-tasks on refined story → verify task creation
5. Re-invoke /plan-tasks with existing tasks → verify creates only missing
6. Invoke /write-issue independently (create + update, story + task)
7. Test PM tool error → verify HALT
8. Read thinned how-to-08 and how-to-09 → verify standalone readability

Testing Strategy:

• Manual Testing: All scenarios listed above

Notes: Final validation before story completion.

---

Refinement Date: 2026-02-08
Review and Approval: Approved (2026-02-09)