workflow-generic-project
Skill19 starsChanged 2 months agoMITView on GitHub
WHAT — Generic client delivery: Jira or ClickUp, full repo context, human gates, English
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 17
Use this skill for client delivery phases and gates.
- Distinctive: line 18
If the task is in a specific client/account context, load the corresponding workspace pack overlay first.
- Distinctive: line 19
If unclear → ask which engagement context to use before proceeding.
- Distinctive: line 40
Do not paste forge or ticket CLI sequences here.
- Distinctive: line 45
Repo standards: Follow AGENTS.md, CONTRIBUTING, PR templates, and documented Docker or devcontainer flows.
- Distinctive: line 48
Traceability: Add concise English comments on the original ticket for plan approval, meaningful milestones, and PR link—no duplicate full …
- Distinctive: line 55
Plan traceability: After plan approval, post a short ticket comment (delegate comment mechanism to clickup-cli, jira-* or confluence-* as …
- Very specific: line 62
Prefer <short-username>/<WORK_ITEM_ID>-<short-slug> (lowercase).
- Distinctive: line 66
If the user requests local-only work: skip push/PR automation.
- Distinctive: line 70
Never commit secrets; no force-push to shared defaults unless the user explicitly requests recovery steps.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Workflow — Generic Project (WHAT)
All skill instructions, ticket comments, and PR text must be in English.
This workflow supports client delivery phases and gates. Apply any client/account constraints by loading the appropriate workspace pack first.
Mode selection (mandatory)
- Use this skill for client delivery phases and gates.
- If the task is in a specific client/account context, load the corresponding workspace pack overlay first.
- If unclear → ask which engagement context to use before proceeding.
Delegation (HOW lives in tool skills)
| Need | Delegate to |
| ClickUp tasks, comments, status | clickup-cli |
| Jira issue ops, comments, dev links | External jira-* skills (e.g. via jira-assistant router; CLI: jira-as) per repo docs |
| Confluence pages, search | External confluence-* skills (e.g. via confluence-assistant router; CLI: confluence-as) per repo docs |
| Planning and estimation | planning |
| Default development workflow / validation fallback | development-workflow |
| Work item structure and templates | work-item, epic, user-story, task, bug, incident |
| Meetings, decisions, agreements, spikes | meeting-minutes, decision-log, agreement, spike |
| Project assessments, evidence maps, technical/management unit scorecards | project-assessment, project-assessment-evidence, technical-unit-assessment, management-unit-assessment |
| PRD / TRD / ADR structure (templates) | prd, trd, adr (WHAT; see local template references inside each skill) |
| Where to save a deliverable + human review | output-handshake (WHAT; always before final deliverables and PR/MR text) |
| Default PR body when the repo has no template | pr-fallback (WHAT) then github-cli-workflow (HOW) |
| Draft PR on GitHub after push | github-cli-workflow |
| Draft MR on GitLab after push | gitlab-cli-workflow |
| Repository discovery and conflicts | assistant |
Do not paste forge or ticket CLI sequences here; open the tool skill and follow it.
Principles
- Context: Pull Jira, ClickUp, Confluence, and linked docs the task references; treat them as source of truth with the codebase (assistant inspection order).
- Repo standards: Follow
AGENTS.md, CONTRIBUTING, PR templates, and documented Docker or devcontainer flows. - Human in the loop: Confirm understanding and plan before substantial implementation; get explicit approval before finalizing PR text; escalate when context is missing.
- Validation first: Align on acceptance criteria and approach before deep implementation.
- Traceability: Add concise English comments on the original ticket for plan approval, meaningful milestones, and PR link—no duplicate full PR bodies in tickets.
Phases (gates)
- Intake: Identify ticket IDs and engagement context; retrieve linked docs via appropriate skills.
- Discovery: Analyze repo per assistant; note CI, templates, dev environments.
- Plan: Written plan → stop for user approval. No implementation until approved.
- Plan traceability: After plan approval, post a short ticket comment (delegate comment mechanism to clickup-cli, jira-* or confluence-* as applicable).
- Implement: Work in logical commits per repo conventions; self-review.
- Push and draft PR/MR: Push branch, then invoke github-cli-workflow or gitlab-cli-workflow for a draft; confirm title/body with the user.
- Close loop: Post final short ticket comment with PR link (via same ticket skills as above).
Branch naming (intent)
Prefer <short-username>/<WORK_ITEM_ID>-<short-slug> (lowercase). Resolve username per repo or user preference; base branch per repo default (main, develop, etc.).
Session override
If the user requests local-only work: skip push/PR automation; note limitations in ticket updates if still posting.
Safety
- Never commit secrets; no force-push to shared defaults unless the user explicitly requests recovery steps.
Checklist
- Engagement context (if any) confirmed
- Work item + doc context retrieved
- Plan approved before code; ticket comment after plan approval
- Repo standards (template, devcontainer) respected
- Draft PR/MR via github-cli-workflow or gitlab-cli-workflow (or documented fallback)
- Final traceability comment with PR link when applicable
In this repository106 other files it gives its agents.
- AGENTS.mdAGENTS.md
- reviewSkill
- mcp-auditSkill
- owasp-agentic-reviewSkill
- supply-chain-auditSkill
- threat-modelingSkill
- architecture-diagramSkill
- c4-modelSkill
- aws-well-architected-reviewSkill
- cloud-design-patternsSkill
- assistantSkill
- dev-companionSkill
- onboardingSkill
- output-handshakeSkill
- pr-fallbackSkill
- projectSkill
- workspace-knowledge-syncSkill
- workspaceSkill
- dbt-validationSkill
- snowflake-validationSkill
- adrSkill
- agreementSkill
- bugSkill
- decision-logSkill
- development-workflowSkill
- epicSkill
- incidentSkill
- management-unit-assessmentSkill
- meeting-minutesSkill
- planningSkill
- prdSkill
- project-assessment-evidenceSkill
- project-assessmentSkill
- spikeSkill
- taskSkill
- technical-unit-assessmentSkill
- trdSkill
- user-storySkill
- workflow-client-bootstrapSkill
- work-itemSkill
- bragSkill
- brag-slimSkill
- design-assessmentSkill
- design-improvementSkill
- figma-code-connect-componentsSkill
- figma-create-design-system-rulesSkill
- figma-create-new-fileSkill
- figma-implement-designSkill
- figmaSkill
- frontend-design-reviewSkill
- frontend-designSkill
- scroll-worldSkill
- web-design-guidelinesSkill
- fix-merge-conflictsSkill
- gh-address-commentsSkill
- gh-contribution-plannerSkill
- gh-fix-ciSkill
- github-cli-workflowSkill
- gitlab-cli-workflowSkill
- worktreeSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.