cntx-ui 3.0.4 → 3.0.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/cntx-ui.js +16 -49
- package/lib/agent-runtime.js +70 -0
- package/lib/api-router.js +1 -136
- package/lib/bundle-manager.js +118 -28
- package/lib/mcp-server.js +0 -146
- package/package.json +1 -1
- package/server.js +85 -373
- package/templates/TOOLS.md +0 -6
- package/templates/agent-config.yaml +0 -5
- package/templates/agent-instructions.md +2 -15
- package/templates/agent-rules/project-specific/architecture.md +0 -1
- package/templates/hidden-files.json +0 -1
- package/web/dist/assets/index-D2RTcdqV.js +1968 -0
- package/web/dist/assets/index-DJi03HLz.css +1 -0
- package/web/dist/index.html +2 -2
- package/templates/activities/README.md +0 -67
- package/templates/activities/activities/create-project-bundles/README.md +0 -84
- package/templates/activities/activities/create-project-bundles/notes.md +0 -98
- package/templates/activities/activities/create-project-bundles/progress.md +0 -63
- package/templates/activities/activities/create-project-bundles/tasks.md +0 -39
- package/templates/activities/activities.json +0 -219
- package/templates/activities/lib/.markdownlint.jsonc +0 -18
- package/templates/activities/lib/create-activity.mdc +0 -63
- package/templates/activities/lib/generate-tasks.mdc +0 -64
- package/templates/activities/lib/process-task-list.mdc +0 -52
- package/templates/agent-rules/capabilities/activities-system.md +0 -147
- package/web/dist/assets/index-4p3KJ0jf.js +0 -2016
- package/web/dist/assets/index-BPIipM25.css +0 -1
|
@@ -1,219 +0,0 @@
|
|
|
1
|
-
[
|
|
2
|
-
{
|
|
3
|
-
"title": "Create Project Bundles with Agent Assistance",
|
|
4
|
-
"description": "Set up organized bundles for a new codebase using agent assistance to analyze project structure and suggest appropriate file groupings.",
|
|
5
|
-
"desired_outcome": "Complete bundle coverage with logical groupings, clear documentation, and automated suggestions for new files. Improved context efficiency for LLM consumption.",
|
|
6
|
-
"references": [
|
|
7
|
-
".cntx/activities/activities/create-project-bundles/README.md",
|
|
8
|
-
".cntx/activities/activities/create-project-bundles/tasks.md",
|
|
9
|
-
".cntx/activities/activities/create-project-bundles/progress.md"
|
|
10
|
-
],
|
|
11
|
-
"status": "todo",
|
|
12
|
-
"tags": ["bundles", "agent-collaboration", "setup"],
|
|
13
|
-
"tasks": [
|
|
14
|
-
{
|
|
15
|
-
"title": "Project Analysis and Discovery",
|
|
16
|
-
"description": "Analyze project directory structure and identify main folders, file types, and architectural patterns.",
|
|
17
|
-
"status": "todo"
|
|
18
|
-
},
|
|
19
|
-
{
|
|
20
|
-
"title": "Bundle Strategy Design",
|
|
21
|
-
"description": "Propose initial bundle structure based on project analysis and define naming conventions.",
|
|
22
|
-
"status": "todo"
|
|
23
|
-
},
|
|
24
|
-
{
|
|
25
|
-
"title": "Bundle Configuration Implementation",
|
|
26
|
-
"description": "Create bundle definitions in .cntx/bundle-states.json and set up automatic file categorization rules.",
|
|
27
|
-
"status": "todo"
|
|
28
|
-
},
|
|
29
|
-
{
|
|
30
|
-
"title": "Documentation and Refinement",
|
|
31
|
-
"description": "Document bundle purposes, create usage guidelines, and refine structure based on testing.",
|
|
32
|
-
"status": "todo"
|
|
33
|
-
}
|
|
34
|
-
]
|
|
35
|
-
},
|
|
36
|
-
{
|
|
37
|
-
"title": "API Audit, Refinement, and Documentation",
|
|
38
|
-
"description": "Review all existing API endpoints, refine their design for consistency and efficiency, and generate comprehensive documentation.",
|
|
39
|
-
"desired_outcome": "All API endpoints are consistent, efficient, and well-documented. API documentation is up-to-date and easily accessible.",
|
|
40
|
-
"references": [
|
|
41
|
-
".cntx/activities/activities/api-audit/README.md",
|
|
42
|
-
".cntx/activities/activities/api-audit/tasks.md",
|
|
43
|
-
".cntx/activities/activities/api-audit/progress.md"
|
|
44
|
-
],
|
|
45
|
-
"status": "todo",
|
|
46
|
-
"tags": ["general", "api"],
|
|
47
|
-
"tasks": [
|
|
48
|
-
{
|
|
49
|
-
"title": "Example",
|
|
50
|
-
"description": "lorem ipsum dolor sit amet, consectetur adipiscing elit.",
|
|
51
|
-
"status": "todo"
|
|
52
|
-
}
|
|
53
|
-
]
|
|
54
|
-
},
|
|
55
|
-
{
|
|
56
|
-
"title": "Agent Stories: Research and Optimization",
|
|
57
|
-
"description": "Create a comprehensive research activity to systematically test and discover optimal patterns for agent interactions with cntx-ui through the .cntx directory and MCP server.",
|
|
58
|
-
"desired_outcome": "Comprehensive coverage of agent interaction scenarios, documented best practices, and an actionable plan for continuous agent testing through the 'Agent Stories Cycle'.",
|
|
59
|
-
"references": [
|
|
60
|
-
".cntx/activities/activities/agent-stories/README.md",
|
|
61
|
-
".cntx/activities/activities/agent-stories/tasks.md",
|
|
62
|
-
".cntx/activities/activities/agent-stories/progress.md"
|
|
63
|
-
],
|
|
64
|
-
"status": "todo",
|
|
65
|
-
"tags": ["general", "agent"],
|
|
66
|
-
"tasks": [
|
|
67
|
-
{
|
|
68
|
-
"title": "Current State Analysis",
|
|
69
|
-
"description": "Analyze existing agent instructions, MCP server tools, and interaction patterns.",
|
|
70
|
-
"status": "todo"
|
|
71
|
-
}
|
|
72
|
-
]
|
|
73
|
-
},
|
|
74
|
-
{
|
|
75
|
-
"title": "Heuristics Configuration Refactor",
|
|
76
|
-
"description": "Transform hardcoded heuristics into a configurable, agent-manageable system. Extract all code categorization logic into centralized configuration with agent activity framework integration.",
|
|
77
|
-
"desired_outcome": "All heuristics are externalized to configuration, agents can automatically refine categorization rules, and the system maintains complete backward compatibility while enabling intelligent self-improvement.",
|
|
78
|
-
"references": [
|
|
79
|
-
".cntx/activities/activities/heuristics-refactor/README.md"
|
|
80
|
-
],
|
|
81
|
-
"status": "todo",
|
|
82
|
-
"tags": ["general", "refactor"],
|
|
83
|
-
"tasks": [
|
|
84
|
-
{
|
|
85
|
-
"title": "Extract Purpose Detection Heuristics",
|
|
86
|
-
"description": "Extract hardcoded purpose detection patterns from semantic-splitter.js to heuristics-config.json",
|
|
87
|
-
"status": "todo"
|
|
88
|
-
},
|
|
89
|
-
{
|
|
90
|
-
"title": "Extract Bundle Suggestion Logic",
|
|
91
|
-
"description": "Extract bundle suggestion heuristics from BundleList.tsx to centralized config",
|
|
92
|
-
"status": "todo"
|
|
93
|
-
},
|
|
94
|
-
{
|
|
95
|
-
"title": "Create HeuristicsManager Service",
|
|
96
|
-
"description": "Build centralized service for loading and applying heuristics with caching and validation",
|
|
97
|
-
"status": "todo"
|
|
98
|
-
},
|
|
99
|
-
{
|
|
100
|
-
"title": "Implement Heuristics API Endpoints",
|
|
101
|
-
"description": "Create REST API for reading, updating, and managing heuristics configuration",
|
|
102
|
-
"status": "todo"
|
|
103
|
-
},
|
|
104
|
-
{
|
|
105
|
-
"title": "Build Agent Activity Framework",
|
|
106
|
-
"description": "Implement activity scheduler and execution system for agent-driven heuristics refinement",
|
|
107
|
-
"status": "todo"
|
|
108
|
-
},
|
|
109
|
-
{
|
|
110
|
-
"title": "Verify Backward Compatibility",
|
|
111
|
-
"description": "Ensure all existing functionality works identically after refactor",
|
|
112
|
-
"status": "todo"
|
|
113
|
-
}
|
|
114
|
-
]
|
|
115
|
-
},
|
|
116
|
-
{
|
|
117
|
-
"title": "VS Code Extension",
|
|
118
|
-
"description": "Adapt the existing cntx-ui tool into a VS Code extension, providing an integrated experience within the editor.",
|
|
119
|
-
"desired_outcome": "A functional VS Code extension that embeds the cntx-ui, allowing users to manage their projects without leaving the editor. The extension will share a codebase with the standalone web application.",
|
|
120
|
-
"references": [
|
|
121
|
-
".cntx/activities/activities/vscode-extension/README.md",
|
|
122
|
-
".cntx/activities/activities/vscode-extension/tasks.md",
|
|
123
|
-
".cntx/activities/activities/vscode-extension/progress.md"
|
|
124
|
-
],
|
|
125
|
-
"status": "todo",
|
|
126
|
-
"tags": ["vscode", "feature"],
|
|
127
|
-
"tasks": [
|
|
128
|
-
{
|
|
129
|
-
"title": "Project Scaffolding",
|
|
130
|
-
"description": "Set up the basic file structure for a VS Code extension, including package.json, extension.ts, and a webpack.config.js.",
|
|
131
|
-
"status": "todo"
|
|
132
|
-
},
|
|
133
|
-
{
|
|
134
|
-
"title": "Implement Webview Panel",
|
|
135
|
-
"description": "Create the command and logic to open a WebviewPanel that loads the existing web/dist/index.html.",
|
|
136
|
-
"status": "todo"
|
|
137
|
-
},
|
|
138
|
-
{
|
|
139
|
-
"title": "Create Communication Bridge",
|
|
140
|
-
"description": "Develop an abstraction layer that handles messaging between the webview and the extension host, supporting both postMessage and WebSockets.",
|
|
141
|
-
"status": "todo"
|
|
142
|
-
},
|
|
143
|
-
{
|
|
144
|
-
"title": "Implement Activation Events",
|
|
145
|
-
"description": "Configure the extension to activate when a .cntx directory is found, when the Activity Bar icon is clicked, or when a command is run.",
|
|
146
|
-
"status": "todo"
|
|
147
|
-
},
|
|
148
|
-
{
|
|
149
|
-
"title": "Add Activity Bar Icon",
|
|
150
|
-
"description": "Create an icon for the extension and configure it to appear in the VS Code Activity Bar.",
|
|
151
|
-
"status": "todo"
|
|
152
|
-
},
|
|
153
|
-
{
|
|
154
|
-
"title": "Implement Command Palette Actions",
|
|
155
|
-
"description": "Add the cntx-ui: Start Server, cntx-ui: Stop Server, and cntx-ui: Open UI commands to the Command Palette.",
|
|
156
|
-
"status": "todo"
|
|
157
|
-
},
|
|
158
|
-
{
|
|
159
|
-
"title": "Build Initial Dashboard UI",
|
|
160
|
-
"description": "Create the simple dashboard view with controls for the server, a health status indicator, and a list of bundles.",
|
|
161
|
-
"status": "todo"
|
|
162
|
-
},
|
|
163
|
-
{
|
|
164
|
-
"title": "Backend Integration",
|
|
165
|
-
"description": "Connect the dashboard UI to the reused backend logic to control the server and fetch the bundle list.",
|
|
166
|
-
"status": "todo"
|
|
167
|
-
},
|
|
168
|
-
{
|
|
169
|
-
"title": "Documentation",
|
|
170
|
-
"description": "Update the project's README.md with instructions on how to build, run, and debug the new VS Code extension.",
|
|
171
|
-
"status": "todo"
|
|
172
|
-
},
|
|
173
|
-
{
|
|
174
|
-
"title": "Packaging and Testing",
|
|
175
|
-
"description": "Create a .vsix package for the extension and test its installation and functionality in a clean VS Code environment.",
|
|
176
|
-
"status": "todo"
|
|
177
|
-
}
|
|
178
|
-
]
|
|
179
|
-
},
|
|
180
|
-
{
|
|
181
|
-
"title": "cntx-ui Init Defaults",
|
|
182
|
-
"description": "Define and implement a comprehensive default template for the .cntx directory, established by `cntx-ui init`.",
|
|
183
|
-
"desired_outcome": "A single command initializes a fully functional .cntx directory with all necessary defaults, compatible with the UI.",
|
|
184
|
-
"references": [
|
|
185
|
-
".cntx/activities/activities/cntx-ui-init-defaults/README.md",
|
|
186
|
-
".cntx/activities/activities/cntx-ui-init-defaults/tasks.md",
|
|
187
|
-
".cntx/activities/activities/cntx-ui-init-defaults/progress.md"
|
|
188
|
-
],
|
|
189
|
-
"status": "todo",
|
|
190
|
-
"tags": ["init", "defaults", "scaffolding"],
|
|
191
|
-
"tasks": [
|
|
192
|
-
{
|
|
193
|
-
"title": "Define Default .cntx Structure & Content",
|
|
194
|
-
"description": "Create templates for config, hidden-files, semantic-cache, activities, and agent-rules.",
|
|
195
|
-
"status": "todo"
|
|
196
|
-
},
|
|
197
|
-
{
|
|
198
|
-
"title": "Extend Existing cntx-ui init Command",
|
|
199
|
-
"description": "Modify the `init` command to copy the default .cntx structure to the user's project.",
|
|
200
|
-
"status": "todo"
|
|
201
|
-
},
|
|
202
|
-
{
|
|
203
|
-
"title": "Integrate Minimal Default Activities & Agent Rules",
|
|
204
|
-
"description": "Ensure the sample activities and agent rules are correctly loaded and displayed.",
|
|
205
|
-
"status": "todo"
|
|
206
|
-
},
|
|
207
|
-
{
|
|
208
|
-
"title": "Testing & Validation",
|
|
209
|
-
"description": "Write tests for the `init` command and verify the created .cntx directory.",
|
|
210
|
-
"status": "todo"
|
|
211
|
-
},
|
|
212
|
-
{
|
|
213
|
-
"title": "Documentation & Release Preparation",
|
|
214
|
-
"description": "Update documentation and prepare for release of the new `init` functionality.",
|
|
215
|
-
"status": "todo"
|
|
216
|
-
}
|
|
217
|
-
]
|
|
218
|
-
}
|
|
219
|
-
]
|
|
@@ -1,18 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
// https://github.com/markdownlint/markdownlint/blob/main/docs/RULES.md
|
|
3
|
-
"default": true,
|
|
4
|
-
// Trailing spaces
|
|
5
|
-
"MD009": false,
|
|
6
|
-
// Line length (default: 80)
|
|
7
|
-
"MD013": false,
|
|
8
|
-
// Duplicate headings (e.g., nested headings)
|
|
9
|
-
"MD024": false,
|
|
10
|
-
// Ordered list item prefix
|
|
11
|
-
"MD029": {
|
|
12
|
-
"style": "ordered"
|
|
13
|
-
},
|
|
14
|
-
// Fenced code blocks should be surrounded by blank lines
|
|
15
|
-
"MD031": false,
|
|
16
|
-
// Emphasis as heading (e.g., table of contents)
|
|
17
|
-
"MD036": false
|
|
18
|
-
}
|
|
@@ -1,63 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description:
|
|
3
|
-
globs:
|
|
4
|
-
alwaysApply: false
|
|
5
|
-
---
|
|
6
|
-
# Rule: Generating an Activity Definition
|
|
7
|
-
|
|
8
|
-
## Goal
|
|
9
|
-
|
|
10
|
-
To guide an AI assistant in creating a detailed Activity Definition in Markdown format, based on an initial user prompt. The Activity should be clear, actionable, and suitable for a junior developer to understand and implement the feature or improvement for the cntx-ui project.
|
|
11
|
-
|
|
12
|
-
## Process
|
|
13
|
-
|
|
14
|
-
1. **Receive Initial Prompt:** The user provides a brief description or request for a new feature, improvement, or functionality for cntx-ui.
|
|
15
|
-
2. **Ask Clarifying Questions:** Before writing the Activity, the AI *must* ask clarifying questions to gather sufficient detail. The goal is to understand the "what" and "why" of the activity, not necessarily the "how" (which the developer will figure out). Make sure to provide options in letter/number lists so I can respond easily with my selections.
|
|
16
|
-
3. **Generate Activity:** Based on the initial prompt and the user's answers to the clarifying questions, generate an Activity using the structure outlined below.
|
|
17
|
-
4. **Save Activity:** Save the generated document as `activity-[feature-name].md` inside the `.cntx/activities/[activity-name]/` directory.
|
|
18
|
-
|
|
19
|
-
## Clarifying Questions (Examples)
|
|
20
|
-
|
|
21
|
-
The AI should adapt its questions based on the prompt, but here are some common areas to explore:
|
|
22
|
-
|
|
23
|
-
* **Problem/Goal:** "What problem does this activity solve for cntx-ui users?" or "What is the main goal we want to achieve with this activity?"
|
|
24
|
-
* **Target User:** "Who is the primary user of this feature? (e.g., developers using cntx-ui, AI assistants, end users of bundled applications)"
|
|
25
|
-
* **Core Functionality:** "Can you describe the key actions a user should be able to perform with this feature?"
|
|
26
|
-
* **User Stories:** "Could you provide a few user stories? (e.g., As a [type of user], I want to [perform an action] so that [benefit].)"
|
|
27
|
-
* **Acceptance Criteria:** "How will we know when this activity is successfully implemented? What are the key success criteria?"
|
|
28
|
-
* **Scope/Boundaries:** "Are there any specific things this activity *should not* do (non-goals)?"
|
|
29
|
-
* **Data Requirements:** "What kind of data does this feature need to display or manipulate? (e.g., bundle configurations, file metadata, semantic chunks)"
|
|
30
|
-
* **Design/UI:** "Are there any existing design patterns in cntx-ui to follow?" or "Can you describe the desired look and feel?"
|
|
31
|
-
* **Edge Cases:** "Are there any potential edge cases or error conditions we should consider?"
|
|
32
|
-
|
|
33
|
-
## Activity Structure
|
|
34
|
-
|
|
35
|
-
The generated Activity should include the following sections:
|
|
36
|
-
|
|
37
|
-
1. **Introduction/Overview:** Briefly describe the activity and the problem it solves for cntx-ui. State the goal.
|
|
38
|
-
2. **Goals:** List the specific, measurable objectives for this activity.
|
|
39
|
-
3. **User Stories:** Detail the user narratives describing activity usage and benefits.
|
|
40
|
-
4. **Functional Requirements:** List the specific functionalities the activity must have. Use clear, concise language (e.g., "The system must allow users to configure bundle rules."). Number these requirements.
|
|
41
|
-
5. **Non-Goals (Out of Scope):** Clearly state what this activity will *not* include to manage scope.
|
|
42
|
-
6. **Design Considerations (Optional):** Link to existing UI components, describe UI/UX requirements, or mention relevant cntx-ui components/styles if applicable.
|
|
43
|
-
7. **Technical Considerations (Optional):** Mention any known technical constraints, dependencies, or suggestions (e.g., "Should integrate with the existing bundle management system").
|
|
44
|
-
8. **Success Metrics:** How will the success of this activity be measured? (e.g., "Improve bundle generation speed by 20%", "Reduce configuration errors by 50%").
|
|
45
|
-
9. **Open Questions:** List any remaining questions or areas needing further clarification.
|
|
46
|
-
|
|
47
|
-
## Target Audience
|
|
48
|
-
|
|
49
|
-
Assume the primary reader of the Activity is a **junior developer** working on cntx-ui. Therefore, requirements should be explicit, unambiguous, and avoid jargon where possible. Provide enough detail for them to understand the activity's purpose and core logic.
|
|
50
|
-
|
|
51
|
-
## Output
|
|
52
|
-
|
|
53
|
-
* **Format:** Markdown (`.md`)
|
|
54
|
-
* **Location:** `.cntx/activities/activities/[activity-name]/`
|
|
55
|
-
* **Filename:** `README.md`
|
|
56
|
-
|
|
57
|
-
## Final instructions
|
|
58
|
-
|
|
59
|
-
1. Do NOT start implementing the Activity
|
|
60
|
-
2. Make sure to ask the user clarifying questions
|
|
61
|
-
3. Take the user's answers to the clarifying questions and improve the Activity
|
|
62
|
-
4. Consider how this activity fits into the broader cntx-ui ecosystem of file bundling and AI development tools
|
|
63
|
-
5. **REQUIRED**: After creating the activity README.md, update `.cntx/activities/activities.json` to register the new activity with proper title, description, desired_outcome, references, status, and tasks
|
|
@@ -1,64 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description:
|
|
3
|
-
globs:
|
|
4
|
-
alwaysApply: false
|
|
5
|
-
---
|
|
6
|
-
# Rule: Generating a Task List from a PRD
|
|
7
|
-
|
|
8
|
-
## Goal
|
|
9
|
-
|
|
10
|
-
To guide an AI assistant in creating a detailed, step-by-step task list in Markdown format based on an existing Product Requirements Document (PRD). The task list should guide a developer through implementation.
|
|
11
|
-
|
|
12
|
-
## Output
|
|
13
|
-
|
|
14
|
-
- **Format:** Markdown (`.md`)
|
|
15
|
-
- **Location:** `/tasks/`
|
|
16
|
-
- **Filename:** `tasks-[prd-file-name].md` (e.g., `tasks-prd-user-profile-editing.md`)
|
|
17
|
-
|
|
18
|
-
## Process
|
|
19
|
-
|
|
20
|
-
1. **Receive PRD Reference:** The user points the AI to a specific PRD file
|
|
21
|
-
2. **Analyze PRD:** The AI reads and analyzes the functional requirements, user stories, and other sections of the specified PRD.
|
|
22
|
-
3. **Phase 1: Generate Parent Tasks:** Based on the PRD analysis, create the file and generate the main, high-level tasks required to implement the feature. Use your judgement on how many high-level tasks to use. It's likely to be about 5. Present these tasks to the user in the specified format (without sub-tasks yet). Inform the user: "I have generated the high-level tasks based on the PRD. Ready to generate the sub-tasks? Respond with 'Go' to proceed."
|
|
23
|
-
4. **Wait for Confirmation:** Pause and wait for the user to respond with "Go".
|
|
24
|
-
5. **Phase 2: Generate Sub-Tasks:** Once the user confirms, break down each parent task into smaller, actionable sub-tasks necessary to complete the parent task. Ensure sub-tasks logically follow from the parent task and cover the implementation details implied by the PRD.
|
|
25
|
-
6. **Identify Relevant Files:** Based on the tasks and PRD, identify potential files that will need to be created or modified. List these under the `Relevant Files` section, including corresponding test files if applicable.
|
|
26
|
-
7. **Generate Final Output:** Combine the parent tasks, sub-tasks, relevant files, and notes into the final Markdown structure.
|
|
27
|
-
8. **Save Task List:** Save the generated document in the `/tasks/` directory with the filename `tasks-[prd-file-name].md`, where `[prd-file-name]` matches the base name of the input PRD file (e.g., if the input was `prd-user-profile-editing.md`, the output is `tasks-prd-user-profile-editing.md`).
|
|
28
|
-
|
|
29
|
-
## Output Format
|
|
30
|
-
|
|
31
|
-
The generated task list _must_ follow this structure:
|
|
32
|
-
|
|
33
|
-
```markdown
|
|
34
|
-
## Relevant Files
|
|
35
|
-
|
|
36
|
-
- `path/to/potential/file1.ts` - Brief description of why this file is relevant (e.g., Contains the main component for this feature).
|
|
37
|
-
- `path/to/file1.test.ts` - Unit tests for `file1.ts`.
|
|
38
|
-
- `path/to/another/file.tsx` - Brief description (e.g., API route handler for data submission).
|
|
39
|
-
- `path/to/another/file.test.tsx` - Unit tests for `another/file.tsx`.
|
|
40
|
-
- `lib/utils/helpers.ts` - Brief description (e.g., Utility functions needed for calculations).
|
|
41
|
-
- `lib/utils/helpers.test.ts` - Unit tests for `helpers.ts`.
|
|
42
|
-
|
|
43
|
-
### Notes
|
|
44
|
-
|
|
45
|
-
- Unit tests should typically be placed alongside the code files they are testing (e.g., `MyComponent.tsx` and `MyComponent.test.tsx` in the same directory).
|
|
46
|
-
- Use `npx jest [optional/path/to/test/file]` to run tests. Running without a path executes all tests found by the Jest configuration.
|
|
47
|
-
|
|
48
|
-
## Tasks
|
|
49
|
-
|
|
50
|
-
- [ ] 1.0 Parent Task Title
|
|
51
|
-
- [ ] 1.1 [Sub-task description 1.1]
|
|
52
|
-
- [ ] 1.2 [Sub-task description 1.2]
|
|
53
|
-
- [ ] 2.0 Parent Task Title
|
|
54
|
-
- [ ] 2.1 [Sub-task description 2.1]
|
|
55
|
-
- [ ] 3.0 Parent Task Title (may not require sub-tasks if purely structural or configuration)
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
## Interaction Model
|
|
59
|
-
|
|
60
|
-
The process explicitly requires a pause after generating parent tasks to get user confirmation ("Go") before proceeding to generate the detailed sub-tasks. This ensures the high-level plan aligns with user expectations before diving into details.
|
|
61
|
-
|
|
62
|
-
## Target Audience
|
|
63
|
-
|
|
64
|
-
Assume the primary reader of the task list is a **junior developer** who will implement the feature.
|
|
@@ -1,52 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description:
|
|
3
|
-
globs:
|
|
4
|
-
alwaysApply: false
|
|
5
|
-
---
|
|
6
|
-
# Task List Management
|
|
7
|
-
|
|
8
|
-
Guidelines for managing task lists in markdown files to track progress on completing a PRD
|
|
9
|
-
|
|
10
|
-
## Task Implementation
|
|
11
|
-
- **One sub-task at a time:** Do **NOT** start the next sub‑task until you ask the user for permission and they say "yes" or "y"
|
|
12
|
-
- **Completion protocol:**
|
|
13
|
-
1. When you finish a **sub‑task**, immediately mark it as completed by changing `[ ]` to `[x]`.
|
|
14
|
-
2. If **all** subtasks underneath a parent task are now `[x]`, follow this sequence:
|
|
15
|
-
- **First**: Run the full test suite (`pytest`, `npm test`, `bin/rails test`, etc.)
|
|
16
|
-
- **Only if all tests pass**: Stage changes (`git add .`)
|
|
17
|
-
- **Clean up**: Remove any temporary files and temporary code before committing
|
|
18
|
-
- **Commit**: Use a descriptive commit message that:
|
|
19
|
-
- Uses conventional commit format (`feat:`, `fix:`, `refactor:`, etc.)
|
|
20
|
-
- Summarizes what was accomplished in the parent task
|
|
21
|
-
- Lists key changes and additions
|
|
22
|
-
- References the task number and PRD context
|
|
23
|
-
- **Formats the message as a single-line command using `-m` flags**, e.g.:
|
|
24
|
-
|
|
25
|
-
```
|
|
26
|
-
git commit -m "feat: add payment validation logic" -m "- Validates card type and expiry" -m "- Adds unit tests for edge cases" -m "Related to T123 in PRD"
|
|
27
|
-
```
|
|
28
|
-
3. Once all the subtasks are marked completed and changes have been committed, mark the **parent task** as completed.
|
|
29
|
-
- Stop after each sub‑task and wait for the user's go‑ahead.
|
|
30
|
-
|
|
31
|
-
## Task List Maintenance
|
|
32
|
-
|
|
33
|
-
1. **Update the task list as you work:**
|
|
34
|
-
- Mark tasks and subtasks as completed (`[x]`) per the protocol above.
|
|
35
|
-
- Add new tasks as they emerge.
|
|
36
|
-
|
|
37
|
-
2. **Maintain the "Relevant Files" section:**
|
|
38
|
-
- List every file created or modified.
|
|
39
|
-
- Give each file a one‑line description of its purpose.
|
|
40
|
-
|
|
41
|
-
## AI Instructions
|
|
42
|
-
|
|
43
|
-
When working with task lists, the AI must:
|
|
44
|
-
|
|
45
|
-
1. Regularly update the task list file after finishing any significant work.
|
|
46
|
-
2. Follow the completion protocol:
|
|
47
|
-
- Mark each finished **sub‑task** `[x]`.
|
|
48
|
-
- Mark the **parent task** `[x]` once **all** its subtasks are `[x]`.
|
|
49
|
-
3. Add newly discovered tasks.
|
|
50
|
-
4. Keep "Relevant Files" accurate and up to date.
|
|
51
|
-
5. Before starting work, check which sub‑task is next.
|
|
52
|
-
6. After implementing a sub‑task, update the file and then pause for user approval.
|
|
@@ -1,147 +0,0 @@
|
|
|
1
|
-
# Activities System Capabilities
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
The activities system provides structured task management for agents, tracking progress on complex development activities through defined workflows and documentation.
|
|
5
|
-
|
|
6
|
-
## When Available
|
|
7
|
-
- Check for activities endpoint: `GET /api/activities`
|
|
8
|
-
- Look for activities directory: `.cntx/activities/activities/`
|
|
9
|
-
- Verify activity definitions and progress tracking
|
|
10
|
-
|
|
11
|
-
## Core Capabilities
|
|
12
|
-
|
|
13
|
-
### Activity Discovery
|
|
14
|
-
**Endpoint**: `GET /api/activities`
|
|
15
|
-
|
|
16
|
-
**Provides**:
|
|
17
|
-
- List of all available activities
|
|
18
|
-
- Activity status and progress percentages
|
|
19
|
-
- Activity metadata (name, description, category)
|
|
20
|
-
- Complete file contents (README, progress, tasks, notes)
|
|
21
|
-
|
|
22
|
-
### Activity Execution (Future)
|
|
23
|
-
**Endpoints**:
|
|
24
|
-
- `POST /api/activities/{id}/execute` (planned)
|
|
25
|
-
- `POST /api/activities/{id}/stop` (planned)
|
|
26
|
-
|
|
27
|
-
**Will provide**:
|
|
28
|
-
- Programmatic activity execution
|
|
29
|
-
- Progress monitoring and updates
|
|
30
|
-
- Result collection and reporting
|
|
31
|
-
|
|
32
|
-
## Activity Structure
|
|
33
|
-
|
|
34
|
-
### Standard Activity Format
|
|
35
|
-
Each activity contains:
|
|
36
|
-
- **README.md**: Activity definition, goals, requirements
|
|
37
|
-
- **progress.md**: Current status, completion tracking
|
|
38
|
-
- **tasks.md**: Detailed task breakdown with priorities
|
|
39
|
-
- **notes.md**: Implementation decisions, technical notes
|
|
40
|
-
|
|
41
|
-
### Activity Metadata
|
|
42
|
-
- **Status**: pending, in_progress, completed, failed
|
|
43
|
-
- **Progress**: Percentage completion (0-100%)
|
|
44
|
-
- **Category**: Type of activity (refactoring, feature, analysis, etc.)
|
|
45
|
-
- **Priority**: Task importance (high, medium, low)
|
|
46
|
-
|
|
47
|
-
## Activity Types and Use Cases
|
|
48
|
-
|
|
49
|
-
### Development Activities
|
|
50
|
-
- **Feature implementation**: Adding new functionality
|
|
51
|
-
- **Refactoring**: Code organization and cleanup
|
|
52
|
-
- **Migration**: Technology or pattern updates
|
|
53
|
-
- **Optimization**: Performance and efficiency improvements
|
|
54
|
-
|
|
55
|
-
### Analysis Activities
|
|
56
|
-
- **Architecture review**: System design evaluation
|
|
57
|
-
- **Code analysis**: Pattern discovery and documentation
|
|
58
|
-
- **Dependency audit**: Library and framework assessment
|
|
59
|
-
- **Security review**: Vulnerability analysis
|
|
60
|
-
|
|
61
|
-
### Maintenance Activities
|
|
62
|
-
- **Documentation updates**: Keeping docs current
|
|
63
|
-
- **Test coverage**: Ensuring adequate testing
|
|
64
|
-
- **Cleanup tasks**: Removing deprecated code
|
|
65
|
-
- **Configuration updates**: Settings and environment management
|
|
66
|
-
|
|
67
|
-
## Progress Tracking
|
|
68
|
-
|
|
69
|
-
### Status Indicators
|
|
70
|
-
- **✅ Completed**: Task finished successfully
|
|
71
|
-
- **🚧 In Progress**: Currently being worked on
|
|
72
|
-
- **⏳ Pending**: Not yet started
|
|
73
|
-
- **❌ Failed**: Encountered blocking issues
|
|
74
|
-
|
|
75
|
-
### Progress Calculation
|
|
76
|
-
Based on task completion percentages from tasks.md:
|
|
77
|
-
- Parse task status indicators
|
|
78
|
-
- Calculate completion ratio
|
|
79
|
-
- Update overall activity progress
|
|
80
|
-
- Track progress over time
|
|
81
|
-
|
|
82
|
-
### Completion Criteria
|
|
83
|
-
Activities are considered complete when:
|
|
84
|
-
- All defined tasks are finished
|
|
85
|
-
- Success criteria are met
|
|
86
|
-
- Documentation is updated
|
|
87
|
-
- Results are validated
|
|
88
|
-
|
|
89
|
-
## Agent Integration
|
|
90
|
-
|
|
91
|
-
### Activity-Driven Development
|
|
92
|
-
Agents can use activities to:
|
|
93
|
-
- **Structure complex work**: Break down large tasks into manageable pieces
|
|
94
|
-
- **Track progress**: Monitor completion status and identify blockers
|
|
95
|
-
- **Coordinate effort**: Understand what work is planned vs in progress
|
|
96
|
-
- **Learn from context**: Use existing activities as templates
|
|
97
|
-
|
|
98
|
-
### Activity Creation Process
|
|
99
|
-
1. **Define goals**: Clear objectives and success criteria
|
|
100
|
-
2. **Break down tasks**: Specific, actionable work items
|
|
101
|
-
3. **Estimate effort**: Time and complexity assessments
|
|
102
|
-
4. **Track progress**: Regular status updates and milestone tracking
|
|
103
|
-
5. **Document results**: Lessons learned and outcomes
|
|
104
|
-
|
|
105
|
-
### Progress Monitoring
|
|
106
|
-
- **Real-time updates**: Activity status reflects current work
|
|
107
|
-
- **Milestone tracking**: Key progress points and deliverables
|
|
108
|
-
- **Blocker identification**: Issues preventing progress
|
|
109
|
-
- **Completion validation**: Ensuring work meets requirements
|
|
110
|
-
|
|
111
|
-
## Integration with Other Systems
|
|
112
|
-
|
|
113
|
-
### Vector Search + Activities
|
|
114
|
-
- Use vector search to find activity-related code
|
|
115
|
-
- Reference activities in code discovery and explanation
|
|
116
|
-
- Connect implementation work to activity goals
|
|
117
|
-
|
|
118
|
-
### Bundle System + Activities
|
|
119
|
-
- Scope activities by bundle boundaries
|
|
120
|
-
- Use bundle organization to plan activity tasks
|
|
121
|
-
- Track activity impact across bundle boundaries
|
|
122
|
-
|
|
123
|
-
## Performance Characteristics
|
|
124
|
-
|
|
125
|
-
### Speed
|
|
126
|
-
- **Activity listing**: ~30ms
|
|
127
|
-
- **Activity details**: ~50ms (includes file contents)
|
|
128
|
-
- **Token efficiency**: High (structured, relevant content)
|
|
129
|
-
|
|
130
|
-
### Use Cases
|
|
131
|
-
- **Project planning**: Understanding planned and ongoing work
|
|
132
|
-
- **Context switching**: Quickly understanding current development state
|
|
133
|
-
- **Progress reporting**: Communicating status to stakeholders
|
|
134
|
-
- **Knowledge transfer**: Sharing implementation context and decisions
|
|
135
|
-
|
|
136
|
-
## Best Practices
|
|
137
|
-
|
|
138
|
-
### Activity-Aware Assistance
|
|
139
|
-
- **Check activity context** when helping with development tasks
|
|
140
|
-
- **Reference related activities** when explaining code or suggesting changes
|
|
141
|
-
- **Respect activity boundaries** and existing work in progress
|
|
142
|
-
- **Contribute to activity documentation** when making related changes
|
|
143
|
-
|
|
144
|
-
### Integration Patterns
|
|
145
|
-
- **Planning**: Activities → Bundle scope → Vector search → Implementation
|
|
146
|
-
- **Execution**: Activity tasks → Code discovery → Implementation → Progress update
|
|
147
|
-
- **Review**: Activity completion → Validation → Documentation → Lessons learned
|