Skill - Project Management

This skill provides a set of universal project management specifications and workflows, designed to ensure projects proceed efficiently and in a standardized manner, covering the entire process from project initialization, requirement management, development, testing to deployment.

Keywords: project management, task, requirement, document, TODO, backlog, workshops

1.1. When to Use This Skill

Use this Skill whenever required by the project charter (

AGENTS.md

) or user instructions. Specific scenarios include but are not limited to:

When the user is managing requirements, tasks, or defects in the project;
When code development, testing, branch management, and deployment operations are needed;
When the user requests to organize the project structure or create new documents; and so on.

1.2. How to Override the Default Description of This Skill

The description of this Skill can be adjusted and overridden according to specific project requirements:

If the project charter (
```
AGENTS.md
```
) mentions something like "Override the ... section of project_management", the project-specific descriptions and specifications should be prioritized in the corresponding section.
If the user requests to override the description of this Skill, confirm the user's intent and write the explicit description in the project charter as "Override the ... section of project_management".

2. Directory Structure and Usage of Special Directories

To ensure project consistency and maintainability, it is recommended to adopt the following standardized Monorepo directory structure in the repository.

2.1. Directory Structure

/                              # Repository root directory
├── .git/
├── workshops/                   # Location of all development projects included in the repository
│   └── <project-name>/            # Single project directory
│       ├── AGENTS.md              # Charter for the single project
│       ├── TODO.md                # Project-specific task list
│       ├── docs/                  # Project-specific documents
│       │   ├── requirements/        # Requirement document list for the single project
│       │   └── specs/               # Overall design documents for the single project
│       └── src/                   # Project source code
├── skills/                      # Repository-specific Skills
│   └── ...
├── local-inbox/                 # "Inbox" directory for users to provide files
├── AGENTS.md                    # Repository charter
├── GEMINI.md                    # Symbolic link (alias) to AGENTS.md
├── README.md                    # Symbolic link (alias) to AGENTS.md
├── TODO.md                      # Global, cross-project task list
├── .gitignore
└── ...

Some repositories may contain only one project. In this case, the directory structure can be simplified, determined by

AGENTS.md

2.2. Usage of the "Inbox" Directory

