Total 43,503 skills, Project Management has 1598 skills
Showing 12 of 1598 skills
Trigger: Invoked when the target is long-term, the task is complex, resources are temporarily at a disadvantage, or a quick win cannot be achieved in the short term but the task cannot be abandoned; common signals include long-term effort, phased plan, endurance, strategic patience, and the need for phased advancement. English: Trigger when the work is long-horizon, difficult, and unlikely to be won quickly. Use this skill to divide the effort into stages, keep strategic confidence, and accumulate small wins into overall victory.
Trigger: Call this skill when the task you are facing clearly requires collaboration of multiple ideological tools. Common trigger signals include: starting a new project from scratch, tackling complex and difficult problems, iterating and optimizing existing solutions. This skill provides standardized cross-skill workflow combinations to solve the problem of "which skill to use first and how to connect them". English: Trigger when a task clearly requires multiple skills in sequence. Use this skill to select a standard workflow that chains skills together, defines data handoff between steps, and specifies termination conditions.
Trigger: Invoked when multiple tasks are competing for time, attention, computing power or budget at the same time, and it is necessary to determine the main attack direction and stop dispersing efforts; common signals include too many priorities, tight resources, scattered progress, and the need to decide what to do first. English: Trigger when limited resources are being split across too many tasks and one main target must be chosen. Use this skill to concentrate effort, sequence work decisively, and finish a meaningful breakthrough before expanding.
Transform design documents into TDD-based implementation plans with parallelizable tasks. Triggers: 'plan implementation', 'create tasks from design', or /plan. Enforces the Iron Law: no production code without a failing test first. Requires an existing design document — use /ideate first if none exists. Do NOT use for brainstorming, debugging, or code review.
Feishu Project (Meego/Meegle) operation tool. Supports functions such as querying and managing work items, node workflow, view querying, personal to-dos, and schedule statistics. Use when user needs to work with Feishu/Lark Meego project management — including querying work items, creating/updating work items, completing workflow nodes, checking views, listing todos, analyzing schedules/workloads, or searching with MQL. Keywords: Feishu Project, meego, meegle, work item, requirement, task, defect, schedule, view, to-do, node.
Phase 3 of the feature workflow – Complete the acceptance closed-loop. Four tasks: 1. Check layer by layer against {slug}-design.md to verify if the implementation deviates from the plan; fix any deviations on the spot instead of just "noting them" in the report. 2. Incorporate this feature into the project's overall architecture documentation. 3. If this feature changes the user story or boundaries of the corresponding requirement, update the requirement doc accordingly. 4. If this feature originated from a roadmap item, change the status of the corresponding entry in roadmap items.yaml to done and sync it with the main document. Finally, produce a {slug}-acceptance.md as the closed-loop proof for the entire workflow. Prerequisite: cs-feat-impl is completed. Trigger scenarios: User says "The feature is done, let's accept it", "Do the final check", "Prepare for merge", "Generate the acceptance report".
Document the finalized tech stack selections, architecture decisions, long-term constraints, and coding conventions in the project into searchable permanent records. No one will remember why X was chosen six months later, but with decision documents, at least the background can be understood before making changes next time. Four categories: tech-stack (which tools/libraries/frameworks to use), architecture (how the system is organized), constraint (what is not allowed), convention (what is uniformly done). Trigger scenarios: Proactively trigger after making important choices during feature-design or issue-analyze, or when the user says "record the decision", "archive tech selection", "ADR", "record this constraint", "write down the convention". Only archive finalized decisions; do not archive proposed solutions under discussion.
Phase 1 of the feature workflow — Draft a design document for the new feature, serving as the sole input for subsequent implementation and acceptance. First gather evidence (read architecture docs, review relevant code, grep to prevent term conflicts, check archives), then write a complete first draft in one go (including YAML frontmatter + three-tier structure + test design), submit it to the user for overall review, and iterate until approval. After approval, extract {slug}-checklist.yaml from {slug}-design.md for use in the next two phases. Trigger scenarios: "Start designing the solution", "Write design doc", "Prepare to implement XX", with the prerequisite that you already know what to do, who it's for, and how to define success.
Document the pitfalls encountered or good practices discovered during this work into searchable learning documents, which can be accessed by both AI and humans when similar tasks arise in the future. Two tracks: The pitfall track records experiences where "things should have worked but didn't" — including bugs, configuration traps, environment issues, and integration failures; The knowledge track records findings that "should be the default approach going forward" — including best practices, workflow improvements, and reusable patterns. Trigger scenarios: Proactively prompt at the end of feature-acceptance or issue-fix workflows, or when the user mentions phrases like "document knowledge", "learning", "document learnings", or "record this experience". Spec documents record what was done, while learning documents record what pitfalls were encountered / what was learned — they complement each other and are not interchangeable.
Issue Workflow Stage 1 — Convert the user's problem into a reproducible, traceable {slug}-report.md through conversation. The AI only asks "what you saw, how to reproduce it, what should happen" here, and does not guess the root cause for the user (that's Stage 2's responsibility). Meanwhile, this stage is the only official decision point for choosing between the fast track and standard path: Based on the user's description, first review the relevant code; if the root cause can be identified at a glance and the required changes are minor, directly inform the user to take the fast track. Trigger scenarios: The user says "file an issue", "record this bug", "I found a problem". This is the starting point of the issue workflow with no pre-dependencies.
Phase 3 of the issue workflow —— Fix code precisely according to confirmed root causes and solutions, verify the results, and document it in {slug}-fix-note.md. This is the final stage of the issue workflow —— no verification closure means the workflow is incomplete. Two entry points: the standard path is triggered from cs-issue-analyze (with existing {slug}-analysis.md), and the fast track is triggered directly from cs-issue-report (without {slug}-analysis.md, as the root cause was identified by AI through code reading during the report phase). Trigger scenarios: User says "Start fixing the bug", "Fix according to the analysis", "Start modifying the code". During the fix, only modify the files specified in the solution; do not make incidental optimizations or introduce new abstractions —— these actions will cause the scope to expand to an untraceable extent.
After implementation is complete and tests pass, sync confirmed details back to Intent. Captures finalized interfaces, data structures, naming conventions, and architecture decisions. Use after development is done and user confirms the implementation.