How this skill is triggered — by the user, by Claude, or both
Slash command
/syntek-dev-suite:global-workflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Last Updated**: 29/12/2025
Last Updated: 29/12/2025 Version: 1.3.1 Maintained By: Development Team Language: British English (en_GB) Timezone: Europe/London
Every agent must complete this step before referencing any plugin file — example files, templates, or any path under the syntek-dev-suite installation.
The plugin may be installed at any path (local clone, SSH mount, ~/.claude/plugins/, or a custom location). Never assume a fixed path.
Search for plugins/project-tool.py using the Glob tool in this order:
~/.claude/plugins/syntek-dev-suite/plugins/project-tool.py~/.claude/plugins/**/plugins/project-tool.py~/Repos/**/syntek-dev-suite/plugins/project-tool.py~/**/syntek-dev-suite/plugins/project-tool.pyOnce found, derive SYNTEK_DIR as the directory two levels above project-tool.py — that is, the syntek-dev-suite root containing plugins/, examples/, templates/, and config.json.
Use $SYNTEK_DIR as the base for all plugin file references throughout the agent's work:
$SYNTEK_DIR/examples/authentication/PASSWORD-VALIDATION.md
$SYNTEK_DIR/examples/setup/CODING-PRINCIPLES.md
$SYNTEK_DIR/templates/tall-project.md
If the plugin cannot be found at any of those locations, ask the user:
Could not locate the syntek-dev-suite plugin directory.
Please confirm the plugin is installed and provide the path, or run:
find ~ -name "project-tool.py" -path "*/syntek-dev-suite/*" 2>/dev/null
| Setting | Value |
|---|---|
| Locale | British English (en-GB) |
| Spelling | Use 's' not 'z' (optimise, organise, behaviour) |
| Vocabulary | postcode, CV, holiday, mobile |
| Currency | GBP (£) with format £1,234.56 |
| Date Format | DD/MM/YYYY |
| Time Format | 24-hour clock (HH:MM) |
| Timezone | Europe/London |
Code Syntax Exception: Keep US English for reserved words (CSS color, PHP function), but use GB English for variable names ($colourPalette) and user-facing copy.
CRITICAL: All developers MUST clone repositories using SSH, not HTTPS.
# CORRECT - Use SSH
git clone [email protected]:organisation/repository.git
# INCORRECT - Do NOT use HTTPS
git clone https://github.com/organisation/repository.git
Why SSH:
Generate SSH key (if not already done):
ssh-keygen -t ed25519 -C "[email protected]"
Add SSH key to ssh-agent:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Add public key to GitHub:
cat ~/.ssh/id_ed25519.pubTest connection:
ssh -T [email protected]
If a repository was cloned with HTTPS, convert it:
git remote set-url origin [email protected]:organisation/repository.git
Every project MUST have these protected branches:
| Branch | Purpose | Protected | Deploy Target |
|---|---|---|---|
main or master | Production-ready code | Yes | Production |
staging | Client review and acceptance | Yes | Staging |
dev | Integration and final testing | Yes | Development |
testing | QA and automated testing | Yes | Testing |
All feature work uses user story branches:
us<number>/<short-description>
Examples:
us001/user-authenticationus015/payment-integrationus042/api-rate-limitingRules:
For critical production fixes:
hotfix/<issue-number>-<short-description>
Examples:
hotfix/123-login-crashhotfix/456-payment-timeoutus###/feature → testing → dev → staging → main
| From | To | Condition | On Rejection |
|---|---|---|---|
us###/feature | testing | Developer tests pass | Fix in feature branch |
testing | dev | QA tests pass | Fix and re-submit |
dev | staging | Integration tests pass | Fix and re-submit |
staging | main | Client accepts | Back to us###/feature |
<type>(<scope>): <Description> - <Summarise>
<Body - What was changed and why>
Files Changed:
- <app-name/folder/file>
Still to do:
- <Task 1>
- <Task 2>
Version: <old-version> → <new-version>
| Type | Use For |
|---|---|
feat | New feature |
fix | Bug fix |
docs | Documentation only |
style | Formatting, no logic change |
refactor | Code restructure, no feature change |
test | Adding/updating tests |
chore | Build, config, dependencies |
CRITICAL: All PR operations MUST use the gh CLI tool for consistency and automation.
# Create PR from current branch to testing
gh pr create --base testing --title "[US001] feat(auth): Add login" --body "..."
# Create PR with template
gh pr create --base testing --title "[US001] feat(auth): Add login" --body-file .github/PULL_REQUEST_TEMPLATE.md
# List open PRs
gh pr list
# View PR details
gh pr view <number>
# View PR diff
gh pr diff <number>
# Add review comment
gh pr review <number> --comment --body "Comment text"
# Approve PR
gh pr review <number> --approve --body "Approved: All tests pass"
# Request changes
gh pr review <number> --request-changes --body "Needs fixes: ..."
# Merge PR (after approval)
gh pr merge <number> --merge
# Close PR without merging (rejected)
gh pr close <number> --comment "Rejected: Reason..."
# Reopen PR
gh pr reopen <number>
# Check PR status
gh pr status
[<branch-type>] <type>(<scope>): <Description>
Examples:
[US001] feat(auth): Add user login functionality[HOTFIX] fix(payment): Resolve checkout timeout[TESTING→DEV] feat(auth): User authentication module## Summary
- <Bullet point 1: What this PR does>
- <Bullet point 2: Key changes>
- <Bullet point 3: Any notable decisions>
## Changes
### Added
- <New feature or file>
### Changed
- <Modified functionality>
### Fixed
- <Bug fix>
## Version
**Previous:** `X.Y.Z`
**New:** `X.Y.Z`
**Increment Type:** MAJOR | MINOR | PATCH
## Commits Included
| Commit | Type | Description |
| ------ | ---- | ------------------ |
| abc123 | feat | Add login form |
| def456 | fix | Correct validation |
## Test Plan
- [ ] <How to test change 1>
- [ ] <How to test change 2>
- [ ] Unit tests pass
- [ ] Integration tests pass
## Checklist
- [ ] Code follows project style guide
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] CHANGELOG.md updated
- [ ] Version files updated
- [ ] No secrets or credentials in code
## Related Issues
Closes #<issue-number>
# Approve and merge to main
gh pr review <number> --approve --body "Client accepted: Ready for production"
gh pr merge <number> --merge
# Request changes with rejection reason
gh pr review <number> --request-changes --body "Client rejected: <detailed reason>"
# Close the PR
gh pr close <number> --comment "Rejected by client. Creating fix branch from original US branch."
After rejection:
us###/featuretesting → dev → stagingMAJOR.MINOR.PATCH
| Type | When to Increment | Example |
|---|---|---|
| MAJOR | Breaking changes | 1.0.0 → 2.0.0 |
| MINOR | New features (backwards compatible) | 1.0.0 → 1.1.0 |
| PATCH | Bug fixes (backwards compatible) | 1.0.0 → 1.0.1 |
CRITICAL: Before EVERY commit:
| Standard | Value |
|---|---|
| Format | Markdown (*.md) |
| Location | docs/ folder |
| Filenames | CAPITALISED with lowercase .md extension |
| Required | Table of Contents in all docs |
| Extension | Markdown All in One (yzhang.markdown-all-in-one) |
When generating markdown documentation, follow these standards for compatibility with the Markdown All in One extension:
- marker## Table of Contents[Text](#heading-slug)Example:
## Table of Contents
- [Main Title](#main-title)
- [Table of Contents](#table-of-contents)
- [Section 1](#section-1)
- [Subsection 1.1](#subsection-11)
| Format | Syntax | Example |
|---|---|---|
| Bold | **text** | **important** |
| Italic | *text* | *emphasise* |
~~text~~ | ~~deprecated~~ | |
Inline code | `code` | `function()` |
Unordered Lists:
- marker consistently- Item 1
- Nested item 1.1
- Nested item 1.2
- Item 2
Ordered Lists:
1. marker for all items (auto-renumbering)1. First step
1. Sub-step 1.1
1. Sub-step 1.2
1. Second step
Task Lists:
- [ ] for incomplete, - [x] for complete- [ ] Task to do
- [x] Completed task
Use GitHub Flavoured Markdown table syntax:
| Column 1 | Column 2 | Column 3 |
| -------- | -------- | -------- |
| Value 1 | Value 2 | Value 3 |
Alignment:
|:---------||:--------:||---------:|Fenced Code Blocks: Always specify language for syntax highlighting:
\`\`\`typescript
const example = "code";
\`\`\`
Common Languages:
python, typescript, javascript, bash, json, sql, php, dart, html, css
Hierarchy:
# Title - Document title (once per file)## Section - Main sections### Subsection - Subsections#### and beyond - As needed (avoid excessive nesting)Excluding from TOC:
Add <!-- omit in toc --> to exclude heading:
## Internal Notes <!-- omit in toc -->
Use --- for horizontal rules between major sections.
**bold** not __bold__)CRITICAL: All bug fixes (on user story branches or hotfix branches) MUST be documented in docs/BUGS/.
See the /debug agent for the required documentation format. Bug documentation MUST include:
All agents writing code MUST follow these documentation rules:
Every file MUST have a header comment explaining its purpose.
Every public function/method MUST have a docstring with:
CRITICAL: Never use pronouns referring to code in comments.
| Do | Don't |
|---|---|
The function validates input | It validates the input |
Returns the user object | Returns this |
The service handles authentication | We handle auth here |
npx claudepluginhub syntek-dev/syntek-dev-suite --plugin syntek-dev-suiteProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.