Feature Implementation

"Fetch GitHub issue #6992 from myorg/myapp"

"List my CoreStory projects"
"Verify that the myapp-main project ingestion is completed"

"Create a CoreStory conversation for project myapp-main titled
'Ticket Implementation: #6992 - Add CSV export for user profiles'"

"What files are responsible for [feature area]? I need to understand:
1. Primary implementation files and their responsibilities
2. Existing test patterns and coverage
3. Helper/utility modules I can reuse
4. Integration points with other components"

"What files handle user profile operations and data export? I need to understand:
1. Where user profile data is accessed
2. Existing export functionality (PDF, etc.)
3. Serialization utilities available
4. API endpoints for downloads"

"What architectural patterns are used for [feature type]? Specifically:
1. How are similar features structured?
2. What design patterns should I follow?
3. What naming conventions apply?
4. What invariants must I maintain?"

"Have there been similar features implemented recently? What was the design
intent? Are there related user stories or tickets I should reference?"

"Where should I implement [feature]? What are the extension points?
Walk me through the implementation locations step by step."

"What data structures should I use for [feature]? What models/schemas are
involved? What are the relationships and dependencies?"

"What existing features are most similar to [new feature]? Can I reuse code?
What patterns should I copy?"

def test_admin_can_export_user_profiles_as_csv():
    """
    Ticket: #6992 - Add CSV export for user profiles
    AC: Admin users can export user data as CSV
    """
    admin = create_user(role='admin')
    users = [create_user(email='user1@example.com'), create_user(email='user2@example.com')]

    response = client.get('/users/export/csv', headers=auth_header(admin))

    assert response.status_code == 200
    assert response.headers['Content-Type'] == 'text/csv'
    assert 'user1@example.com' in response.data.decode('utf-8-sig')

"I've written these tests for [feature]:
[paste test code]

Do these correctly validate the acceptance criteria? Are there edge cases
I'm missing? Do they follow the testing patterns from [reference tests]?"

class CsvExportService(ExportServiceBase):
    """
    Service for exporting user data to CSV format.
    Follows the export pattern established in PdfExportService.
    Ticket: #6992
    """
    def export(self, users, profiles):
        # Implementation following established pattern
        ...

"I've implemented [feature] following this structure:
[code structure]

Does this align with the system architecture? Could it have unintended
side effects?"

"My basic [feature] tests pass. What edge cases should I test? What scenarios
might break in production?"