If the user needs to send non-text files, images, or multiple files to the assistant, the user will place the files in a agreed "Inbox" directory (default

local-inbox/

The assistant needs to regularly check this directory for new files, rename the files based on their content, user instructions, and documents, and move them to the appropriate archive location (such as

docs/specs/

docs/requirements/

3. Requirement and Task Management

3.1. Document Management

When creating any requirement, design, or other type of document, the following specifications must be followed:

Determine Location: Confirm the target document location according to this Skill and the project charter file;
Get Timestamp: Must first run the command
```
date +'%Y-%m-%d-%H-%M'
```
to get the current time;
Name the File: The file name must follow the format
```
YYYY-MM-DD-HH-mm-{document-name}.md
```
to facilitate sorting and retrieval by time;
Update TODO: After creating the document, add a reference link to this document in the corresponding
```
TODO.md
```
task.

Whenever possible, documents should link to their "subordinate" documents to form a clear document hierarchy. For example, the main specification document should link to each functional specification document, requirement documents should link to related design documents, and TODO items should link to corresponding requirement or defect documents.

You can obtain document templates from other Skills to ensure consistency and quality.

3.2. Task Tracking Management

To track and continuously advance collaboration between the user and the assistant, all tasks proposed by the user must:

Be recorded in the corresponding
```
TODO.md
```
file for tracking;
Link entries in
```
TODO.md
```
to more detailed documents;
Write corresponding requirement, defect, and Spec documents according to task requirements. Even if the assistant itself has
```
todo
```
-type tools, the above specifications must be followed.

You can obtain the

TODO.md

template from other Skills. When using it, ensure it includes the following key elements:

Status: Tasks should be placed in one of the following lists according to their lifecycle stage:
```
In Progress
```
,
```
TODO
```
,
```
Blocked
```
,
```
Done
```
,
```
On Hold
```
.
Task Units:
- Task: A macro goal that usually needs to be broken down into smaller "Development Items" for execution.
- Development Item: A specific, directly executable work unit.
Attributes: Each task or development item should include
```
Creation Date
```
and
```
Priority
```
(High, Medium, Low).)

3.3. Product Specification Management

All product specifications should be recorded in the

docs/specs/

directory of the project directory. This helps maintain clear, versioned functional documents.

Main Specification Document: There should be a main specification document (e.g.,
```
main-spec.md
```
) in the
```
docs/specs/
```
directory, providing an overall project overview and linking to detailed specification sub-documents for each feature or component.
Sub-documents: Each major feature or component should have its own independent specification document.
Image Resources: Images related to specification documents (such as design drafts, reference screenshots) should be stored in a directory with the same name as the document.
- Example: Image resources for
```
docs/specs/feature-A.md
```
  should be stored in the
```
docs/specs/feature-A/
```
  directory.
Test Case References: Each specification document must explicitly list and link to related test case documents to ensure a one-to-one correspondence between requirements and acceptance criteria.

4. Development Verification and Testing

This Skill describes a general development process; for more detailed processes, refer to the specific descriptions in the project charter (

AGENTS.md

) and other mentioned Skills.

4.1. TDD Development Workflow

Development should generally follow the Test-Driven Development (TDD) pattern to ensure code quality and functional correctness

The general sequence is as follows:

Ensure the charter, Spec documents, and requirement documents are complete;
Commit changes (document changes);
Write test cases and documents covering expected functions and boundary conditions;
Perform development, run tests, and ensure all tests pass, including newly written tests;
Update Spec, requirement, and test documents if necessary;
Commit changes (code and document changes).

4.2. Git Branch and Deployment Workflow

Unless otherwise agreed, the following Git branching strategy and workflow are recommended:

Branching Strategy:

```
main
```
: Main branch, always in a deployable state;
```
master
```
can also be used as the name.
```
dev
```
: Development branch for integrating various features.
```
feat/{feat_name}
```
: Branch for a specific feature.
```
fix/{bug_name}
```
: Branch for defect fixes.

Commit Message Specifications:

```
feat: ...
```
(New feature)
```
fix: ...
```
(Defect fix)
```
docs: ...
```
(Document changes)
```
test: ...
```
(Testing-related)
```
refactor: ...
```
(Code refactoring)
```
chore: ...
```
(Build, tools, etc.)

5. General Requirements

5.1. Understand Context

Before performing any operation, it is necessary to first determine whether it is at the global level or project level.

Check User Instructions:
- If the instruction explicitly mentions a project name (e.g., "In the
```
my-project
```
  project..."), enter the project-level workflow.
- If the instruction is ambiguous or involves multiple projects (e.g., "What are the high-priority tasks?"), start analysis from the global
  TODO.md
  first.
Read Core Files:
- Global Level: Read the root directory's
```
GEMINI.md
```
  and
```
TODO.md
```
  .
- Project Level: Read
```
workshops/${project_name}/AGENTS.md
```
  and
```
workshops/${project_name}/TODO.md
```
  .
```
AGENTS.md
```
  is the primary source of information for understanding the project's internal structure and key files.)

5.2. Secrets Management (Private Keys and Tokens)

Core Principle: Strictly prohibit including or pushing any keys, tokens, passwords, or sample files containing such information to the Git repository.

Secret Files: All keys used for local development should be stored in the
```
.secrets
```
file in the project root directory, and loaded using an appropriate method at runtime according to the tech stack.
Version Control: The
```
.secrets
```
file must be added to
```
.gitignore
```
.
Sample Files: You can create a
```
.secrets.example
```
file containing placeholders and instructions for keys for developers' reference, but must never contain real key information.

5.3. Best Practices

Trust
AGENTS.md
: The global and project-specific
```
AGENTS.md
```
files are the "source of truth".
Distinguish Global vs. Project: Always clearly distinguish whether operations are at the global level or project level, and use the corresponding
```
TODO.md
```
.
Follow Naming Specifications: Strictly follow the timestamp prefix naming specification when creating documents.

5.4. Emoji Usage

The user and assistant agree that the following Emojis can be used in documents to mark key information:

🟩: Indicates completed, passed, successful.
🟥: Indicates to-do, problematic, incomplete, requiring attention.

Do not add other Emojis arbitrarily.

project_management

NPX Install

Tags

SKILL.md Content (Chinese)