SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsproject_management

project_management

Office & productivity

View repository

Updated 10-15 17:31

About this skill

Skill - Project Management

This skill provides a set of general project management specifications and workflows, designed to ensure that projects are carried out efficiently and in a standardized manner, covering the entire process from project initialization, requirements management, development, and testing to deployment.

Keywords: project management, tasks, requirements, documents, TODO, backlog, workshops

1.1. When to use this skill

If the project charter (AGENTS.md) or user instructions require it, this Skill should be used at any time. Specific situations 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 organizing the project structure or creating new documents; etc.

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 needs:

  • If the project charter (AGENTS.md) mentions something like 覆盖 project_management 的 ... 部分, then in the corresponding section, the project-specific description and specifications should be used first.
  • If the user requests overriding the description of this Skill, please confirm the user's intent and write it into the project charter according to the explicit description 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

/                              # 仓库根目录
├── .git/
├── workshops/                   # 所有仓库包含的开发项目所在地
│   └── <project-name>/            # 单个项目目录
│       ├── AGENTS.md              # 单个项目的章程
│       ├── TODO.md                # 单个项目特定的任务列表
│       ├── docs/                  # 单个项目特定的文档
│       │   ├── requirements/        # 单个项目的需求文档列表
│       │   └── specs/               # 单个项目的整体设计文档
│       └── src/                   # 项目源代码
├── skills/                      # 仓库特定 Skill
│   └── ...
├── local-inbox/                 # 「收件箱」目录，用于用户提供文件
├── AGENTS.md                    # 仓库的章程
├── GEMINI.md                    # AGENTS.md 的符号链接（别名）
├── README.md                    # AGENTS.md 的符号链接（别名）
├── TODO.md                      # 全局的、跨项目的任务列表
├── .gitignore
└── ...

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

2.2. How to use the "Inbox"

If the user needs to pass non-text files, images, or multiple files to the assistant, the user will place the files in an agreed "Inbox" directory (default local-inbox/）。

The assistant needs to regularly check whether this directory has new files, rename the files according to the file contents, user instructions, and documents, and move them to an appropriate archive location (for example docs/specs/ or docs/requirements/）。

3. Requirements and task management

3.1. Document management

When creating any requirements, design, or other types of documents, the following specifications must be followed:

  1. Determine the location: Determine the target document location according to this Skill and the project charter file;
  2. Get the timestamp: mustfirst run the date +'%Y-%m-%d-%H-%M' command to get the current time;
  3. Name the file: The file name must be in the format YYYY-MM-DD-HH-mm-{文档名称}.md , to facilitate sorting and retrieval by time;
  4. Update TODO: After creating the document, a reference link to the document should be added in the corresponding TODO.md task.

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

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

3.2. Task tracking management

In order to track and continuously advance the collaboration between the user and the assistant, all tasks proposed by the user must

  1. be recorded in the corresponding TODO.md file for tracking;
  2. set the TODO.md entries link to more detailed documentation;
  3. According to the task requirements, write the corresponding requirements, defect, and Spec documents. Even if the assistant itself has todo type tools, it must still follow the above specifications.

You can obtain the TODO.md template from other Skills. When using it, please ensure the following key elements are included:

  • Status: Tasks should be placed in one of the following lists according to their lifecycle stage:进行中 (In Progress), 待办 (TODO), 阻塞 (Blocked), 已完成 (Done), 已搁置 (On Hold)。
  • Task Unit:
    • Task: A macro-level goal, usually needs to be broken down into smaller "development items" before it can be executed.
    • Development Item: A specific, directly executable unit of work.
  • Attributes: Each task or development item should include 创建日期 and 优先级 (High, Medium, Low)。)

3.3. Product Specification Management

All product specifications should be recorded in the project directory's docs/specs/ directory. This helps maintain clear, versioned functional documentation.

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

4. Development Verification and Testing

This Skill describes the general development process. For a more detailed process, refer to the specific description in the project charter (AGENTS.md), as well as other Skills mentioned.

4.1. TDD Mode Development Process

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

The general order is as follows:

  1. Ensure the charter, Spec documents, and requirements documents are complete;
  2. commit changes (documentation changes);
  3. Write test cases and documentation covering expected functionality and edge cases;
  4. Perform development, run tests, and ensure all tests pass, including newly written tests;
  5. Update Spec, requirements, and test documentation (if necessary);
  6. commit changes (code and documentation changes).

4.2. Git Branching and Deployment Process

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

Branching Strategy:

  • main: Main branch, always kept deployable; master can also be used as the name.
  • dev: Development branch, used to integrate various features.
  • feat/{feat_name}: Branch for a specific feature.
  • fix/{bug_name}: Defect fix branch.

Commit Message Convention:

  • feat: ... (new feature)
  • fix: ... (defect fix)
  • docs: ... (documentation changes)
  • test: ... (test-related)
  • refactor: ... (code refactoring)
  • chore: ... (build, tools, etc.)

5. General Requirements

5.1. Understanding Context

Before performing any operation, you must first determine whether it is at thegloballevel or at theprojectlevel.

  1. Check user instructions:

    • If the instruction explicitly mentions a project name (for example, "in the my-project project..."), then enter the project-level workflow.
    • If the instruction is vague or involves multiple projects (for example, "what high-priority tasks are there?"), then prioritize starting the analysis fromglobal TODO.md .

  2. 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. Private Key and Token Management (Secrets Management)

Core principle: It is strictly prohibited to include or push any keys, Tokens, passwords, or example files containing such information into the Git repository.

  • Key files: All keys used for local development should be stored in the .secrets file in the project root directory, and combined with the technology stack, an appropriate method should be chosen at runtime to load these keys.
  • Version control: .secrets filemustbe added to .gitignore .
  • Example files: You can create a .secrets.example file containing placeholders and explanations for keys for developers' reference, but it absolutely must not contain real key information.

5.3. Best Practices

  • Trust AGENTS.md: The global and each project's AGENTS.md is the "source of truth".
  • Distinguish global from project: Always clearly distinguish whether an operation is at the global level or the project level, and use the corresponding TODO.md。
  • Follow naming conventions: When creating documents, strictly follow the timestamp-prefix naming convention.

5.4. Emoji Usage

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

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

Do not add other Emoji at will.