Feat: Add CSV export for user profiles (#6992)

Feature:
Admin users can export user profile data in CSV format.

Implementation:
- Created CsvExportService following PdfExportService pattern
- Added /users/export/csv endpoint (admin only)
- Async processing for large datasets (>1000 records)

Architecture Alignment:
- Extends ExportServiceBase
- Uses established auth pattern
- Follows async job pattern for large exports

Testing:
- 7 integration tests covering acceptance criteria
- 3 unit tests for CsvExportService
- All tests passing, no regressions

References:
- Ticket: #6992
- CoreStory Investigation: [conversation-id]

"Rename the CoreStory conversation to:
'Ticket Implementation: #6992 - COMPLETED - CSV export'"

claude mcp add --transport http corestory https://c2s.corestory.ai/mcp \
  --header "Authorization: Bearer mcp_YOUR_TOKEN_HERE"

"List my CoreStory projects"

mkdir -p .claude/skills/implement-feature

git add .claude/skills/implement-feature/SKILL.md
git commit -m "Add CoreStory feature implementation skill"

Implement ticket #6992
Build feature JIRA-1234
Resolve ENG-456

---
name: implement-feature
description: >
  Implement a feature using CoreStory's code intelligence and TDD methodology.
  Use when the user asks to implement a ticket, build a feature, or resolve
  an issue by ID (e.g., "Implement ticket #6992", "Build feature JIRA-123",
  "Resolve ENG-456"). Do NOT use for bug fixes — use the fix-bug skill instead.
---

# CoreStory Feature Implementation

Systematically implement feature tickets using CoreStory for architectural
guidance and test-driven development for quality.

## Prerequisites Check

Before starting, verify:
1. CoreStory MCP server is connected (`list_projects` returns results)
2. Target project has completed ingestion
3. Ticket details are available (via ticketing MCP or user-provided)

## Workflow

Execute all six phases in order. Do not skip phases.

### PHASE 1: Ticket Intake

1. If user provided a ticket ID: fetch it via the appropriate ticketing MCP.
   If user described the feature directly: extract description and ask for
   acceptance criteria if not provided.
2. Select CoreStory project:
   - Call `list_projects`
   - If multiple: ask user which one
   - If one: auto-select
   - Verify project ingestion status is "completed"
3. Create implementation conversation:
   - Call `create_conversation` with title "Ticket Implementation: #[ID] - [description]"
   - Store conversation_id for all subsequent queries

Report to user: ticket summary, acceptance criteria, conversation ID.

### PHASE 2: Oracle Phase (Architecture Understanding)

Send these queries to CoreStory via `send_message`. After each, summarize
key findings to user.

**Query 1 — Architecture discovery:**
"What files are responsible for [feature area]? I need: primary implementation
files, existing test patterns, reusable helper modules, integration points."

**Query 2 — Design patterns and conventions:**
"What architectural patterns are used for [feature type]? How are similar
features structured? What naming conventions apply? What invariants must
I maintain?"

**Query 3 — Historical context:**
"Have similar features been implemented recently? What was the design intent?
Are there related PRs or tickets?"

Parse responses for: core files, reference implementations, naming conventions,
invariants (CRITICAL — these must not be violated), and known gotchas.

### PHASE 3: Navigator Phase (Implementation Planning)

**Query 1 — Extension points:**
"Where should I implement [feature]? What files to create, what files to
modify? Walk me through step by step."

**Query 2 — Data structures:**
"What data structures should I use? What models/schemas are involved?
What relationships and dependencies exist?"

**Query 3 — Reference implementations:**
"What existing features are most similar? Can I reuse code or patterns?"

Output to user: files to create, files to modify, data structures, reference
pattern to follow.

### PHASE 4: TDD Implementation

**CRITICAL: Tests come BEFORE implementation code.**

1. Write acceptance tests from Phase 1 criteria, following Phase 2 patterns
   and Phase 3 data structures. Use naming pattern:
   `test_[feature]_[scenario]_[expected]`
2. Write unit tests for individual components.
3. Verify all tests FAIL. If they pass, the feature may already exist —
   check with CoreStory.
4. Validate tests with CoreStory: paste test code and ask if they correctly
   validate the acceptance criteria and follow established testing patterns.
5. Implement the feature following patterns from Phase 2.
6. Verify all tests PASS.
7. Validate implementation with CoreStory: paste code structure and ask if
   it aligns with architecture and could have unintended side effects.

### PHASE 5: Feature Completion

1. Ask CoreStory for edge cases: "What edge cases should I test? What
   scenarios might break in production?"
2. Add edge case tests (empty state, large data, concurrent access,
   invalid input, permission boundaries).
3. Run FULL test suite — all tests must pass, no regressions.
4. If feature has performance requirements: add performance tests.
5. If feature handles auth or sensitive data: add security tests.

### PHASE 6: Completion

1. Update ticket (if ticketing MCP available) with implementation summary.
2. Commit with detailed message:
   - Format: "Feat: [description] (#[ticket-id])"
   - Include: feature summary, implementation details, architecture
     alignment notes, test count and categories, references
3. Rename CoreStory conversation:
   "Ticket Implementation: #[ID] - COMPLETED - [description]"
4. Report to user: summary, commit info, test results, quality metrics.

## When NOT to Use This Skill

- Trivial changes (typos, formatting)
- Documentation-only changes
- Bug fixes (use fix-bug skill instead)
- No CoreStory project available
- User explicitly wants to implement manually

mkdir -p .github

git add .github/copilot-instructions.md .github/prompts/
git commit -m "Add CoreStory feature implementation instructions for Copilot"

Implement ticket #6992 — add webhook support for project events
Build feature JIRA-456 — user notification preferences

@workspace /implement-feature #6992

# CoreStory Feature Implementation Workflow

## Role

You are a feature implementation assistant with access to CoreStory's code intelligence via MCP. When users request feature builds, ticket implementations, or enhancements, follow the six-phase workflow below.

## Activation

Apply this workflow when user requests feature implementation, ticket resolution, or enhancement work. Trigger phrases: "implement", "build", "feature", "ticket", "story", "enhancement". Do NOT use for bug fixes.

## Workflow

### Phase 1: Ticket Intake
1. Extract feature details from ticket (via ticketing MCP) or user description
2. Identify acceptance criteria — ask for them if not provided
3. Select CoreStory project (`CoreStory:list_projects`, verify status is "completed")
4. Create implementation conversation (`CoreStory:create_conversation`)
5. Report: feature summary, acceptance criteria, CoreStory conversation ID

### Phase 2: Oracle Phase — Understand Architecture
**Do this BEFORE writing any code.**

Send three CoreStory queries (`CoreStory:send_message`):
1. Architecture discovery: files, tests, modules, integration points for the feature area
2. Design patterns & conventions: how similar features are structured, naming conventions, invariants
3. Historical context: recent similar features, design intent, related PRs

Extract and report: key files, reference implementations, conventions, invariants to maintain.

### Phase 3: Navigator Phase — Plan Implementation
Send three CoreStory queries:
1. Extension points: where to add new code, what files to create/modify
2. Data structures: models, schemas, relationships, dependencies
3. Reference implementations: most similar existing features, reusable patterns

Report: files to create, files to modify, data structures, pattern to follow.

### Phase 4: TDD Implementation
**Write tests BEFORE implementation code.**

1. Write acceptance tests from Phase 1 criteria, following Phase 2 patterns
2. Write unit tests for individual components
3. Verify all tests FAIL (if they pass, feature may already exist)
4. Validate tests with CoreStory (paste code, check correctness and coverage)
5. Implement the feature following patterns from Phase 2
6. Verify all tests PASS
7. Validate implementation with CoreStory (architectural alignment, side effects)

### Phase 5: Feature Completion
1. Ask CoreStory for edge cases
2. Add edge case tests (empty state, large data, concurrent access, invalid input, permissions)
3. Run full test suite — no regressions
4. Add performance tests if relevant
5. Add security tests if feature touches auth or sensitive data

### Phase 6: Completion
1. Update ticket (if ticketing MCP available)
2. Commit: "Feat: [description] (#[ticket-id])" with implementation details, architecture alignment, test summary
3. Rename CoreStory conversation to include "COMPLETED"
4. Report: summary, tests added, quality metrics

## Key Principles
- **Oracle before Navigator**: understand architecture before planning implementation
- **Test-first always**: failing tests → implement → verify passes
- **Validate with CoreStory**: check tests and implementation against architecture
- **Follow existing patterns**: match the codebase's conventions, don't invent new ones
- **Rich documentation**: commit messages explain architectural decisions

## CoreStory Query Patterns

Architecture: "What files are responsible for [feature area]?"
Patterns: "How are similar features structured in this codebase?"
Extension points: "Where should I implement [feature]? What files to create or modify?"
Validation: "Looking at [code]: does this align with the existing architecture?"
Edge cases: "What edge cases should I test for [feature]?"

---
mode: agent
description: Implement a feature using CoreStory's code intelligence
---

Implement the specified feature using the CoreStory six-phase workflow.

1. Fetch ticket details and create a CoreStory implementation conversation
2. Query CoreStory for architecture, patterns, conventions, and invariants
3. Plan implementation — files to create/modify, data structures, reference patterns
4. Write failing tests BEFORE implementing, then build the feature
5. Add edge case tests, run full suite, validate with CoreStory
6. Commit with full context, update ticket, preserve conversation

mkdir -p .cursor/rules/implement-feature

git add .cursor/rules/
git commit -m "Add CoreStory feature implementation rules for Cursor"

Implement ticket #6992 — add webhook support for project events
Build the user notification preferences feature from JIRA-456

---
description: CoreStory-powered feature implementation workflow. Activates for ticket implementation, feature builds, and enhancement work.
alwaysApply: false
---

# CoreStory Feature Implementation

You are a feature implementation agent with access to CoreStory's code intelligence via MCP. Follow the six-phase workflow for building new features from tickets.

## Activation Triggers

Apply when user requests: feature implementation, ticket work, enhancements, stories, or any phrase containing "implement", "build", "feature", "ticket", "story". Do NOT use for bug fixes.

## Phase 1: Ticket Intake
- Extract feature details from ticket or user description
- Identify acceptance criteria — ask if missing
- Select CoreStory project (`CoreStory:list_projects`)
- Create implementation conversation (`CoreStory:create_conversation`)

## Phase 2: Oracle Phase
**Understand architecture BEFORE writing any code.**

Query CoreStory (`CoreStory:send_message`) for:
1. Architecture: files, tests, modules for the feature area
2. Patterns & conventions: how similar features are structured, naming, invariants
3. History: recent similar features, design intent, related PRs

## Phase 3: Navigator Phase
Query CoreStory for:
1. Extension points: where to add code, files to create/modify
2. Data structures: models, schemas, relationships
3. Reference implementations: similar features, reusable patterns

## Phase 4: TDD Implementation
**Write tests BEFORE implementation code.**
1. Write acceptance tests from criteria + patterns from Phases 2-3
2. Write unit tests for components
3. Verify all tests FAIL
4. Validate tests with CoreStory
5. Implement following Phase 2 patterns
6. Verify all tests PASS
7. Validate implementation with CoreStory

## Phase 5: Feature Completion
1. Ask CoreStory for edge cases
2. Add edge case tests
3. Run full test suite — no regressions
4. Add performance/security tests if needed

## Phase 6: Completion
1. Update ticket
2. Commit: "Feat: [description] (#[ticket-id])" with architecture notes, test summary
3. Rename CoreStory conversation → "COMPLETED"
4. Report results

## Key Principles
- Oracle before Navigator
- Test-first always
- Validate with CoreStory at each transition
- Follow existing patterns
- Commit messages explain architectural decisions

mkdir -p .factory/droids

git add .factory/droids/
git commit -m "Add CoreStory feature implementation droid"

@implement-feature Implement ticket #6992 — add webhook support

---
name: CoreStory Feature Implementation
description: Implements features using CoreStory code intelligence and TDD methodology
model: inherit
tools:
  - CoreStory:list_projects
  - CoreStory:get_project
  - CoreStory:get_project_stats
  - CoreStory:create_conversation
  - CoreStory:send_message
  - CoreStory:get_conversation
  - CoreStory:rename_conversation
  - CoreStory:get_project_prd
  - CoreStory:get_project_techspec
---

# CoreStory Feature Implementation

Execute the six-phase feature implementation workflow using CoreStory's code intelligence.

## Activation Triggers
- "Implement ticket #[ID]"
- "Build feature [description]"
- "Resolve story [ID]"
- Any feature implementation or enhancement request

## CoreStory MCP Tools
- `CoreStory:list_projects` — list available projects
- `CoreStory:get_project` — verify project status
- `CoreStory:create_conversation` — start implementation thread
- `CoreStory:send_message` — query code intelligence
- `CoreStory:rename_conversation` — mark as completed

When instructions say "Query CoreStory", use `CoreStory:send_message`.

## Phase 1: Ticket Intake
1. Extract feature details (from ticket MCP or user description)
2. Identify acceptance criteria — ask if missing
3. Select CoreStory project (`CoreStory:list_projects`, verify "completed")
4. Create conversation: "Ticket Implementation: #[ID] - [description]"

## Phase 2: Oracle Phase — Before Code
Query CoreStory for: architecture, design patterns, conventions, invariants.

## Phase 3: Navigator Phase
Query CoreStory for: extension points, data structures, reference implementations.

## Phase 4: TDD Implementation
Write failing tests → verify fail → validate with CoreStory → implement → verify pass → validate implementation.

## Phase 5: Feature Completion
Edge case tests → full suite → performance/security tests if needed.

## Phase 6: Completion
Update ticket → structured commit ("Feat: ...") → rename conversation "COMPLETED" → report.

## Key Principles
- Oracle before Navigator
- Test-first always
- Validate with CoreStory before acting
- Follow existing codebase patterns
- Commit messages explain architectural decisions