feature-design-assistant
Verifiedby davila7 · Updated Apr 16, 2026
Turn ideas into fully formed designs and specs through natural collaborative dialogue. Use when planning new features, designing architecture, or making significant changes to the codebase.
See It In Action
Let me explore the codebase first.
Got it. Here's what I see:
The app: Node.js/Express API, PostgreSQL via Sequelize, JWT auth with RBAC (admin/owner roles), multi-tenant.
Audit log model (src/models/audit-log.js): id, tenant_id, actor_id, action, resource, resource_id, metadata (JSONB), ip_address, created_at. Four composite indexes already in place.
Existing endpoint: GET /api/v1/admin/audit-logs — returns paginated JSON with filters for action, actor_id, resource, start_date, end_date. Capped at 100 rows per page.
No export functionality exists yet. No streaming, no CSV serialization, no download routes.
A few questions before I plan this out:
Take your time — once you answer those I'll have what I need to put together a solid plan.
Let me read the key files directly before writing the plan.
Good. Here's the full vetted plan.
Implementation Plan: Audit Log CSV Export
Overview
One new route, one file changed (src/routes/admin.js), no new dependencies, no migrations.
Endpoint: GET /api/v1/admin/audit-logs/export
Auth is inherited automatically — server.js:30 already applies authenticate + requireRole('admin', 'owner') to every route under /api/v1/admin.
Critical: Route Ordering
Express matches routes top-down. GET /audit-logs/:id already exists at admin.js:54. The new export route must be registered before it — otherwise Express will match export as a UUID and return 404.
GET /audit-logs ← existing list
GET /audit-logs/export ← NEW — must come before /:id
GET /audit-logs/:id ← existing single-entry
Step 1 — Extract shared filter logic (avoids duplication)
Extract the where-building code that the list route already uses into a module-level helper at the top of admin.js:
function buildAuditLogWhere(tenantId, { action, actor_id, resource, start_date, end_date }) {
const where = { tenant_id: tenantId };
if (action) where.action = action;
if (actor_id) where.actor_id = actor_id;
if (resource) where.resource = resource;
if (start_date || end_date) {
where.created_at = {};
if (start_date) where.created_at[Op.gte] = new Date(start_date);
if (end_date) where.created_at[Op.lte] = new Date(end_date);
}
return where;
}
Update the existing list route to call buildAuditLogWhere(tenantId, req.query) instead of its inline block.
Step 2 — Add a minimal CSV serializer (no new dependency)
Small inline helper, RFC 4180 compliant:
const CSV_COLUMNS = ['id', 'created_at', 'actor_id', 'action', 'resource', 'resource_id', 'ip_address', 'metadata'];
function csvEscape(val) {
if (val == null) return '';
const str = typeof val === 'object' ? JSON.stringify(val) : String(val);
// Wrap in quotes if value contains comma, quote, or newline
if (str.includes(',') || str.includes('"') || str.includes('\n')) {
return '"' + str.replace(/"/g, '""') + '"';
}
return str;
}
function rowsToCsv(rows) {
const header = CSV_COLUMNS.join(',');
const lines = rows.map(row =>
CSV_COLUMNS.map(col => csvEscape(row[col])).join(',')
);
return [header, ...lines].join('\r\n');
}
Note: tenant_id is intentionally excluded from the CSV — it's the same for every row and provides no value to the consumer.
Step 3 — Add the export route
// --------------- Audit Log: export CSV ---------------
const EXPORT_ROW_LIMIT = 50_000;
router.get('/audit-logs/export', async (req, res, next) => {
try {
const where = buildAuditLogWhere(req.tenantId, req.query);
const rows = await AuditLog.findAll({
where,
order: [['created_at', 'DESC']],
limit: EXPORT_ROW_LIMIT,
});
const csv = rowsToCsv(rows.map(r => r.dataValues));
const filename = `audit-logs-${req.tenantId}-${Date.now()}.csv`;
res.setHeader('Content-Type', 'text/csv');
res.setHeader('Content-Disposition', `attachment; filename="${filename}"`);
res.send(csv);
} catch (err) {
next(err);
}
});
The 50K row hard cap protects the DB and keeps memory bounded. At ~200 bytes/row that's ~10MB in the worst case — well within acceptable.
Step 4 — Update the list route
Replace the inline where-building block in the existing list route with a call to the new helper. No behavior change, just deduplication.
What changes, exactly
| File | Change |
|---|---|
src/routes/admin.js | Add buildAuditLogWhere helper, csvEscape/rowsToCsv helpers, GET /audit-logs/export route. Refactor list route to use shared helper. |
No other files touched. No new packages. No DB migration. No schema change.
Things to verify before shipping
- Route order — confirm
exportis registered before/:idin the file -
dataValues— Sequelize model instances expose raw values via.dataValues; confirm this renders the JSONBmetadatafield as a plain object (it does, per Sequelize docs) - Date format —
created_atwill serialize as ISO 8601 via.toString()on a JS Date — confirm that's acceptable to the prospect, or format it explicitly - 50K cap — decide whether to silently cap or add a
Warningresponse header when the cap is hit (recommend the header for enterprise transparency) - Rate limit — the existing 120 req/min limiter applies. An export of 50K rows is expensive; consider a separate lower limit on this route if abuse is a concern in v2
Test cases to write
- Returns
Content-Type: text/csvandContent-Disposition: attachment - CSV header row matches
CSV_COLUMNS - Filters (
action,actor_id,resource,start_date,end_date) correctly scope results metadataJSONB is JSON-stringified and CSV-escaped (especially if it contains commas)- Empty result → CSV with header row only, 200 response
- Unauthenticated request → 401
- Non-admin role → 403
- Cross-tenant isolation — tenant A cannot see tenant B's rows
Ready to implement on your say-so. The entire change is self-contained in src/routes/admin.js — fast to review, easy to revert if needed.
Permissions
| Scope | Description |
|---|---|
| filesystem:read |
SKILL.md
Feature Design Assistant
Help turn ideas into fully formed designs and specs through structured information gathering and collaborative validation.
Announce at start: "I'm using the feature-design-assistant skill to design this feature."
Phase 1: Context Discovery
First, explore the codebase to understand:
- Project structure and tech stack
- Existing patterns and conventions
- Related features or modules
- Recent changes in relevant areas
Phase 2: Structured Information Gathering
Use AskUserQuestion to batch collect information efficiently. Each call can ask up to 4 questions.
Round 1: Core Requirements (4 questions)
{
"questions": [
{
"question": "What is the primary goal of this feature?",
"header": "Goal",
"multiSelect": false,
"options": [
{ "label": "New Functionality", "description": "Add entirely new capability to the system" },
{ "label": "Enhancement", "description": "Improve or extend existing feature" },
{ "label": "Bug Fix", "description": "Fix incorrect behavior or issue" },
{ "label": "Refactoring", "description": "Improve code quality without changing behavior" }
]
},
{
"question": "Who are the primary users of this feature?",
"header": "Users",
"multiSelect": true,
"options": [
{ "label": "End Users", "description": "External customers using the product" },
{ "label": "Admins", "description": "Internal administrators or operators" },
{ "label": "Developers", "description": "Other developers using APIs or SDKs" },
{ "label": "System", "description": "Automated processes or background jobs" }
]
},
{
"question": "What is the expected scope of this feature?",
"header": "Scope",
"multiSelect": false,
"options": [
{ "label": "Small (1-2 days)", "description": "Single component, limited changes" },
{ "label": "Medium (3-5 days)", "description": "Multiple components, moderate complexity" },
{ "label": "Large (1-2 weeks)", "description": "Cross-cutting concerns, significant changes" },
{ "label": "Unsure", "description": "Need to explore further to estimate" }
]
},
{
"question": "Are there any hard deadlines or constraints?",
"header": "Timeline",
"multiSelect": false,
"options": [
{ "label": "Urgent", "description": "Need this ASAP, within days" },
{ "label": "This Sprint", "description": "Should be done within current sprint" },
{ "label": "Flexible", "description": "No hard deadline, quality over speed" },
{ "label": "Planning Only", "description": "Just designing now, implementing later" }
]
}
]
}
Round 2: Technical Requirements (4 questions)
{
"questions": [
{
"question": "Which layers of the system will this feature touch?",
"header": "Layers",
"multiSelect": true,
"options": [
{ "label": "Data Model", "description": "Database schema, models, migrations" },
{ "label": "Business Logic", "description": "Services, domain logic, rules" },
{ "label": "API", "description": "REST/GraphQL endpoints, contracts" },
{ "label": "UI", "description": "Frontend components, user interface" }
]
},
{
"question": "What are the key quality requirements?",
"header": "Quality",
"multiSelect": true,
"options": [
{ "label": "High Performance", "description": "Must handle high load or be very fast" },
{ "label": "Strong Security", "description": "Sensitive data, auth, access control" },
{ "label": "High Reliability", "description": "Cannot fail, needs redundancy" },
{ "label": "Easy Maintenance", "description": "Needs to be easily understood and modified" }
]
},
{
"question": "How should errors be handled?",
"header": "Errors",
"multiSelect": false,
"options": [
{ "label": "Fail Fast", "description": "Stop immediately on any error" },
{ "label": "Graceful Degrade", "description": "Continue with reduced functionality" },
{ "label": "Retry & Recover", "description": "Automatic retry with recovery logic" },
{ "label": "Context Dependent", "description": "Different strategies for different cases" }
]
},
{
"question": "What testing approach is preferred?",
"header": "Testing",
"multiSelect": false,
"options": [
{ "label": "TDD (Recommended)", "description": "Write tests first, then implementation" },
{ "label": "Test After", "description": "Implement first, add tests after" },
{ "label": "Minimal Tests", "description": "Only critical path testing" },
{ "label": "No Tests", "description": "Skip testing for this feature" }
]
}
]
}
Round 3: Integration & Dependencies (4 questions)
{
"questions": [
{
"question": "Does this feature need external integrations?",
"header": "Integrations",
"multiSelect": true,
"options": [
{ "label": "Database", "description": "New tables, queries, or migrations" },
{ "label": "External APIs", "description": "Third-party service calls" },
{ "label": "Message Queue", "description": "Async processing, events" },
{ "label": "None", "description": "No external integrations needed" }
]
},
{
"question": "Are there dependencies on other features or teams?",
"header": "Dependencies",
"multiSelect": true,
"options": [
{ "label": "Auth System", "description": "User authentication or authorization" },
{ "label": "Other Features", "description": "Depends on features being developed" },
{ "label": "External Team", "description": "Needs input from another team" },
{ "label": "None", "description": "Fully independent feature" }
]
},
{
"question": "How should we handle backwards compatibility?",
"header": "Compat",
"multiSelect": false,
"options": [
{ "label": "Must Maintain", "description": "Cannot break existing clients" },
{ "label": "Version API", "description": "Create new version, deprecate old" },
{ "label": "Breaking OK", "description": "Can make breaking changes" },
{ "label": "Not Applicable", "description": "New feature, no existing users" }
]
},
{
"question": "What documentation is needed?",
"header": "Docs",
"multiSelect": true,
"options": [
{ "label": "API Docs", "description": "Endpoint documentation" },
{ "label": "User Guide", "description": "How-to for end users" },
{ "label": "Dev Guide", "description": "Technical implementation details" },
{ "label": "None", "description": "No documentation needed" }
]
}
]
}
Round 4: Clarifying Questions (Context-Dependent)
Based on previous answers, ask follow-up questions. Examples:
If UI layer selected:
{
"questions": [
{
"question": "What UI framework/approach should we use?",
"header": "UI Tech",
"multiSelect": false,
"options": [
{ "label": "React", "description": "React components with hooks" },
{ "label": "Vue", "description": "Vue.js components" },
{ "label": "Server-Side", "description": "Server-rendered HTML templates" },
{ "label": "Existing Pattern", "description": "Follow current project conventions" }
]
}
]
}
If High Security selected:
{
"questions": [
{
"question": "What security measures are required?",
"header": "Security",
"multiSelect": true,
"options": [
{ "label": "Input Validation", "description": "Strict input sanitization" },
{ "label": "Rate Limiting", "description": "Prevent abuse and DoS" },
{ "label": "Audit Logging", "description": "Track all sensitive actions" },
{ "label": "Encryption", "description": "Encrypt data at rest/transit" }
]
}
]
}
Phase 3: Approach Exploration
After gathering requirements, propose 2-3 approaches:
## Approach Options
### Option A: [Name] (Recommended)
**Pros:** ...
**Cons:** ...
**Best for:** ...
### Option B: [Name]
**Pros:** ...
**Cons:** ...
**Best for:** ...
### Option C: [Name]
**Pros:** ...
**Cons:** ...
**Best for:** ...
Use AskUserQuestion to confirm approach:
{
"questions": [
{
"question": "Which approach would you like to proceed with?",
"header": "Approach",
"multiSelect": false,
"options": [
{ "label": "Option A (Recommended)", "description": "Brief summary of approach A" },
{ "label": "Option B", "description": "Brief summary of approach B" },
{ "label": "Option C", "description": "Brief summary of approach C" }
]
}
]
}
Phase 4: Design Presentation
Present design in sections (300-500 words each), validate after each:
- Architecture Overview - High-level structure
- Data Model - Entities, relationships, schema
- API Design - Endpoints, request/response
- Component Design - Internal modules, interfaces
- Error Handling - Error cases, recovery strategies
- Testing Strategy - What and how to test
After each section, use AskUserQuestion:
{
"questions": [
{
"question": "Does this section look correct?",
"header": "Review",
"multiSelect": false,
"options": [
{ "label": "Looks Good", "description": "Continue to next section" },
{ "label": "Minor Changes", "description": "Small adjustments needed" },
{ "label": "Major Revision", "description": "Significant changes required" },
{ "label": "Questions", "description": "Need clarification before proceeding" }
]
}
]
}
Phase 5: Documentation & Tasks
Save Design Document
Write to docs/designs/YYYY-MM-DD-<topic>-design.md:
# Feature: [Name]
## Summary
[Brief description]
## Requirements
[From Phase 2 answers]
## Architecture
[From Phase 4]
## Implementation Tasks
[Task checklist]
Generate Implementation Tasks
## Implementation Tasks
- [ ] **Task Title** `priority:1` `phase:model` `time:15min`
- files: src/file1.py, tests/test_file1.py
- [ ] Write failing test for X
- [ ] Run test, verify it fails
- [ ] Implement minimal code
- [ ] Run test, verify it passes
- [ ] Commit
- [ ] **Another Task** `priority:2` `phase:api` `deps:Task Title` `time:10min`
- files: src/api.py
- [ ] Write failing test
- [ ] Implement and verify
- [ ] Commit
Phase 6: Execution Handoff
{
"questions": [
{
"question": "How would you like to proceed with implementation?",
"header": "Next Step",
"multiSelect": false,
"options": [
{ "label": "Execute Now", "description": "Run /feature-pipeline in this session" },
{ "label": "New Session", "description": "Start fresh session for implementation" },
{ "label": "Later", "description": "Save design, implement manually later" },
{ "label": "Revise Design", "description": "Go back and modify the design" }
]
}
]
}
Key Principles
- Batch questions efficiently - Use all 4 question slots when appropriate
- Use multiSelect for non-exclusive options - Layers, features, requirements
- Use single-select for decisions - Approach, timeline, strategy
- Mark recommendations - Add "(Recommended)" to preferred options
- Progressive refinement - General → Specific questions
- Validate incrementally - Check understanding at each phase
- YAGNI ruthlessly - Remove unnecessary features from designs
FAQ
What does feature-design-assistant do?
Turn ideas into fully formed designs and specs through natural collaborative dialogue. Use when planning new features, designing architecture, or making significant changes to the codebase.
When should I use feature-design-assistant?
Use it when you need a repeatable workflow that produces text response.
What does feature-design-assistant output?
In the evaluated run it produced text response.
How do I install or invoke feature-design-assistant?
npx skills add https://github.com/davila7/claude-code-templates --skill feature-design-assistant
Which agents does feature-design-assistant support?
Claude Code
What tools, channels, or permissions does feature-design-assistant need?
It uses no extra tools; channels commonly include text; permissions include filesystem:read.
Is feature-design-assistant safe to install?
Static analysis marked this skill as low risk; review side effects and permissions before enabling it.
How is feature-design-assistant different from an MCP or plugin?
A skill packages instructions and workflow conventions; tools, MCP servers, and plugins are dependencies the skill may call during execution.
Does feature-design-assistant outperform not using a skill?
About feature-design-assistant
When to use feature-design-assistant
When planning a new feature before implementation. When designing architecture for a significant codebase change. When you need a structured requirements and design discussion grounded in the existing project.
When feature-design-assistant is not the right choice
When you only need code implementation rather than planning and design. When there is no codebase or project context to analyze.
What it produces
Produces text response.
Install
npx skills add https://github.com/davila7/claude-code-templates --skill feature-design-assistantInvoke: Ask Claude Code to use feature-design-assistant for the task.